Re: Using Global Variables

[crispen <@ada3.ca.boeing.com:crispen@efftoo.boeing.com>]

alvin@eyepoint.com (Alvin Starr) asks:

Me>Which is why I wonder about designs that use common memory "for speed".
Me>Did these designs begin as data-flow-controlled designs, and the
Me>common memory was retrofitted when the speed *actually* was too slow?

AS> Is it possible that you are confusing static variables with variables 
AS> that are keep on a stack or display. 

I was taking as my two alternatives: (a) variables which are declared
in package specs, and (b) parameters which are passed with function
calls.  Obviously, there are more alternatives, but let's use these
for now.

In the latter ("data-flow-controlled") mechanism, there is a requirement
to copy variables onto the stack, call the subprogram, and copy them off
the stack.  In the former, most compilers I know of simply declare the
variable as global, in which case, there's simply a memory fetch or store.

That's the reason that people have said that data-flow-controlled
designs "waste CPU cycles".

In fact, every time I have done a data-flow-controlled design, it
has executed *faster* than the global-data design it replaced.  There
seem to be three reasons for this:

	(a) Data on the stack is generally in cache, while global
	data generally isn't.

	(b) When I go to redevelop the earlier design, I find that
	the programmer (often me) did some dumb things (slow
	algorithms, meaningless variable stores, etc.) that I can
	avoid this time.  I'll restate a point I made earlier: to
	speed up your code, get rid of the dumb things you're doing
	before you get rid of the smart things you're doing.

	(c) Because I'm highly prejudiced toward a data-flow-
	controlled design, I'm highly motivated to make it fast
	to confound my enemies.

And, of course, I get the payoffs of reduced integration time, greater
maintainability, and lack of mysterious glitches for free.
+-------------------------------+--------------------------------------+
| Bob Crispen                   |   The owls are not what they seem    |
| crispen@foxy.boeing.com       +--------------------------------------+
| (205) 461-3296                |Opinions expressed here are mine alone|
+-------------------------------+--------------------------------------+