Re: 64 bit official Windows builds

["Óscar Fuentes" <ofv@wanadoo.es>]

Eli Zaretskii <eliz@gnu.org> writes:

>> > No.  The program was compiled by mingw.org's MinGW for 32 bits and by
>> > MinGW64 for 64 bits.
>> 
>> There you have a strong candidate for explaining the difference. That
>> probably also means that they were different compiler versions.
>
> I find it hard to believe that compiler version differences can
> explain a factor of two.  It contradicts every bit of my experience
> with GCC over the last 30 years.

You missed the "also". The compiler version can have a dramatic impact
on some cases (it is quite common to find 10x differences on some
microbenchmarks) but I'm more prone to point fingers to what is around
of the compiler, something that I hinted on my previous message.

>> As you know, there are other code pieces that are linked into the
>> executable besides the C runtime (which MinGW(-w64) supersede by
>> providing their implementations for certain functions, plus other
>> features missing from msvcrt.dll). IIRC some *stat functions are very
>> slow on Mingw, maybe the MinGW-w64 guys introduced improvements, just a
>> guess.
>
> Not according to the current MinGW64's Git repository.  They basically
> simply call the msvcrt _stat.

Okay, let's scratch that hypothesis then.

>> Why don't you build both 32 and 64 bits executables of GNU Find with
>> MinGW-w64 (same toolset version) for comparing its performance?
>
> Sorry, I don't have time for that.  But anyone who is interested can
> do this experiment, the sources (and the binaries) are on the
> ezwinports site.  FWIW, I'd be very glad to hear that my measurements
> were some fluke and should be disregarded.

Maybe I'll try the comparision, but at the moment I only have virtual
machines with Windows 64 bits and those are not specially reliable for
performance measurements, although a 2x difference on real metal should
have some impact on the VM too.

>> Not saying that GNU Find will be representative of what you can expect
>> from Emacs. (GNU Find: I/O bound; Emacs: user bound.)
>
> Performance only matters when you do prolonged operations.  One such
> prolonged operation in Emacs is reading a directory in Dired, in which
> case what Emacs does is quite similar to what Find does.  For someone
> who uses Dired extensively, the GNU Find example is not irrelevant.

Are there reports about Dired being slow on Windows 32 bits? Just
curious.

> Memory- and CPU-intensive operations is another matter.  But here,
> too, I'd welcome actual measurements more than theories.  Measurements
> can and do surprise, as is known to anyone who ever profiled a
> real-life program.

I'm glad you think this way. So now we have agreed that the existence of
a dramatic performance gap between 32 and 64 bits Emacs executables and
its cause being API thunking is just a theory of yours based on limited
evidence :-)

My also (limited) evidence is that 64 bit Windows binaries can be a bit
faster than 32 bit ones, and vice-versa. For instance: my experience
building complex C++ code with GCC is that the 32 bit compiler runs a
bit faster than its 64 bit version. For Emacs, I see no difference, it
is responsive on both systems.