Re: 64 bit official Windows builds

[Eli Zaretskii <eliz@gnu.org>]

> From: Óscar Fuentes <ofv@wanadoo.es>
> Date: Fri, 12 Feb 2016 08:16:37 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> > That thunking is the culprit is my theory, not a fact; however, I
> >> > cannot find any other explanation.  If someone does, I'm all ears.
> >> 
> >> I mentioned some possibilities on a previous message. Did you use the
> >> same toolset and libraries for the 32 and 64 bits build?
> >
> > 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.

> >> The MinGW and MinGW-w64 (32/64 bits) runtimes diverged quite a bit.
> >
> > GNU Find uses only msvcrt.dll, no other runtime libraries are involved
> > in any significant way.
> 
> 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.

And I doubt such a speedup is really possible at all, given the
simplistic implementation of 'stat' in msvcrt -- you cannot do less,
really.

> 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.

> 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.

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.