On dual core processors - to prevent misinformation
I wrote this on some other game forum because people apparantly have a lot of misconceptions about multi cores and how this works and affects single core users (in short support for multi core doesn't affect single core users at all, can only benifit them):
Quote:
The reason that they havent coded for multi core is not because it is hard, it is because it would be hard to support both single and multi core in the same game. And since most gamers are still running single core it just doesnt merit the switch. I'd wager in a year or two things will change.
Um. What?
No wait, let me read that over again...
Um, what?
Speaking as a software engineer and indie game developer who's done both clients and servers, I can say that statement is completely and utterly false. In fact, I'm in the process of assembling a dual core computer myself, because I understand how it works. I don't want people to be dissuaded from getting a dual core CPU because of false information, so here is how it works to the best of my knowledge:
Dual core basically means you have two processors built into one, and both can run simultaneously, simultaneously processing input. Unfortunately there is one big software implication (in fact two):
1. You must have an OS that supports dual core. AFAIK but I'm not 100% sure thats Windows XP Pro but not Home, Vista, and various forms of linux.
2. The software you're running must be multithreaded.
A little explanation about multithreading. Normally when you have a program it runs sequentially, waiting for one operation to process before hopping to the next, waiting until that is done, and so on and so forth. While the term isn't used often this fully sequential running of code is called "single threaded".
Why? Because a "thread" is a segment of code being executed independantly. This is what creates multitasking. All your applications have one or more threads. Without threads you'd have... well, DOS. Run one program at a time one step at a time and when it's done you can run another.
So your IRC program will be running on a thread, as your browser, as your mp3 player. Because threads allow a computer to execute multiple code segments in a lateral fashion (at the same time), as opposed to sequentially.
Problem is, you can't simply "split a thread" and push it onto two processors. This would break the code, since the practice of code is built on the premise that a code segment will be executed sequentially, not simultaneously.
An example chunk of code:
a = 1
b = 3
a = b + 2
b = b + 5
You cannot run parts of this at the same time. You HAVE to first assign 1 to a, then 3 to b, and so on and so forth. If you don't you might wind up with the value of "a" being equal to 10, instead of 5.
Okay, so you can't split a thread. What implications does that have for dual core?
The implication is, a singlethreaded application CANNOT use both cores. They will use one or the other, and you can probably depending on your OS tell it which core to use, but it will still use only half the potential of your dual core CPU. Period.
The solution is, where possible, to perform two difference operations simultaneously. You now have a "multithreaded" application. Since you have more than one thread, you can use more than once CPU. Not all software is fit for this model; some just need to be completely sequential, and some just don't have enough complexity to be able to break it up into two chunks to do simultaneously.
For example: hellgate london could use various threads. They could use one thread for input, one thread for rendering, one thread for networking, and one thread for physics and logic. That's four things it's doing simultaneously, and four things it can do on whichever core you have available. If you have one dual core CPU it'll do two things on one core, and two things on the other, full utilizing the resources your hardware has to offer. If however (and it won't according to ivan) simply processes network, input, physics and logic, and then rendering in sequence on a single thread then it'll only use one core and only half the potential of your system.
But doing that would just be plain silly when you might as well split it up and not shaft your users.
The funny thing is, multithreading is nothing new. You can multithread on a single core CPU. You've been doing it since you ditched the DOS days and have been multitasking! So the only thing a developer has to do to make software "dual core capable" is split its operations into multiple threads, the load of which can be distributed among multiple cores. On a single core its no different from running two programs simultaneously, but since there's only a single core it'll split resources.
There is no loss from that. Having to execute all the code on a single core would still require these resources. In fact often multithreaded applications on a SINGLE core can have small boosts in performance, as opposed to any decrease.
So there really is no question of wether an application supports single core and/or multi core. If it supports multi core it supports single core and it might even run better on the latter. However not all applications support multi core, while all support single core. And yes, it /is/ harder to code for dual core. Multithreading is a dangerous business that can create a lot of subtle and elusive bugs from where threads overlap, or even create certain situations where the software will simply freeze up entirely due to threads waiting on eachother to finish something. Of course, if done well, there are none of these problems. The concept of dealing with these problems is called "thread safety", and I won't go into that here as well.
Now, with all that out of the way, here are the considerations for buying a dual core:
1. There is no reason to be afraid that programs that can in any fashion split their functions won't do so. The programs will still run just as well if not better on a single core if they multithread, and will take advantage of multicore CPUs which are the obvious future for compting.
2. Older software is often NOT going to be multithreaded and cannot take advantage of dual core technology. If your favourite FPS isn't multithreaded it's not going to run better on a 2.13 ghz dual core than on a 3ghz single core; in fact it will run better on the single core.
Unfortunately you have to choose then; do I want to run all software at an averagely better speed, or do I want to run some software (that probably doesn't need all the juice anyhow) to run slightly below average while giving a huge boost to intensive games and software that do need it?
If it were me, and it is, I'd buy a dual core over a single core. There's only so much speed they can stuff into one core and it really seems like the way to the future is dual core and then multi core. Mind, the same problems that apply to single vs dual core software will apply then too; if a program only uses two threads and you have three cores one won't be used.
Professional developers who make software that can use the extra speed afforded by using two cores will most likely start developing all that software to do this; because they have nothing to lose! Single core processors will still run the program just as well, if not slightly better due to the threading. So again it's not a question of supporting both single and dual core in the same game, it's just a question of supporting dual core at all, and that decision has no effect on single core users, so will never be a deterrent to making a program make use of dual core.
In fact, developers have already been writing multithreaded applications for a long time now, since having two CPUs on one computer was already an option long before dual core in a single CPU arrived on the scene. Though it was mostly for servers and the most avid of gamers. Again; if a program can at all use multithread there is no reason not to in terms of support for single core.
It's a very different problematic than for instance supporting physics card. Because there you /would/ have to write both an implementation that utilizes the hardware physics card, /and/ write your own software implementation.
Right, if anyone reads all that, I'll be thoroughly amazed, just didn't like the thought of people being misinformed.
Quote:
The reason that they havent coded for multi core is not because it is hard, it is because it would be hard to support both single and multi core in the same game. And since most gamers are still running single core it just doesnt merit the switch. I'd wager in a year or two things will change.
Um. What?
No wait, let me read that over again...
Um, what?
Speaking as a software engineer and indie game developer who's done both clients and servers, I can say that statement is completely and utterly false. In fact, I'm in the process of assembling a dual core computer myself, because I understand how it works. I don't want people to be dissuaded from getting a dual core CPU because of false information, so here is how it works to the best of my knowledge:
Dual core basically means you have two processors built into one, and both can run simultaneously, simultaneously processing input. Unfortunately there is one big software implication (in fact two):
1. You must have an OS that supports dual core. AFAIK but I'm not 100% sure thats Windows XP Pro but not Home, Vista, and various forms of linux.
2. The software you're running must be multithreaded.
A little explanation about multithreading. Normally when you have a program it runs sequentially, waiting for one operation to process before hopping to the next, waiting until that is done, and so on and so forth. While the term isn't used often this fully sequential running of code is called "single threaded".
Why? Because a "thread" is a segment of code being executed independantly. This is what creates multitasking. All your applications have one or more threads. Without threads you'd have... well, DOS. Run one program at a time one step at a time and when it's done you can run another.
So your IRC program will be running on a thread, as your browser, as your mp3 player. Because threads allow a computer to execute multiple code segments in a lateral fashion (at the same time), as opposed to sequentially.
Problem is, you can't simply "split a thread" and push it onto two processors. This would break the code, since the practice of code is built on the premise that a code segment will be executed sequentially, not simultaneously.
An example chunk of code:
a = 1
b = 3
a = b + 2
b = b + 5
You cannot run parts of this at the same time. You HAVE to first assign 1 to a, then 3 to b, and so on and so forth. If you don't you might wind up with the value of "a" being equal to 10, instead of 5.
Okay, so you can't split a thread. What implications does that have for dual core?
The implication is, a singlethreaded application CANNOT use both cores. They will use one or the other, and you can probably depending on your OS tell it which core to use, but it will still use only half the potential of your dual core CPU. Period.
The solution is, where possible, to perform two difference operations simultaneously. You now have a "multithreaded" application. Since you have more than one thread, you can use more than once CPU. Not all software is fit for this model; some just need to be completely sequential, and some just don't have enough complexity to be able to break it up into two chunks to do simultaneously.
For example: hellgate london could use various threads. They could use one thread for input, one thread for rendering, one thread for networking, and one thread for physics and logic. That's four things it's doing simultaneously, and four things it can do on whichever core you have available. If you have one dual core CPU it'll do two things on one core, and two things on the other, full utilizing the resources your hardware has to offer. If however (and it won't according to ivan) simply processes network, input, physics and logic, and then rendering in sequence on a single thread then it'll only use one core and only half the potential of your system.
But doing that would just be plain silly when you might as well split it up and not shaft your users.
The funny thing is, multithreading is nothing new. You can multithread on a single core CPU. You've been doing it since you ditched the DOS days and have been multitasking! So the only thing a developer has to do to make software "dual core capable" is split its operations into multiple threads, the load of which can be distributed among multiple cores. On a single core its no different from running two programs simultaneously, but since there's only a single core it'll split resources.
There is no loss from that. Having to execute all the code on a single core would still require these resources. In fact often multithreaded applications on a SINGLE core can have small boosts in performance, as opposed to any decrease.
So there really is no question of wether an application supports single core and/or multi core. If it supports multi core it supports single core and it might even run better on the latter. However not all applications support multi core, while all support single core. And yes, it /is/ harder to code for dual core. Multithreading is a dangerous business that can create a lot of subtle and elusive bugs from where threads overlap, or even create certain situations where the software will simply freeze up entirely due to threads waiting on eachother to finish something. Of course, if done well, there are none of these problems. The concept of dealing with these problems is called "thread safety", and I won't go into that here as well.
Now, with all that out of the way, here are the considerations for buying a dual core:
1. There is no reason to be afraid that programs that can in any fashion split their functions won't do so. The programs will still run just as well if not better on a single core if they multithread, and will take advantage of multicore CPUs which are the obvious future for compting.
2. Older software is often NOT going to be multithreaded and cannot take advantage of dual core technology. If your favourite FPS isn't multithreaded it's not going to run better on a 2.13 ghz dual core than on a 3ghz single core; in fact it will run better on the single core.
Unfortunately you have to choose then; do I want to run all software at an averagely better speed, or do I want to run some software (that probably doesn't need all the juice anyhow) to run slightly below average while giving a huge boost to intensive games and software that do need it?
If it were me, and it is, I'd buy a dual core over a single core. There's only so much speed they can stuff into one core and it really seems like the way to the future is dual core and then multi core. Mind, the same problems that apply to single vs dual core software will apply then too; if a program only uses two threads and you have three cores one won't be used.
Professional developers who make software that can use the extra speed afforded by using two cores will most likely start developing all that software to do this; because they have nothing to lose! Single core processors will still run the program just as well, if not slightly better due to the threading. So again it's not a question of supporting both single and dual core in the same game, it's just a question of supporting dual core at all, and that decision has no effect on single core users, so will never be a deterrent to making a program make use of dual core.
In fact, developers have already been writing multithreaded applications for a long time now, since having two CPUs on one computer was already an option long before dual core in a single CPU arrived on the scene. Though it was mostly for servers and the most avid of gamers. Again; if a program can at all use multithread there is no reason not to in terms of support for single core.
It's a very different problematic than for instance supporting physics card. Because there you /would/ have to write both an implementation that utilizes the hardware physics card, /and/ write your own software implementation.
Right, if anyone reads all that, I'll be thoroughly amazed, just didn't like the thought of people being misinformed.