Re: Fat references vindicated

Jon Harrop <jon@ffconsultancy.com>
Sun, 10 Jan 2010 05:43:38 +0000

          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: Jon Harrop <jon@ffconsultancy.com>
Newsgroups: comp.compilers
Date: Sun, 10 Jan 2010 05:43:38 +0000
Organization: Flying Frog Consultancy Ltd.
References: 10-01-046 10-01-047
Keywords: interpreter, GC, performance
Posted-Date: 11 Jan 2010 10:52:46 EST

Kaz Kylheku wrote:
> 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.


On larger heaps with more (fat) references, HLVM beats all other garbage
collected language implementations and approaches the performance of C++.
That is a significant result.


> 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.


Yes. That aspect of the discussion was not related to this.


> 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.


HLVM isn't storing numbers in fat references.


> You don't think benchmarks could be written which reveal performance
> disadvantages in fat references?


Good question. I can certainly construct contrived examples but I cannot
think of any realistic test that would suffer significantly from the use of
fat references.


--
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/?u



Post a followup to this message

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