Robert Klemme wrote:
> 2006/7/1, M. Edward (Ed) Borasky <znmeb / cesmail.net>:
>> 4. The Ruby community needs to get Ruby's performance up where PHP 4 is
>> on benchmarks like this. It would be wonderful if it was better than
>> Perl and PHP, but a bare minimum is to be competitive with PHP 4.
>>
>> On 4, I'm not sure a "virtual machine" is the answer, by the way.
>> "Virtual machines", or as I prefer to call them, "abstract machines",
>> were primarily intended for portability, not performance. C happens to
>> be a great abstract machine, and GCC happens to be a great way to
>> achieve portability and performance.
>
> There's a significant difference between GCC and the JVM for example:
> VM's can collect performance data while the application is running
> whereas GCC has to optimize at compile time. This yields advantages
> for the VM approach because it can better target optimizations.
Ah, but at least for the multiprogramming case, so can (and *does*) the
operating system! And the *interpreter* can "collect performance data
while the application is running" and optimize just as easily -- maybe
ever more easily -- than some underlying abstract machine.

In any event:

1. The hardware is optimized to statistical properties of the workloads
it is expected to run.

2. The operating system is optimized to statistical properties of the
workloads it is expected to run and the hardware it is expected to run on.

3. Compilers are optimized to statistical properties of the programs
they are expected to compile and the hardware the compiled programs are
expected to run on.

As a result, I don't see the need for another layer of abstraction. It's
something else that needs to be optimized!


-- 
M. Edward (Ed) Borasky

http://linuxcapacityplanning.com