Related articles |
---|
Fat references vindicated jon@ffconsultancy.com (Jon Harrop) (2010-01-08) |
Re: Fat references vindicated kkylheku@gmail.com (Kaz Kylheku) (2010-01-08) |
Re: Fat references vindicated jon@ffconsultancy.com (Jon Harrop) (2010-01-10) |
From: | Kaz Kylheku <kkylheku@gmail.com> |
Newsgroups: | comp.compilers |
Date: | Fri, 8 Jan 2010 21:56:00 +0000 (UTC) |
Organization: | A noiseless patient Spider |
References: | 10-01-046 |
Keywords: | storage, VM, performance |
Posted-Date: | 09 Jan 2010 16:14:33 EST |
On 2010-01-08, Jon Harrop <jon@ffconsultancy.com> wrote:
> I just published some significant benchmark results:
>
> http://flyingfrogblog.blogspot.com/2010/01/hlvm-on-ray-tracer-language-comparison.html
I don't see fat references being vindicated.
The apparent winner of the benchmark is a C++ program running on a C++
implementation that presumably does not use fat references.
In the same blog entry above you do not argue about fat references,
but rather that HLVM comes close to C++ because, like the C++ program,
its inner loop computations are done with unboxed numbers. (Which is
plausible).
Use of unboxed numeric values, and use of fat references, are orthogonal ideas.
Fat references merely make it /easy/ to implement unboxed numbers in
the face of a garbage collector that is ignorant of static type.
By using these fat references, you have built a ``four-lane highway'',
which paves the way for all your ``wide loads'' like double-precision
floats to travel anywhere that references can go. Any generic storage
location that can hold a reference also has enough space to hold an
unboxed number.
You don't think benchmarks could be written which reveal performance
disadvantages in fat references?
Return to the
comp.compilers page.
Search the
comp.compilers archives again.