I wonder how much programmers in the 50's and 60's argued about how many CPU
cycles this programming construct took vs. that. ;)
________________________________
From: Dave McGuire <mcguire at neurotica.com>
To: General Discussion: On-Topic and Off-Topic Posts <cctalk at classiccmp.org>
Sent: Tue, February 9, 2010 2:28:30 PM
Subject: Re: Algol vs Fortran was RE: VHDL vs Verilog
On Feb 9, 2010, at 2:19 PM, Josh Dersch wrote:
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?
Yes, to a large degree! You're talking about it as if it happens ONCE, and you know
it doesn't. Would you care to estimate how many of those vtable lookup happen when
someone simply clicks a mouse in a modern OS? I don't know for certain, but I'm
willing to bet that it's thousands.
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.
That's nice. Now if only C# weren't a proprietary product from one company
which happens to be obsessed with creating vendor lock-in situations. ;)
(though actually, hmm, that IS rather nice...)
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.
There's a bit of congruity between C's structs and C++/C#/Java/etc objects,
but..
What other overheads/inefficiencies are you thinking
of?
...what happens when someone uses an Integer instead of an int? A whole object gets
created when all one likely needed was a memory location. What happens when one adds that
Integer to another Integer? Add in the address offset calculations to find out where the
actual int is stored within the Integer object, what would those be on most
architectures...two or three instructions? So our nice single-instruction add turns into
at least five instructions.
So you're arguing that increasing the number of instructions required to execute a
simple operation by a factor of five doesn't involve overhead? Ok, howabout when it
happens all the time, which additions tend to in most programs?
In C (for example), there's no motivation at all to wrap a struct around an int just
for the sake of doing so, so it doesn't happen.
And howabout template programming. I've never seen executables so big as the ones
in which templates were overused. (yes, here I have to give a nod to your point about bad
programmers below!) All in the name of "saving programmer time", as if
that's such a big deal, consequences be damned.
Note well, however, that I'm talking about more than just the number of instructions
required to accomplish a given task. Sure, that in itself has bad side effects when you
think about what it does to the instruction cache hit rates...the principal of locality of
reference is blown out the window. But what about memory utilization? How big, in bytes,
is an Integer compared to an int? Ok, the difference may be only a few bytes, but what
about the program (which would be "most of them") with tens of thousands of
them? (I'm typing this on a Mac, into Mail.app, which is currently eating 1.73GB of
memory)
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."
I'm sorry, but knowing how processors work, it's pretty obvious to me. The data
that backs it up is lots of programs (some of which are operating systems) that I use
every day, written in OO languages, including (perhaps especially!) OS X, are far slower
than they should be given the hardware they're running on. YOU know how processors
work too, I know you do, so I know you see my point.
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.
Yes, I have to acknowledge this; you'll get no argument from me there. But bad
programmers are the rule, not the exception. Code written by bad programmers constitutes
90% of the code written today. It's possible to write fast, compact C++ or Java code;
we've both seen it. But it's not the norm. KDE, OS X (and several of its apps,
Mail.app comes to mind) *are* the norm, and they're both horribly slow for the
hardware they're typically run on.
In an ideal world, one in which all programmers were competent, OO languages
wouldn't be such a problem. So I guess what I really mean is, "Bad programmers
are even more detrimental to computing when armed with OO languages".
-Dave
--Dave McGuire
Port Charlotte, FL