Would an alternate approach be to write a Clojure interpreter in RPython and have the PyPy toolchain create everything for you? That way you get an interpreter with a tracing JIT for free, plus it looks like they've got STM working now. It seems like that could save a lot of work. Am I missing something? What are the downsides of this approach?
On Friday, March 29, 2013 12:04:33 PM UTC+8, tbc++ wrote: > > This is something I've thought/talked about for some time now. In reality > this is one of the reasons I started Mjolnir. I would like to see an > implementation of Clojure on LLVM. Mjolnir is several months away from > being able to handle a project like this, but I took the time tonight to > type up my thoughts on the topic. > > https://github.com/halgari/clojure-metal/blob/master/README.md > > I'd love to hear anyone's input on this doc. I just typed this up, so it's > a bit rough, but it should communicate some of the ideas I have. > > Timothy Baldridge > > > > On Thu, Mar 28, 2013 at 7:26 PM, Mikera <mike.r.an...@gmail.com<javascript:> > > wrote: > >> On Friday, 29 March 2013 05:45:53 UTC+8, Laurent PETIT wrote: >> >>> 2013/3/28 Marko Topolnik <marko.t...@gmail.com>: >>> > Or you may have just a trivial requirement for a program that both >>> starts >>> > and executes quickly. >>> >>> To what extent would an LLVM / C version of a Clojure program not >>> incur startup penalty as the JVM does. >>> >>> As far as I understand it, the startup cost is manyfold: >>> 1/ JVM startup >>> 2/ loading of Clojure Core >>> 3/ loading of non-lazy parts of your application (generally from >>> loading a global namespace to invoke its -main function) >>> >> >> In my experience 1) is a small fraction of the total. A trivial "hello >> world" Java program runs in less than 0.1sec on my machine, which proves >> that JVM startup isn't really important. Or at least, far less important >> than most people think. >> >> >>> >>> I know AOT compilation can somehow reduce load-time of 2/ and 3/, but >>> not bring them to zero. As far as I understand it, all the namespaces >>> involved in your application will still have to be linearly executed, >>> in a depth-first manner following the graph of namespace dependencies >>> + loaded configuration files etc. Only the compilations of functions >>> will be optimized into loading of their corresponding classes. >>> >>> So, short of having a "image-like" environment, I wonder what the time >>> taken to do 2/ + 3/ would be in LLVM / C versions of Clojure. >>> >> >> It might even be slower in LLVM / C, unless you can at least match the >> JVM in terms of JIT optimisation and garbage collector efficiency, which in >> turn affects the runtime for 2+3 (I believe a garbage collector is a >> requirement to execute Clojure?). Beating the JVM isn't an easy feat. >> >> Something I would be very interested in would be enhancements to Clojure >> that allow for lazy compilation, i.e. deferring compilation of parts of >> your application or Clojure Core until they are directly invoked for the >> first time. This is probably going to be the most promising approach for >> reducing Clojure startup time, although I expect it would require some >> breaking changes. >> >> -- >> -- >> You received this message because you are subscribed to the Google >> Groups "Clojure" group. >> To post to this group, send email to clo...@googlegroups.com<javascript:> >> Note that posts from new members are moderated - please be patient with >> your first post. >> To unsubscribe from this group, send email to >> clojure+u...@googlegroups.com <javascript:> >> For more options, visit this group at >> http://groups.google.com/group/clojure?hl=en >> --- >> You received this message because you are subscribed to the Google Groups >> "Clojure" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to clojure+u...@googlegroups.com <javascript:>. >> For more options, visit https://groups.google.com/groups/opt_out. >> >> >> > > > > -- > “One of the main causes of the fall of the Roman Empire was that–lacking > zero–they had no way to indicate successful termination of their C > programs.” > (Robert Firth) > -- -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
