somebody wrote:
> Doesn't matter. Absolute faith in compilers isn't warrented in any case.

Nah. Nothing absolute about it.

> That begs the question of why those features are there to begin with.

Firstly, it doesn't.  "Begs the question" doesn't mean what you think it 
does. ;-)

Secondly, while it's true that 90% of the time you use only 10% of the 
features, it's a different 10% for everyone. Which leads to some rather 
dumb arguments on this list too about compatibility and such.

> importantly, OS's memory management brings yet another level of layering
> into the picture. 

Well, yeah, that's kind of what I was talking about.

> Ideally, only the application programmer is in a position
> to make informed calls about such matters.

I'll disagree. I think many programs are in the middle - too high-level 
to be hand-coded efficiently, but too low-level to let software improve 
on what the programmer asked for.

Consider, for example, an SQL interpreter that can look at the balance 
of values in the tables being joined and decide, on a day by day basis, 
the order in which to join them. Sure, obviously, someone coded this 
behavior, but it wasn't the application programmer.

 > Compilers, OS, virtual
> machines... etc are making decisions without having an "understanding" of
> the intent, and are a source of inefficiency.

Partly, yes, but you can also, for example, save memory and disk I/O by 
using shared libraries that the application programmer can't possibly 
predict at compile time whether they'll already be cached in memory or 
sharable with another application, for example.

> modern, bloated, multitasking OSs. 

Not nearly as much care is taken with modern OSes, I'll grant. It used 
to be the OS would lay out on disk your files, accomidating rotational 
latency and even how long it took to process the interrupt for the next 
sector to be loaded. Nowadays, you can't even figure out how many actual 
cylinders the disk has.

> Add to this AV software that can take up to half of your raw processing power. 

Well, yes.

And using languages like C means you need address translation and memory 
protection on your hardware in order to support multi-user machines, 
which is also a drain on speed.

-- 
   Darren New / San Diego, CA, USA (PST)
     Remember the good old days, when we
     used to complain about cryptography
     being export-restricted?

Post a reply to this message