At 09:58 PM 7/22/2002 +0100, Nicholas Clark wrote: >On Sun, Jul 21, 2002 at 11:46:34AM -0700, Scott Walters wrote: > > Perl 5 runs *awesome* on a 486/25. Java (Kaffe) is completely unusable. > > AWT windows come up in a matter of *days*, whereas a Tk window comes up > > in about 45 seconds. On a fast computer, these things are blurred. The > point > > is, you can thrash your system on a faster computer, but register > renaming, a > > large L2 cache, lots of disc bandwidth to thrash with etc obscured the > fact > > that you are wasting resources horribly. > >perl builds damn fine on a K5/133 with 16M of RAM. >parrot now takes 4 hours in swap hell to compile the computed goto ops. > >But that's a different story, and wondering how gcc works isn't the purpose of >this list. (No, I'm not going to *buy* a faster machine. The whole point is >that this machine was free, and is upgraded with other people's cast-offs. >But if anyone can suggest where to prod the code to make it compile faster >with no loss of functionality I'll have a prod. I prodded Encode's compiler >on 5.7.3, and in addition to going faster on my box, it also went >significantly >faster on everyone else's sensibly sized machines. But that was optimising >perl, whereas computed goto is C.)
Feeling your pain, I already did some surgery on the whole core.ops and its spawn, but it appears we are still far from perfect. Originally find_op() used a gigantic (read 500k) unrolled switch statement which was the fastest on the planet, but took quite a lot of resources to compile. I suspect we may end up releasing binary builds for common platforms, but even this won't satisfy everyone. Dan has already said he doesn't care as much about compile time resources as he does about runtime resources, and I'm inclined to side with him, but I also have a gut feeling that there are things we can do better. -Melvin
