Algol vs Fortran was RE: VHDL vs Verilog

[Josh Dersch]

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
>