Return to BSD News archive
Newsgroups: comp.os.386bsd.development
Path: sserve!newshost.anu.edu.au!munnari.oz.au!spool.mu.edu!wupost!decwrl!netcomsv!netcom.com!jmonroy
From: jmonroy@netcom.com (Jesus Monroy Jr)
Subject: Kindeling material... Send your flames early
Message-ID: <1993Mar15.105943.18258@netcom.com>
Keywords: Computer theory good design techniques
Organization: Netcom - Online Communication Services (408 241-9760 guest)
Date: Mon, 15 Mar 1993 10:59:43 GMT
Lines: 302
Here is the chance many of you have waited for
----------------------------------------------
But before We start... some meaningless dribble.
Technocrats start at the "=".
----------------------------------------------
----------------------------------------------
----------------------------------------------
"Everything is variable and nothing is known"
-Will Crawford; Wolfhound Computer Service
----------------------------------------------
"The ........, with their respective allies, are locked
in a long, costly, and dangerous contest rooted in
fundamentally different and irreconcilable views of the
nature of human existence.
The outcome will be determined by level of commitment
on each side to its own value system."
-chapter 1, "The Choice We Face"; p.1
-A Strategy for Peace Through Strength
-ASC Foundation
----------------------------------------------
"If you are going to design for yourself, then you have
to make sure you design deeply for yourself. Otherwise
you are just designing for your eccentricities, and that
can never be satisfying to anyone else."
-Charles Eames
-chapter 3, "The Elements of Friendly Software Design"
-section 2, "Know Your Audience"
-The Elements of Friendly Software Design; by Paul Heckel
----------------------------------------------
"These innovations makes it possible to offer the most
widely varying products to increasingly numerous users.
The machine will become a part of our daily lives."
-The Future:Data Processing for the Masses;p.18
-The Computerization of Society
-Report to the president of France, Dec. 20, 1976
----------------------------------------------
"There is, I think, asymmetry in this. Using computers
to help people communicate more freely in traditional ways
is a contribution in degree, but using communications to help
transform information with far more sophistication than
otherwise possible is a contribution in kind. In the end it
may be the more significant."
-comments by Dr. John M. Richardson;US Department of Commerce
-Computers and Crisis: How computers are shaping our future.
-edited session of the ACM 70; Sept. 1-3, 1970
----------------------------------------------
"Maybe someone is listening, and can hear this."
jmonroy@netcom.com
==================================================================
In attempts to speak with most of you, I can gather
from the responses, comments & flames, that I have *NOT*
been altogether excessively clear. My assumption (where I made
an ASS of U and ME) is that, "you all" were on the plateau as I.
This is by no means to signify that some of you are ill-educated,
by the statistics are with me. I, again, assume that terms such
as modular, encapsulation, inheritance & objects to be in you
venacular.
Those of you with no concept of bottom-up design, advance
data structures, encapsulation & function aliasing can stop
reading now! I have not the time _or_ patience to fill-in the
lack of foresight by the institutions to which you subscribe.
What follows are simple and common techniques for
maximizing code for optimum speed & size. I remind you that,
while both are independent, they are reciprocals of each other
(in exercise)*. By my notes I hope that some of you will at
least look at the code.
*activity requiring physical exertion
BIT MANIPULATION
----------------
is by far not only the fastest, but the most compact
method for data abstraction. In practice some languages such as
Pascal offer no real method for bit manipulation and from your
school lessons many of you may have resorted to coding in this
fashion.
/* pretty retarded code */
loop_de_loop1()
{ int stop=1,
go=0,
move;
while ((stop=1) && (go=0)) {
move =external_stuff;
::
::
if (move=0)
stop =0;
if (move=1)
go =1;
}
}
/* this will run a lot faster and better */
#define STOP 2
#define GO 1
#define INIT_VAR 3
/* prototype for ANSI */
void loop_de_loop2(void);
/* a better way */
loop_de_loop2()
{ int move = INIT_VAR; /* "move" is not important to anything */
while (move & (STOP | GO))
{ move = external_stuff;
::
::
/* this is implicit logic, it works just like the previous */
move &= (STOP | GO);
}
return;
}
We have removed at least 3 conditional jumps from the
assembly code, just by this logic. We have also removed 3
comparisons & 2 data references from the stack.
JUMPS/BRANCHES/CALLS
--------------------
Right now the impact of this is insignificant, but in
the near future -the future of processor caches, super pipelining
and super pre-fetching- Jumping, Branching, and Calling without
due consideration will, in time, degradate and ruin the precept
of optimization employed by our tools of trade.
That was a pretty ugly statement, I could find no other
way to express it.
What makes this such a loser concept?
Taking a "miss" in the "cache*" means that the CPU must clear
its's pre-fetch, pipeline & cache, the reload it from RAM.
*by cache, I mean all cache, pipeline, pre-fetch _here_.
So what, you say?
Part of the reason that some of the new CPUs can claim such low
clock cycles per instruction is by super-pre-fetching or
pipelining that is built in. And with CPUs with internal cache
the refill of the cache equates to approx. (1/2)* the time needed
to write to RAM of equivocal size or type.
*please don't quote me on this number.
STACK VARIABLES
---------------
This I should leave this for last, but with the nature of
"modern" compilers, I will speak to it now.
Why are they costly vs. heap (or even global variables)?
First, the standard method for assigned local variables is to
assign them at the beginning of a function. What is done is
pre-assigned stack space is pointed to. The data segment
register is pointed to stack segment. After that, the pointer
index is pointed to the stack area needed. Access in now
possible.
There are ways around this with the new C++ compiler; it
is called "static" ------look it up if you want info on it.
Now in contrast heap & global variables do not need to
be de-referenced. I cannot say more about this at this time.
USING DUMB MATH
---------------
Here is a classic:
int sec_no = 0,
head = 0; /* you can have some */
foo_be_barr();
for (i=0; till_done; i++)
{ ::
::
sec_no = find_sec_no();
read(sec_no);
}
/* boob */
find_sec_no()
{ logical_block_number = buffer_block_no_requested \
+ bytes_done/sector_size_in_bytes;
/* middle idiotics */
logical_sector_number = logical_block_number % sectors_pertrack;
head = logical_sector_number / sectors_pertrack;
sec_no = logical_sector_number % sectors_pertrack;
return sec_no;
}
Looks OK when you work the math, but this is faster.
/* Lets blow some minds first, by doing some aliasing */
#define find() find_sec_no()
/* better */
find()
{
sec_no++;
glob_err = (sec_no >= sectors_pertrack) ? { head++; sec_no = 0;} :
(head > head_pertrack) ? seek(track++) : report_err();
/* may you would like this better */
/*
if (sec_no >= sectors_pertrack) {
head++;
sec_no = 0;
}else if (head > head_pertrack)
seek(track++)
else
glob_err = report_err();
*/
return sec_no;
}
Multiplication & Division are the two most costly
(in terms of clock cycles) of the instruction that do not
require variables.
DERIVE YOUR EXPLICIT LOGIC, NOW, AND GET BACK TO ME.
==================================================================
I have not talked about other dumb things like:
while(1)
Using sleep() vs. timeout()
spl[xxx]() usage
using "-1" as a buffer flag
variable->maynotbewhatIwant;
*(variable[]->obfuscated)() /* really ugly stuff */
Here is SOME NEAT STUFF, to think about:
array [100][100][100][100];
variable++;
abstract_table[my_name[your_addr[his_ss_no[what_Iwant]]]];
struct
{
*funct[] ();
func[] ();
*ptr;
index;
}
kernel stack de-loading.
Arrange your code so as to have zero _or_ minimum
flags _or_ switches.
___________________________________________________________________________
Jesus Monroy Jr jmonroy@netcom.com
/386BSD/device-drivers /fd /qic /clock /documentation
___________________________________________________________________________