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

In article <45c2f4ab$1@xxxxxxxxxxxxxxxxxxxxxx>, Florian Klaempfl says...

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:

Well pardon me for pointing out that 1.5 x <> a "doubling".

And isn't it also the case that FPC will be using dfferent "back-ends"
for 32-bit and 64-bit code generation? i.e. I suspect that you aren't
comparing like for like.

To compare the 64-bit performance of re-targetted 32-bit code shouldn't
you be comparing cross-compilation results? i.e. a 64-bit compiler
producing 32-bit code vs 32-bit compiler producing 32-bit code.

Maybe you'll get end up getting similar results any way, but currently I
don't believe those results support the conclusion you are drawing from
them.


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

Maybe using results from _appropriate_ tests with sound bases for
comparison is more important than doing my own inappropriate tests?


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

Link?

Google is your friend.


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.

True, but the CPU has to switch in-out of 32-bit compatability mode
every time it needs to execute 32-bit code, which from the vast numbers
of benchmarking results publicly available (see: Google) would seem to
offset much, if not all, of the benefit in this area.

Hint: Avoid anything which looks like an advert and focus on independent
benchmarking test results. Theses are widely available and reasily
recognised - you certainly don't need me to do the legwork to find them
for you.


2. Integer have the same size (32 bit) on Win64.

That really rather depends on the size of the integer - notice that I
didn't capitalise. From the usage I thought it was pretty clear that I
meant specifically the integer type native to the processor.


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

See above.

I did - your own figures contradict the conclusion the drew from them.


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

If/when passed as parameters to procedures - yes. Just as with all
other data.

Perhaps you aren't aware that the Delphi compiler (to name just one
relevant example) makes extensive use of register optimizations -
parameters are passed in registers where-ever possible.


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.

The size of a (32-bit) integer doesn't change either - you said it
yourself. So I still don't see how you conclude that memory footprint
issues benefit FPU-intensive apps any more than integer-intensive apps.


--
Jolyon Smith
Say, do any of you guys know how to Madison?
.

Relevant Pages

  • Re: Pedants
    ... However Jacob publishes only his binaries. ... I would be interested to see what you think you are comparing against ... were compiled by the same compiler program and with identical compiler ... PUSH ...
    (comp.lang.c)
  • Re: Detecting WIN32 or .NET example in a compiler directive
    ... WriteLn('Welcome to the WIN32 world!'); ... there's no reason for the compiler directives ... Delphi for Win32 ...
    (alt.comp.lang.borland-delphi)
  • Re: The New Roadmap
    ... C# and Chrome don't have these issues because they don't have Win32 ... between different versions of the compiler and in both Win32 and .Net ... The question was "What's better in Delphi for .NET than C# or Chrome?", ... Forward migration of WinForms projects works ...
    (borland.public.delphi.non-technical)
  • Re: Can Someone Change My Mind About .NET?
    ... >> Win32 is not going away with LH. ... > the compiler that optimizes it for the current known processors. ... > If you do not recompile the .NET applcation and conventional program, ... > laid out in a certain memory order at the moment you compiled and linked. ...
    (microsoft.public.dotnet.general)
  • Re: Processing workload distribution
    ... underlying Win32 system calls still work the same way: ... There are no Win64 results from CPAN Testers, ... You need to use *exactly* the same compiler; ... Activestate provided with this build that Win32::process is available, ...
    (comp.lang.perl.misc)
Loading