On 11/07/01 Ken Fox wrote: > Simon Cozens wrote: > > ... Mono's work on JIT compilation ... they've got some pretty > > interesting x86 code generation stuff going on. > > Mono is doing some very cool stuff, but it's kind of hard > to understand at this time. The x86 code generation macros are > easy to use, but the instruction selection is based on a > re-implementation (?) of BURG and it will take some time to > dig through the way that code works. BURG is a code-generator > generator in the style of yacc. (More trips to the library...)
monoburg is different because it allows using functions to determine the cost of a rule, instead of using constants only. It makes it easier to create optimizing rules (for a specific processor, for example). Moreover, the previous *burg implementations were not free software. You can read any BURG related papers to understand how that code works. > I also poked around the Lightning project which is documented a > bit better. It's also more widely ported (although I'm sure Mono > is going to catch up soon -- those guys code like maniacs.) > Here's a quote from Lightning that worries me a bit: GNU lightning is fine for some quick&dirty JIT work, but it produces code in a platform-independednt way and that prevents optimizations... We are not interested in maximum performance right now in mono, but we want to be able to get there down the line, so we have a design that lets us move quickly with the implementation and we can optimize later. > There's a more fundamental issue though. After spending time > looking at the benefits of a JIT and thinking about the "yet > another switch/goto implementation" conversation, I'm starting > to think that a JIT will be almost useless for Parrot. It depends how much the dispatch is going to cost in an average parrot program and how smart the runtime can be: if the interp can detected that the arguments to a method are of a specific type, it can create a jitted implementation and exec that, instead of going with the slow path. This is the approach taken by the python optimizer, IIRC. Or all the code can be JITted and you avoid at least the dispatch cost. > About the only place where a JIT might really win big is in > regexps. Since when I wrote x86-codegen.h I wanted to use it and compile a regex down to native code, I'm convinced it can be a *huge* win. Alas, my free time is very little lately. > Is there any interest in a less dynamic dialect of Perl that can > take advantage of a JIT? Should we feed a request to p6-language > to think about this? IMHO, a less dynamic perl is perl no more, though some consideration should be made to make it easier to implement the language on virtual machines such as the JVM and CLR. That said, I'm open to sneak into mono opcode handling that may make it easier to run parrot code there, if it is needed. lupus -- ----------------------------------------------------------------- [EMAIL PROTECTED] debian/rules [EMAIL PROTECTED] Monkeys do it better
