Multi cores

Hi, was wondering where we are heading with these dou/ quad processors.
Are we going to have 64 running at 3Gz for example.
What is the time scale? And will Blitz (Max) be able to take advantage of them?

Jim

No Blitz can not take advantage of more than 1 core in a single app. If you use pub.freeprocess you can thought.

And I don't think that it will be 64 running at 3Ghz ... more like nehelem will do: use as many cores as needed and scale the processor speed.

The actual problem is that even people like Tim Sweeney, the guy behind the Unreal engine, and John Carmack, the guy behind the Doom and Quake engines, have serious problems to take advantage of more than one processor for their game technologies. Just google for "Carmack multithreaded game programming" or something similar and read for yourself why he tinks that it basically makes game development more complicated while actually not producing enough benefit.

With BlitzMax as it is today, you would have to launch new processes instead of spawning new threads and you would have to implement a communication layer between those processes. This --can-- make sense in various problem domains (for example communication and database servers). If it makes sense for a game depends a lot on your specific game.

I think that for a game, or for most games, you've really got to have access to all of the same memory shared between each piece of code that's running on a core, so it really needs to be more like threads than processes. Processes have a much more confined wall between things which means you then have to use something to bridge the gap, which is additional overhead and doesn't exactly seem very easy to synchronize or be efficient.

I guess that to make use of lots of cores, you'd have to rethink how you structure your app, so that it is ready to be highly parallel. Ideally you'd maybe want one core per game object, or small group of game objects, and have them all be calculating at the same time, like each core handles x number of particles or whatever, or width x height area of landscape.

I can't see that using processes is very intuitive or flexible, the whole point is that programs are blind to each other and enclosed in separate memory areas, and trying to then open up those boundaries to make it share enough to be useful seems like a pointless exercise when the boundaries shouldn't have been there in the first place. I vote for threads with shared memory, if at all.

My ideal is to have one dedicated core per object so that every object is being processed in parallel with no need for any `multitasking` or scheduling or timelicing.

One of the areas where multi core can have a real impact on games is the calculation of audio-efects at real time (reverbs, EQs, Dopler etc.) One core can work as a dedicated DSP for the game. the rest of the engine doesn't need to read audio data, just sync the 3d-spaces, but all additional calculation and audio-data acces can be on another thread running on a dedicated core.

SMP systems actually -do- share the same memory, system bus and other hardware resources, which has --disadvantages-- for many if not most application domains. Threads also share the address space of their host process. The disadvantage is that all hardware access, including memory, must be serialized.

A parallelized architecture based upon parallelized processes could actually be spread over a grid of computers (and not only CPU cores). The processes must still be synchronized, but not the hardware I/Os. That is why render farms used this technology before they also took advantage of SMP architectures.

The only difference between multithreading in single and multicore systems is that threads can actually really run in parallel (instead of waiting for their timeslice) when the OS spreads them over the available processors/processor cores. So you if you spawn one thread per object, your program would in best case be spread over all available cores.

No more than 5 years.

No.

That's not entirely true. There are plenty of ways to take advantage of more cores - they're already doing it on the graphics card.

Well that's what you get for using a language that's over 20 years old and inherently poor at multithreading.

Here at Valve we shall champion the evolution of multi-core gaming.

Interesting, sounds like programming languages will have to change quite a bit for multi cores.
Jim

Depends on the level you're acting on. If you're using an engine which is subdivided into meaningful threadable pieces then not this much.

Maybe some C/C++ tools that are converted to multicore technology. Wonder if Intel or Microsoft would have thought about that one. Most certainly hope that the people behind GCC and MinGW will come up with new compilers and new ways of making programs work with the new hardware.

The only real gaming applications for multicore CPUs are physics and streaming media loading. Everything else is just Intel's marketing BS.

That's not true: procedural content creation and AI are also ideal for multithreading. Apart from that multithreaded software rendering could be very cool, too.

Well, can't think two ways about it, if there were any games that supported the old Hyper-Threading technology, would there be a chance those same games would run under two true cores, as opposed to a "virtual" second core like before?

Yeah. It doesn't matter to the scheduler (which assigns time slices to individual threads and processes) whether it's an extra pipeline, an extra core or an extra CPU that makes up the "other" virtual processor.

Who uses procedural content creation? I've been hearing that it's the new hip thing for 10 years, and have yet to see a practical application. As for AI, I only see multicore processing as being useful for special cases, like a very large number of objects. AI isn't a CPU-intensive task, and raycasts should be cheap if you have them implemented right.

Like I said, Intel marketing hype.

Spore is one.
But most likely the only one I've seen so far.

AI isn't a CPU intense task just because AI does not AI but patterned stuff.
Make them autonomous agents with command hierarchies, group behavior etc and recheck that note on "not cpu intense" from the moment on they use multiple sensors to be environment aware and interact with the environment.
And that on a larger scale than only a small area of movement and 4 agents simultaniously like it happens in by far too many shooters for example.
I've yet to see any game that applies any technology to the AI that is not 20+ years old. If the eye candy backend would be handled with the same lame excuses as AI has been handled for over a decade now, NES would still be mid range graphics!

Well, then you got games that were written around the time that HT technology was around, like Doom 3, HL2, Prey, Oblivion, and all those, now, how do you feel games like those would make the transition from Hyper-Threading to multicore CPUs?