[gameprogrammer] Re: What do the new processors mean for game programming?
- From: Bob Pendleton <bob@xxxxxxxxxxxxx>
- To: Gameprogrammer Mailing List <gameprogrammer@xxxxxxxxxxxxx>
- Date: Tue, 01 Mar 2005 22:10:28 -0600
On Wed, 2005-03-02 at 04:27 +0100, David Olofson wrote:
> On Wednesday 02 March 2005 03.49, Bob Pendleton wrote:
> > On Tue, 2005-03-01 at 22:46 +0000, Robert Chafer wrote:
> > > Very interesting question, and not only for games programming. Not
> > > only is thread programming poorly understood (generally) and ...
> > > difficult.
> >
> > Yes!
> >
> > > Also, the multi-core technologies will allow threading
> > > models that are really completely different to current ones. The
> close
> > > coupling of the cores will mean very (very) fast signalling and
> > > sharing of information.
> >
> > Very interesting point. You are correct, due to being on the same
> > chip and perhaps sharing a common cache interprocessor signaling
> > times will drop to an all time low. Hmmm, what does that mean? I
> > think it means that it will be practical to use threads for very
> > fine grained tasks.
>
> ...provided there isn't a general purpose OS in the way, ruining
> everything by trying to enforce "fair sharing", as is usually the
> case. :-/
Yeah... I recently had a discussion with fellow who is using my net2 and
fastevents libraries for SDL on XP pro. He was asking about the
performance and it came out that the libraries, which do a lot of mutex
operations, ran about the same speed on a 500MHz k6 running a 2.4 linux
kernel as they do on a 2+Ghz Pentium 4 running XP. Windows will just
have to get better at doing threads.
>
> Maybe HT is best left alone on the OS level (no support beyond
> saving/restoring state properly; the OS views HT CPUs as single CPUs
> with extensions), and provided as an acceleration feature for
> applications, pretty much like the various SIMD extensions?
>
> I mean, HT is really just the next step beyond SIMD and deep
> pipelining. Deeper, more flexible and potentially more parallel.
>
> If it's intended to boost raw processing power, rather than being a
> cheap way to get 1.5 CPUs instead of a real dual CPU SMP box, this
> low level "CPU extension" type of view makes more sense. We have
> already concluded long ago that SMP is of little use to normal people
> (though that is part because of crappy scheduling in widely available
> OSes) running normal applications (such as games) - so why does it
> seem like we're intended to abuse this new technology to emulate real
> SMP?
Because it is a fairly cheap way to get higher instruction level
parallelism that is not available in a single thread. You get better
over all performance for less than the cost of two full cores.
The whole point of what is happening to processor development right now
is that Moore's law is cranking right along doubling the number of
transistors you can put on a chip every couple of years. But, at the
same time, scaling effects have kicked in that make it very very hard to
make those transistors run faster. Used to be the reduction in
transistor size driven by Moore's law automagically gave you faster
transistors. For the last few years that has not been true. You get more
transistors that run at the same, or slightly slower, speeds. So, you
*MUST* make use of parallelism to get better performance.
That is the trend that is driving the move toward HT and multicore CPUs.
Since we are going to have HT and multicore CPUs (or give up on having
increases in CPU power) we have to *find* ways to make multiple threads
meaningful for normal people. If multiple threads can't be made useful
for normal applications, we are looking at stagnation in application
development. Games have driven increases in CPU and GPU performance.
Games are developed on short product cycles so they have a good chance
of being where applications of the new CPUs will first be put to use in
applications used by normal people. Games the benefit from the
HT/multicore systems are needed to get people to buy the new processors.
So, I am asking for people's thoughts on how to do that. And, if it
means the MS has to improve Windows so that multithreaded games run
faster... Well, considering the billions they have put into developing
tools and APIs to support games and considering how important the game
market is to the success of their OS, then I suspect that MS will do
what ever they have to do to make multithreaded games run well on
Windows.
The day some new "A" title comes out and runs twice as fast on the same
hardware running Linux (or *any* non-MS OS) than it runs on Windows is
the day MS will turn a thousand programmers loose and making sure that
game runs at least as well on Windows. I have faith in MS to do what
ever it takes to keep control of the PC game market. :-)
>
>
> How about this:
>
> int do_heavy_number_crunching()
> {
> for(lots of data)
> {
> /* Grab some data */
> ...
> switch(ht_split(2))
> {
> case 0:
> /* Do some work */
> ...
> break;
> case 1:
> /* Do some other work */
> ...
> break;
> case -1:
> /* We don't have that many cores! */
> return FAILURE; /* Or do it in one thread... */
> }
> ht_join();
> /* Combine results from the two threads */
> ...
> }
> }
>
> Basically sending work off to threads on the function call level,
> rather than on the module/engine/daemon level.
>
> With some compiler support, one could have functions execute in
> parallel automatically when doing stuff like:
>
> do_stuff(get_data(), get_more_data());
>
> (The get_*data() functions would run in parallel if possible, and
> provided they can't interfere.)
That is exactly the kind of idea I am looking for.
Any else remember concurrent pascal with its cobegin and coend
statements?
cobegin
x++; y++;
coend
and the two statements in between the cobegin/coend get run as separate
threads that automagically join at the coend.
What can we add to languages to make the job of writing parallel code
easier and less error prone.
Bob Pendleton
>
>
> //David Olofson - Programmer, Composer, Open Source Advocate
>
> .- Audiality -----------------------------------------------.
> | Free/Open Source audio engine for games and multimedia. |
> | MIDI, modular synthesis, real time effects, scripting,... |
> `-----------------------------------> http://audiality.org -'
> --- http://olofson.net --- http://www.reologica.se ---
>
>
> ---------------------
> To unsubscribe go to http://gameprogrammer.com/mailinglist.html
>
>
>
---------------------
To unsubscribe go to http://gameprogrammer.com/mailinglist.html
Other related posts:
