Performance optimization vs satisficing (was Language Oriented Programming)

On Thu, 21 Jul 2005 16:05:20 GMT, "H. S. Lahman"
<h.lahman@xxxxxxxxxxx> wrote:
>> I think I disagree with this somewhat, as I have my own, my very own,
>> theory (think the old Monty Python routine) that computation is more a
>> unipolar constructive enterprise than a mapping, but that's another
>> rant. The use of the term "optimization" sort of jumped out at me
>> here, aren't we satisficed if it at least works, isn't optimization
>> sort of a secondary issue?
>
>It depends on the subject matter. I spent two decades in R-T/E working
>on megabuck machines where the hardware was an order of magnitude faster
>than the computer feeding it and the customer wants throughput for that
>investment. I spent another decade solving np-Complete problems on
>machines that were too small. So from my perspective performance is
>often as important as correctness in practice.

Well, I hear you, but even so.

><hot button>
>Years ago Djikstra wrote a piece for one of the professional rags
>bewailing code bloat and downgrading performance. (Anyone remember when
>one could run a spread*** on an Apple II, whose cycle rate was
>measured in KHz, with 128 Kb of memory and a 700 Kb floppy disk?) At
>the time I thought he was, once again, ahead of his time. Moore's Law
>has lulled a lot of the industry into believing that performance
>problems can be solved by waiting for next month's bigger and better
>machine.

Microsoft has been a leading offender here. The year I graduated
college, IBM mainframe (core, 2 microsecond) memory was a nice, round
one million dollars (that's about $4m in current dollars) per
megabyte, for a 2 MIP 370/168 that might support a hundred TSO and CMS
users on 2741 Selectric and 327x green (or color!) channel-connected
CRTs that cost about 2x what PCs cost. Girl friend employed there was
assigned to enhance IMS performance running in an average sized 256KB
(kilobyte) partition. Ah yes, those were the days!

>IT has been particularly affected because disk access time has not
>dropped as quickly as CPU cycles/sec have grown so the traditional I/O
>bottleneck has just gotten worse and software optimization has become an
>arcane issue for server engines. Got a performance problem? Buy
>another server.

Well, yes and no. Someone always wants more, and the numbers are as
you say, but now typical Wintel networks have terabyte SAN/NAS (RAID)
boxes on gigabit channels, which helps overall thruput, it's not news
by mainframe standards but it's pretty darned fast, pilgrim, long as
you don't mind at least a little latency. And the processors are just
ridiculously fast, even though Wintel still doesn't grok large degrees
of parallelism and has various difficulties loading (dirt-cheap!) RAM
about 4gb or so. So yes, the gap between processor and disk may grow,
but the overall power available for commercial apps is huge. What I
mostly see around town is endlessly sloppy code that gets by because
the hardware is sufficiently fast.

>The result is that the industry has largely forgotten how to optimize so
>I think there is going to be a nasty surprise coming up in the next
>decade. Moore himself has expressed concern that his Law is likely to
>fail soon. But far more important, IMO, is the fact that the problems
>are beginning to catch up to the machines. That is, until recently the
>size of the problems being solved has not grown as quickly as computing
>power, especially in IT where the thing that tends to scale is I/O volume.

I've been doing a lot of database the last few years, and there is a
common recruiting ad, "must have experience with databases of at least
300gb". Huh? What they're really after is, yes, someone who has some
sense of scalability and bandwidth performance tradeoffs. Well, it is
to laugh. I learned my performance tuning on systems three orders of
magnitude slower, yes, I recall working on a 200mb database, trying to
keep it from bogging on the superminicomputer it ran on. The several
times I've worked with 300gb database performance, did I do all sorts
of numeric analysis of the server and exotic nth-degree normalizations
and denormalizations? Nah. I run a few logs, identify the
bottlenecks, universally find a missing index, ghastly code, or an
optimizer bug, and by the time I've finished the easy stuff I've
increased performance by 300% or so and everyone loses interest in
doing anything *interesting*! Generally I arrive just after they've
installed a new server which has *already* decapitated their load
peaks, and between that and my prelims, I soon move on to
non-performance issues.

So, in the mundane commercial world, I don't see performance as much
of an issue in the immediate future (although doing the simple-minded
stuff is turning into my own bread and butter!). Microsoft remains an
immense resource-pig, capable of putting wait loops and malformed
concurrency models deep in their engines, so faster processors get in
their own way at ever-higher speeds, but even Microsoft in Server2003
and COM 1.5 is finally getting the platform straightened out, about
where OS/360 was in 1968, maybe.

Comments on Wintel hyperthreading, anyone?

Josh

.