hyperthreading and games

[Saem]

I'm not sure how 64bit ints are going to help much in games. I think people need to remember the extra registers is where the performance will come in not the extra bits.

As for parallelism, I don't seem it being exploited heavily until we get languages that are better suited for the task.

 

[mczak]

When I got my dual Xeon Machine last december, hyperthreading was only available in the Xeons and not the P4's yet.

..or am I remembering wrong. What CPU introduced HT to the gaming market and when?

xeons had HT before the P4, but the 3.06 was launched 14 nov 2002. I doubt that volume of HT-enabled P4 was very high until the 800Mhz FSB cpus (which all have HT) shipped though. The first 800Mhz FSB was the 3.0C, launched 14 april 2003, the other 800Mhz FSB parts (2.4, 2.6, 2.8 and 3.2Ghz up to now) followed even later (june?).

 

[Bouncing Zabaglione Bros.]

When I got my dual Xeon Machine last december, hyperthreading was only available in the Xeons and not the P4's yet.

Im not saying HT is beneficial, but making an argument that they are available and thuse we would see it taken advantage of in games doesnt make sense to me. Especially since AMD has a piece of the gaming pie.

..or am I remembering wrong. What CPU introduced HT to the gaming market and when?

Well that's kind of my point. My recollection is that HT arrive with the 3.06 gig P4, which is what, six month back? In which case there arn't that many HT P4's making up significant parts of the gaming market, and there's no payback in developers spending time and money coding HT for them.

If (as incurable contends) there have been millions of HT enabled processors sold into the gaming market over the last two years and I am underestimating their usefulness, why don't we see more (or any) multithreaded games that make use of HT?

I think the answer is that it is too much hard work for too little payback. Sure, you can set a switch and compile for HT, but you don't gain much. The only way to make gains is to spend a large amount of time and money doing a complete top-to-bottom, multithreaded design.

The only way multithreading will take off is if the compilers arrive to make it transparent, which will only happen when everyone has multiple CPU's - we're far off from that.

 

[Saem]

I believe there is HT on CPUs alway the way down to 2.4 GHz.

 

[BRiT]

IIRC, Only the newer 2.4C models have HT. The old models do not.

 

[Cyberon]

HT will not help games much. It's quite logical; HT is optimising the chips performance by using those parts of the pipeline not used by the app (simpy put, i am no hardware geek). however, i can imagine a game uses some parts of the cpu-core consequently and other parts rare or not. So HT doesn't have much "room" to operate since the parts it needs are already in use. Seems to me HT benefits the most when there are more then one application is running or games.

It isn't so hard for me to imagine this, for example; take a production-line

you have 9 processes 1,2,3,4,5,6,7,8,9

product a is made by 1,2,3,4,5,6
product b is made by 5,6,7,8,9

if both the products are made, product a and b can achieve a boost
a never used 7,8 and 9 and b never 1,2,3, and 4
with a clever manager you can cut time and money..
while when you always make product a
7,8,9 are always idle so you not get the best efficiency from your productline....

So a game runs it code, much of it is the same process using the same parts of the core in the same way. HT won't do much (maybe helps some with the processes in the background; thats it).

 

[Oompa Loompa]

Are you suggesting that developers should spend significant amounts of time and money, increasing development time and costs in order to give a very small gain for a very small part of the market?

Hmm. Have you looked at Intel's market share recently? Have you noticed that they are transitioning all of their product lines to HT?

The point is that the investement for HT means a lot of work for the developer with very little payoff. Why would a developer put that investment in for a game who's life will be over by the time multithreading will make any difference - especially as by that point there will be more payback from the newer CPU/VPU's ? It's just not very economical.

As I said in my last message, the short term payoff is minimal. And taking an existing engine and hacking it to create additional threads probably isn't worth the effort. However, starting a NEW project with a multithreaded engine is a wise investment. Again, you don't seem to understand that CPU and VPU speed increases are a given, and play no role in the developer's decision regarding what CPU specific optimizations to apply.

But if was writing game engines, I'd ask myself what technologies I will *need* to have in my games 2-3 years from now, and begin to figure out how to build those in. 64-bit is a useful advance, but so long as AMD is the only one promoting it, it will never go mainstream. It's that simple.

I think you'll find that there is a great deal of potential parallelism in a modern game. The types of applications we're describing are essentially life simulators, with simulated individuals making independent decisions, and being independently acted on by physical rules. The renderer is a different matter, but then, that's a problem for the video processor.

Let's see *your* evidence for this assertation, epecially given what Valve recently said and is quoted above. You will gain very little by parallelising the things (such as your music code), if they only take a very small amount of your game cycle. The place you will make gains is in the things your engine spends the most time doing, ie rendering.

My assumption is that in order to make games more lifelike and interactive, AI-related processing will become more significant, and rendering less so. That's certainly what Warren Spector and Doug Church are saying.

You're suggesting that it's economical for a developer to spend time and effort designing, coding, and maintaining a *second* multithreading version of their code, for HT processors that have only just arrived on the very high end of the CPU market, and does not even exist on the AMD processors that are a significant part of the gaming market?

I guess you aren't up to speed on how HT works. Non-HT processors run threaded code just fine. Have you ever used Windows Media Encoder on your AMD CPU?

What you don't seem to understand is that supporting 64 bit is relatively easy - for the most part you just need to recompile your code, so unless you've written something really badly, or very close to particular hardware, its realtively little work, for a payback of 30-50 percent depending on the app. It's near transparent if your code is portable.

Yeah, it's almost as easy as supporting TrueForm for ATI-based video cards, or triple-head displays for Matrox cards. But developers can be quite ruthless when it comes to denying support for fringe markets.

AMD has just launched the Athlon 64 platform. How many endorsements and commitments from game developers to make 64-bit code did you see?

That's exactly how many 64 bit games you should expect. It sucks, but to expect developers to do charity work is... unwise.

As for addressing your intention to belittle me as some kind of AMD fan boy, are you some kind of Intel fan boy because you think HT is the only way forward? Would you be disturbed to hear that at the recent Athlon 64 launch that AMD also said they intended to move forward with HT-type pseudo-multiple processors-on-a-single-die on their future Athlon 64s?

Er... why do you think being called an AMD fan is an insult? You are reacting hysterically.

 

[Bouncing Zabaglione Bros.]

Hmm. Have you looked at Intel's market share recently? Have you noticed that they are transitioning all of their product lines to HT?

The impact of multithreading for games in a HT "fake dual processor" P4 is tiny when compared to CPU/VPU performance. That's why we still see no multithreaded games, and the major developers have it at the bottom of their lists of "worthwhile things to optimise for".

 

[WaltC]

Then they'd better well start optimizing, because the P4 has the largest part of the market AND currently only has Hyperthreaded versions in stores.

OK, so you're saying software developers should spend 50% more programming time in order to construct multithreaded games simply so that people with 2.8GHz P4s can turn on multithreading and run the games as fast as people with 3.0-3.2GHz P4s with multithreading turned off? Or better yet--to get the same performance that people who overclock their P4's by ~15% can get without invoking HT at all?

It's just not going to happen. Look at it this way: most games already run optimally on non-HT P4's and AXPs running a good deal slower than 3GHz...the task of writing a multithreaded game is simply a lot of wasted time--a lot--because the need for it just isn't there. Even if you devote so much extra time--writing multithreaded game software is not a trivial exercise--the pay off in added performance is *trivial.* It's a simple case of the advantages being far outweighed by the disadvantages--from the developer's perspective, of course.

As well, although P4 rules in the general market in terms of quantities when the pre-Opteron business market is included (which makes up 80% of Intel's cpu sales--which is likely to change in the next year as Opteron takes hold), the fact is that the 3d-gaming marketplace consists mainly of Athlons at present (at least--every 3d-gaming site I've seen which has run a cpu poll shows Athlons used by 70-80% of their readers who respond to the poll), and many non-HT capable P4's. The numbers just don't persuade game developers to write multithreaded games. They just aren't there--whether you talk about general performance benefits to writing their engines multithreaded or you talk about the number of users or you talk about the performance increases possible but not guaranteed by HT. The numbers simply don't justify the work--it's a non-trivial exercise.

This is the problem--game developers aren't pushing cpus and gpus--game developers are pushing their *games*, ironically enough... When I hear folks expounding on what game developers *better* do--like writing multithreaded game engines/games and writing in special code paths for specific 3d cards--I just have to think that these people have gotten the goals of game developers and the goals of cpu/gpu manufacturers completely confused. It's in Intel's marketing advantage to tout HYPErthreading, and it's in nVidia's marketing advantage to discuss nVidia-specific code paths as alternatives to the API--but *neither* of these things is congruent with the goals or advantages of game developers--whose goal is to create great games that run well on most hardware and adhere to the standard API conventions.

HYPErthreading, from the standpoint of your basic 3d gamer, is pretty much irrelevant. The users can get much more performance, and often do, from simply overclocking non-HT cpus.

So what's a likely "optimization" that game developers can use that will make a performance difference...? SSE2 support is one, and I suspect we'll see this really take off now that Athlon supports SSE2. Things like that are nowhere as difficult to implement as multithreading. Besides, any cpu can theoretically benefit from multiple threads in an application or OS--you don't have to have an HT cpu to run multithreaded software in the first place. What HT does for the P4 is make it more efficient per clock while running *some* multithreaded software. Some multithreaded software shows a performance deficit when HT is turned on--so it's neither consistent nor guaranteed--certainly nothing like simply ramping up the cpu clock will do for general performance. The simple truth is that someone with a 2.8Ghz non-HT P4 is going to run multithreaded applications faster than someone with a 2.2GHz HT-enable P4 is going to run them.

Basically, what I'm saying is that if and when game developers start doing multithreaded games it will be because of reasons other than HT in the P4 that they do so. The fact is that you don't *need* to use HT at all to get good performance from a P4, and you don't need an HT-enabled P4 to run multithreaded software.

 

[3dcgi]

Personally I think HT is most useful for non-game apps, but I hope Intel's developer relations people are getting companies to start multi-threading their software and games. That way when dual core chips start arriving in a few years the apps will be there to take advantage of them.

 

[cthellis42]

64-bit is a useful advance, but so long as AMD is the only one promoting it, it will never go mainstream. It's that simple.

Do you seriously think Intel is going to remain 32-bit for many years to come? Of course not. AMD beat them out of the gate with it, but they will bring 64-bit to bear soon as well. Some aspects are rumored to be coming in with Prescott, in fact.

64-bit would seem to be a useful investment in exactly the way you're talking about, as though only the AMD Hammer chips right now are using it, more will follow.

Meanwhile the "easier time making more noticable enhancements" part still stands.

 

[Oompa Loompa]

Do you seriously think Intel is going to remain 32-bit for many years to come? Of course not. AMD beat them out of the gate with it, but they will bring 64-bit to bear soon as well. Some aspects are rumored to be coming in with Prescott, in fact.

I choose to take Intel at their word: no 64-bit desktop CPUs in the few years. Obviously they are working on it - it's just a question of when it appears. But in the two year time frame that has been discussed in this thread, I don't expect Intel to release anything.

At the moment, 64 bit math can probably do more for games, with less effort, than optimizing for hyperthreading. As I said before, the only really interesting thing about HT for gaming is that it provides an entry point to threaded programming, which everyone will eventually need to use in order to exploit increasingly parallelized processing power. However, none of this really matters compared to market sizes - and it will be quite a while before Athlon64 chips are available for the sub-$100 commodity prices people are accustomed to paying for their AMD processors. And even then, fab capacity limitations mean that the rate of proliferation is limited.

So unless AMD starts throwing money at game developers to deliver AMD64 products (which would work wonders, I'm sure), I expect support to arrive rather slowly.

 

[cthellis42]

You might be surprised. Devs do like to do something "new" and "super-duper" and all that, and if the modifications are not entirely burdensome... It's just extra marketing for them to say "64-bit," and the chips themselves are the newest thing of any real excitement to hit the desktop PC's for a while now. Also, AMD being rather a gamer/enthusiast choice makes for extra props for... well... them gamers. Likely devs can do a bit of number-crunching for added props, and so long as they can find at least ONE bench showing impressive gains, they'll have a nifty enticement.

It's not something that will supercede the usual process, but of the "extra features" to throw in, it is one of the most visual right now, and hence--good advetising.

 

[WaltC]

Personally I think HT is most useful for non-game apps, but I hope Intel's developer relations people are getting companies to start multi-threading their software and games. That way when dual core chips start arriving in a few years the apps will be there to take advantage of them.

I agree with you--I very much like the concept of multiple threads and always have. Don't want you to think I oppose the concept because I certainly don't. I'm being realistic, though, I think, in saying that with current cpu power on the desktop, and likely in the future, the incentive for developers to spend the extra time--which would be considerable--in writing mutlithreaded engines/games just isn't there. To be blunt, I'm not sure how many game development houses even have that kind of know-how on staff--it's a considerable job, IMO. And like with anything else, its pros and cons have to be evaluated from the standpoint of the age-old equation Time = Money... If it was as easy as adding SSE2 support we'd already see gobs of multithreaded games...

What I objected to in the post I responded to above is the implication that there's some "special" relationship between multithreaded software and the cpu feature Intel markets as HYPErthreading. That's what really sticks in my craw...

Clearly, even today, the much superior path to a P4 HT cpu is SMP, if your interest is in running multiple threaded software, and your other interest is performance. Two cpus running two threads is always--always--a LOT better than one cpu multitasking two threads in its single core--which is what the P4 and every other cpu currently shipping do when they run multithreaded software. When you have two cpus you can literally run two threads at the same time--a thread executes on each respective cpu simultaneously. The difference between SMT/SMP and SMT/single-cpu HYPErthreading is huge. While it's not uncommon to see a linear performance increase in dual-cpu SMP rigs of 100% in *some software* while doing SMT, you'll be very lucky indeed to hit a 30% improvement under the same conditions using HYPErthreading in a single P4 (I capitalize "HYPE" because I think the word needs to be emphasized in relation to this feature.)

I'm not trying to say that, for the P4 architecture, HYPErthreading isn't a valid "feature", only that it's much more valuable to Intel as a marketing gimmick than it is to an end user whose primary use of his machine is running 3d games... It helps Intel, but does comparatively nothing for the end user in this case, except to lighten his wallet a bit more...

As far as a "catalyst" goes for developing multithreaded software--of course x86 SMP rigs, by both Intel and AMD, have been with us for years, already. If their presence hasn't spurred more multithreaded software development, then it's unlikely that the the P4's HYPErthreading capability will do any better. Chief reason I think this is because you don't need an HT P4 to run multithreaded software--and never have. Theoretically, running any old cpu, you should get some performance benefit out of running multithreaded software normally, since you can "multitask threads" provided the OS supports it. The problem unfortunately, is the same without regard to owning an HT cpu--the added development time and effort doesn't equal the payoff--by a long shot. Of course, in very expensive professional software of various types--programs selling for hundreds/thousands of dollars--written to run on SMP rigs of great power--the development angle is much different, and the extra boost in performance is considered worthwhile.

Really, I guess the way I look at it is that a 3d-gamer using an HT-capable cpu is doing "play SMT," whereas you really need to go SMP and spend the bucks if you want to see the advantages of multithreaded software performance, in reality.

How will mutlitple-core cpus affect things? I really don't know... I would imagine off hand--not much--and that it'll be very much like the kind of situation that exists today if you really want to pay for SMP hardware and the applications that can make use of multithreaded performance. IE, the way the next couple of years look from here, it's going to be years and years before we see dual-core cpus making it out into the mass consumer markets. First, they'll go to businesses and professionals and, after a couple of years of saturation, they *may* filter down into the consumer markets. I mean, dual-SMP rigs have been available for years now, mainly in the professional markets, but the consumer cpu market is still very much dominated by the single cpu.

OK, I'll quit boring you...

 

[3dcgi]

If anyone is interested in trying out multi-threaded programming I recommend http://www.openmp.org/. You need a compiler that supports it like Intel's, but it is very easy to use if your application is easily parallelizeable.

 

[MfA]

The only thing easy about shared memory parallel programming is introducing bugs.

 

[crystalcube]

If anyone is interested in trying out multi-threaded programming I recommend http://www.openmp.org/. You need a compiler that supports it like Intel's, but it is very easy to use if your application is easily parallelizeable.

Parallel programming and multithreaded pragramming are different thing.

 

[Gubbi]

A better (easier) place to start is with the jCSP lib

Once you have modelled parallel processes with CSP it is real hard to go back to monitor based approaches.

Cheers
Gubbi

 

[Frank]

Isn't hyperthreading just that each process (up to a maximum number) gets its own set of registers, so you don't have to store and recall the processor state while swapping processes (context switching)? If that's the case, you can indeed improve things a bit.

The problem with threads is the interprocess communication. That's why SMP is not twice as fast as a single processor. But there is a good thing to running multiple threads/processes without the overhead on a single processor: if you use a common data space, there is no need to check for dependant writes, as there can only be one process active at any one time. (As long as you make sure a thread finishes it's writes before being swapped out, that is.)

So, if you write your code in such a way, you don't need your main loop to check for actions that happen only part of the time (like running a complex bit of AI) and breaking that up in chunks to prevent the framerate dropping a bit every so many frames when you run that part.

So, it can make life quite a bit easier for the programmers.

 

[sonix666]

WaltC, I really don't understand your viewpoint on Hyperthreading. Game developers won't use it because gamers can overclock their P4 by 15%? What on earth has that got to do with eachother. Just imagine, 15% improvent from HyperThreading *and* 15% overclock.

The simple fact is, wheter you want to acknowledge it or not, that CPU designs will go more and more towards parallellity. Both Intel, AMD and every other manufacturer has plans for SMT (Hyperthreading) and multiple cores on one die. Intel even sees the need for dual cores on the desktop withing two years.

Game developers will go the multithreaded route, but I do agree, not for existing engines. However, there is a big chance that new projects built from the ground up will be built with multithreading in mind.

It is plainly sad that UT2k3 has a 'reduce mouse lag' option that tries to sync your framerate to the mouse update rate to avoid any controller lag (because it might miss any changes in mouse state). This ofcourse results in (much) lower framerates. If it were done in a seperate thread from the renderer thread I wouldn't even dare to imagine why such an option would be necessary.

Even more rediculous is that the world ticks (AI/world update rate) depend on your framerate. So, depending on how fast your scene can be built from any position this might be faster or slower. The AI code and such have to adjust for this kind of effect (at least in original UT). Do it in another thread at a fixed rate, independant from the rendering thread.

I see enough reasons why multithreading in engines might be beneficial. Maybe not for performance reasons, but surely for responsiveness.