On Sun, 17 Feb 2002 11:49:51 -0500, you wrote:

>I'm no authority on dual processors or parallel processing, but I 
>hope that it's transparent to us programmers. I hope that when we 
>program something to draw something to the screen, that the commands 
>are sent to a graphic processor that's totally transparent to us. I 
>don't want to be required to divide my programming into functions to 
>be sent to different processors.
   Note that I'm primarly a IBM guy whose switching more and more to
Macintosh as we speak.... I've read up some where once on the subject,
and from what I read, its much like that of the IBM world from what I
remembered, in that your programs will need to be Multi-Threaded.  If
what I read is correct, I'm not particularly sure if FB3 supports
Threads, and how to create them, but you'd want to break your program
down into several smaller task. Each task gets qued to run on the
first CPU available, if only one program's running, then the OS and
the program will together run between the two cpus... Suppose your
writing a game.  You'd write 1 task to read the keyboard, 1 task to
read the mouse, 1 task to read the joystick, 1 task to play the
background music, and 1 task to draw the graphics on the screen.  No
problems there, the problem arises when the graphics needs information
from another subroutine that hasn't finished before it can draw, like
loading the background from disk....  In this case, you'd use
Semaphores on the task to tell the main program and the other task
when certain other task are completed.  Basically, it's something that
when IBM created OS/2 2.1, and Microsoft started using Multi-threaded
in their compilers, they made it sound so darn easy, but in reality,
all this checking for other task to complete, and in real world
programs each part of your program is so heavily dependant on other
parts of your program to the point that even though its setup as
multi-threaded, it runs single-threaded from start to finish!  An
awesome use for this would be a merge sort.  Sort the upper part of
the array in one thread, the lower part in another, then merge them on
a 3rd thread.... 

>Likewise, with parallel processing, I don't want to think about what 
>process is going to finish first so that I can arrange my programming 
>to take full advantage of the speed parallel provides. I want it to 
>be done automatically for me -- I'm lazy that way.
Yeah, like optimizing for the 80486+ processors.... Simple
instructions like basic add/subtract/multiply/divide can be ran two at
a time on the CPU, but if a register or memory location used on one
instruction is used on the very next instruction, a stall occurs since
both instructions must run by its self....  So to code around this,
often you'd have to use longer code that stretched out the math over
longer series to allow more commands to be run side-by-side on the
CPU....  This is not symetrical processing, just the 80486 and Pentium
Series processors can run some commands in parallel on a single CPU...
It'd be nice to have things all automatic like, but doing so, the best
I could picture would be to have each subroutine treated like a
thread, in which case the more subroutines the better.... But on
single CPU's, depending on how the PowerPC and 68k processors handle
the jumps to subroutines, it could also mean a significant slow-down
on non-multi-processor machines.... Which means, you may need to write
two seperate programs, one for multi-processors and one for single
processors ;-)