[LLVMdev] ML types in LLVM

[Jon Harrop]

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