Re: What does 32 bit application mean?

Marco van de Voort <marcov@stack.nl> writes:


> [No, on an AMD64 a process is either in long mode that has the extra
> registers and address modes and 64 bit addresses, or in compatibility
> more which is just like ia86 protected mode. You can't mix and match.


You could in theory (either by defining additional code segments for
compat mode) or defining a new code model in long mode that uses 32bit
pointers. However that would require a third set of shared libraries
for everything , which probably nobody wants.


The main use case for it is probably JIT compilers where the JIT could
run 64bit, but execute 32bit code. Unfortunately there are still some
issues with this model, in particular compatibilility with kernels and
external libraries.


> The comments I've seen say that the code savings from the extra
> registers and IP-relative addressing about cancel out the code bloat
> from the bigger pointers, but 64 bit apps still run slower because the
> tools are less mature and so much code has been heavily optimized to
> run fast on x86. -John]


To inject some hard data for gcc into this "unnamed sources"
discussion see page 92+ in
http://zenii.linux.org.uk/~ajh/gcc/gccsummit-2003-proceedings.pdf


It does not agree at all. e.g. as a real world test KDE startup (a
very complex C++ application) is around 18% faster on a older machine
and a gimp compilation around 20%


For not so real world tests SpecCPU also benefits significantly in
most tests (except for a minority of subtests which are pointer bound)


The memory usage seems to be up a bit, but also performance is.


On Microsoft the results might be a bit different because they use
completely different ABIs.


Sometimes you see regressions when inline assembly optimizations
haven't been ported (iirc on Microsoft the new AMD64 compiler doesn't
even support inline assembly anymore). This is also a smaller problem
on Linux. Fortunately in practice a lot of the "optimized" inline
assembly tends to be actually tuned for ancient CPUs and the compiler
can do better on its own when generating code for a modern x86.


Another factor is that 32bit x86 tend to be optimized for older
CPUs (e.g. no use of SSE2), while 64bit can assume a modern system
which allows more efficient code in many cases.


From my own experience on Linux I also cannot confirm the less mature
toolkits claim.


-Andi
[I've been trying FreeBSD on my amd64, and the sentiment on the FreeBSD
list was what I said. If other people believe that the amd64 toolchain
is as mature as the ia36, great, but it doesn't match what I see. -John]

Return to the comp.compilers page.
Search the comp.compilers archives again.