On Tue, Oct 03, 2000 at 02:38:01PM -0400, Dan Sugalski wrote: > At 06:42 PM 10/3/00 +0100, Nicholas Clark wrote: > >But I seem to remember someone who should know (Tom Christiansen?) at > >YAPC::Europe being confident that bytecode would never be faster. > > Really? I think we shall have to prove him wrong. (And not by slowing down > the parsing, either--that's cheating...) I had some ideas about making bytecode (Well the current bytecode) denser (certainly in the sense of more compact, if not some of the other connotations) but there's still far too much I don't understand about the current backend (and via its tentacles, everything as far as the op tree) and I keep finding ways to break it. (which I try to fix before getting any further with playing). I suspect denser==slower. Nicholas Clark
- data storage and representation when designing bytecode ... Jarkko Hietaniemi
- Re: data storage and representation when designing ... Dan Sugalski
- Re: data storage and representation when design... Nicholas Clark
- Re: data storage and representation when design... Jarkko Hietaniemi
- Re: data storage and representation when de... Dan Sugalski
- Re: data storage and representation when designing ... Nicholas Clark
- Re: data storage and representation when design... Jarkko Hietaniemi
- Re: data storage and representation when de... Nicholas Clark
- Re: data storage and representation whe... Dan Sugalski
- Re: data storage and representatio... Nicholas Clark
- Re: data storage and represent... Dan Sugalski
- Re: data storage and representation when de... Dan Sugalski
- Re: data storage and representation whe... Joshua N Pritikin
- Re: data storage and representatio... Dan Sugalski
- Re: data storage and representation when design... Dan Sugalski
