Good point Timothy - 100% agreed on the value of hard facts / benchmarks. Though I think it's still useful to have some discussions first, in order to determine where to start / what to benchmark / where the problems are likely to be hiding. Good research should start with an understanding of the relevant issues, some hypotheses to test and a sensible experimental design - ideally before you start collecting too much data.
Also we shouldn't underestimate the value of sharing the wisdom and intuition gained from many years of optimising code on the JVM, which I'm sure many people around here can contribute :-) On Wednesday, 9 October 2013 21:39:33 UTC+8, tbc++ wrote: > > One of the problems with these sort of discussions is the total lack of > hard facts. Words such as "could do this" or "doesn't do that" when > referring to HotSpot are very rarely backed up by actual benchmarks, or ASM > printouts. I would imagine that any serious attempt at an optimization > layer will be prefixed by lots of research into where the current compiler > fails, and what the proper enhancements should be. > > Timothy > > > On Wed, Oct 9, 2013 at 6:29 AM, Mikhail Kryshen > <mik...@kryshen.net<javascript:> > > wrote: > >> Nicola Mometto <brob...@gmail.com <javascript:>> writes: >> >> > I don't think that's what Mike was talking about. >> > Say we have (defn x ^long [] 1), clojure will use the IFn$L and emit an >> > "public long invokePrim()" method. >> > >> > When we do (defn y [] (let [a (x)] a) the compiler will call .invokePrim >> > instead of invoke. >> > >> > If we redefine (defn x [] "") then y won't work because the new version >> > of x doesn't implement IFn$L, we'd need to recompile y too. >> >> Actually I am talking about the same problem. For virtual calls the JIT >> compiler can determine that only one implementation of the method is >> being used, inline the call and perform object explosion, effectively >> removing boxing of primitives. When new implementation becomes >> available it dynamically recompiles affected bytecode. I don't know if >> the current implementation does this for invokedynamic calls, but there >> is a potential. It just does not feel right to invent a whole new >> complex optimization layer on the Clojure side until we fully use the >> optimization capabilities of the JVM. >> >> -- >> Mikhail >> > > > > -- > “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.
