Re: Super Serial Card Question?

["mdj" <mdj.mdj@gmail.com>]

Eric Smith wrote:

> The technology (and I don't just mean IA64, but in general) isn't yet able
> to do that without significant performance penalty.  It's not clear that
> it will ever be possible.

I'm not sure this is true. Certainly with the current generation of
VM's there is a significant performance overhead in regards to
application load time, related primarily to the nature of the dynamic
class loaders employed. On current implementations, most of this is
cached on disk to allow for a one-time hit. Most synthetic benchmarks
show that from a computational perspective the VM's equal, and
sometimes significantly better statically compiled code.

There's a general feeling out there that the VM based environments are
"slow" but none of this slowdown is related to the VM's themselves, but
rather the API code having been written very badly. A classic example
of this is Java's GUI layer Swing, which for the most part performs
poorly because it's implemented using the smallest possible number of
primitives from the host operating environment. This implementation
technique would produce similar, if not identical performance
characteristics if implemented in a supposedly 'faster' language.

There is a tremendous advantage to be had from using runtime profiling
as input to a code optimiser. While many of these techniques are
possible on a smaller scale in hardware, hardware design simply cannot
match software design in this arena.

> If you do the translation in software, there
> will always be a penalty, and if you throw enough transistors at it to
> do it in hardware, it won't match the performance you could get if you
> kept a fixed architecture and used those transistors to speed it up
> rather than using them for dynamic translation.

Sure, but the penalty can be incurred during development, in terms of
generating the optimisation data, then the only penalty is runtime
translation, which can be cached, or made a part of the softwares
installation routine.

It's the only way I can see of moving to higher and higher level
languages, which is bound to happen, once we again reach the point that
a developer simply cannot engineer 'impressive' solutions in a
reasonable number of man hours.

Matt