PH> Yes, I can absolutely agree with you. But I still hope that OS2PPC
PH> will  handle these things in a not perfect but really usable way. 
PH> Like "What, box too slow ? OK, let's plug in another  processor" :) 

I'm not sure "let's plug in another processor" will cause things like,
say, Photoshop edge sharpen on a scanned A4-size image {at}2400DPI to go
faster. A Photoshop clone for OS/2 that does edge sharpen w/multiple
thread algorithm (that would run faster on MULTIPLE processors) would
run slower than single-thread on a single CPU. For now, if you develop
an OS/2 application, yours may be the ONLY one: no competition. Soon,
though, competition will increase, and designing NOW for some future
nirvana when SMP's highly affordable takes guts.

Some common processes will likely never fully succumb to a multithread
design, so your hope of speeding a PPC system by increasing # CPUs
may not be rational. Sperry's EXEC 8 OS multitasked nicely (not
multiple THREADS, 'tho) on 1-4 CPUs. Note also that the Sperry 1100s
eventually grew IOAUs to give multiple highspeed I/O channels to such a
complex, something missing in SMP designs to date: multiple parallel I/O
buses. If efficient SMP designs manage to transcend Amdahl's law, the
next barrier may be I/O bandwidth.

I've seen reports that OS/2 sources are porting nicely to the PPC OS/2
in beta, which is a hopeful sign, since most of us shan't be able to
afford PPC equipment anytime soon, much less SMP. With good reports
on others' experience, we can code up OS/2 80x86 programs to run on
single CPUs and expect, if we hew to the recommendations, to have
them run nearly as good on PPC and/or SMP hardware as code done by
our weathier bretheren.

___
 X KWQ/2 1.2e X We all want justice, but you have to have the money to buy it

--- Maximus/2 2.02