On Mon, Sep 04, 2006 at 01:23:16PM +0900, M. Edward (Ed) Borasky wrote:
> 
> The gap has narrowed. It's rare that an assembly language coder can beat
> a compiler by more than a factor of 2 these days, and on some
> architectures it's a dead tie -- there's only one way to do something
> and the compiler always finds it. Interpreters are better now too,
> mostly because today's languages have such a large component that has to
> be dealt with at run time anyway that the "heavy lifting" is done by
> compiled code.

This brings me to a thought I've been having a lot, lately: that the
future of compiled code will probably start looking in some ways more
and more like interpreted code.  I don't see why we can't, relatively
soon, have a compiler that produces a compiled executable of a dynamic
language such as Ruby that does not require a VM or interpreter to be
run (outside of the very loose definition of "interpreter" or "VM" that
might include your whole OS in that definition).  The dynamic aspects of
the language would be handled by the executable binary itself, rather
than by an interpreter external to the program.

I'm not entirely sure how to explain what I'm thinking at this time so
I'm sure I get my point across.  Hopefully someone who reads this will
get where I'm aiming, and may even be able to help me clarify it.


> 
> I'm not sure JIT is "necessary" for efficient interpretation of Ruby
> anyway. But you're right ... if the economics is there, the gap will get
> closed, just like the compiler/assembler gap got closed.

There are things that Ruby allows that simply cannot be done without a
certain amount of runtime interpretation, with the possible exception of
the evolution of persistent compiled executable binaries described
above.

-- 
CCD CopyWrite Chad Perrin [ http://ccd.apotheon.org ]
"It's just incredible that a trillion-synapse computer could actually
spend Saturday afternoon watching a football game." - Marvin Minsky