POV-Ray : Newsgroups : povray.off-topic : Mac Plus vs AMD Dual Core : Re: Mac Plus vs AMD Dual Core Server Time
11 Oct 2024 15:22:17 EDT (-0400)
  Re: Mac Plus vs AMD Dual Core  
From: Darren New
Date: 9 Oct 2007 21:28:10
Message: <470c2aaa$1@news.povray.org>
somebody wrote:
> "Darren New" <dne### [at] sanrrcom> wrote
> 
>> Humans are notoriously bad at guessing where the time in their programs
>> go, and notoriously bad at keeping track of things like whether the
>> value in R147 is going to be needed before the value in R93 is.
>>
>> 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.

> I know what you are *trying* to say. However, no matter how efficient, high
> level to low level is a translation layer, and if the application writer is
> as proficient as the compiler writer, 

... and if the application writer understands not only the application 
but also the machine details, and if the application is not signficantly 
larger than the compiler ...

 > However, in practice,
> it's an economical decision, and that's why there are many, many layers of
> abstraction between the machine and the application programmer.

That's not the only reason for the layers of abstraction. Of course, 
everything's possible *given* enough effort. But if it takes you 20 
years to learn the physics, 20 years to learn the engineering to build 
the machine that does the physics, 20 years to learn how to write the 
code that does the calculation to run the machine that does the physics, 
20 years to learn to write the code that makes the calculations that run 
the machine that does the physics, well, you just ran out of time to 
prove your theories of quantum gravity.

> 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.

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.

-- 
   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

Copyright 2003-2023 Persistence of Vision Raytracer Pty. Ltd.