> Hans-Martin Mosner writes:
>> Doable, but not really a good way to implement Smalltalk.
>> You'd lose the binary portability and in turn gain a lot of weight,
>> since bytecodes are so much more compact than machine language.
>> IIRC, Peter Deutsch stated that dynamic compilation of bytecodes to
>> machine language is actually faster than paging pre-compiled machine
>> code into memory.

This is one of those things that varies over time as the relative  
performance of disk, main memory, cpu and cache (and its size of  
course) develop. In the 84-90 timeframe when LPD was doing this work  
discs were sloooooo     oooow  ww and
caches were tiny and main memory wasn't hugely slower than cache.
These days, caches are huge but still grossly inadequate to cope with  
the bloated obscenities that are claimed to be 'modern operating  
systems', cpus are massively faster than main memory and even more so  
if actual random access of data is considered. Set against that, we  
tend to have our little silicon servants doing many more things at  
once and so if compiled code were being paged in whilst some other  
useful work gets done it might seem like the total system is better.
How aggressively one compiles will affect the equation as well; PS &  
HPS do fairly simplistic optimisation because the aim is to get a  
usable answer *right now*. Exupery is being more painstaking AIUI.
On a machine with multiple cpus available (including a cluster of  
machines of course) one could imagine having a somewhat Spoon-like  
arrangement where a separate image running somewhere else does the  
careful optimised compile and provides the result to clients, rather  
than simply passing the method back. You'd need to make it work  
asynchronously to some extent I guess rather than blocking. Hell,  
extend Spoon a bit and have a compiler service for fee!

tim
--
tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim
My computer NEVER cras