🚀 go-pugleaf

Just an anecdote to add fuel to the fire.

I used to work for the folks who owned the weather service, national
geodetic survey, etc.

The weather service, in particular, was in the habit of buying the
fastest available computers, then programming huge weather model
software suites all in assembler, "for speed".

The only problem was, when, every few years, a much faster machine
became available from a new vendor, the huge software suites had to be
rewritten from the specifications. This process typically took five
years from start to tuned, screaming fast code, and it really was the
fastest code that would run on that machine, at least twice as fast as
higher level language code out of the best then current optimizing
compilers.

The problem was, new machines running four to ten times as fast were
coming along every two to three years, so that by the time the assembler
code was running, it was running on obsolete hardware in terms of leading
edge technology.

_If_ the huge software suites were available to compile and run from
higher level languages on the then current speed champion computers, the
higher level code would run faster _in_ _the_ _same_ _year_ than the
assembler, because the assembler had two or three more years of rewrite
to complete.

This is a general problem. Assembly may be fast, but an existing
assembly suite cannot, generally, take advantage of the fastest current
hardware, so _when_ _development_ _time_ _is_ _taken_ _into_ _account_,
assembly runs _slower_, not faster, on any given date, given a wide open
choice of computer platforms, for any non-trivial code suite.

If you want your big piece of code to run the fastest it can run _today_
_on_ _any_ _platform_, you are always money ahead to program in a higher
level language, so that you can port to the fastest platform while it
still _is_ the fastest platform.

Fast code that I can't use on my faster platform doesn't help me.

Kent, the man from xanth.
<xanthian@Zorch.SF-Bay.ORG> <xanthian@well.sf.ca.us>