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

*GRIN* I had a reputation of "If you want something done, hunt up Bonomi,
tell him it's 'impossible', and stay out of his hair for a couple of weeks."

Yeah, I used to do that too, until I twigged to the fact that people
were doing it intentionally to me. In college, (mumble) years ago, for
one of the fabrication classes the assignment was to make a 2-sided PCB
for a logic analyzer. "Can't be done single-sided, so don't even try".
Well, it wasn't _that_ tough to do (he forgot that components are also
jumpers), so I did it single-sided. He threatened me with an
incomplete, because he had specified double-sided...

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

so I handed him the
other version done the way he wanted it.

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.

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.

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.

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.

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'. 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.
( About this point, the top dog of the visiting crew gets distracted by
what's going on outside the window of our offices -- mid-level of a
high-rise, with a _new_ building going up on the adjacent property;
construction up to about our floor-level.)
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. He came "thisclose" to calling the first guy a liar
right to his face, only when the rest of the crew was all jumping in and
insisting it 'really was true', did he calm down. I re-ran a couple
of change cycles, _while_ he was paying attention, and he got *very* quiet.

Needless to say, we got that project. And a fair number more from IBM.


Note: the more the boss looked at what I had done to that software, the
*more* ****ed-off he got. He *knew*, for example, that the fastest way
to search is a 'binary search'. And had carefully organized the data in
sorted order so that his finely tuned and optimized binary search would
operate at maximum efficiency. Whereas _I_, the freshly-out-of-college
'young twerp', wasn't bothering to maintain any kind of ordering in the
data, and was using brute-force _linear_ searches. 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. I _could_ have don binary searches, too, but this was a *very*
restricted memory environment (total address-space of 32k 16-bit words)
and the additional _space_ consumed by the binary-search code - and the
requisite sorting of the data - wasn't worth the space penalty,

The boss understood _programming_. I understood *systems*. He had done
his best optimizing the software -- and the algorithm _was_ very highly
optimized. I looked at the _system_, and engineered away the _systemic_
bottlenecks. I/O is *slow*, so you minimize it. 'Record-based' I/O also
lots of overhead, so you do large block I/O instead. Organize the data
in the way the _machine_ uses it, rather than 'people-rational' style,
etc.,etc.

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!