On Jan 27, 2007, at 4:05 PM, Bryan Sant wrote:
???, I would think that "high-level" languages would have a major
advantage in these cases. Porting your language runtime would be a
beast, but once you've done so, all of the software written in that
language would be usable and optimized for the target arch. The
people who are more likely to feel the pain are low-level language
users. You have to port your compiler and then you have to port a
large portion of the software written in said language.
The EPIC architecture is a VLIW variant, where each instruction is a
compound of several smaller instructions that get executed in
parallel. A standard superscalar architecture like modern x86 chips
prefetches several instructions in advance and uses complex logic in
the die to figure out how to run them in parallel. VLIW, on the
other hand, requires the compiler to perform that logic and simply
runs the smaller instructions on their corresponding execution units
as the compound instruction is loaded. This leaves a bunch of
complexity out of the CPU die, which leaves more room for extra
execution units or other performance-boosting circuitry.
So, a bytecode-interpreting virtual machine for dynamic languages
would be fairly easy to port, and would probably run fairly well as
long as the compiler that built the virtual machine was smart. The
problem is, the key to efficient execution of dynamic languages is
JIT compilation and optimization based on runtime profiling.
Designing a runtime like that is difficult enough as it is; adding in
the necessity to detect instruction-level parallelism just raises
another barrier to an efficient runtime.
--Levi
/*
PLUG: http://plug.org, #utah on irc.freenode.net
Unsubscribe: http://plug.org/mailman/options/plug
Don't fear the penguin.
*/
