from the wonderful person said:
Okay, I'll bite.
What multi-CPU aware apps are you using then?
None at the moment, because I can't afford a multi CPU workstation to
play with, which is why I've been drooling over the x2 chips for some
time..
Media encoding and rendering are the obvious apps which would soak up
lots of cores/CPUs with ease.
If you've written a multi-threaded single core program in assembler
(not to be confused with multi-tasking - sorry, just being sure), then
dude - surely you'd know the hassles involved in getting all that to
work.
Minor hassles, and certainly no worse than writing interrupt driven OS
code and trying to weave that around the regular applications. Some game
(engine) designers are really smart people (some are just glorified
graphics artists or authors or musicians, which is why the team are now
so huge).
Yeah, debugging is an issue, but hey, these folks can't debug what they
deliver today, so nothing new there.. 8>.
Now imagine all those problems multiplied because now you've got to
synchronise across 2 or more CPU cores.
Odd you should be using assembler? Compiler optimizations are pretty
good these days (unless your into deliberately writing obfuscated code
of course).
Or were you just being facetious.
Nope, there (was) no other way of doing 80bit maths on an x87 and
keeping the (right) 80 bit values in the (right) x87 registers in the
stack at that time. These days maybe you could do as well with SSEn,
although I suspect not.
If you want to 'fly through' a Julia set you can fly a lot deeper (in
reasonable time - i.e. without getting into multi-word arithmetic) with
80 bit operands than you can with 64 bits, before you run into the
pixellation limit (i.e. where adjacent pixels have the =same= floating
point value to N bits, and your picture blacks out). All the C/C++
compilers I looked at didn't really believe in 80bit data values, and
certainly didn't have a clue as to how to leave them in the FPU for the
whole of a scan line.
I've got some code sitting here which ought be able to soak up however
many cores I can afford to throw at it - one thread for the display
(rate limited by how fast the user flies &/or the availability of frame
buffers), one for the UI (may be mostly idle), and 1-N threads (1 per
frame) doing the calculation, (allowing as how you may have to dump
future frames if the user decides to scroll sideways). All one process,
although nobody gets to play with anyone else's frame buffer until it is
'done', and there is no interaction between frame<N> and frame <N+1>
during the calculation phase. Actually there isn't any interaction
between each scan line and the next one IIRC, so I could actually toss
1024 cores at =each= frame buffer (but it isn't coded that way).
Chess plays pretty well on multi-CPU systems of course, an I don't see
why an X2 is going to be any different from a two CPU workstation in
that regard - Fritz<n> should be able to handle it right out of the box.
Not that I'm very excited by that, except for analysis - I already can't
beat Fritz on an XP3000+.
For something like Morrowind, I guess you'd turn most of the processing
power loose on the 'wandering monsters' (and sundry mobile bits of
scenery/weather) which need animating, and where the interaction between
the 'objects' is actually pretty small (and again you can play the 'next
frame, frame after that' trick).
Wait and see .. however history says that game designers have never let
complications of technology stand in the way of consuming all the PC
they can find, and then some - and in 5(?) years time I bet you'll have
trouble buying a single core desktop CPU chip.
most of my $$ will be going on a 7800GT or GTX and
been doing some googling and apparently people
(Yeah right)