Guile virtual machine targets

Guile virtual machine targets

[Ewan Higgs]

Hi all,
With Noah's suggestion of moving the Guile vm in a direction to support CLisp 
work as well, I became curious about the status of the various Guile back ends 
(Lightning and Guile-vm). These questions are largely out of personal interest 
and not leading up to any particular piece of work I had in mind.

Is Lightning actually supported? I saw that there is some mention of it on the 
old CVS page[1], but almost nothing else. I also see that Noah was working on 
something last year but it doesn't appear to have gotten into the master repo 
[1]. Is Lightning embeddable? If so, then I guess that work could replace the 
existing libguile virtual machine.

CLisp is currently using Lightning as of 2.45 (2008/02/24)[2]. So if Guile and 
CLisp are using this then would Noah's interests be satisfied? If Lightning 
doesn't provide enough features to support work that Guile's vm does, would it 
make sense to port the work for the Guile-vm to Lightning instead and simply 
support that back end?

If Lightning isn't embeddable, is LLVM? If so, wouldn't that become an 
attractive target for Guile as it's well documented and has a lot of inertia?

Thanks!

-Ewan

[1] As mentioned here: http://www.gnu.org/s/guile/anon-cvs.html -- though CSV is 
no longer used.
Noah has some work here): https://github.com/noahl/guile-lightning
[2] http://www.clisp.org/impnotes.html

NB: This was intentionally not cross posted to Clisp developers list.

Re: Guile virtual machine targets

[Noah Lavine]

Hello,

Let me clarify a bit about Lightning and the stuff I've been doing:

Lightning is a very low-level assembler framework. It is embeddable,
and Guile could certainly target it, but targeting Lightning would be
just a speed enhancement - it wouldn't make us more compatible with
anything else.

Actually I had decided a while ago that we should look at using GNU
Libjit rather than Lightning, mostly because it does register
allocation for us, whereas Lightning doesn't. It also provides tail
call support, which Lightning does not (I think).

Libjit is about the same level of abstraction as LLVM, but with much
less optimization ability. We talked about LLVM a bit, but Andy
thought that we should avoid it because it is BSD-licensed rather than
LGPL (if my memory is correct). However, I don't think optimization is
our primary concern right now, because before we start optimizing any
sort of low-level representation we would want better optimization for
Tree-IL or a similar higher-level representation of Guile code.

Noah

On Mon, Apr 18, 2011 at 11:43 AM, Ewan Higgs <ewan_higgs@yahoo.co.uk> wrote:
> Hi all,
> With Noah's suggestion of moving the Guile vm in a direction to support CLisp
> work as well, I became curious about the status of the various Guile back ends
> (Lightning and Guile-vm). These questions are largely out of personal interest
> and not leading up to any particular piece of work I had in mind.
>
> Is Lightning actually supported? I saw that there is some mention of it on the
> old CVS page[1], but almost nothing else. I also see that Noah was working on
> something last year but it doesn't appear to have gotten into the master repo
> [1]. Is Lightning embeddable? If so, then I guess that work could replace the
> existing libguile virtual machine.
>
> CLisp is currently using Lightning as of 2.45 (2008/02/24)[2]. So if Guile and
> CLisp are using this then would Noah's interests be satisfied? If Lightning
> doesn't provide enough features to support work that Guile's vm does, would it
> make sense to port the work for the Guile-vm to Lightning instead and simply
> support that back end?
>
> If Lightning isn't embeddable, is LLVM? If so, wouldn't that become an
> attractive target for Guile as it's well documented and has a lot of inertia?
>
> Thanks!
>
> -Ewan
>
> [1] As mentioned here: http://www.gnu.org/s/guile/anon-cvs.html -- though CSV is
> no longer used.
> Noah has some work here): https://github.com/noahl/guile-lightning
> [2] http://www.clisp.org/impnotes.html
>
> NB: This was intentionally not cross posted to Clisp developers list.
>
>

Re: Guile virtual machine targets

[Ludovic Courtès]

Hello,

There are experience reports suggesting that LLVM is not well suited for
JIT: it’s relatively slow because the main goal is AOT, not JIT, and has
a large memory footprint.

For example, from <http://vmkit.llvm.org/publications/vmkit.html>,
Section 4.3 (“Startup Time”):

  Although LLVM has the advantage of being language-independent and
  generating efficient code, it only performs aggressive optimizations.
  A Java HelloWorld program thus takes 8 seconds to run without any
  optimization activated.

Likewise, from
<http://qinsb.blogspot.com/2011/03/unladen-swallow-retrospective.html>:

  Unfortunately, LLVM in its current state is really designed as a
  static compiler optimizer and back end. LLVM code generation and
  optimization is good but expensive.

Thanks,
Ludo’.

Re: Guile virtual machine targets

[Ewan Higgs]

Hello again,
 
Ludovic, those were interesting reads. Thanks for sending them my way. For those 
reading along, however, it should be noted that vmkit is part of the broader 
llvm project[1]. So I found the report read as a rationalization for the vmkit 
sub project and it's likely that vmkit is what any jit language would use should 
it chose llvm as a back end.

With regards to libJit, I tried to download it and go through the tutorial code, 
but it appears to have been deserted. The link to download the source[2] is dead 
though there is a package on the gnu ftp for version 0.1.0[3]. Unfortunately, 
that package doesn't appear to compile (using gcc 4.4 on x86_64 GNU/Linux)[4]. 
The most recent git source I found is for version 0.0.1 when I build it[4]. 
Unfortunately, when I try to run the first tutorial program[5], I get a segfault 
in jit_value_get_param (though it's likely I've done something wrong). 

Looking through the mailing list, it appears to have gone silent since 2010/11 
(incidentally, Noah's the second last person to mail it)[6]. Interestingly 
enough, I found Chris Lattner invited libJit to be merged into llvm in 2004[7]. 
This was before vmkit was pulled into llvm (in 2008).

So it appears libJit has out of date documentation, the source hasn't changed 
since 2010/10/28, the latest stable package I found doesn't build, and the 
mailing list is all but dead. If libJit is the way to go, maybe it's worth 
forking it and adopting it. Otherwise, if this is to become a dependency for 
Guile and it maintains it's current profile, it will likely become a pain point 
for Guile.

I tried to read around the topic and do my research, but I can't help but feel 
that I'm missing something here. Please let me know if I've misunderstood 
anything.

Thanks,
Ewan

[1] http://vmkit.llvm.org/
[2] http://www.gnu.org/software/dotgnu/libjit-doc/libjit_1.html#SEC1 links to 
http://www.southern-storm.com.au/libjit.html
[3] ftp://ftp.gnu.org/gnu/dotgnu/pnet/libjit-0.1.0.tar.gz
[4] http://www.gnu.org/software/dotgnu/pnet-git.html
[5] http://www.gnu.org/software/dotgnu/libjit-doc/libjit_3.html#SEC6
[6] http://lists.gnu.org/archive/html/dotgnu-libjit/
[7] http://lists.gnu.org/archive/html/dotgnu-libjit/2004-05/index.html



----- Original Message ----
From: Ludovic Courtès <ludo@gnu.org>
To: guile-devel@gnu.org
Sent: Mon, 18 April, 2011 22:12:47
Subject: Re: Guile virtual machine targets

Hello,

There are experience reports suggesting that LLVM is not well suited for
JIT: it’s relatively slow because the main goal is AOT, not JIT, and has
a large memory footprint.

For example, from <http://vmkit.llvm.org/publications/vmkit.html>,
Section 4.3 (“Startup Time”):

  Although LLVM has the advantage of being language-independent and
  generating efficient code, it only performs aggressive optimizations.
  A Java HelloWorld program thus takes 8 seconds to run without any
  optimization activated.

Likewise, from
<http://qinsb.blogspot.com/2011/03/unladen-swallow-retrospective.html>:

  Unfortunately, LLVM in its current state is really designed as a
  static compiler optimizer and back end. LLVM code generation and
  optimization is good but expensive.

Thanks,
Ludo’.

Re: Guile virtual machine targets

[Marijn]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Ewan,

On 04/20/11 12:57, Ewan Higgs wrote:
> With regards to libJit, I tried to download it and go through the tutorial code, 
> but it appears to have been deserted. The link to download the source[2] is dead 
> though there is a package on the gnu ftp for version 0.1.0[3].

I checked my distribution packages and since they included version 0.1.2
I decided to investigate a bit further. This version was released in
2008 and you can it from
http://download.savannah.gnu.org/releases/dotgnu-pnet/libjit-releases/

Marijn
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.17 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk2+h+QACgkQp/VmCx0OL2zOJgCfV89GR3/3gDCQnPUddlqU8SoB
cSEAn17uHDfWK7/FjHgamm6yMTI3VCg0
=JCwP
-----END PGP SIGNATURE-----