On Mon, 2009-09-14 at 18:19 +0200, Reini Urban wrote: > My 5 cent on the other discussion points: > It's ridicolous to rip out our current jit, just because not all *ops* > are yet jitted, and some are buggy.
It's getting ripped out because it's broken, no one currently interested in Parrot knows how to fix it, it never was much of a performance booster except in contrived micro-benchmarks, and most importantly *it's actively in the way* of getting other things done. In short, it was a classic example of premature "optimization". We cannot afford any additional forms of friction on our path to VM domination, so it has to go. > Switching to another jit library is not the point, the point is to fix > the bugs in our jitted ops. The calls using the library, not the library > itself. > When I was active I started fixing x86_64 and double. > Our jit library is optimized for parrot. llvm, libjit, lightning are not. Yes, but our JIT is broken, uses very out of date techniques, and has no optimization beyond the mere act of JIT itself -- which isn't even a solid win for our code mix. The others you list actually work, and some (like llvm) include decent optimization. Plus, being more JIT-agnostic will serve us well when we eventually move up to a modern JIT design, such as a trace-based JIT. We would have had to anyway to become performance competitive. > But maybe you will attract more capable developers, and not stupid them > away, as it happened in the past with parrot. I'm not sure what you meant by this, but my expectation is that working with solid, experienced JIT engineers cannot be a loss for us. And doing JIT for a dynamic VM will probably feed some very valuable knowledge to the JIT folks as well, so it's a win all around. -'f _______________________________________________ http://lists.parrot.org/mailman/listinfo/parrot-dev
