[erlang-questions] Erlang performance on Windows

[Mikael Pettersson]

Benjamin Tolputt writes:
 > Mikael Pettersson wrote:
 > > Using autoconf or not is not my call, but the problems I had
 > > trying to build the system in cygwin with a cross-compiler to
 > > mingw had to do with various non-standard special case hacks
 > > the otp team has put in the configure files.
 > >   
 > 
 > While I can't comment too much on the good/bad of the make system used
 > for Erlang; it was my impression that at least one of the special cases
 > was to use the Microsoft compiler (rather than gcc) for the compilation.
 > I remember reading (either in the README or this list) that the speed
 > difference between compiling with gcc & compiling with msvc is really
 > noticeable - with the exception of one file where the gcc "address of
 > label" extension helped speed up what would otherwise be a (very) large
 > switch statement.
 > 
 > While I've not compiled Erlang with gcc, I can attest to the fact that
 > msvc tends to optimise code somewhat better than gcc (at least as far as
 > the Win32 platform is concerned).

gcc evolves. I doubt those comparisons were made using modern gcc-4.x
versions. Besides, the ISO C99 issue is a strong argument for gcc in
my book. (I think Intel's compiler also supports C99, but it isn't free.)

 > > The first thing I'll do on the Windows port is to make it possible
 > > to build the system with cygwin+mingw in a clean way. Once that's
 > > done a HiPE port should be easy.
 > >   
 > 
 > It was my impression from the technical discussions (RE: HiPE on Win32)
 > that the problem was not one of difficulty but one of whether it was
 > advisable to use a certain feature of windows relating to stacks &
 > exception handling. Has this been resolved in a positive fashion (i.e.
 > we're happy with the issue being negligible and/or have a different method)?

The sigaltstack() issue still exists and is now known to be unsolvable
(can't emulate the effect).  Instead I'll go with the workaround of
adding a page's worth of slack space at the bottom of the native stacks,
and possibly also an inaccessible guard page. This makes native threads
less light-weight, but so be it.

Another issue probably not mentioned before is HiPE's desire to have the
system enable floating-point exceptions as that improves the performance
of floating-point code in Erlang and simplifies the compiler. The mechanisms
for enabling FPEs are highly system-dependent, but I've recently worked
out how to do that on Win32/x86, so that's no longer an obstacle.

/Mikael