Dave McGuire wrote:
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.
Ok, I'm envisioning it. A few
instructions to do a vtable lookup and a
jump to the correct virtual function. Wow. So those extra instructions
are what's making every machine in the world (apparently) very very slow?
In C#, virtual lookups are cached at runtime so the cost of the first
virtual call to a function goes through the vtable routine; future calls
are very fast.
Objects in their raw form are not "incredibly high-level." In C++, an
object is referenced via a pointer; data fields are accessed via offsets
just like in C. There is a small overhead for virtual function
dispatch. I fail to see how this overhead is somehow responsible for
performance problems in computers today.
What other overheads/inefficiencies are you thinking of?
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?
You keep talking about how OO programming is the reason that software
today is so inefficient but you offer no data to back it up other than
"it doesn't map to the hardware."
And you brought it up in another response:
A modern multi-GHz Linux box running GTK is far less
"responsive"-feeling than my old SPARCstation-IPX running fvwm when
just tooling around the GUI. A little more time spent by the
programmers, ignoring the "easy way out" or heavy OO programming and
it'd be FAR faster.
So it finally comes out: it's the *bad progammers* at fault here. I
knew it all along! Don't confuse poor programmers with programming
languages. There are always efficiency tradeoffs in programming
languages and a good programmer knows how to make the right choices.
Josh
-Dave