Re: Fat references vindicated

Kaz Kylheku <kkylheku@gmail.com>
Fri, 8 Jan 2010 21:56:00 +0000 (UTC)

          From comp.compilers

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)
| List of all articles for this month |

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?


Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.