Re: [stella] A warning to newbies -- every cycle becomes sacred!

Subject: Re: [stella] A warning to newbies -- every cycle becomes sacred!
From: tower@xxxxxxxxx
Date: Thu, 19 Jun 2003 15:30:44 -0400
Does this mean your wife is a release engineer?


                      "Mark Graybill"                                                                
                      <saundby@foothil         To:      <stella@xxxxxxxxxxx>                         
            >                   cc:                                                   
                      Sent by:                 Subject: Re: [stella] A warning to newbies -- every   
                      owner-stella@big         cycle becomes sacred!                                 
                      05/06/03 04:45                                                                 
                      Please respond                                                                 
                      to stella                                                                      

----- Original Message -----
From: Matthew Ozor <matt@xxxxxxxx>
To: <stella@xxxxxxxxxxx>
Sent: Tuesday, May 06, 2003 7:30 AM
Subject: Re: [stella] A warning to newbies -- every cycle becomes sacred!

> Visual Basic is for writing programs faster not writing fast programs.
> Worrying about cycles in 2 GHZ machines is unnecessary.

Usually, yes, but that's not entirely true. It's possible to squander any
amount of computing resources, since the resources are always finite but
ability to squander them has no known limit.

As a case in point, there is the computing environment my wife supports.
They do builds of a software product on a high end multiprocessor system
with a number of other systems supporting it. It was taking about 12 hours
to do a build on these systems before they decided to do an upgrade. They
need to be able to do about 3 builds a day. The upgrade increased processor
speed and the number of processors to result in about a doubling of the
available CPU cycles, while also increasing the available RAM by about 50%.
They were shocked when the upgrade only resulted in the builds being
to about 10 hours each.

After the upgrade debacle they finally allowed my wife to start
some of a laundry list of fixes she had recommended they do before spending
money on more hardware. She implemented the fixes more or less in her spare
time around the other work she does on the systems, and also put together
another server out of old cast-off equipment to test her fixes. The test
hardware has less than 1/10th the CPU cycles, and less than 1/2 the RAM of
the production hardware. The build now takes about 6-8 hours on the test
hardware, and just over 3 hours on the production hardware.

The software they use to run builds is all written in Unix shell script,
awk, perl, and other RAD languages. One of their biggest problems was
profligate abuse of the Unix 'find' command (any use of which borders on
abuse, IMO.)

So I say go on counting cycles and thinking about optimizations, even in
There are places in code where you can optimize the heck out of it and it
won't make a bit of difference. But there are also places in code where
trimming a few parts of a percent off the time can pay off big time.
in a constrained enviroment like the 2600 is great training for learning
rules of optimization that are applicable at any level.

-Mark G.


Archives (includes files) at
Unsub & more at

Archives (includes files) at
Unsub & more at

Current Thread