Markus E L wrote:
> Jon Harrop wrote:
>> When I stated that no SML implementations have good 64-bit support I was
>> referred to the PolyML compiler. I just benchmarked it with the ray
>> tracer and got the following results:
>>
>> ocamlopt: 3.97s
>> mlton: 8.81s
>> ocamlc: 199s
>> polyml: 445s
>>
>> 2.2GHz Athlon64 x2
>>
>> So PolyML is 112x slower than OCaml.
>
> I hate to contradict all the time, but ...
>
> What does "good 64-bit support" mean? It would mean (a) that 64-bit
> executables can be generated and (b) that the performance of the
> 64-but code is not worse than that of the 32-bit code (else one would
> talk about a bad 64-bit implementation).
Here are the results for 32-bit:
g++: 4.82s
stalin: 6.32s
mlton: 6.43s
ocaml: 8.20s
sbcl: 8.45s
smlnj: 9.69s
ghc: 10.5s
Here are the latest results on 64-bit:
g++: 3.64s
stalin: 3.81s
ocaml: 3.97s
sbcl: 6.15s
ghc: 7.05s
mlton: 8.81s
smlnj: N/A
On 32-bit x86, MLton was at 3rd place, only 33% slower than the fastest
implementation, beating OCaml and giving Stalin a run for its money.
On 64-bit amd64, MLton is last, slower than before and now 2.4x slower than
the fastest implementation.
In contrast, stalin, sbcl, ocaml and ghc have not only improved performance
moving to 64-bit but have all narrowed the gap to C++. OCaml is more than
twice as fast on 64-bit! So I say that all of these implementations have
good 64-bit support and, in contrast, the few 64-bit SML implementations
that exist all have bad 64-bit support.
> "Worse" is actually difficult
> to judge, since (as somebody weote in another message), 64-bit code
> puts more memory pressure on the machine, so some programs might
> execute significantly worse as 64-bit code on some / the same
> hardware.
While true, that is a red herring. I've benchmarked dozens of different
OCaml programs and only ever found one that was slower on 64-bit and, even
then, the difference was small. SML has almost identical properties to
OCaml in this respect.
Historically, the only other language implementation that ever did worse on
64-bit than 32-bit was SBCL-compiled Lisp. However, the latest SBCL
compilers are vastly better and give competitive performance.
> So even then the circumstances will have to be weighted
> against each other. (Take home message is: 64-bit code doesn't mean
> faster, it just means more addressable memory. What makes the
> processor faster are the wider data paths e.g. to memory and similar
> stuff, but also 32-bit code profits from that: 64-bit is basically a
> decision to support a larger memory (sometimes larger ints, but if the
> 32-bit version doesn't overflow the ints, the 64-bit version will not
> profit from larger ints, just use up more memory and bus bandwidth).
The overwhelming benefit of 64-bit is the vastly better floating point
performance, particularly in this context.
> So back to the problem: You just benchmarked 64-bit Ocaml and 64-bit
> PolyML against each other. That doesn't say a thing aboout the quality
> of 64-bit support. Perhaps your PolyML implementation (of the ray
> tracer) is just slow slow slow.
PolyML is running the same code as SML/NJ and MLton. MLton was very
competitive with this code on 32-bit.
> Or PolyML is simply a slow implementation of ML.
Looks like PolyML is extremely slow at anything using floating point
arithmetic:
http://mlton.org/Performance
Slow-downs compared to MLton:
FFT: 24.2x slower
flat-array: 1,041.6x slower
Mandelbrot: 51.1x slower
Matrix multiply: 13.2x slower
Nucleic: 23.5x slower
Another ray tracer: 22.3x slower
etc.
PolyML is also vastly slower at some non-float benchmarks like
wc-scanStream.
> Which wouldn't preclude good 64-bit support, if
> you can follow me: To judge the quality of 64-bit support you would
> have to compare relative performance of 32-bit Ocaml vs. 64-bit Ocaml
> with the relative performance of 32-bit PolyML vs. 64-bot PolyML. I
> hope I made myself understood: The quality of 64-bit support is a
> relative factor. Any other definition (IMHO) doesn't make much
> sense. This definition on the other side would allow to separate the
> quality of your chosen algorithm and the quality of the common part of
> the compiler from the quality of the target specific code generator.
Perhaps you are right. A better phrase might have been "No SML
implementations give competitive performance on 64-bit", i.e. SML is no
longer a fast language.
--
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/products/?u
On Nov 8, 4:19 am, Jon Harrop <······@jdh30.plus.com> wrote:
> Looks like PolyML is extremely slow at anything using floating point
> arithmetic:
>
> http://mlton.org/Performance
Please note that those performance numbers are quite dated, comparing
MLton 20051202 and Poly/ML 4.1.3. Both compilers have had major
revisions/releases since.