Re: 64-bit on the horizon? (Was Re: Vista Requirement Already)


Jolyon Smith <jsmith@xxxxxxxxxxxxxxxxxxxxx> wrote:
In article <45c26c25$1@xxxxxxxxxxxxxxxxxxxxxx>, Florian Klaempfl says...
Jolyon Smith schrieb:
What say you for example on the ridiculous assertion that Win64 apps run
slower than their Win32 counterparts?

Win64 code is very often slower than win32 because the size of the
memory foot print increases.

Do you have sources for that assertion?

Of course, own experiments, e.g. rebuilding of FPC for win32 and win64 using always a native compiler (same machine and setup of course).

i386-win32 on Windows x64
200 22.297/31.488 Kb Used
300 22.371/31.488 Kb Used
200 22.311/31.488 Kb Used
Linking ./pp
199363 lines compiled, 7.3 sec

x86_64-win64 on Windows x64
200 34.172/46.144 Kb Used
300 34.277/46.144 Kb Used
200 34.231/46.144 Kb Used
Linking ./pp
185033 lines compiled, 9.5 sec

Memory usage increased by 1.5, compilation time increased by 1.3 thought the i386 compiler contains more code because it supports more targets. Even worse if you calculate lines/sec:

i386-win32 ~27000 lines/sec
x86_64-win64 ~19500 lines/sec

Both compilers used only the optimizations available for both targets, x86-64 and i386 compiler share then 99% of the code generator.

(I note that in this discussion
every little comment of mine has to be substantiated, but counter-
assertions seemingly have intrinsic truth).

Every (and I do mean _every_) benchmarking exercise that I have seen
comparing 32-bit and 64-bit performance (of NATIVE apps) shows a clear
performance improvement on 64-bit for ALL manner of applications and
benchmarks.

Yes? Maybe you should do your own tests and then continue and don't believe in advertisements.


They also clearly show a performance PENALTY when running Win32 code on
WoW64.

Link?



E.g. TList simply takes twice as much space
on win64 than on win32 and thus causing much more memory traffic which
is one of the biggest bottlenecks of modern CPUs.

AMD64 has on-chip RAM controllers, so memory access is vastly improved.
Improved, it seems, to the extent that it more than compensates for the
fact that pointers and integers are twice as big.

1. 32 Bit applications benefit from this improvements as well so this doesn't matter.
2. Integer have the same size (32 bit) on Win64.


And note that memory footprint is only intrinsically doubled for
"native" data types, e.g. integers and pointers.

i.e. code that allocates 1MB of memory and maintains a pointer to that
memory requires only an additional 4 bytes on 64-bit - the pointer
increases in size, but there is still only 1MB of RAM allocated.

That's not a "doubling of memory footprint" in anybodies book.

See above.


Whilst much of the memory allocated by an app _may_ need to doubled, a
very great deal will also not.


In addition of course, x86-64 processors have more, and bigger, GPR's -
so the _need_ for memory access should be reduced in 64-bt processes (if
you have a 64-bt compiler that can produce code that makes use of those
registers obviously - which is precisely THE POINT!!).

Really? So the data of e.g. TList or whatever is kept in registers ;)?




Win64 makes only sense for:
- fpu intensive applications e.g. a double has the same size on win32
and win64 but the number of registers is twice as much as on win32

I'm not sure why you single out FPU in this point.

.... because the size of FPU data types doesn't change and thus the memory footprint doesn't increase.



aiui the significant improvements in FPU performance on x86-64 are more
directly related to the abandonment of the x87, 80-bit FPU architecture
in favour of a RISC 32/64-bit implementation.

You can get rid of the x87 FPU and use SSE2 in 32 bit mode too.
.

Relevant Pages