On Feb 9, 2010, at 1:44 PM, Josh Dersch wrote:
What "commonly used" constructs are these
that are so horribly
inefficient that they would make a multi-GHz processor stumble?
(And in what language(s)?)
OBJECTS!
Our processors have registers, ALUs, and memory locations...not
objects. (iAPX432 notwithstanding) Constructs that don't map to
that paradigm are going to be inefficient, to a degree that
corresponds to how badly they match the paradigm. And objects
don't map to it at all.
That's not answering my question. What part of implementing
OBJECTS! are modern compilers for OO-language-du-jour incapable of
translating efficiently to native machine code? And why? And what
exactly is the performance hit in the cases you're thinking of?
How, precisely, do objects NOT map to registers or memory locations
in modern OO languages? Where does the inefficiency come in?
Ok. Show me a processor that has an "object" data type, that has
subtypes like "member" and "method" and such. There aren't any.
Translating from such incredibly high-level constructs to registers,
stacks, and memory locations is not without a lot of overhead. Try
to envision what happens in the instruction stream during things like
virtual function lookups in C++, for example.
It's similar to using floating-point math on a processor with no
floating-point support. It all has to be implemented in software,
and it's slow. Going a bit farther back, processors lacking hardware
multiply and divide...we ended up using subroutines and macros, and
it was a lot slower.
How much faster than a Sparc IPX running FVWM would
my machine be
if my existing software had been written in C instead of horribly-
inefficient-language? Details, please.
Why are you asking this question?
-Dave
--
Dave McGuire
Port Charlotte, FL