On Mon, Sep 14, 2009 at 12:19 PM, Reini Urban <[email protected]> wrote: > lightning is still active and I use it on clisp. The developer is > responsive, however there are no releases, everybody has to use current CVS. > [email protected]:/sources/lightning > > There are rarely bugs in the lib, so there are not many changes in the last > years.
Yes, this is the same information I saw. I did worry that it being such a quiet project, but it appears very stable and usable. > 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. This is not the reason why we are ripping it out at all. Individual ops or individual bugs are not enough and would be fixed if that's all it was. It's a fundamental problem with the design that's the killer. Parrot JIT does essentially NOTHING to improve execution performance, other then streamlining op dispatch. There are no optimization phases, or even optimization opportunities in it, we are stuck with only a small boost to dispatch speed while other VMs in this world with proper JITs pass us by in the performance benchmarks. Here is a small incomplete list of reasons why to remove it: 1) No real performance benefit 2) No opportunities for optimization 3) Poorly encapsulated 4) Difficult to add support for other platforms 5) Must define ops multiple times, and implementations must be identical 6) Poorly designed and documented, no developer support for it, and lousy bugs that slow down the pace of development for everybody. > 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. It's not a question of individual bugs. It is a fundamental design problem. We aren't looking just for a solution with less bugs, we're looking for less bugs AND better performance AND better encapsulation AND more supported platforms AND more features. This is a better decision for Parrot and Parrot's users by a wide margin. --Andrew Whitworth _______________________________________________ http://lists.parrot.org/mailman/listinfo/parrot-dev
