this is kinda off topic, -- but people here seem really smart, so I'll risk the occasional flames for good criticism + insight i think the llvm/jvm projects are really cool, since so much work is put into jitting; and for one reason or another, I like llvm more than jvm i'm curious about the possiblity of a high performance scheme (and perhaps gambit in particular) running on llvm; where the 'initial implementation' may not be all that fast ... but letting llvm jit it away how does this sound? feasible for a scheme (but not gambit)? down the pipes planned for gambit? or totally stupid/crazy? the 'main' advantage of this approach is that I _assume_ that the llvm guys are pretty good at hacking up interpreters / jit's ... so why not benefit from their constant progress :-D
On 15-Feb-09, at 12:47 AM, lowly coder wrote:
this is kinda off topic, -- but people here seem really smart, so I'll risk the occasional flames for good criticism + insight
i think the llvm/jvm projects are really cool, since so much work is put into jitting; and for one reason or another, I like llvm more than jvm
i'm curious about the possiblity of a high performance scheme (and perhaps gambit in particular) running on llvm; where the 'initial implementation' may not be all that fast ... but letting llvm jit it away
how does this sound? feasible for a scheme (but not gambit)? down the pipes planned for gambit? or totally stupid/crazy?
the 'main' advantage of this approach is that I _assume_ that the llvm guys are pretty good at hacking up interpreters / jit's ... so why not benefit from their constant progress :-D
I had a group of students implement a LLVM backend for Gambit in one of the courses I teach (compilers). I'm CCing them. Perhaps they can give you more information and add their code to the dumping grounds. I also had a student write a Scheme to CLR compiler which can bootstrap itself. Marc
2009/2/15 Marc Feeley <feeley@iro.umontreal.ca>:
On 15-Feb-09, at 12:47 AM, lowly coder wrote:
this is kinda off topic, -- but people here seem really smart, so I'll risk the occasional flames for good criticism + insight
i think the llvm/jvm projects are really cool, since so much work is put into jitting; and for one reason or another, I like llvm more than jvm
i'm curious about the possiblity of a high performance scheme (and perhaps gambit in particular) running on llvm; where the 'initial implementation' may not be all that fast ... but letting llvm jit it away
how does this sound? feasible for a scheme (but not gambit)? down the pipes planned for gambit? or totally stupid/crazy?
the 'main' advantage of this approach is that I _assume_ that the llvm guys are pretty good at hacking up interpreters / jit's ... so why not benefit from their constant progress :-D
I had a group of students implement a LLVM backend for Gambit in one of the courses I teach (compilers). I'm CCing them. Perhaps they can give you more information and add their code to the dumping grounds. I also had a student write a Scheme to CLR compiler which can bootstrap itself.
Marc
We did a partial back-end for Gambit using LLVM and were just a little bit faster for the benchmarks I tried. Although, in all cases the speed difference could well be credited to some part not being implemented properly and thus requiring less work. I have some plans to take the implementation in another direction, to ease the expression of the various gambit back-end statements. I have not done any work on this yet. As for the code we did, it is incomplete, but I have no objection to it being posted on the dumping grounds, but I have no place to host it. I can send you the code if you are interested. Also, the back-end we did was only for static compiling. Although once I get back in it and maybe get it to work solidly, it could be used for gsi too. Don't hold your breath for now though. Arnaud
2009/2/15 Arnaud Bergeron <abergeron@gmail.com>:
2009/2/15 Marc Feeley <feeley@iro.umontreal.ca>:
On 15-Feb-09, at 12:47 AM, lowly coder wrote:
this is kinda off topic, -- but people here seem really smart, so I'll risk the occasional flames for good criticism + insight
i think the llvm/jvm projects are really cool, since so much work is put into jitting; and for one reason or another, I like llvm more than jvm
i'm curious about the possiblity of a high performance scheme (and perhaps gambit in particular) running on llvm; where the 'initial implementation' may not be all that fast ... but letting llvm jit it away
how does this sound? feasible for a scheme (but not gambit)? down the pipes planned for gambit? or totally stupid/crazy?
the 'main' advantage of this approach is that I _assume_ that the llvm guys are pretty good at hacking up interpreters / jit's ... so why not benefit from their constant progress :-D
I had a group of students implement a LLVM backend for Gambit in one of the courses I teach (compilers). I'm CCing them. Perhaps they can give you more information and add their code to the dumping grounds. I also had a student write a Scheme to CLR compiler which can bootstrap itself.
Marc
We did a partial back-end for Gambit using LLVM and were just a little bit faster for the benchmarks I tried. Although, in all cases the speed difference could well be credited to some part not being implemented properly and thus requiring less work.
I forgot to mention, but what we did was using LLVM 2.3. 2.5 is about to be released now and has a lot of improvements over 2.3.
I have some plans to take the implementation in another direction, to ease the expression of the various gambit back-end statements. I have not done any work on this yet. As for the code we did, it is incomplete, but I have no objection to it being posted on the dumping grounds, but I have no place to host it. I can send you the code if you are interested.
Also, the back-end we did was only for static compiling. Although once I get back in it and maybe get it to work solidly, it could be used for gsi too. Don't hold your breath for now though.
Arnaud
I can't make any promises -- initially, I was interested in it as an intellectual exercise; but Marc beat me to it by having students implement it already (maybe this is why being a Professor is useful). But if you don't mind posting the code, it'd be great -- the next time I'm procrastinating, instead of watching the latest TV shows on hulu.com, maybe I can fire up gambit on llvm. Thanks! On Sun, Feb 15, 2009 at 2:23 PM, Arnaud Bergeron <abergeron@gmail.com>wrote:
2009/2/15 Arnaud Bergeron <abergeron@gmail.com>:
2009/2/15 Marc Feeley <feeley@iro.umontreal.ca>:
On 15-Feb-09, at 12:47 AM, lowly coder wrote:
this is kinda off topic, -- but people here seem really smart, so I'll risk the occasional flames for good criticism + insight
i think the llvm/jvm projects are really cool, since so much work is
put
into jitting; and for one reason or another, I like llvm more than jvm
i'm curious about the possiblity of a high performance scheme (and perhaps gambit in particular) running on llvm; where the 'initial implementation' may not be all that fast ... but letting llvm jit it away
how does this sound? feasible for a scheme (but not gambit)? down the pipes planned for gambit? or totally stupid/crazy?
the 'main' advantage of this approach is that I _assume_ that the llvm guys are pretty good at hacking up interpreters / jit's ... so why not benefit from their constant progress :-D
I had a group of students implement a LLVM backend for Gambit in one of the courses I teach (compilers). I'm CCing them. Perhaps they can give you more information and add their code to the dumping grounds. I also had a student write a Scheme to CLR compiler which can bootstrap itself.
Marc
We did a partial back-end for Gambit using LLVM and were just a little bit faster for the benchmarks I tried. Although, in all cases the speed difference could well be credited to some part not being implemented properly and thus requiring less work.
I forgot to mention, but what we did was using LLVM 2.3. 2.5 is about to be released now and has a lot of improvements over 2.3.
I have some plans to take the implementation in another direction, to ease the expression of the various gambit back-end statements. I have not done any work on this yet. As for the code we did, it is incomplete, but I have no objection to it being posted on the dumping grounds, but I have no place to host it. I can send you the code if you are interested.
Also, the back-end we did was only for static compiling. Although once I get back in it and maybe get it to work solidly, it could be used for gsi too. Don't hold your breath for now though.
Arnaud
On Mon, Feb 16, 2009 at 8:12 AM, Arnaud Bergeron<abergeron@gmail.com> wrote:
We did a partial back-end for Gambit using LLVM and were just a little bit faster for the benchmarks I tried. Although, in all cases the speed difference could well be credited to some part not being implemented properly and thus requiring less work.
I have some plans to take the implementation in another direction, to ease the expression of the various gambit back-end statements. I have not done any work on this yet. As for the code we did, it is incomplete, but I have no objection to it being posted on the dumping grounds, but I have no place to host it. I can send you the code if you are interested.
Also, the back-end we did was only for static compiling. Although once I get back in it and maybe get it to work solidly, it could be used for gsi too. Don't hold your breath for now though.
It's six months since this post. Any progress on the llvm backend? -- Duy
On Jul 31, 2009, at 12:39 AM, Nguyen Thai Ngoc Duy wrote:
It's six months since this post. Any progress on the llvm backend?
The last time I compiled the Gambit-generated C code with LLVM (which wasn't so long ago) gsi failed at startup. (I know this isn't what you're referring to, but I presume the LLVM compiler may have the same difficulties compiling the LLVM intermediate representation.) I wasn't impressed. Brad
I've been on gambit for 6+ months now; and the more I dig into the internal *.scm's, the more I'm impressed -- anyone interested in forming a group to port this to LLVM as an exercise to better understand gambit internals? Something like meeting on irc 15 minutes every week or so to discuss would be really nice. On Thu, Jul 30, 2009 at 9:50 PM, Bradley Lucier<lucier@math.purdue.edu> wrote:
On Jul 31, 2009, at 12:39 AM, Nguyen Thai Ngoc Duy wrote:
It's six months since this post. Any progress on the llvm backend?
The last time I compiled the Gambit-generated C code with LLVM (which wasn't so long ago) gsi failed at startup. (I know this isn't what you're referring to, but I presume the LLVM compiler may have the same difficulties compiling the LLVM intermediate representation.)
I wasn't impressed.
Brad _______________________________________________ Gambit-list mailing list Gambit-list@iro.umontreal.ca https://webmail.iro.umontreal.ca/mailman/listinfo/gambit-list
participants (5)
-
Arnaud Bergeron -
Bradley Lucier -
lowly coder -
Marc Feeley -
Nguyen Thai Ngoc Duy