"Darren New" <dne### [at] sanrrcom> wrote
> somebody wrote:
> > "Darren New" <dne### [at] sanrrcom> wrote

> >> And if a compiler already generates optimum code, you obviously can't
> >> improve on it.

> > Since *humans* write compilers, your argument is self defeating.

> Only if you assume all humans are equal, and/or your compiler is your
> biggest and most complicated piece of code.

Doesn't matter. Absolute faith in compilers isn't warrented in any case.

> > be achived with careful low level coding. "Hello World" windows
application
> > in Delphi, for instance, takes several hundered kilobytes. Don't tell me
> > that an assembler version can not be more optimized.

> Sure. But the fact that small programs are bloated doesn't mean large
> programs can effectively be cut down.

If you write effectively to mean economically, I agree. Of course one can
not, in that sense, effectively go against the grain. The industry has
chosen a particular path, and all of us pretty much follow it.

> The comments on the web page are pretty amusing too. Nobody seems to
> notice much that large programs don't take up more memory than small
> programs. Features you never use never get loaded and don't occupy memory.

That begs the question of why those features are there to begin with. More
importantly, OS's memory management brings yet another level of layering
into the picture. Ideally, only the application programmer is in a position
to make informed calls about such matters. Compilers, OS, virtual
machines... etc are making decisions without having an "understanding" of
the intent, and are a source of inefficiency. Yet, that's a price we pay for
modern, bloated, multitasking OSs. Add to this AV software that can take up
to half of your raw processing power. I'm not saying we should go back, but
pointing out that much of the performance gained through hardware is
"wasted" through these channels.

Post a reply to this message