[erlang-questions] Erlang performance on Windows
Mon Nov 24 08:38:24 CET 2008
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.
More information about the erlang-questions