All these new n-core CPU systems...

General Discussions
#1

I’m wondering what the difference is for the normal programmer?

Almost every new system out there has a multi-core architecture; but does that mean we can start cutting our games up into bunch of threads?

One thread running the game-logic-loop, and one thread running the render-buffer-loop?

Intel said there will be 80-core systems out within 5 years (for datacenters though only), but for desktop computers we already have multi-core systems (2-4 cores). I wonder when those 80-core systems will be out for desktops, we’ll be able to not only run game-logic and render in seperate threads, but also individual game objects, or other calculations.

It sure seems old to run a game in a linear fashion.

Has there any research been done into, hm, what can I call it, “Parallel Game Engines” | “Multicore Game Engines”?

Also, are modern OO languages outdated because of the complexity of writing synchronized multi-threaded applications? Will we all be programming in some other type of languages within 5 years?

#2

Of course, 1 google query gives me a good article to read; http://harkal.sylphis3d.com/2006/02/16/multithreading-game-engines-for-multicore-machines/

Still a very interesting topic, although not a new one, but has become more interesting in recent months.

#3

I’m not very hardware savvy, but don’t n-core processors share the same data bus? so there may be some improvement with 2-4 cores, but any higher would probably cost performance instead of gain it. it may be a good rule of thumb to keep your games at a max of 2 threads (logic/render). I personally keep mine 1-threaded, as AWT is doing its own collection of threads anyway (but this doesnt apply to lwjgl users etc…)

#4

Well, it’s very simple really. If you have 1 CPU, then that 1 CPU is only capable of linear processing, that is, 1 calculation at a time. If you have many threads on a 1 CPU system, then only 1 thread will be processed at any given time. The multi-threaded architecture in operating systems makes sure that (depending on priority) all threads running on the system gets some CPU time.

The bad thing about threads on a 1 CPU system is that they’re all competing for CPU time, since only 1 of them can be processed at a given time. The rest sits idle, eagerly waiting. And when some idle thread gets the goahead to be processed, then the CPU needs to get prepared for a) put away the thread it was working on b) get prepared for the new thread to work on. This is a delay time, and this is wasted time, our CPU is basically idle during this, and this is a expensive maneuver.

The more threads we have on our system, then the more thread(process)-switching we need to do, and hence we have more delay time that starts to accumulate.

This is one of the reason you don’t do multi-threaded games on a single-core system.

However, if you have two processors, then you can have two threads in process at any given time. This would be really good for games, so on one CPU you could have the game-logic-thread, and on the other CPU you could have the render-thread. (or some other arrangement)

Imagine if you have 80 CPUs(cores), and you could have 80 threads in process at any given time.

#5

Sorry, didn’t answer your question.

I don’t really know how that works. My guess is yes, they share the same data bus, since those n-core processors are in one package, they have to be connected to the same data bus.

#6

true, but like I was saying, the bandwidth of the data bus I think would negate the parallelization, assuming they share the same bus

with 2 to 4 cores, i dont think there’s much problem. I think I read somewhere that dual-cores range from a 40% to 70% improvement

edit: aha! found that article (dated April 2005): http://news.com.com/AMD+releases+dual-core+server+chips/2100-1006_3-5678562.html

5th paragraph down…

also in that article…

so maybe they can go above 4 cores, but I think 80 might be a stretch for today’s buses :slight_smile:

#7

Yes, “depending on the application”, hehe, only if the application supports multithreading, which a lot don’t do.

Also, I’ve noticed many of these high-end multicore CPU’s being sold as a “powerful gaming computer”. Appearently, targeting end-users that don’t know any better.

[quote]Unlike Intel, AMD will not bring the dual-core concept to its Athlon 64 FX line of gamer chips yet because most games aren’t threaded for dual-core operations.
[/quote]
The fact that most of these multicore systems are also (or mainly) targeted for servers shows the difference between the desktop and server enviroment, and that desktop enviroment is yet not ready for multicore systems.

In 5-6-7 years, who knows, maybe we’ll have some new type of system buses that have better support for a high number of cores.

I find this to be interesting, how to use all these new multicore CPU’s on the market on the desktop, and how a programmer can make use of multicore systems without the hazzle of multi-threaded programming. :>

#8

Here is a nice video showing a game designed to run on a multicore system, pretty amazing;

#9

wow, that’s pretty amazing.

When they say ‘we use a core just for the physics’ do you think that they can actually secure the core for the physics thread or would it be done by the operating system & they’d just schedule a thread for physics like we would, hoping that it gets its own core?

#10

Does anyone know how Java supports multicore architectures? Can you create a thread and assign it to be always run on a defined core? Or do you have to simply hope the JVM/OS assign the thread to a unoccupied core?

Anyway, here’s a awesome article exactly about what I’m wondering about: http://www.gamasutra.com/features/20060906/monkkonen_01.shtml

#11

No, its not possible to do this in Java AFAIK. You just schedule a thread & then its all up to the OS. Thread priorities can be used however.

For example, you can’t even tame the garbage collector thread to run when you want :(.

#12

I you look on google video for QuakeCon 2006, John Carmack from id software talks a bit about his research into using multi-core processors.
For example in a dual-core system one would be used for the graphics rendering loop and the other for everything else.

#13

Yes, but if you design your game to work only for dual-core systems, then it won’t make use of the other two cores if you’re running the game on quad-core systems.

You need some game-engine design that can work for all multicore systems, even if they only have 1 processor, or 2, or 80. The game engine needs to be able to spread as much processing around. That sort of a problem is what I’m interested in.

#14

Ok, hm, what is the future in Java then if you cannot control the threads on a lower-level, like dedicate a whole core to a defined thread? Multicore systems are appearently the future and the way to go, so are we seeing Java dying out?

#15

What, exactly, would you gain by being able to control the threads on such a low level?

#16

This topic has got me interested as I’d always thought that new threads created in a java app may be ‘assigned’ a different cpu core if the operating system sees fit.
Well, one quick test project on an Intel Centrino Duo (Win XP) shows that 2 worker threads kicked off will use all of ONE core only.

Looking on the Java Technology forums, there are quite a few posts where people have indicated:

  • Whether or not your application’s multiple threads will be allocated its own CPU depends on both your OS and the JVM implementation
  • AND the OS can “dynamically distribute threads to different cores as they use more or less system resources”

Some quick googling reveals that it may be possible to start your application with an option for the JVM indicating that you want new threads to be allocated a new CPU (if possible), however this option is only available for systems running Solaris as the OS.

#17

Yes, this is a interesting topic in Java, especially since multicores are becoming the STANDARD. If Java is left handicapped, with accessability to only 1 processor, then I see a BIG PROBLEM.

Have these new multicore CPU’s taken us programmers by surprise? Are we wakening up and finding ourselves asking the question “Why didn’t we see this coming?”. Im studying BSc (computers science) at my university now, and there is little or no mention of parallel processing, I think there should be at least a whole course dedicated to this subject.

The reason why I want to control what threads get allocated to what CPU?

Well, if I have a game that has multiple threads; 1 for game logic, 1 for physics, 1 for rendering, 1 for audio, 1 for networking etc., then I want to bind each of those threads to their own core, and no other thread will be allowed to run on that core. Also, I don’t want the OS to go process-switching the threads between all the cores…there is no reason to do it. Nor do I want all these threads to be run on just the first core, or the first 2 cores, I want to say that ThreadA runs on CoreA, and ThreadB runs on CoreB…and so forth.

As PeterB said, if you create 2 threads on a duo-core system, then both of those threads get run on the same core, with all that process-switching invovled. That’s the reason why you want to control what thread get assigned to which core.

#18

Done some more googling;

http://www.artima.com/forums/flat.jsp?forum=276&thread=170444


Man, this is like that law that states (if this is a law, should be); As computers get cheaper, programming gets more expensive.

#19

Hi

Why not let the OS do this?, you have to remember, that there are other processes happening on the box besides ours. The OS knows best (or should do) how to assign the threads around, and it knows when another thread, from a different app needs some time. You can’t lock everything else out. I almost never shut everything else down but the game I’m playing. Quite often I have mail client, ssh client, maybe a few web pages open aswell. These threads also need to happen. If i have 2 threads, one using 50% of a dual core system, and 1 using 25% of it, then the os knows where best to place those threads. In my app, I have no idea of the rest of the system setup.

What we need to be able to do, is get a hold of the number of cpu cores, and kick off ourselves the right number of threads. The OS should handle the rest. We need to figure out if there are only 2 cores, that we fire off 2 threads, if there are 4, we fire off 4 threads. On the other hand, it may be easier to just let the OS context switch our 4 threads on a 2 core system, it maybe less of a performance over head than any code we write to throttle back the number of threads we launch.

Writing future proof apps means being able to handle possible many more cores, this time next year we may see 16 cores or something silly (I’m no cpu expert, so don’t ask me if thats realistic).

Endolf

#20

Totally agree. As long as a Java-thread is actually an OS-native thread then there isn’t a problem (although it would be nice to know the number of hardware threads too). OS writers aren’t stupid you know. The whole point of thread priorities is so that you can do stuff like this without kicking all the other running apps in the teeth because you’ve just grabbed all the CPU time.

The whole “allocate a whole core to do X” only really applies when you’re on a console, and there aren’t any other apps running.