I've attached a benchmark run for x86-FreeBSD on my machine. An interesting<br>thing from the benchmark-run of the recent trunk:<br><br>testing real<br>666c666<br>< 11.59195423<br>---<br>> 11.59195518<br>817c817<br>
< 11.59195423<br>---<br>> 11.59195518<br><br>I note that <br><br><a href="http://mlton.org/pages/PortStatus/attachments/x86-freebsd.log">http://mlton.org/pages/PortStatus/attachments/x86-freebsd.log</a><br><br>has the regression as well.
<br><br><div><span class="gmail_quote">On 6/21/07, <b class="gmail_sendername">Matthew Fluet</b> <<a href="mailto:fluet@tti-c.org">fluet@tti-c.org</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Jesper Louis Andersen wrote:<br>> Yup, that was indeed the problem. With -codegen x86 it runs. I can add the<br>> benchmark results besides yours in the same format in SVN if you like it,<br>> or I can post them here.
<br><br>I "reset" the <a href="http://www.mlton.org/PortStatus">http://www.mlton.org/PortStatus</a> wiki page.<br>I think it makes sense to accumulate logs and benchmarks there.<br><br>> It will probably take some time to run anyway.
<br><br>Definitely. It's multiple hours with 8 different compilers.<br><br><br>> On 6/21/07, Matthew Fluet <<a href="mailto:fluet@tti-c.org">fluet@tti-c.org</a>> wrote:<br>>><br>>> Jesper Louis Andersen wrote:
<br>>> > Hmm, it failed the -codegen native as well as -codegen amd64. I'll<br>>> > investigate further.<br>>><br>>> For mlton-20051205 (on x86 or x86_64), -codegen native implies using the
<br>>> x86 codegen.<br>>><br>>> For mlton.svn.trunk, -codegen native has been eliminated.<br>>> On x86, -codegen x86 implies using the x86 codegen.<br>>> On amd64, -codegen amd64 implies using the amd64 codegen.
<br>>><br>>> It would be easy to restore the -codegen native option on<br>>> mlton.svn.trunk and choose the appropriate native codegen for the<br>>> architecture.<br>>><br>>> > On 6/21/07, Jesper Louis Andersen <
<a href="mailto:jesper.louis.andersen@gmail.com">jesper.louis.andersen@gmail.com</a>><br>>> wrote:<br>>> >><br>>> >> I have a 32bit FreeBSD compile ready. Benchmarks to trickle in<br>>> tomorrow
<br>>> >> when I<br>>> >> get it to crunch while at work (It takes a fair amount of time for it<br>>> to<br>>> >> finish and I don't<br>>> >> want to mess too much with the laptop while it processes the
<br>>> benchmarks).<br>>> >><br>>> >> There are also a few tweaks needed to run on 64-bit FreeBSD. I hope to<br>>> be<br>>> >> able to<br>>> >> look into them around the 1st of July.
<br>>> >><br>>> >> On 6/20/07, Matthew Fluet <<a href="mailto:fluet@tti-c.org">fluet@tti-c.org</a>> wrote:<br>>> >> ><br>>> >> > I've merged the x86_64 branch into trunk. Since the previous
<br>>> >> > announcement of the experimental release, there were only two minor<br>>> >> bugs<br>>> >> > reported:<br>>> >> > 1) Bug with -align 8 on x86_64<br>>> >> > 2) Inconsistent behavior with -const '
MLton.detectOverflow false'<br>>> >> > These have both been fixed, and I'm pretty happy with the state of<br>>> the<br>>> >> > x86_64 port.<br>>> >> ><br>>> >> > I ran the benchmark suite to compare the last public release to the
<br>>> >> > current trunk. It is a bit of an apples-to-oranges comparison,<br>>> since<br>>> I<br>>> >> > ran the benchmarks on an AMD Opteron (64-bit) system. So, the<br>>> 20051205
<br>>> >> > compiler (and its resulting executables) are running in 32-bit mode,<br>>> >> > while the trunk compiler (and its resulting executables) are running<br>>> in<br>>> >> > 64-bit mode.
<br>>> >> ><br>>> >> > [BTW, it would be nice if someone could run a corresponding<br>>> benchmark<br>>> >> > suite on a 32-bit system, for a more apples-to-apples comparison.]
<br>>> >> ><br>>> >> > You can see all of the results at:<br>>> >> ><br>>> >> ><br>>> >><br>>> <a href="http://mlton.org/cgi-bin/viewsvn.cgi/*checkout*/mlton/trunk/doc/x86_64-port-notes/bench-20070619.txt?rev=5659">
http://mlton.org/cgi-bin/viewsvn.cgi/*checkout*/mlton/trunk/doc/x86_64-port-notes/bench-20070619.txt?rev=5659</a><br>>><br>>> >><br>>> >> ><br>>> >> > Some of the highlights:
<br>>> >> ><br>>> >> > * Benchmarks were run on a uni-core, dual-processor AMD Opteron<br>>> >> 2.0GHz ,<br>>> >> > 8GB Memory, Fedora Core 6 machine (with gcc version
4.1.1 and linux<br>>> >> > version 2.6.20 (x86_64)).<br>>> >> ><br>>> >> > * compile time and code size is up across the board on trunk vs<br>>> >> > 20051205. I suspect that part of the code size increase can be
<br>>> >> > attributed to the comparison of 32-bit executables to 64-bit<br>>> >> > executables. Any 64-bit operation requires an additional 8bit<br>>> >> > instruction prefix (as do 32-bit ops that touch the extended
<br>>> register<br>>> >> > set). Compile time is probably partly explained by the bigger Basis<br>>> >> > Library implementation (increasing elaboration time and carrying<br>>> more
<br>>> >> > code through early optimizations), and partly by the fact that the<br>>> >> trunk<br>>> >> > compiler is executing a little slower than the 20051205 compiler.<br>>> >> >
<br>>> >> > * recent versions of gcc are doing fairly well with the C<br>>> code. (Note<br>>> >> > that using -codegen c with 20051205 uses the version of gcc on the<br>>> host<br>
>> >> > machine.) Indeed, the flat-array.sml benchmark needs to be revised,<br>>> as<br>>> >> > gcc recognizes that the inner loop is pure (Overflow exceptions are<br>>> >> > handled within the loop) and unused. The SSA{,2} optimizer should
<br>>> also<br>>> >> > discover that the loop may be optimized, but that is another issue.<br>>> >> > GCC also does fairly well on the checksum benchmark with 20051205,<br>>> >> > though it does horribly on the checksum benchmark with trunk.
<br>>> >> > I suspect that the later behavior is due to the fact that on x86_64,<br>>> >> > sequences (arrays/vectors) are indexed by 64-bit integers in the<br>>> >> > primitive operations (sub, update, etc), but indexed by 32-bit
<br>>> integers<br>>> >> > in the user code (Array.sub, Array.update, etc. since <a href="http://Int.int">Int.int</a><br>>> >> > corresponds to <a href="http://Int32.int">Int32.int</a> ). Hence, there are quite a few 64/32
<br>>> >> > conversions going on.<br>>> >> ><br>>> >> > * I note that with both native codegens and C codegens, with both<br>>> >> > 20051205 and trunk, that -align 8 often has a positive impact on
<br>>> >> > runtime, and rarely has a significant negative impact. This<br>>> might be<br>>> >> > due to the Opteron memory system. Aligned reads probably help most<br>>> on<br>
>> >> > Real64 intensive benchmarks.<br>>> >> ><br>>> >> > * The amd64 codegen is doing alright as compared to the x86<br>>> codegen. I<br>>> >> > see at most a factor of 2 slowdown, and a few speedups. Again, I'm
<br>>> not<br>>> >> > sure what real conclusions can be drawn. Some slowdowns are going<br>>> >> to be<br>>> >> > due to the changes to the runtime and Basis Library since 20051205;
<br>>> to<br>>> >> > isolate those, I need a comparison of 20051205 to trunk on a 32-bit<br>>> >> > system. Some slowdowns are probably going to be due to the sequence<br>>> >> > indexing discussed above.
<br>>> >> ><br>>> >> ><br>>> >> ><br>>> >> > _______________________________________________<br>>> >> > MLton mailing list<br>>> >> >
<a href="mailto:MLton@mlton.org">MLton@mlton.org</a><br>>> >> > <a href="http://mlton.org/mailman/listinfo/mlton">http://mlton.org/mailman/listinfo/mlton</a><br>>> >> ><br>>> >> >
<br>>> >><br>>> ><br>>> ><br>>> ><br>>> ------------------------------------------------------------------------<br>>> ><br>>> > _______________________________________________
<br>>> > MLton mailing list<br>>> > <a href="mailto:MLton@mlton.org">MLton@mlton.org</a><br>>> > <a href="http://mlton.org/mailman/listinfo/mlton">http://mlton.org/mailman/listinfo/mlton</a><br>
>><br>>><br>><br>><br>> ------------------------------------------------------------------------<br>><br>> _______________________________________________<br>> MLton mailing list<br>> <a href="mailto:MLton@mlton.org">
MLton@mlton.org</a><br>> <a href="http://mlton.org/mailman/listinfo/mlton">http://mlton.org/mailman/listinfo/mlton</a><br><br></blockquote></div><br>