Re: Low-level vs. High-level programming (was My First Computer)

["Kevin Lawton" <kepla@btinternet.com>]

 < big snip >

| Most employeers probably figure that by the time you need to spend more
| than a few hours to get another 1% performance from your design, it's
| time to move on to the next project. Additionally, keep in mind that
| in many pieces of software these days, the CPUs are fast enough that
| the bottleneck is going to be, e.g., the hard drive speed or the
| network link speed and the total CPU time consumed by the program is
| almost negligible.  In any case, the point is that high-level
| languages ostensibly allow programmers to not have to constantly keep
| learning the ever more complex details of new processor architecture
| while incurring only a 'small' (<20%?) reduction in performance
| relative to native assembly coding.

I have to disagree with the above figure of 20%, and would suggest that the
overhead of using some modern high-level languages can be at least 200% or
even more like 2000% !
My 20+ years programming career has spanned a number of different software
technologies - from Assembler, Fortran and Cobol on Mainframes and Minis
through to Web-HTML and mobile Java. One thing I have noticed is that
programming languages seem to evolve to absorb the processing power
available to them. Assembler and C are massively powerfull and efficient,
but require much skill to use properly. The result is small fast programs
which can get the best performance out of the hardware they are running on.
Java, HTML, etc are barely 'coding' at all - they are more like a technical
specification of a program than the program code itself - the result being
that the computer has to do far more work at runtime to sucessfully execute
the program. The result of al this 'dumbing-down' isn't cheaper
programmers - just look at the sort of salaries paid to Java programmers and
Cobol programmers respectively. The result is that the end-user, the
consumer, has to provide much bigger, faster and expensive hardware at their
own cost. The software might be cheaper to produce (though looking at
Micro$oft's prices you'd hardly think so !) but any advantage gained is paid
for dearly with the hardware required to run it.
As an example, I've tried writing the same programs in both C and Java and
then running them on representative machines. A graphical representation of
the 'sieve of erastothanes' puzzle. On a 4 MHz 8-bit machine written in C
with optimised assembler the execution speed was similar to the Java version
running on a 1.4 GHz Athlon Thunderbird. On a 333 MHz Intel Pentium-II the C
version was ashtonishingly fast (too fast to watch  clearly) while the Java
version was so slow that you could only just notice that something was
happening. My point is that if modern software was written in a fast
efficient language, an average consumer could be getting better performance
out of an 800 MHz Duron machine than they might currently see in a 2.4 GHz
Athlon with big slow software. This appplies right across the board: Op
Sytem, Drivers, Application Programs, the lot.  The only area these days
where some gesture towards program efficiency seems to be being made is in
Gaming and even there the consumer is expected to throw vast amounts of cash
at the graphics sub-system in order to acheive acceptable results.
Okay, maybe my viewpoint is slightly biased because I'm an 'old-school'
programmer who's had to learn 'new wave' tricks in order to survive, but
where's the progress when the greatest change seems to have been to
dumb-down the software writing business ?
Kevin.
  < big snip >