I really like the idea of having one VM for many languages, but having just watched the Google IO video on V8, I think there might be some real performance advantages to specialized engines.
For example, they replaced the regular expression engine that Webkit was using with one that was specially designed to work with Javascript's regex syntax. Maybe you can get similar performance with a generalized engine, but I'm no longer of the mind that one VM for all languages will be the end-all-be-all solution.
I really like the idea of having one VM for many languages, but having just watched the Google IO video on V8, I think there might be some real performance advantages to specialized engines.
An specialized VM (both for the source language and the deployment architecture) would leave anything generic in the dust. Languages do not have the same usage; the truly unique ones (i.e. worth learning) encourge different programming styles. The G-Machine is as different from the Warren Machine is as different from a SECD machine and all are different from P-CODE machine or an SKI graph reduction machine.
Smilarly, a custom made application DSP would rape any other binary for a stock hardware platform of the same speed (ignoring all costs, of course.)
If you wrote a specialized VM's for Python, Perl, Smalltalk, Ruby, and JavaScript on the x86 would they have any components that were largely identical?
I would postulate that there are features of a VM that are common, like garbage collection.
It would be worthwhile to work out the features common to many VM implementations and put them in hardware. Until that happens, sharing some of a VM implementation seems useful.
I'd be willing to bet that most general purpose languages that are in mainstream use could easily share the majority of their compiler/interpreter code. The main differences are in which combination of features are included and the syntax that you use.
Why put them in hardware? That sounds like an awful lot of extra silicon for every single architecture. Wouldn't it be better to have a higher level software abstraction like Parrot that you just build everything else on top of?
The rule of thumb for instruction set design is that an instruction which is worth 1% in overall performance is worth considering. (That's how one game processor got a 2x2 matrix multiply instruction.)
It's unclear why VM design would be significantly different. In other words, if a specialized regex engine provides a significant performance boost, why not add it? Applications that can use it get faster, applications that can't stay the same.
Of course, one often discovers that redesigning the previous solution so it does the right thing for the special case is even better.
Couldn't there be a way to extend and/or override portions of Parrot specifically for one's language-of-choice? This way, lots of communities can work together on relevant and mutually beneficial places and drop-in their custom code where it suits their language.
You can. You have two different ways of doing it: the first is to write your own low level opcodes, the other, and I think more powerful, is through PMCs. A PMC (Parrot Magic Cookie) is a basic type of your language (e.g. an Integer, a Char, etc.) with some operations associated to it that you can override. Operations include assignment, type conversion, invocation, your own methods and many more. After writing a PMC you can then "map" it to a core type. As an example, if you write a "function" PMC and map it to Parrot's "function" PMC every time the VM needs to create/use a function, it will use the one you defined instead of the default one. This gives a LOT of flexibility.
Comments
I really like the idea of having one VM for many languages, but having just watched the Google IO video on V8, I think there might be some real performance advantages to specialized engines.
For example, they replaced the regular expression engine that Webkit was using with one that was specially designed to work with Javascript's regex syntax. Maybe you can get similar performance with a generalized engine, but I'm no longer of the mind that one VM for all languages will be the end-all-be-all solution.
http://code.google.com/events/io/sessions/V8BuildingHighPerf...
I really like the idea of having one VM for many languages, but having just watched the Google IO video on V8, I think there might be some real performance advantages to specialized engines.
An specialized VM (both for the source language and the deployment architecture) would leave anything generic in the dust. Languages do not have the same usage; the truly unique ones (i.e. worth learning) encourge different programming styles. The G-Machine is as different from the Warren Machine is as different from a SECD machine and all are different from P-CODE machine or an SKI graph reduction machine.
Smilarly, a custom made application DSP would rape any other binary for a stock hardware platform of the same speed (ignoring all costs, of course.)
If you wrote a specialized VM's for Python, Perl, Smalltalk, Ruby, and JavaScript on the x86 would they have any components that were largely identical?
I would postulate that there are features of a VM that are common, like garbage collection.
It would be worthwhile to work out the features common to many VM implementations and put them in hardware. Until that happens, sharing some of a VM implementation seems useful.
I'd be willing to bet that most general purpose languages that are in mainstream use could easily share the majority of their compiler/interpreter code. The main differences are in which combination of features are included and the syntax that you use.
Why put them in hardware? That sounds like an awful lot of extra silicon for every single architecture. Wouldn't it be better to have a higher level software abstraction like Parrot that you just build everything else on top of?
The rule of thumb for instruction set design is that an instruction which is worth 1% in overall performance is worth considering. (That's how one game processor got a 2x2 matrix multiply instruction.)
It's unclear why VM design would be significantly different. In other words, if a specialized regex engine provides a significant performance boost, why not add it? Applications that can use it get faster, applications that can't stay the same.
Of course, one often discovers that redesigning the previous solution so it does the right thing for the special case is even better.
Couldn't there be a way to extend and/or override portions of Parrot specifically for one's language-of-choice? This way, lots of communities can work together on relevant and mutually beneficial places and drop-in their custom code where it suits their language.
You can. You have two different ways of doing it: the first is to write your own low level opcodes, the other, and I think more powerful, is through PMCs. A PMC (Parrot Magic Cookie) is a basic type of your language (e.g. an Integer, a Char, etc.) with some operations associated to it that you can override. Operations include assignment, type conversion, invocation, your own methods and many more. After writing a PMC you can then "map" it to a core type. As an example, if you write a "function" PMC and map it to Parrot's "function" PMC every time the VM needs to create/use a function, it will use the one you defined instead of the default one. This gives a LOT of flexibility.
I'm not so sure that parsing / syntax is the bottleneck - didn't that regex engine get most of its improvements from JIT compiling the regexs?