Criticism of garbage collection support in LLVM

[Mikhail Glushenkov-3]

This may be of interest:

http://lhc-compiler.blogspot.com/2009/01/case-against-cllvm.html

People implementing a new Haskell compiler explain why LLVM is an
unsuitable target for them.

_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

[Daniel Berlin]

It's nice that he claims it's way too high overhead without any, you know, data.

Then again, he also thinks writing a good native code generator isn't
that difficult, so ....

On Sat, Jan 17, 2009 at 1:18 PM, Mikhail Glushenkov <[hidden email]> wrote:

> This may be of interest:
>
> http://lhc-compiler.blogspot.com/2009/01/case-against-cllvm.html
>
> People implementing a new Haskell compiler explain why LLVM is an
> unsuitable target for them.
>
> _______________________________________________
> LLVM Developers mailing list
> [hidden email]         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>

_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

[Chris Lattner-2]

On Jan 17, 2009, at 10:18 AM, Mikhail Glushenkov wrote:

> This may be of interest:
>
> http://lhc-compiler.blogspot.com/2009/01/case-against-cllvm.html
>
> People implementing a new Haskell compiler explain why LLVM is an
> unsuitable target for them.

I find the article, and particularly the preceding one (http://lhc-compiler.blogspot.com/2009/01/what-is-lhc.html 
) to be quite amusing.  First, this article should be titled "the case  
against C / LLVM 2.5", not against LLVM in general.  There is nothing  
in the design that prevents holding GC roots in registers, it is just  
that noone has implemented support for it yet.  It would actually be a  
pretty simple hack to move the current GC implementation to use the  
address space support, and say that all pointers into address space 42  
are GC'd pointers (for example).  This would work fine for languages  
like haskell and java where the GC doesn't need static metadata  
associated with the pointers.

I assert that the time and cost to implement an entirely new x86  
backend (to start with?) is far more than would be required to add  
this feature to LLVM (also note that their non-existent code generator  
doesn't support this feature either).  Further, the skill set required  
to implement a very performant low-level code generator is very  
different than that required to produce a performant implementation of  
a high level language like Haskell.

In the end, I consider this to be a yet-another chapter in the  
"functional language people don't like LLVM" saga.  Whether it be  
small improvements in LLVM tail calls or the fact that LLVM currently  
pins GC roots to the stack, there is always a "good reason" to justify  
writing something new, rather than learning and extend an existing  
system.  I'm sure that LLVM being written in C++ (as opposed to, say,  
ocaml) is part of this as well.

In the end, I think that diversity is good in the compiler world, and  
wish them the best.  It's just not the approach I would take in  
2009. ;-)

-Chris
_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

[Jon Harrop]

On Saturday 17 January 2009 19:02:47 Chris Lattner wrote:
> In the end, I consider this to be a yet-another chapter in the
> "functional language people don't like LLVM" saga.

The OCaml Journal has published around 40 articles now. The most popular and
third most popular articles are both about LLVM. So I don't think it is
correct to say that "functional language people don't like LLVM". Indeed, I
thought I was a kook for trying to write a compiler for a functional language
using LLVM until I mentioned it to the OCaml community and half a dozen
people stepped forward with their own alternatives. :-)

--
Dr Jon Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/?e
_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

[Lennart Augustsson]

I just want to say that the "functional language people don't like
LLVM" saga is not complete.
I think the LLVM is very cool, and although I've not looked into
supporting GC yet, I'm sure it's possible.
I'd rather try that than duplicating the LLVM effort (I've written
enough code generators).

  -- Lennart

On Sat, Jan 17, 2009 at 7:02 PM, Chris Lattner <[hidden email]> wrote:

>
> On Jan 17, 2009, at 10:18 AM, Mikhail Glushenkov wrote:
>
>> This may be of interest:
>>
>> http://lhc-compiler.blogspot.com/2009/01/case-against-cllvm.html
>>
>> People implementing a new Haskell compiler explain why LLVM is an
>> unsuitable target for them.
>
> I find the article, and particularly the preceding one (http://lhc-compiler.blogspot.com/2009/01/what-is-lhc.html
> ) to be quite amusing.  First, this article should be titled "the case
> against C / LLVM 2.5", not against LLVM in general.  There is nothing
> in the design that prevents holding GC roots in registers, it is just
> that noone has implemented support for it yet.  It would actually be a
> pretty simple hack to move the current GC implementation to use the
> address space support, and say that all pointers into address space 42
> are GC'd pointers (for example).  This would work fine for languages
> like haskell and java where the GC doesn't need static metadata
> associated with the pointers.
>
> I assert that the time and cost to implement an entirely new x86
> backend (to start with?) is far more than would be required to add
> this feature to LLVM (also note that their non-existent code generator
> doesn't support this feature either).  Further, the skill set required
> to implement a very performant low-level code generator is very
> different than that required to produce a performant implementation of
> a high level language like Haskell.
>
> In the end, I consider this to be a yet-another chapter in the
> "functional language people don't like LLVM" saga.  Whether it be
> small improvements in LLVM tail calls or the fact that LLVM currently
> pins GC roots to the stack, there is always a "good reason" to justify
> writing something new, rather than learning and extend an existing
> system.  I'm sure that LLVM being written in C++ (as opposed to, say,
> ocaml) is part of this as well.
>
> In the end, I think that diversity is good in the compiler world, and
> wish them the best.  It's just not the approach I would take in
> 2009. ;-)
>
> -Chris
> _______________________________________________
> LLVM Developers mailing list
> [hidden email]         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>

_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

[Jon Harrop]

On Saturday 17 January 2009 18:18:50 Mikhail Glushenkov wrote:
> This may be of interest:
>
> http://lhc-compiler.blogspot.com/2009/01/case-against-cllvm.html
>
> People implementing a new Haskell compiler explain why LLVM is an
> unsuitable target for them.

FWIW, I am a physicist with no formal training in compiler writing yet LLVM
has allowed me to create a compiler for a statically-typed functional
language in only one week that outperforms OCaml on a variety of numerical
benchmarks, often by a substantial margin on x86.

Moreover, I took the simplest design choice at every stage in order to
maximize the chances of actually ending up with a working compiler. In
particular, I used a shadow stack based on the pessimistic assumption that
LLVM is uncooperative and I found the performance degradation to be
insignificant on all code except integer Fibonacci which is ~30% slower but
only because I have not yet optimized away the shadow stack for functions
that do not use reference types.

So if anyone is considering writing a compiler for a functional language, I
strongly recommend building upon LLVM.

--
Dr Jon Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/?e
_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

[Albert Graef]

Chris Lattner wrote:
> In the end, I consider this to be a yet-another chapter in the  
> "functional language people don't like LLVM" saga.

Yet another counterexample:

http://pure-lang.googlecode.com/

LLVM from the ground up, proper tail calls, interactive interpreter,
JIT, easy C interface. Works great. :) Without LLVM, I could have never
pulled that off in a couple of months.

Albert

--
Dr. Albert Gr"af
Dept. of Music-Informatics, University of Mainz, Germany
Email:  [hidden email], [hidden email]
WWW:    http://www.musikinformatik.uni-mainz.de/ag
_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

[Chris Lattner-2]

On Jan 17, 2009, at 1:25 PM, Albert Graef wrote:

> Chris Lattner wrote:
>> In the end, I consider this to be a yet-another chapter in the
>> "functional language people don't like LLVM" saga.
>
> Yet another counterexample:
>
> http://pure-lang.googlecode.com/

Hey, this is incredibly cool. I had never heard of pure, nice work!  
Would you mind writing a blurb for this page?
http://llvm.org/ProjectsWithLLVM/

> LLVM from the ground up, proper tail calls, interactive interpreter,
> JIT, easy C interface. Works great. :) Without LLVM, I could have  
> never
> pulled that off in a couple of months.

That's very nice.  Do you (or anyone else out there that I don't know  
about :) want to be mentioned in the LLVM 2.5 release notes?  I am  
happy to have the LLVM 2.5 release notes and announcement mention and  
link to (active and well maintained) projects like this!

Incidentally, my comment about functional language people hating LLVM  
wasn't meant as a universal statement.  I'm thrilled that there are  
people using and liking it, please help spread the good word! :)

-Chris
_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

[Csaba Hruska]

Hi!

Essential Haskell Compiler (EHC) also has llvm backend.

http://www.cs.uu.nl/wiki/bin/view/Ehc/WebHome
http://www.cs.uu.nl/wiki/bin/view/Stc/CompilingHaskellToLLVM

Cheers,
Csaba

_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

[Jon Harrop]

On Sunday 18 January 2009 00:35:06 Csaba Hruska wrote:
> Hi!
>
> Essential Haskell Compiler (EHC) also has llvm backend.
>
> http://www.cs.uu.nl/wiki/bin/view/Ehc/WebHome
> http://www.cs.uu.nl/wiki/bin/view/Stc/CompilingHaskellToLLVM

Interesting that John van Schie's slides show a similar result to my own: LLVM
generates faster code than heavily-optimizing existing compilers on all but
one benchmark.

--
Dr Jon Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/?e
_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

[Libor Spacek-2]

>Chris Lattner wrote:

>>http://pure-lang.googlecode.com/
 
>Hey, this is incredibly cool. I had never heard of pure, nice work!  Would you mind writing a blurb for this page?
>http://llvm.org/ProjectsWithLLVM/
 
>-Chris

It was the other way round for me. I have been introduced to LLVM by first seeing it employed effectively in Pure.
Libor



_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

[Albert Graef]

Chris Lattner wrote:
> Hey, this is incredibly cool. I had never heard of pure, nice work!

Thanks. I only just started to write about it as we're getting close to
version 1.0 now, so you might hear more about it in the future. ;-)

> Would you mind writing a blurb for this page?
> http://llvm.org/ProjectsWithLLVM/

Here goes:

Pure (http://pure-lang.googlecode.com/) is an algebraic/functional
programming language based on term rewriting. Programs are collections
of equations which are used to evaluate expressions in a symbolic
fashion. Pure offers dynamic typing, eager and lazy evaluation, lexical
closures, a hygienic macro system (also based on term rewriting),
built-in list and matrix support (including list and matrix
comprehensions) and an easy-to-use C interface. The interpreter uses
LLVM as a backend to JIT-compile Pure programs to fast native code.

In addition to the usual algebraic data structures, Pure also has
MATLAB-style matrices in order to support numeric computations and
signal processing in an efficient way. Pure is mainly aimed at
mathematical applications right now, but it has been designed as a
general purpose language. The dynamic interpreter environment and the C
interface make it possible to use it as a kind of functional scripting
language for many application areas.

(Please feel free to edit for editorial purposes.)

> That's very nice.  Do you (or anyone else out there that I don't know  
> about :) want to be mentioned in the LLVM 2.5 release notes?

Sure, that would be nice!

> Incidentally, my comment about functional language people hating LLVM  
> wasn't meant as a universal statement.  I'm thrilled that there are  
> people using and liking it, please help spread the good word! :)

Will do. But I think that if there are any compiler writers who haven't
heard about LLVM yet then they must have been hiding under a rock. :)

Cheers,
Albert

--
Dr. Albert Gr"af
Dept. of Music-Informatics, University of Mainz, Germany
Email:  [hidden email], [hidden email]
WWW:    http://www.musikinformatik.uni-mainz.de/ag
_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

[Florian Weimer]

* Daniel Berlin:

> It's nice that he claims it's way too high overhead without any, you
> know, data.

I was quite suprised by the performance of the conservative
Boehm-Demers-Weiser collector, even in cases where I thought it was
sub-par.  So benchmarking available solutions makes sense indeed. 8-)

(Lack of continuations is probably a better excuse if you don't want
to use LLVM, especially if you don't want to perform whole-program
analysis.)
_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

[Keir Mierle-2]

And the followup:

http://lhc-compiler.blogspot.com/2009/01/why-llvm-probably-wont-replace-c.html

On Sat, Jan 17, 2009 at 1:18 PM, Mikhail Glushenkov <[hidden email]> wrote:

>
> This may be of interest:
>
> http://lhc-compiler.blogspot.com/2009/01/case-against-cllvm.html
>
> People implementing a new Haskell compiler explain why LLVM is an
> unsuitable target for them.
>
> _______________________________________________
> LLVM Developers mailing list
> [hidden email]         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

[Nick Lewycky]

Keir Mierle wrote:
> And the followup:
>
> http://lhc-compiler.blogspot.com/2009/01/why-llvm-probably-wont-replace-c.html

And if you're pointing to that, you should probably also read the next
followup:

http://lhc-compiler.blogspot.com/2009/01/llvm-is-great.html

Nick

> On Sat, Jan 17, 2009 at 1:18 PM, Mikhail Glushenkov <[hidden email]> wrote:
>> This may be of interest:
>>
>> http://lhc-compiler.blogspot.com/2009/01/case-against-cllvm.html
>>
>> People implementing a new Haskell compiler explain why LLVM is an
>> unsuitable target for them.
>>
>> _______________________________________________
>> LLVM Developers mailing list
>> [hidden email]         http://llvm.cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
> _______________________________________________
> LLVM Developers mailing list
> [hidden email]         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>

_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev