Dear fft1976, On Fri, 2009-08-14 at 17:16 -0700, Jarkko Oranen wrote:
> > I don't think spending too much effort on the compiler at this point > is useful. It will eventually be rewritten in Clojure anyway, and Rich > has stated that he is more interested in architectural improvements > rather than an optimising compiler, for now at least. > I agree with that. The code generator is going to be under a lot of changes soon anyway. If I understand well how new new works, it will give a longer horizon to the JIT allowing better optimisation, making a lot of hand-written optimization useless. You also have to check which bottlenecks are removed with a better JVM. A lot of new optimisations will be performed by 1.7, or are already made by other JVMs. If an optimisation is/can be made by someone else, that's less work for maintaining Clojure and making it evolve. Anyway, the first step of improving performance would be to compare bytecodes/jited assembly of Clojure and Java on problems where Clojure seems really slow. You could even take these examples for your domain of interest where you need both expressivity and very high level of performance. Showing the trade-off between expressivity and performance in today's Clojure will be a real help for everybody. If you can have some examples and good analysis of why this happens somewhere on a blog/wiki, this would be really helpful. Both for implementors - looking to improve code generation - and developers, who can use that information to optimize their clojure code. > When it comes to Clojure/java performance comparisons, I think Clojure > code is too different from Java to be directly comparable in most > cases. And yes, I agree that getting the best performance possible is > a chore. Sure, getting an inner loop to produce the same bytecode as > the java equivalent *is* possible, but to do so on whole program level > would require writing Java in Clojure and a lot of macro trickery to > avoid boxing. No-one wants to do that. > I completely agree. However, one of the point that makes Clojure performant enough in a lot of situations anyway is that you don't need to do that on your whole program. just on the very small part it spends 95% in. Best regards, Nicolas. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
