In article ,
Dave Hinz wrote:
On Tue, 31 May 2005 18:31:26 -0000, Robert Bonomi
wrote:
In article ,
Dave Hinz wrote:
On Mon, 30 May 2005 14:23:17 -0000, Robert Bonomi

That's when you hand over the layout for the other side, showing the
etched-away surrounds for all the holes *except* one, which is plated-through
from ground on the other side. And explain it's a start towards TEMPEST
protection. grin

Once again, I bow to the superiour deviousness. Deviousity.
Deveveiance. Whatever. Well played, Sir, is what I'm saying here.

grin

I've had *LOTS* of practice.

It also runs in the family. My brother had a college course in Mech. Eng.,
where on one exam, they had to design a mechanism for keeping a particular
pressure differential between two tanks. And there was a list of components
that you had to use -- anything else in addition was OK, but you had to use
_those_ pieces. My brother looks at the problem, realizes that there is an
'absurdly simple' solution, involving nothing more than a couple of
appropriately-sized pieces of pipe, a free cylinder, and a couple of pin-holes
in the pipes. *But* he has to use the required hardware. so he adds a
pulley, with a wire over it, hangs all the electronics on the end of the
wire -- as dead-weight *ballast*, to provide for some hysteresis in the
movement of the free cylinder. He told us, later, that there was a *LOT*
of discussion on how to grade that answer.


I never managed one _quite_ like that, although I did manage to sabotage
a final in a course I wasn't even taking. Freshman year, and I'm struggling
through the regular 2nd-quarter integral calculus course. an acquaintance
is in the "honors" advanced calculus course. They had a 'take home' final
in that course, with all of 5 questions on it. And an entire _week_ to
do it in. Explicit rules were "Anything goes" for references, etc. except
for consulting other students in the class. He brings it with him to lunch
in the cafeteria. I look it over, don't even _understand_ the first 4
problems; look at #5 and say "Oh! that one's easy!" Not quite an "AHA!"
solution, but close. *IF* you approached the problem the way it was laid
out it was a real doozy. If you took "two steps back", and squinted at it
sideways, there was a far, far, simpler method of getting at the answer.
elementary integral calculus. I didn't "know enough" to tackle it the
hard way, but, in my ignorance, immediately saw the simple approach.
It turned out that the professor had overlooked the existence of the simple
approach when designing the problem. that was the problem that "nobody"
was expected to get entirely right. OOPS!

For some reason, I was _not_ terribly popular with TAs, and even some
professors, in college.

OTOH, many of the profs and I got along fabulously. Intro assembler-language
course, and about the 3rd assignment is to write a sort routine -- trivial
one -- given an array of numbers in memory, sort into order. Everybody else
is struggling with a simple bubble sort -- I turn in an insertion sort that
doesn't use _any_ additional storage; everything is in registers. Comes
back from grading with a single comment across the top:
"And now, for something COMPLETELY different..."
I _liked_ that professor!


On the other hand, there was the 'algorithms' class. where, at one point,
we had to write, and *time*, various sorting algorithms. In the language
of our choice. So we could 'see for ourselves' the relative performance
of the various algorithms. I chose to write in assembler, and the prof
got upset. Two reasons: 1) he didn't understand assembler, 2) my results
didn't show what they were supposed to show -- he was convinced I'd done
something wrong. We had to turn in the programs, so he could critique the
style, and verify the performance. My "inconsistent" performance numbers
*did* verify, somewhat to his consternation. He had to go consult some
of the gurus over at the computer center about the code. They looked at
it, and verified that they were all 'good quality' implementations of the
algorithms.

So, *why* was 'bubble sort' _faster_ than all the other algorithms, for
anything that would fit in memory on that machine? Things *AINT* supposed
to work that way! _Hardware_ quirk. that machine had a very small
instruction cache. Just barely big enough to hold a carefully coded
bubble sort. Any 'smarter' algorithm didn't fit in the cache. and you
had constant reloading from main memory. Plus, physical memory was
small enough that _within the constraints of available memory, you
didn't get enough advantage from the lower 'order' to make up for the
much larger constant.

That Prof was seriously miffed at having the 'real world' trample all over
his nice theories.

Point is, the "It's impossible, you can't do it" is a tactic that people
to use to get people like you and me to work on something. Just so you
know. Not saying it's a problem, because those are usually the fun
projects anyway, but just something to be aware of.

*snort* I'd tumbled to _that_ by about fifth grade. Never got sucked into
anything unless I *wanted* to.

Just checking. Because I used to work with a really dumb smart guy who
still hadn't figured it out by age 30, and the sight of it dawning on
him as I explained what was going on, was _priceless_.

I daresay.

It's like you say, though -- for those who enjoy "problem solving" those are
the 'fun' projects. beats the h*ll out of doing routine support work
any day.

I don't mind the end-users so much now that I don't have to deal with
them, unless there's a "Sherlock Holmes" thing going on.

I was talking about 'maintenance coding', not user hand-holding. I generally
enjoyed that, too. Except for the guy who got it into his head that I was
a Lotus 1-2-3 guru. A program I knew *NOTHING* about. He'd ask me to come
out to his desk, and say "I've got this problem. I'm trying to do to thus-
and-such, and it won't work." My invariable response was "Give me the 1-2-3
manual. Lessee, the index says 'thus-and-such' is on page xxx. Page xxx
says..." and I would read verbatim from the manual. "Gee. THANKS!!! That
does it!" *sigh* I'm glad _he_ understood it. Frequently _I_ didn't!
But, that's how a consultant gets a reputation as an expert. wry grin


Then there was the day I made the 'mistake' of suggesting to the boss that
I might be able to improve the performance of our 'critical path' project
scheduling software (which was believed to be the fastest package then
in existence at that work). The boss was doubtful -- *very* doubtful in
fact -- giving me permission to try, but saying "I'm 'Thomas'". I found
out *later* that that program was his pride-and-joy, that he had sweated
blood optimizing it. Well, 4 days later, I'm back to see him. Requesting
an appointment with "Mr. Thomas". Puzzlement, he can't place any client
named "Thomas". then he remembers "Oh??" "Yup!" (with a *BIG* grin.)
And show him a quick-and-dirty that is more than *one*hundred*times* faster
than the production software. Disbelief was rampant, to put it mildly.
It took numerous runs, with radical changes to the data, before he'd believe
that it was calculating the entire solution each time.

Easy to step on someone's toes by making a radical change to something
they've been improving incrementally. Not that that stops me, but it's
understandable. I'm told that at times like that, there's this thing
called "tact" that I should try to use (shrug?) whatever that is.

This wasn't a tact issue -- it was just that he'd been tuning that program
for a number of years. and it was known to the fastest thing going, vs.
what _any_ of the competition had. The new version simply _couldn't_ be
*that*much* faster. He _had_ sort of lit-up (friendly!) when he figured
out the "Mr. Thomas" reference -- I think figuring I might have found a
way to squeeze out maybe 10-20% faster runs. 100x, on the other hand wasn't
credible. 'Incredible' it was, in the *literal* meaning of the word

Boss had a *real* problem with that piece of work. Terribly conflicted.
*SERIOUS* "pride of authorship" in the work he had done on the one side, and
cupidity on the other. On same-size networks, on roughly equivalent CPUs,
competing software would have run-times measured in hours. Our production
product gave you enough time to go have a somewhat leisurely cup of coffee
(i.e. the 10-15 minute range). My 'improved' version reduced the calculation
time to under 10 *seconds*. Not even enough time to stand up. The
'economic advantage' of _that_ was obvious to him.

Lovely, that!

Yeah. Unfortunately *he* didn't realize/recognize the depth of the conflict,
While cupidity governed his primary decisions, there _was_ still the other
stuff going on.

It did get a little funny though -- the performance of the whole package when
I got through 'playing with it' was so high that there was a degree of
disbelief that it could "really" be doing what it claimed. One example;
IBM was building a new chip-fabrication plant on the East Coast. They had
a project-scheduling package that ran on their mid-range systems. the
complexity of the fab plant construction was exceeding the limits of
that software, _and_ taking almost an entire shift (8 hours) to calculate
a set of solutions. The general contractor was _insisting_ that they
user our service; so, eventually, an entire troop of IBM big-wigs came
out to our offices for the 'dog and pony show'.

That's normally a clear setup for a catastrophic setup during a demo.
As I'm sure you know.

We had already input
the data for their project into the system, to for the demonstration.
*I* am the "lucky" guy who gets to do the demo. I'm showing the date-entry
capabilities, review and editing stuff, etc. to establish that it's the
real project data, and then I do the 'generate solution' command.

...and here it comes...

12 seconds later, our computer says the solution is ready; so I'm showing
those who are paying attention that we do have a solution. "now, lets
change some data and re-solve", Doing this for several iterations, I push
the 'critical path' all around the project, leaving no doubt that actual
solutions are being generated. One final set of data edits, to remove
all the changes, and another solution generation, About this point, the
'top dog' pulls his awareness back to the demo -- 'how long till we see
some answers?' he asks. His disbelief, when *his* people insist to him
that it's =already= been done, and not just once, but _half_a_dozen_times_,
was a sight to see.

I _love_ that look.

My boss, back in the corner, was thoroughly enjoying it.
I *really* didn't know enough to appreciate it. 2nd job, fresh out of college.

The IBM bigwig _really_ thought the guy was pulling his leg, at first.

He knew what kind of 'toy' equipment we were running on (Data General mini),
and had been using the IBM in-house product for years -- where the turn-
around time on _much_smaller_ projects was 10s of minutes, if not
hours. This *exact* dataset -- on their (much bigger) platform -- had a
run-time that was just over eight _hours_.

I _think_ that crew came out with the intention of a quick once-over, and
then dismiss it as 'unworkable' for any reason they could think up. You
realize that this was IBM corporate, coming to a _non-IBM-equipment_ shop
for data-processing services. What kind of odds would you offer _against_
that =actually= happening?

They went away sold. They hired us.

The fact that he was
doing a binary search of a _disk_file_, and I was doing a linear search
of an array _in_memory_ had a *great* deal to do with my approach being
faster.

Still applies today. Index that database & keep the index in RAM.
Seems blisteringly obvious, but at the time, the field was still full of
surprises. What am I saying - it's still full of surprises...

Part of it was 'database organization', too. Split the database into
multiple parallel tables (although this violates 'standard' database design),
so that you can pull in *only* the critical fields for any particular
operation. Then pull the entire table into memory in -one- operation,
rather than a row-by-row read. (not forgetting the 'incidentals', like
declaring that disk allocation for that file was to be contiguous, and
creating it at maximum size.

Even the report generator worked the same way. compose an entire block
of pages _in_memory_ (I had room for 5 print pages), and then issue _one_
system call to output the whole mess. Made the report writer more than
100x faster, just due to the I/O reductions.


When somebody was using that package, it was *immediately* obvious on
the system status monitoring tools. Bam, the system I/O rate goes through
the roof (like 8x the normal load rate); BANG! CPU utilization hits 100%,
and stays there, while I/O plummets back to normal; Then the CPU load
drops to normal, with another big spike in I/O. Nothing else on the system
came close to touching _either_ the CPU utilization or the I/O rates.
It _was_ fun to watch.

The boss understood _programming_. I understood *systems*.

Right. The best possible improvement to the wrong solution still gives
you the wrong solution, in the end. In his case the fundamental design
flaw was masked by the improvements he was making to it.

Even deadlier. He's started out developing something to solve _small_
networks (that did fit into memory). As he got the software "good",
he needed to be able to deal with more network elements than there was
memory available. "Paging" the data to disk was an 'obvious' solution.
(no hardware VM, no O/S support, memory management _was_ the domain of
the application program.)

I had a significant advantage -- looking at initially as a 'big' problem.
And, if you didn't have room for all the data, and all the code, you
keep only the 'critical' part for any given step in memory (but keep _all_
of that), and do the same thing with the code. modularize it, with only
a single module in memory at at time. Not even 'overlays', a whole
flock of stand-alone programs, and an entirely separate 'user interface'
program that did nothing in and of itself, just the function menu display
and invoked the other tools, as needed -- some menu options invoked only
one tool, others invoked multiple tools in succession.

Running with a _total_ address-space of 32 k words, most of the tools had
declared data areas in excess of 27K words this left d*mn little room
for code.


By the time I got _done_ playing, performance was just over 3-orders of
magnitude better then the prior version -- on a 'maximum-size' network,
*and* the maximum-size of the project it could handle was _60%_ larger.
(this is a textbook "order n-squared" problem, so the total performance
differential was about 3.5 orders of magnitude. Not too shabby!

Fun stuff...