hyperthreading and games
- Thread starter gurgi
- Start date
crystalcube
Newcomer
3dcgi said:
Agreed but they are still not the same. You can do multithreading without parallel processing. You dont need any special compiler for multithreading. Multithreading can achieve performance improvements even on a single CPU while parallel processing takes advantage of multiple CPUs.
crystalcube
Newcomer
gurgi said:So if a developer wrote a multithreaded game it could not only take advantage of HT, but my second CPU? That has to offer more than a 5% performance increase. SMP has been around a lot longer than HT.
Why do you think multithreading can automagically improve performance in games ? The overhead of mutithreading may actually degrade performance in some cases.
crystalcube said:gurgi said:So if a developer wrote a multithreaded game it could not only take advantage of HT, but my second CPU? That has to offer more than a 5% performance increase. SMP has been around a lot longer than HT.
Why do you think multithreading can automagically improve performance in games ? The overhead of mutithreading may actually degrade performance in some cases.
The overhead of using MMX/SSE/SSE2 can also cause more overhead and degrade performance as well. The only reason it isn't becuase the devs use it only when needed.
IE: under very intense math calcs.
sonix666 said:
OK, my point was, and if I made it poorly I apologize, that the primary reason developers for 3d games aren't building multithreaded engines now is the amount of extra work involved compared with single-threaded games. It's way more work right now than it's worth in terms of performance increases. I recall several years ago getting very excited about multithreaded software design because it was easy to see some nice performance advantages running on the relatively very slow hardware at the time. What I did not foresee was the enormous power that economies of scale and market competition was going to bring to the desktop--such as we have today. Heh...
We talked about separate threads for music, 2d animation, physics (though not really of importance there until 3d), and other things, and on the existing hardware of the time the idea sounded appealing.But look around today and the pace of technological advancement is so brisk that the fact is that between the time a game developer begins his game, and ships it, shipping desktop technology has gone beyond the expectations he had when he began development. IE, he's got power to burn he had not anticipated or necessarily planned to ever use. (Games like HL2 and D3 will only scratch the surface of currently shipping DX9 graphics hardware, for instance.)
So for one thing the by-comparson small increases in performance brought about by multithreading just aren't as interesting today as they were, because raw power is seldom a problem. Today--it's simply a matter of the amount of extra work required, not to mention the programming skill and competence needed for multithreaded games, and it simply doesn't pay much of a dividend. That's why I compared it to SSE2 support which comparatively is not that difficult to implement and provides a nice little boost--heck, for P4 SSE2 was really *necessary* as opposed to using its very slow x87 processing (compared to Athlon) as applications routinely did prior to SSE. In terms of time spent for dividend, game developers have had little problem with SSE2. Building multithreaded game engines is not in the same league in terms of pay-off versus time required, however. And that's why we aren't seeing them. I can't think of anything else to add here.
The second thing is your assumptions about P4 HT and overclocking. You probably knew that the orginal P4s--at least the Northwoods--all had disabled HT circuitry built in. But it was disabled permanently in the chip and could never be used. As you recall it wasn't until the P4 ramped to 3GHz that Intel "turned on" the HT circuitry in the P4. And for a long time after, it was the only HT cpu you could buy from Intel. That's because as the HT capability adds additional circuitry in the cpu to do what it does, the additional active transistors affected yields negatively. Also, the additional HT circuitry considerably upped the power consumption of the cpu over that of non-HT-activated P4s, such that Intel had to issue new electrical and thermal guidelines for motherboard makers to support the HT cpu. By waiting until it had successfully ramped P4 to 3GHz before enabling HT in the cpu, Intel was able to "sit on" HT in the P4 until it worked out the yield issues it needed to fix, as well as the specification changes it needed to finalize, before it could begin "turning on" HT on slower-clocked P4s and begin shipping them as such. I think that if Intel had implemented HT, say, at 2.2GHz, for instance, it would have taken them much longer to ramp up to 3GHz than it did. So they got to 3Ghz first and then did HT, and worked backwards in implementing it from there.
What this has to do with overclocking should be obvious--with HT circuitry, the P4 ramps up in MHz much more slowly under the .13 micron processes Intel uses (which is one of the reason they jumped into .09 as they did.) Simply put--you don't have as much headroom in an HT cpu to overclock as you do in a non HT cpu--or else an HT cpu with HT disabled (although I really don't know what the difference between an HT cpu with HT disabled and a non-HT P4 might be when ramping up the clock in over clocking.)
But because of the added thermal and electrical power demands HT circuitry brings to the P4, overclocking it is definitely a different picture. So it's really not accurate to talk about an HT-enabled P4 in terms of overclocking as you would in comparing it to a non-HT P4 and overclocking.) That's what it looks like to me, anyway. 3.2+ Ghz in the HT Northwood cpu is pretty much all she wrote in terms of clock--as far as something Intel is going to sell and guarantee and validate, until Prescott at .09.
Next is the problem that HT in the P4 is not consistent in terms of performance in multithreaded applications. Performance ranges from a -10% to a +30% when HT is turned on. In most cases of a positive performance gain, you'll see something around 10%-15%. So, how does this inspire a game developer to spend many extra hours programming a multithreaded game when he could conceivably wind up with an engine which runs slower that the single threaded version would run...? Is he then going to spend additional weeks or months prodding his software in order to tweak out a 10% gain, in addition to all of the extra time he's already spent doing a multithreaded engine to begin with? I think you can answer that...
But when you either do a reasonable overclock, or else simply buy a faster P4, the performance gains will be pretty consistent and predictible for the developer in his single-threaded game. There's a lot for a developer to consider here.
That's why I said earlier that while HT in the P4 serves a useful purpose for Intel marketing, it doesn't pay anyone to assume that software game developers have the same goals as Intel. Intel sells the cpu, the developer sells his game. Big difference. Whole different set of design, development, and support imperatives.
Finally, here, is the subject of backwards compatability. Is there a single game shipping today which says on the box "3Ghz P4 or 2Ghz Athlon required"...? Most 3d games are designed to run optimally on far less cpu power. Doesn't mean having a faster cpu won't help--just that one isn't required to run the game with decent performance. The game developer has to consider his target market. His goal is not to promote cpus of any type--but to sell as many copies of his software as he can. His concerns are not Intel's concerns or AMD's concerns, in other words. Millions of people in that market will not have HT P4s, but will be using non-HT P4s or Athlons, or even P3's, and some K6's event. All you have there is further disincentive for going multithreaded by the game developer.
The whole point is that for doing multithreaded games there are many more "gotchas" for the game developer than there are incentives at the present time. That's the way it looks to me--and that's all I can say.
Well, talking about SMP and multiple-core cpus is a much different subject than talking about an HT P4, or an AFX, Athlon, or Prescott. Game developers tend to think in timespans relative to the games they are working on. The one thing I think you can count on them to do, however, is not to develop software based on theories as to "what is coming to the x86 desktop in 3-5x years." They are smart enough to know that they aren't smart enough to look that far ahead and get it right--so they're not even going to try....
I know I'm not smart enough to do that, either...What I find interesting about your idea of what's coming is you seem to think that, in the unlikely event that AMD or Intel were to bring dual-core cpus to the x86 desktop market two years from now, that everybody's singlethreaded software would become irrelevant overnight. I don't think that's a logical assumption. In fact, I would assume that two years from now an x86 dual-core cpu would indeed run a singlethreaded application a good deal faster than current x86 cpus run them, instead. Further, you have to consider that if and when dual-core cpus are introduced into the x86 desktop segment of the market, there will be maybe 150,000,000 (maybe a lot more--I really couldn't say) single-core cpu machines in use around the world from which their owners will be deriving great utility. In other words, it won't be for a period of years after the introduction of the first dual-core cpus that we see dual-core cpus totally integrated into the landscape. People are not going to run out and dump their current machines the day after the first dual-core cpu is introduced into the x86 desktop market. Integration will be slow for a lot of reason, and take years, IMO.
I'm not saying I am opposed to multithreaded software...
I'm not. What I'm trying to present for you is a viewpoint consistent with the kinds of considerations a game developer working in the present has to consider. Sure, in 2013 there might not be *anything but* multicore cpus everywhere and everything will be multithreaded from the start, and single-core cpus will be as antiquated as '486 DOS machines are today (although in some places hardware and software like that is still in use.) But game developers really can't be expected to make decisions *today* about a game they want to ship in 18 months that are based on theories about unnannounced cpu architectures of the future. What they have to work with is the present technology available, and as I pointed out earlier, they also have to consider maintaining support for the past technology still widely deployed. The vast majority of machines in use around the world are not 3Ghz Northwoods or 2GHz Athlons, and game developers want to reach as wide an audience as possible--not one as artificially small as they can make it. And I certainly can't blame 'em...as they have to eat, too...Whew--I'm talked out on this subject--but it was interesting. This just constitutes my own opinion, of course, and doesn't necessarily invalidate yours. It's just the way things look to me...
A long time ago, in a distant past, (well, not actually of course, 20 years ago, but prehistoric in IT-terms anyway ), a game loop consisted of: drawing a bit to the screen, playing a tune, updating an object, drawing some more, playing another tune, updating the next object, drawing a bit more, playing the next note, activating a trigger, etc.
And not much has changed.
Ok, the framerate increased so much, that the other things could be done a bit at a time each iteration of the drawing process. In chunks. Draw a frame, check your input, update the objects, check your sounds, run a bit AI, etc. Due to raw power it has become a bit easier.
And to wring each and every last FPS out of the hardware, multithreading is no improvement. Better cut down on all the other stuff.
But if you use different threads for the different things, you want to make sure, that there are no dependancies. No inter-process communications. No dependent writes. No multiple processors. That only generates overhead.
But, those dependencies are there anyway! Check your input before calculating the objects. And then you know what sounds to play. Etc. So you split that up and 'stagger' the interdependend bits chunk by chunk through the game loop. Or just call them in sequence each iteration and let them perform the next bit. Lots of work. And overhead!
As long as all your processes use the same dataspace, multithreading is not much of a problem. Just make sure that each variable is only modified by one process. And you want that anyway.
And when you write the program that way and want to change the gameplay, you just alter the priority of the individual threads slightly. Harder? Give the AI a higer priority. More FPS? Give the graphic thread a higher priority. Better sound? Better reaction to the controls (user input)? Etc.
That's a whole lot easier than cutting those bits up in different-sized chunks each time! Or using another mechanism to gradually increase/decrease the fidelity of that sub-process.
So, with multi-threading you can do all that, and make life easier for the programmers as well. Just don't try to do inter-process communications. And on a single processor, it is easier to do than on multiple processors.
), a game loop consisted of: drawing a bit to the screen, playing a tune, updating an object, drawing some more, playing another tune, updating the next object, drawing a bit more, playing the next note, activating a trigger, etc.And not much has changed.
Ok, the framerate increased so much, that the other things could be done a bit at a time each iteration of the drawing process. In chunks. Draw a frame, check your input, update the objects, check your sounds, run a bit AI, etc. Due to raw power it has become a bit easier.
And to wring each and every last FPS out of the hardware, multithreading is no improvement. Better cut down on all the other stuff.
But if you use different threads for the different things, you want to make sure, that there are no dependancies. No inter-process communications. No dependent writes. No multiple processors. That only generates overhead.
But, those dependencies are there anyway! Check your input before calculating the objects. And then you know what sounds to play. Etc. So you split that up and 'stagger' the interdependend bits chunk by chunk through the game loop. Or just call them in sequence each iteration and let them perform the next bit. Lots of work. And overhead!
As long as all your processes use the same dataspace, multithreading is not much of a problem. Just make sure that each variable is only modified by one process. And you want that anyway.
And when you write the program that way and want to change the gameplay, you just alter the priority of the individual threads slightly. Harder? Give the AI a higer priority. More FPS? Give the graphic thread a higher priority. Better sound? Better reaction to the controls (user input)? Etc.
That's a whole lot easier than cutting those bits up in different-sized chunks each time! Or using another mechanism to gradually increase/decrease the fidelity of that sub-process.
So, with multi-threading you can do all that, and make life easier for the programmers as well. Just don't try to do inter-process communications. And on a single processor, it is easier to do than on multiple processors.
crystalcube
Newcomer
3dcgi said:
I never said you did, I was just highlighting a few differences between parallel processing & multithreading and thats just one of the difference. btw openMP is not an easy way to write multithreaded code for single or multi processor. You can possibly write mt code easily using the standard mt api for any OS.
A very easy way to use multiple processes is to have the main thread spawn them. Not really 'threads', but the difference is small. You can use messages to communicate, if you would want to. But you would need to use a trick to have a global dataspace that way.
Sounds like there are many non-programmers arguing on the, "HT isn't that great" side of the fence.
HT will exist in all Intel CPUs, AMD has its own plans to introduce something along the lines of a dual core system.
Games and their engines, content and tools are taking longer and longer to develop. The times are starting to easily hit 3 years for a good game. That's with a lot of overlap, it wouldn't be suprising if it's about 2 years or more per section. It is foolish for companies to invest in building games from scratch. Already the trend is to license all but the stuff that doesn't already exist, which is usually content.
Game engines are starting to break down into their own sub-categories, with physics engines, sound engines and graphics engines.
Companies that are going to start providing these solutions will take advantage of HT as it's going to become more and more well estabilished.
Additionally, for those foolish enough to make the, "why optimise for HT when x86-64 is a compile away" arguement, that's a one time gain, once you get the extra registers, that's it!
HT will exist in all Intel CPUs, AMD has its own plans to introduce something along the lines of a dual core system.
Games and their engines, content and tools are taking longer and longer to develop. The times are starting to easily hit 3 years for a good game. That's with a lot of overlap, it wouldn't be suprising if it's about 2 years or more per section. It is foolish for companies to invest in building games from scratch. Already the trend is to license all but the stuff that doesn't already exist, which is usually content.
Game engines are starting to break down into their own sub-categories, with physics engines, sound engines and graphics engines.
Companies that are going to start providing these solutions will take advantage of HT as it's going to become more and more well estabilished.
Additionally, for those foolish enough to make the, "why optimise for HT when x86-64 is a compile away" arguement, that's a one time gain, once you get the extra registers, that's it!
Lille_Skutt
Newcomer
I am a non-programmer that likes to play games once in a while. I have an old dual P3 system that I use most for CAD. A couple of years ago we, me and my friends, played Quake3 a lot. I noticed a huge performance in some maps over my friends systems who only had one CPU. When there was a lot of players and movements in a map I could gain as much as 50% in FPS-performance. Here are some numbers that I had written down from that time.
Quake3 v1.17 (high quality settings)
timedemo 1
1 cpu: 99 fps
2 cpu: 116 fps
nv15 bunker timedemo
1 cpu: 27 fps
2 cpu: 43 fps
So you programmers out there have to start learning how to make multithreaded games and apps too.
Take my CAD program for example. I am using CATIA v5 and the modules I use are not multithreaded. I don´t know if I would gain performance if these modules would have been programmed with multithreading in mind.....but when I rotate some models I can see 100% CPU usage on one of my CPUs. The second CPU is idling at 0%. I have no idea how difficult it is to make a code multithreaded.
I know there aren´t so many dual CPU system among gamers so why bother....but it would be nice to see more multhreaded games.
Quake3 v1.17 (high quality settings)
timedemo 1
1 cpu: 99 fps
2 cpu: 116 fps
nv15 bunker timedemo
1 cpu: 27 fps
2 cpu: 43 fps
So you programmers out there have to start learning how to make multithreaded games and apps too.
Take my CAD program for example. I am using CATIA v5 and the modules I use are not multithreaded. I don´t know if I would gain performance if these modules would have been programmed with multithreading in mind.....but when I rotate some models I can see 100% CPU usage on one of my CPUs. The second CPU is idling at 0%. I have no idea how difficult it is to make a code multithreaded.
I know there aren´t so many dual CPU system among gamers so why bother....but it would be nice to see more multhreaded games.
