[MLton] latest benchmarks

[Jesper Louis Andersen]

I have a 32bit FreeBSD compile ready. Benchmarks to trickle in tomorrow when
I
get it to crunch while at work (It takes a fair amount of time for it to
finish and I don't
want to mess too much with the laptop while it processes the benchmarks).

There are also a few tweaks needed to run on 64-bit FreeBSD. I hope to be
able to
look into them around the 1st of July.

On 6/20/07, Matthew Fluet <fluet at tti-c.org> wrote:
>
> I've merged the x86_64 branch into trunk.  Since the previous
> announcement of the experimental release, there were only two minor bugs
> reported:
>   1) Bug with -align 8 on x86_64
>   2) Inconsistent behavior with -const 'MLton.detectOverflow false'
> These have both been fixed, and I'm pretty happy with the state of the
> x86_64 port.
>
> I ran the benchmark suite to compare the last public release to the
> current trunk.  It is a bit of an apples-to-oranges comparison, since I
> ran the benchmarks on an AMD Opteron (64-bit) system.  So, the 20051205
> compiler (and its resulting executables) are running in 32-bit mode,
> while the trunk compiler (and its resulting executables) are running in
> 64-bit mode.
>
> [BTW, it would be nice if someone could run a corresponding benchmark
> suite on a 32-bit system, for a more apples-to-apples comparison.]
>
> You can see all of the results at:
>
> http://mlton.org/cgi-bin/viewsvn.cgi/*checkout*/mlton/trunk/doc/x86_64-port-notes/bench-20070619.txt?rev=5659
>
> Some of the highlights:
>
> * Benchmarks were run on a uni-core, dual-processor AMD Opteron 2.0GHz,
> 8GB Memory, Fedora Core 6 machine (with gcc version 4.1.1 and linux
> version 2.6.20 (x86_64)).
>
> * compile time and code size is up across the board on trunk vs
> 20051205.  I suspect that part of the code size increase can be
> attributed to the comparison of 32-bit executables to 64-bit
> executables.  Any 64-bit operation requires an additional 8bit
> instruction prefix (as do 32-bit ops that touch the extended register
> set).  Compile time is probably partly explained by the bigger Basis
> Library implementation (increasing elaboration time and carrying more
> code through early optimizations), and partly by the fact that the trunk
> compiler is executing a little slower than the 20051205 compiler.
>
> * recent versions of gcc are doing fairly well with the C code.  (Note
> that using -codegen c with 20051205 uses the version of gcc on the host
> machine.)  Indeed, the flat-array.sml benchmark needs to be revised, as
> gcc recognizes that the inner loop is pure (Overflow exceptions are
> handled within the loop) and unused.  The SSA{,2} optimizer should also
> discover that the loop may be optimized, but that is another issue.
> GCC also does fairly well on the checksum benchmark with 20051205,
> though it does horribly on the checksum benchmark with trunk.
> I suspect that the later behavior is due to the fact that on x86_64,
> sequences (arrays/vectors) are indexed by 64-bit integers in the
> primitive operations (sub, update, etc), but indexed by 32-bit integers
> in the user code (Array.sub, Array.update, etc. since Int.int
> corresponds to Int32.int).  Hence, there are quite a few 64/32
> conversions going on.
>
> * I note that with both native codegens and C codegens, with both
> 20051205 and trunk, that -align 8 often has a positive impact on
> runtime, and rarely has a significant negative impact.  This might be
> due to the Opteron memory system.  Aligned reads probably help most on
> Real64 intensive benchmarks.
>
> * The amd64 codegen is doing alright as compared to the x86 codegen.  I
> see at most a factor of 2 slowdown, and a few speedups.  Again, I'm not
> sure what real conclusions can be drawn.  Some slowdowns are going to be
> due to the changes to the runtime and Basis Library since 20051205; to
> isolate those, I need a comparison of 20051205 to trunk on a 32-bit
> system.  Some slowdowns are probably going to be due to the sequence
> indexing discussed above.
>
>
>
> _______________________________________________
> MLton mailing list
> MLton at mlton.org
> http://mlton.org/mailman/listinfo/mlton
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mlton.org/pipermail/mlton/attachments/20070621/382a4076/attachment.htm