The extra work involved in developing multi-processor sims is far from trivial - I
know because I design and code multi-threaded apps for a living. Multi-threaded
apps only really work properly if they are originally designed as such and it is
not simply a case of porting the app to a multi-processor environment. There are
several important issues:
1) Memory and resource contention. 2 or more threads must be prevented from
accessing the same memory or other resouirces simultaneously. Thread control
mecanisms must be used to prevent this. It is not simply a case of sprinkling
thread control objects around your code because you will almost always be left with
several threads executing one after another - which is actually less efficient than
a single-threaded app.
2) Deadlocks and deadly embraces. Once you have all these thread control objects in
place the most common problem is to have two threads each waiting for a thread
control object that the other owns. These are often a nightmare to rid from your
app - and a maintenance headache as well. Once multi-threaded sims are released we
will start to see much more "freezing up" than you get at the moment.
3) Unix in most, but not all, of its flavours only supports heavy-weight threading
models (ie on a process level) and this would be unacceptable in a racing sim. All
methods of crossing the process boundary are expensive in terms of processor usage.
I don't know whether Linux supports light-weight threading, but apart from the old
IBM mainframe operating systems, the best light-weight threading model I have seen
is in Windows NT - soon to become Windows 2000 and to replace Windows 98
altogether. This is hardly surprising since it is based on DEC's VMS, IMHO, one of
the best operating systems ever written.
4) Putting 2 processors in a box does not double your processing power. The OS
needs to spend some processor time managing the extra complexity introduced. At an
extreme end I believe that with NT 3.51 there was no extra benefit to be had by
placing more than 4 processors in a box. I think these problems are sorted out, but
it is still the case that you cannot multiply your processors speed by how many
you've got to give you a final "power" figure.
5) Multi-processor motherboards are expensive, as are the CPUs you can put in them.
Given this, the low usage of Linux (as already mentioned) and the maintenance
problems multi-threading causes, I think it is unlikely that we will see
multi-threading in sims in the next 5 years.
Cheers,
Paul
> Well, I haven't got an extra PC to install my copy of Linux yet, but as a UNIX
> network administrator, here's my thoughts on the matter.
> Yes, most flavors of UNIX have something like SoftWindows, to run Windows
> software. This is software emulation, so there will be some processor overhead
> incurred in running it. Not having used it myself, I can't give a good
> ballpark percentage figure; it may well be dependant on the individual system.
> In multi-processor setups, the chips generally are set up to run in parallel -
> each runs seperate threads. How the threads are split between processors is
> dependant on how the software is written. I think the logical split for a dual
> system would be physics running on one chip, and graphics on the other (though
> with accelerated graphics cards, the 2nd CPU might handle car position or
> something).
> As for 60fps graphics, considering that movies run at 28fps and television at
> 30fps, IMO 60fps would be overkill, and an unnoticible improvement. The
> physics would probably not be "twice as good", but could perhaps be sampled
> twice as often, therefore giving a smoother feel to it.
> Bob
