----- Original Message ----- From: "Ken Fox" <[EMAIL PROTECTED]> To: "Uri Guttman" <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Sent: Tuesday, October 30, 2001 7:05 AM Subject: Re: Improved storage-to-storage architecture performance
> Uri Guttman wrote: > > so my point is the the speed of the VM is a separate issue from the ease > > of code generation. an S2S VM would be easier to code generate for but > > may be slower to run. the speed difference is still an open point as dan > > has said. but since his goal is execution speed, that will determine the > > best parrot design, not ease of code generation. > > Absolutely. Which is why I posted my numbers and my code. > > The other thing to consider is that Perl is still a compile-on-the-fly > system. I hope Perl 6 keeps this aspect of Perl instead of moving to a > more Javaesque development environment. it could compile on the fly and store the result, I believe python does it this way. > > This means time spent doing dataflow analysis to help with register > allocation is going to eat into perceived execution speed. Parrot might > fly, but if the Perl 6 compiler is slow, the user experience will be > poor. Hopefully the compiler will run quickly and generate decent code. definitely this is the worst thing about java, you have to spend ages compiling your app in a special step then when it is run the jit kicks in and the simplest program takes a couple of second to start. The worst is that it re JIT compile a lot of the standard classes for each program it runs. > A separate super-optimizing compiler can be used for important things > like CGI.pm. ;) > > - Ken Benoit
