llvm dev - Jun 2009 - [LLVMdev] ML types in LLVM

>On Sunday 14 June 2009 14:09:33 Wesley W. Terpstra wrote:
>> On Sun, Jun 14, 2009 at 10:50 AM, Florian Weimer<fw at
deneb.enyo.de> wrote:
>> > Is this really a problem for MLton? I think you only get less
precise
>> > alias analysis, and that's it.
>>
>> Correct. However, I want a fair comparison between LLVM performance
>> and the native x86 codegen. If I don't give LLVM the same
information
>> the x86 codegen has, it's an unfair comparison.
>
>Even if this puts LLVM at an unfair disadvantage, I think you will find 
>that
>LLVM will thrash MLton's current x86 backend anyway.
>
>I did some benchmarking on HLVM and found that it was often several times
>faster than OCaml when the GC is not the bottleneck:
>
>http://flyingfrogblog.blogspot.com/2009/03/performance-ocaml-vs-hlvm-beta-04.html
For numerical tasks and Array tasks but your graphs show for data 
manipulation for Lists LLVM is slower. I thnk you need further benchmarks, 
is this at all posible for you to do :)

Interesting,

Aaron

On Tuesday 16 June 2009 15:44:04 Aaron Gray wrote:
> Jon Harrop wrote:
> >Even if this puts LLVM at an unfair disadvantage, I think you will find
> >that
> >LLVM will thrash MLton's current x86 backend anyway.
> >
> >I did some benchmarking on HLVM and found that it was often several
times
> >faster than OCaml when the GC is not the bottleneck:
> >
>
>http://flyingfrogblog.blogspot.com/2009/03/performance-ocaml-vs-hlvm-beta-
> >04.html
>
> For numerical tasks and Array tasks but your graphs show for data
> manipulation for Lists LLVM is slower. I thnk you need further benchmarks,
> is this at all posible for you to do :)
The only benchmarks where HLVM does not thrash OCaml are GC intensive and that 
is solely because HLVM has a very naive and inefficient GC implementation 
(going via a hash table!). I assume Wesley intends to reuse MLton's existing
GC which does not have these issues so I do not believe those results are 
relevant here. My point is simply that LLVM makes it easy to generate 
extremely performant x86 (and x64) code, IME.

However, I would very much like to continue benchmarking and improving HLVM. 
HLVM is currently on hold temporarily while we ship a new product but I'll 
get back to it ASAP. I would also very much like to implement a concurrent GC 
so Talin's recent news about Scarcity was very interesting to me.

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

On Thursday 18 June 2009 08:16:37 Jon Harrop wrote:
> On Tuesday 16 June 2009 15:44:04 Aaron Gray wrote:
> > Jon Harrop wrote:
> > >Even if this puts LLVM at an unfair disadvantage, I think you will
find
> > >that
> > >LLVM will thrash MLton's current x86 backend anyway.
> > >
> > >I did some benchmarking on HLVM and found that it was often
several
> > > times faster than OCaml when the GC is not the bottleneck:
> > >
> >
>http://flyingfrogblog.blogspot.com/2009/03/performance-ocaml-vs-hlvm-bet
> > >a- 04.html
> >
> > For numerical tasks and Array tasks but your graphs show for data
> > manipulation for Lists LLVM is slower. I thnk you need further
> > benchmarks, is this at all posible for you to do :)
>
> The only benchmarks where HLVM does not thrash OCaml are GC intensive and
> that is solely because HLVM has a very naive and inefficient GC
> implementation (going via a hash table!).
Incidentally, Henderson described his shadow stack algorithm as a means of 
implementing accurate garbage collection in an uncooperative environment back 
in 2002:

http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.19.5570

I used a similar approach in HLVM in order to implement an accurate GC without 
having to do any unsafe low-level LLVM hacking in C++. The difference is that 
Henderson stored structs of references on the stack in order to keep them 
contiguous and pushed only a single pointer to the whole struct onto the 
shadow stack. In contrast, I literally stored every reference separately on 
the shadow stack.

Many people (particularly functional programmers, who are always whining ;-) 
have expressed concerns about using shadow stacks as a workaround for 
low-level LLVM hacking in order to implement an accurate GC. Consequently, I 
also did a little study of the impact of having used a shadow stack in HLVM:

http://flyingfrogblog.blogspot.com/2009/03/current-shadow-stack-overheads-in-hlvm.html

Suffice to say, I found the performance of the shadow stack to be more than 
adequate for my needs. However, I am somewhat unusual among functional 
programmers in that I am persuing the performance profile of F# rather than 
OCaml or Haskell. Specifically, I want to be able to implement numerical 
methods using the abstractions of a high-level language without sacrificing 
the predictably-good performance of Fortran and, in particular, I have no 
desire to be able to allocate lots of short-lived values in 
performance-critical code.

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