well if you can afford an I-7 get that!!! Then you wont have to worry about upgrading the CPU for a very long time. If on the budget get the I-5 at least you will be good for at least 3 years on most current games i think. If you are struggling get an I-3. At least you will be able to play whatever game you want on medium settings at least.
Uhh, you need to talk to some programmers. Writing multithreaded code is far more difficult, thats why its taken this long to get to the point where you're starting to get programs that are multithreaded that aren't professional programs (i.e. cad/cam software, etc)
Nope. Back in the days when multi-threaded processing came to be it was hard yes. Nowadays the tools and languages have improved and it all works almost natively. Thread synchronization, deadlock checks, race conditions ... those are all things that have been done wrong many many times and are already improved. There are even smart pointers, to stop you from being stupid and waste heap memory all the time. All the things I said are supported in the STL of C++11 which is completely implemented at the big compilers and work is starting on C++17 which will bring even more goodies (but not yet)
Not to mention that you don't always need multi-threaded processing. Simple apps don't. 32-bit, single-threaded wide character support application is still very much acceptable.
Other stop is that old code is not only hard to maintain in most cases, its terribly hard to upgrade. Most of the times its easier/faster/cheaper to start from the scratch. There are many articles about it. All in all ... in the long run ... old codebase costs you more, but your finance manager is never going to *get it* as long as the prices dont go up and you have a working solution with bunch of known bugs and no new ones.
EDIT: Almost forgot to put that there's plethora of ways to do multi-threaded processing. Its not hard as per se. Just requires some forward thinking.
Ontopic ... OP, imagine you ask this question 10 years ago. It would sound like this "Celeron vs Pentium 4...is it worth it". I'd tell you to go with Core 2 Duo which would be the equivalent of i7, because both are not top of the line. Today though, you have cheap AMDs (not that you didn't 10 years ago but that's beside the point). Locked processors are bad idea in general. You want unlocked multiplier. That only works on the i5 (and up) and that, only on the K series which is usually ~50$ plus. The red team however mostly sells unlocked core CPUs, for obvious reasons.
I'm personally still running i5-2500k, old but golden. Plays Dragon Age: Inquisition at ultra graphics paired with R9 290X and Mantle with 60+ FPS. My brother runs the aforementioned FX-6300 and my girlfriend runs FX-8350. Both their motherboards are super cheap and they support overclocking for the price. Both have UEFI bios (yeah that cool stuff) + backup bios if they fuck things up.
Point is ... the 3 of us play Battlefield 3 and 4 at least once a week, mostly Gw2 which god replaced by Dragon Age Inquisition for the time being.
tl;dr. I'd never get an i3. i5 if unlocked is a safe bet. If you are money constrained just go for AMD.
Also don't always believe everything you see. Benchmarks are only relative unless you have the same machine that is tested. Don't be a brand fanboy and always wait for initial reviews before you "pull the trigger". If something is going to give you 5-10 frames per average but costs 100$ more, that's just bullshit. With proper overclocking you'll be able to get that fps back. Be smart, and screw the fanboys.
Originally posted by Quizzical I don't think you know what hyperthreading is.
Haha, it is you who is mistaking Multithreading for Hyperthreading.
Hyperthreading is all about simultanious processing, allocating CPU resources to each logical unit so you can indeed process 2 threads on a single core, albeit not as efficiently.
It is something entirely different from what you wrote up so thoroughly.
Haha, it is you who is mistaking Multithreading for Hyperthreading.
Hyperthreading is all about simultanious processing, allocating CPU resources to each logical unit so you can indeed process 2 threads on a single core, albeit not as efficiently.
It is something entirely different from what you wrote up so thoroughly.
Yes try that on Windows XP service pack 1 *chuckles*
You just need to read better, dont skip through posts You are in an awkward misunderstanding.
Originally posted by BailoPan15Yes try that on Windows XP service pack 1 *chuckles*You just need to read better, dont skip through posts You are in an awkward misunderstanding.
Try what? Multithreading is supported since W2K.
What Quizzical was describing is mutlithreading on single core system, without any Hyperthreading.
Yes try that on Windows XP service pack 1 *chuckles*
You just need to read better, dont skip through posts You are in an awkward misunderstanding.
Try what? Multithreading is supported since W2K.
Hyperthreading is something completely different.
You're weird. You give explanation about hyper threading, I'm telling you to try that on older windows and then you start talking about multi threading
Either way, I wouldn't praise hyper-threading. It's not all cool and flashy as they are marketing it.
Originally posted by BailoPan15 You're weird. You give explanation about hyper threading, I'm telling you to try that on older windows and then you start talking about multi threading
And I am asking trying what?
Hyperthreading isn't related to OS, besides multithreading support.
You're weird. You give explanation about hyper threading, I'm telling you to try that on older windows and then you start talking about multi threading
And I am asking trying what?
Hyperthreading isn't related to OS, besides multithreading support.
Originally posted by BailoPan15It most certainly is. Well sure, not today because Windows is smarter, but to prove a point, the OS support *does* matter.
And I am wrong because you can't read full sentances...?
Originally posted by GdemamiHyperthreading isn't related to OS, besides multithreading support.
Hyperthreading does not require OS support, it isn't related to OS. Period.
Yes try that on Windows XP service pack 1 *chuckles*
You just need to read better, dont skip through posts You are in an awkward misunderstanding.
Try what? Multithreading is supported since W2K.
Hyperthreading is something completely different.
The reason hyperthreading had trouble early on Windows is that two different threads on the same core with hyperthreading is vastly slower than those same two threads running on two different cores. Windows saw a dual core with hyperthreading as four threads and if there were two threads active, put them wherever it pleased--sometimes putting both threads on the same core. That's much slower than putting those two threads on different cores--even on two separate cores without hyperthreading.
Since then, Windows has gotten smarter. If you have a dual core with hyperthreading and only two threads doing much, Windows will know which virtual cores correspond to which physical cores and make sure those two threads will go on different physical cores. Windows will try to make hyperthreading irrelevant unless you have enough threads doing enough work at once that having more cores would help.
-----
Now, threading on a GPU is, indeed, rather different from threading on a CPU. On a GPU, everything that could plausibly be high latency probably is. GPUs cover up latency by having massive numbers of threads operating at once, and likely switching which threads get scheduled every single clock cycle. The idea is that by switching threads so much, by the time you come back to have the first thread execute something else, anything that it would have had to wait on will hopefully be done and it will be ready to go again.
CPUs are optimized much more for latency at the expense of throughput (lower latency times for many things, out of order execution, branch prediction, etc.), so you don't need a zillion threads on a core to cover up latency pretty well. But still, there are pieces of silicon to do certain things, and only one thread can use that silicon at a time.
If, as you claim, two cores plus hyperthreading were just as good as four cores, then why would a Core i5 even exist? Look here:
That's a Core i3-4360 versus a Core i5-4670K. They're both Haswell, so they're basically the same cores. The former has two cores plus hyperthreading, while the latter has four cores with no hyperthreading. So they both have four threads in total. The Core i3 runs at 3.7 GHz all of the time when not clocking down for idle. The Core i5 has a base clock speed of 3.4 GHz and a max turbo boost of 3.8 GHz. In a single-threaded test, the Core i5 will run at 3.8 GHz and should win by a little. If you're pushing all four cores, it could easily reduce the turbo frequency. If thread count were all that mattered, one would expect the two CPUs to be very close in well-threaded benchmarks.
That's not what we see. They are close in single-threaded benchmarks, as one would expect. But none of the multi-threaded benchmarks are remotely close. The Core i3 loses badly, only offering even 2/3 of the performance of the Core i5 in one benchmark.
Before you run off and compare this to an FX-6300, you might also want to note that this is not one of the cheaper Core i3 chips. This is a $145 version, so you're paying a big price premium over an $89 FX-6300.
Haha, it is you who is mistaking Multithreading for Hyperthreading.
Hyperthreading is all about simultanious processing, allocating CPU resources to each logical unit so you can indeed process 2 threads on a single core, albeit not as efficiently.
And why isn't it as efficient? Because transistors can only be working on one thing at a time. If you have some portion of silicon that is built to add two integers, it can only add one pair of integers at a time. A core could have one thread add two integers one clock cycle and then the other add two integers the next clock cycle. Or perhaps more appropriately, one thread goes through one pipeline stage for addition one cycle and the other through the same pipeline stage in the next cycle. (Actually, this is getting low enough level that I'm not sure if it can switch that fast--but it certainly can't go faster than that.) But the same silicon can't be processing data from both threads on the core simultaneously. For that, you'd need separate silicon to handle the other thread. Such as another core. Some patch of silicon can be adding two numbers on one core at exactly the same time that an identical patch of silicon is adding two other numbers on a different core.
Originally posted by BailoPan15 Because unless the OS is scheduling instructions in a way to take advantage of hyperthreading, it is nothing but a stamp on the IHS
And yeah its not all about synthetics either. We already know that synthetics does not equal gaming performance. By experience, as i stated in an earlier post of mine, the FX-6300 has unlocked multiplier, cheap motherboards supporting it and it has decent FPS in Bf3, Bf4 even crysis 3 on Radeon HD 6850 in crossfire (which is a bit dated graphics but still, it hits the 60s)
Hyperthreading does not require OS support, it isn't related to OS. Period.
If you want hyperthreading to only make things go faster and not slower, that absolutely does require OS support beyond merely being able to handle multiple threads. If you only care that hyperthreading is being used and not whether it's making things run faster or slower than if there were no hyperthreading, then you don't need specialized OS support for it.
Originally posted by QuizzicalAnd why isn't it as efficient?
Because it still has to share resources of 1 core. Yet, each logical unit has it's own resources, own registers. The threads are processed simultaneously.
That is where drawback linked on Wiki above comes from - if you have 2 heavy load threads, the performance might actually decrease.
Originally posted by Quizzical If you want hyperthreading to only make things go faster and not slower, that absolutely does require OS support beyond merely being able to handle multiple threads. If you only care that hyperthreading is being used and not whether it's making things run faster or slower than if there were no hyperthreading, then you don't need specialized OS support for it.
From software point of view, processor with hyper threading appears as 2 processors. No special treatment there.
The operating system needs to support multiple processors, otherwise it won't work at all. Beyond that the OS does not need any special support but if it's aware of hyperthreading it will be able to schedule tasks more optimised for it than having two real CPU cores.
A core with hyperthreading presents itself as two cores, but they are purely virtual. It is nothing like having two physical cores that can execute independently of each other.
Originally posted by Athisar It is nothing like having two physical cores that can execute independently of each other.
That is still possible with HT.
Once the threads are executed on logical processors and are dispatched for core execution, they are executed with out-of-order scheduling within 1 cycle for most efficiency.
Unless you meant something else...
Yeah, HT allows truly concurrent processing of 2 threads...
Uhh, you need to talk to some programmers. Writing multithreaded code is far more difficult, thats why its taken this long to get to the point where you're starting to get programs that are multithreaded that aren't professional programs (i.e. cad/cam software, etc)
That depends very, very strongly on what you're trying to do. Some algorithms are intrinsically single-threaded and can't be parallelized. Some algorithms take a great amount of work to parallelize. Some are pretty easily parallelizable such that making it scale to many cores only adds a few percent to the work in coding it.
There is also an intrinsic amount of work it takes to write a parallel program, so for something simple enough that you can write a single-threaded version in ten minutes, a parallel version might well make it take two or three times as long. But that intrinsic amount of work becomes far less significant in larger projects.
Or to take an extreme example, if you've got a modern, highish-end GPU (basically, if you spent over $200 on it in the last few years and didn't buy something incredibly stupid), your GPU probably has several thousand threads going most of the time in most games, unless it's light enough on GPU usage that your video card is mostly idle while playing the game.
Most things in games are pretty easy to parallelize enough that no thread needs more than a small fraction of a core. The glaring exception is the thread that communicates with the GPU, and that is often the thing that creates a single-threaded bottleneck somewhere. But even that may well be going away soon, as both OpenGL and Mantle offer ways to greatly reduce the amount of work that thread has to do, and DirectX will join them next year.
Well said. I guess i should have clarified. Writing multithreaded code isn't intrinsically more difficult, its just that the vast majority of programmers aren't top tier guys who are good at this stuff. They're used to doing brute force methods, using tricks/cheats they've used along the way etc. Whats interesting in Microsoft is actually banking on that with DX12 as far as the low level API programming. They're hoping/assuming that the more talented, higher tier people, will end up working for companies like Crytek, or (whoever makes) Unreal Engine, and they'll be coding the low level api stuff and then the companies making the games, licensing the engines, who might have less talented people won't have to worry about all the low level API coding crap since they licensed the engine.
Anyways, im getting off topic.
The main gist is that We've had multicore CPU's for a long time, and only really in the last 2-3 years have modern games been able to properly utilize them. I remember one early game, i can't rem which, but they were touting how it utilized multiple cores, and id check and see one core at like 95%, 1 core around 10%, and the rest idle. I'm like /facepalm.
"The surest way to corrupt a youth is to instruct him to hold in higher esteem those who think alike than those who think differently."
If you want hyperthreading to only make things go faster and not slower, that absolutely does require OS support beyond merely being able to handle multiple threads. If you only care that hyperthreading is being used and not whether it's making things run faster or slower than if there were no hyperthreading, then you don't need specialized OS support for it.
From software point of view, processor with hyper threading appears as 2 processors. No special treatment there.
From the perspective of someone writing a program in C++ or whatever, that's true. But when writing a program at that level, you don't specify that this thread goes on this core while this other thread goes on that core instead. You really can't do that intelligently as you usually don't know what else is going to be running on the computer at the same time as your program.
Rather, what you do is just say, here are some threads and here's the work that each thread does. The operating system has to pick which thread gets scheduled on which core and when. And the operating system needs to be aware of hyperthreading, as it has to know these two "cores" are two virtual cores that correspond to the same physical core, while these other two "cores" correspond to a different physical core. If you're going to have two threads running, they'll run much better on two different physical cores than on two virtual cores corresponding to the same physical core. But if you've got a lot of threads running, you want to be able to make use of hyperthreading for improved performance. This is not a trivial thing to do intelligently, but neither is it impossible, as it's essentially a solved problem these days.
If a CPU can have multiple threads resident at a time, there are some resources on the CPU shared between multiple threads and some for which each resident thread has its own. What is shared at what level of granularity depends on the architecture. For example, all modern x86 architectures have each core have its own L1 cache, but some give each core its own L2 (AMD Bobcat/Jaguar/Puma, Intel Sandy Bridge/Ivy Bridge/Haswell), while others share L2 cache among all cores on the chip (e.g., Core 2 Duo), or even have multiple L2 caches shared among pairs of cores (Intel Core 2 Quad, AMD Bulldozer and its successors).
The hyperthreading approach is to say, each of the two threads resident on a CPU core can have its own registers and some scheduling stuff, and I'm not sure exactly what else. But each core does not have its own execution resources; those are shared by the two threads on a single core. As only one thread can use execution resources at a time, if they're both ready to do computations in one clock cycle, one of them has to sit and wait. If they were two separate cores, they'd each have their own execution units, and be able to execute computations simultaneously without having to wait.
Uhh, you need to talk to some programmers. Writing multithreaded code is far more difficult, thats why its taken this long to get to the point where you're starting to get programs that are multithreaded that aren't professional programs (i.e. cad/cam software, etc)
That depends very, very strongly on what you're trying to do. Some algorithms are intrinsically single-threaded and can't be parallelized. Some algorithms take a great amount of work to parallelize. Some are pretty easily parallelizable such that making it scale to many cores only adds a few percent to the work in coding it.
There is also an intrinsic amount of work it takes to write a parallel program, so for something simple enough that you can write a single-threaded version in ten minutes, a parallel version might well make it take two or three times as long. But that intrinsic amount of work becomes far less significant in larger projects.
Or to take an extreme example, if you've got a modern, highish-end GPU (basically, if you spent over $200 on it in the last few years and didn't buy something incredibly stupid), your GPU probably has several thousand threads going most of the time in most games, unless it's light enough on GPU usage that your video card is mostly idle while playing the game.
Most things in games are pretty easy to parallelize enough that no thread needs more than a small fraction of a core. The glaring exception is the thread that communicates with the GPU, and that is often the thing that creates a single-threaded bottleneck somewhere. But even that may well be going away soon, as both OpenGL and Mantle offer ways to greatly reduce the amount of work that thread has to do, and DirectX will join them next year.
Well said. I guess i should have clarified. Writing multithreaded code isn't intrinsically more difficult, its just that the vast majority of programmers aren't top tier guys who are good at this stuff. They're used to doing brute force methods, using tricks/cheats they've used along the way etc. Whats interesting in Microsoft is actually banking on that with DX12 as far as the low level API programming. They're hoping/assuming that the more talented, higher tier people, will end up working for companies like Crytek, or (whoever makes) Unreal Engine, and they'll be coding the low level api stuff and then the companies making the games, licensing the engines, who might have less talented people won't have to worry about all the low level API coding crap since they licensed the engine.
Anyways, im getting off topic.
The main gist is that We've had multicore CPU's for a long time, and only really in the last 2-3 years have modern games been able to properly utilize them. I remember one early game, i can't rem which, but they were touting how it utilized multiple cores, and id check and see one core at like 95%, 1 core around 10%, and the rest idle. I'm like /facepalm.
There's an enormous difference between multi-threading a game when you plan on how you're going to thread it before you've written any code for the game, versus when you've got a game that is already far along as a single-threaded game and then you'd like to go back and change it to be multi-threaded. Even if the former is easy to do, the latter is can be very hard. Depending on how well documented the code is, whether the people who wrote it originally are the same ones trying to modify it, and how careful they were writing it the first time rather than rushing to meet deadlines, going back and making lower level threading changes may be intractable enough as to be a bad idea right from the start.
-----
On offering lower level access to GPUs, the way I'd put it is this:
Do games need atomic counters on a GPU?
There's an obvious answer to this: "no".
So should graphics APIs offer atomic counters?
The obvious answer to this is also "no". But both AMD and Nvidia implemented atomic counters because they could be useful for GPU compute purposes. So if they're already available in all modern GPU architectures anyway, why not expose them via OpenGL in case someone might find some use for them?
It was on this basis that atomic counters were added to the OpenGL specification in OpenGL 4.1. It was never their intention that games should have to use atomic counters. But it's another option in case you happen to be programming a game and come across a situation where atomic counters would be really useful to have.
Low level access to GPUs is like that. It's not something that the expect everyone to need and make extensive use of. But GPU architectures have converged a lot since OpenGL 1.0 released in 1992. No longer do we have game cartridges including a processing chip inside the cartridge that does a lot of the computations for that particular game. Rather, whether you get an AMD video card or Nvidia, a lot of the capabilities will be about the same. If all modern GPUs can do something well, why not offer it in the graphics APIs?
Where the i5 and i7 outshine the i3 is also when you have multiple programs running at once. So if you have Skype and TS3 running, Chrome with a few tabs, your game, and Spotify all going at once it's going to really work the i3 compared to the i5/i7.
An i3 can do the job, if it's not a junk model, but an i5/i7 is going to be much more flexible and powerful under a load.
Browsers and audio programs don't really use any significant amount of CPU by today's standards. The exception might be if the browser has a Java game running on it, or a few animated Flash advertisements. An Atom or mobile (phone/tablet) processor might struggle to run a game alongside audio programs, but you shouldn't be depending on those processors for serious PC gaming.
I would rather have a Core i5 than a Core i3. If you want to play a game that needs those extra cores, you will regret purchasing the i3 if it was just to save a small amount of money. I would only use a Core i3 in a system that isn't for gaming.
Comments
Nope. Back in the days when multi-threaded processing came to be it was hard yes. Nowadays the tools and languages have improved and it all works almost natively. Thread synchronization, deadlock checks, race conditions ... those are all things that have been done wrong many many times and are already improved. There are even smart pointers, to stop you from being stupid and waste heap memory all the time. All the things I said are supported in the STL of C++11 which is completely implemented at the big compilers and work is starting on C++17 which will bring even more goodies (but not yet)
Not to mention that you don't always need multi-threaded processing. Simple apps don't. 32-bit, single-threaded wide character support application is still very much acceptable.
Other stop is that old code is not only hard to maintain in most cases, its terribly hard to upgrade. Most of the times its easier/faster/cheaper to start from the scratch. There are many articles about it. All in all ... in the long run ... old codebase costs you more, but your finance manager is never going to *get it* as long as the prices dont go up and you have a working solution with bunch of known bugs and no new ones.
EDIT: Almost forgot to put that there's plethora of ways to do multi-threaded processing. Its not hard as per se. Just requires some forward thinking.
Ontopic ... OP, imagine you ask this question 10 years ago. It would sound like this "Celeron vs Pentium 4...is it worth it". I'd tell you to go with Core 2 Duo which would be the equivalent of i7, because both are not top of the line. Today though, you have cheap AMDs (not that you didn't 10 years ago but that's beside the point). Locked processors are bad idea in general. You want unlocked multiplier. That only works on the i5 (and up) and that, only on the K series which is usually ~50$ plus. The red team however mostly sells unlocked core CPUs, for obvious reasons.
I'm personally still running i5-2500k, old but golden. Plays Dragon Age: Inquisition at ultra graphics paired with R9 290X and Mantle with 60+ FPS. My brother runs the aforementioned FX-6300 and my girlfriend runs FX-8350. Both their motherboards are super cheap and they support overclocking for the price. Both have UEFI bios (yeah that cool stuff) + backup bios if they fuck things up.
Point is ... the 3 of us play Battlefield 3 and 4 at least once a week, mostly Gw2 which god replaced by Dragon Age Inquisition for the time being.
tl;dr. I'd never get an i3. i5 if unlocked is a safe bet. If you are money constrained just go for AMD.
Also don't always believe everything you see. Benchmarks are only relative unless you have the same machine that is tested. Don't be a brand fanboy and always wait for initial reviews before you "pull the trigger". If something is going to give you 5-10 frames per average but costs 100$ more, that's just bullshit. With proper overclocking you'll be able to get that fps back. Be smart, and screw the fanboys.
Haha, it is you who is mistaking Multithreading for Hyperthreading.
Hyperthreading is all about simultanious processing, allocating CPU resources to each logical unit so you can indeed process 2 threads on a single core, albeit not as efficiently.
It is something entirely different from what you wrote up so thoroughly.
Yes try that on Windows XP service pack 1 *chuckles*
You just need to read better, dont skip through posts
You are in an awkward misunderstanding.
Try what? Multithreading is supported since W2K.
What Quizzical was describing is mutlithreading on single core system, without any Hyperthreading.
You're weird. You give explanation about hyper threading, I'm telling you to try that on older windows and then you start talking about multi threading
Either way, I wouldn't praise hyper-threading. It's not all cool and flashy as they are marketing it.
And I am asking trying what?
Hyperthreading isn't related to OS, besides multithreading support.
You couldn't be more wrong. Here let me show you http://en.wikipedia.org/wiki/Hyper-threading - 3rd paragraph.
Ah dang it, silly me ... there's a subcategory "Drawbacks". Its better explained in there. The 3rd paragraph might be a bit vague.
Lets just agree that it is a good thing to have but you shouldn't rely on it if you have a better option ... e.g. something with real cores
Erm...and what precisely I am wrong about? Please do provide a quote...
"quotes": Hyperthreading isn't related to OS
It most certainly is. Well sure, not today because Windows and the linux kernel are smarter, but to prove a point, the OS support *does* matter.
I mean ... if you have the feature but it underperforms because the OS doesn't know how to utilize it properly is kind of OS related thing right?
And I am wrong because you can't read full sentances...?
Hyperthreading does not require OS support, it isn't related to OS. Period.
Because unless the OS is scheduling instructions in a way to take advantage of hyperthreading, it is nothing but a stamp on the IHS
The reason hyperthreading had trouble early on Windows is that two different threads on the same core with hyperthreading is vastly slower than those same two threads running on two different cores. Windows saw a dual core with hyperthreading as four threads and if there were two threads active, put them wherever it pleased--sometimes putting both threads on the same core. That's much slower than putting those two threads on different cores--even on two separate cores without hyperthreading.
Since then, Windows has gotten smarter. If you have a dual core with hyperthreading and only two threads doing much, Windows will know which virtual cores correspond to which physical cores and make sure those two threads will go on different physical cores. Windows will try to make hyperthreading irrelevant unless you have enough threads doing enough work at once that having more cores would help.
-----
Now, threading on a GPU is, indeed, rather different from threading on a CPU. On a GPU, everything that could plausibly be high latency probably is. GPUs cover up latency by having massive numbers of threads operating at once, and likely switching which threads get scheduled every single clock cycle. The idea is that by switching threads so much, by the time you come back to have the first thread execute something else, anything that it would have had to wait on will hopefully be done and it will be ready to go again.
CPUs are optimized much more for latency at the expense of throughput (lower latency times for many things, out of order execution, branch prediction, etc.), so you don't need a zillion threads on a core to cover up latency pretty well. But still, there are pieces of silicon to do certain things, and only one thread can use that silicon at a time.
If, as you claim, two cores plus hyperthreading were just as good as four cores, then why would a Core i5 even exist? Look here:
http://anandtech.com/bench/product/1197?vs=837
That's a Core i3-4360 versus a Core i5-4670K. They're both Haswell, so they're basically the same cores. The former has two cores plus hyperthreading, while the latter has four cores with no hyperthreading. So they both have four threads in total. The Core i3 runs at 3.7 GHz all of the time when not clocking down for idle. The Core i5 has a base clock speed of 3.4 GHz and a max turbo boost of 3.8 GHz. In a single-threaded test, the Core i5 will run at 3.8 GHz and should win by a little. If you're pushing all four cores, it could easily reduce the turbo frequency. If thread count were all that mattered, one would expect the two CPUs to be very close in well-threaded benchmarks.
That's not what we see. They are close in single-threaded benchmarks, as one would expect. But none of the multi-threaded benchmarks are remotely close. The Core i3 loses badly, only offering even 2/3 of the performance of the Core i5 in one benchmark.
Before you run off and compare this to an FX-6300, you might also want to note that this is not one of the cheaper Core i3 chips. This is a $145 version, so you're paying a big price premium over an $89 FX-6300.
And why isn't it as efficient? Because transistors can only be working on one thing at a time. If you have some portion of silicon that is built to add two integers, it can only add one pair of integers at a time. A core could have one thread add two integers one clock cycle and then the other add two integers the next clock cycle. Or perhaps more appropriately, one thread goes through one pipeline stage for addition one cycle and the other through the same pipeline stage in the next cycle. (Actually, this is getting low enough level that I'm not sure if it can switch that fast--but it certainly can't go faster than that.) But the same silicon can't be processing data from both threads on the core simultaneously. For that, you'd need separate silicon to handle the other thread. Such as another core. Some patch of silicon can be adding two numbers on one core at exactly the same time that an identical patch of silicon is adding two other numbers on a different core.
LOL, no.
And yeah its not all about synthetics either. We already know that synthetics does not equal gaming performance. By experience, as i stated in an earlier post of mine, the FX-6300 has unlocked multiplier, cheap motherboards supporting it and it has decent FPS in Bf3, Bf4 even crysis 3 on Radeon HD 6850 in crossfire (which is a bit dated graphics but still, it hits the 60s)
EDIT: @Gdemami, here https://www.youtube.com/watch?v=wnS50lJicXc . I really can't explain it more simply.
If you want hyperthreading to only make things go faster and not slower, that absolutely does require OS support beyond merely being able to handle multiple threads. If you only care that hyperthreading is being used and not whether it's making things run faster or slower than if there were no hyperthreading, then you don't need specialized OS support for it.
Because it still has to share resources of 1 core. Yet, each logical unit has it's own resources, own registers. The threads are processed simultaneously.
That is where drawback linked on Wiki above comes from - if you have 2 heavy load threads, the performance might actually decrease.
From software point of view, processor with hyper threading appears as 2 processors. No special treatment there.
The operating system needs to support multiple processors, otherwise it won't work at all. Beyond that the OS does not need any special support but if it's aware of hyperthreading it will be able to schedule tasks more optimised for it than having two real CPU cores.
A core with hyperthreading presents itself as two cores, but they are purely virtual. It is nothing like having two physical cores that can execute independently of each other.
That is still possible with HT.
Once the threads are executed on logical processors and are dispatched for core execution, they are executed with out-of-order scheduling within 1 cycle for most efficiency.
Unless you meant something else...
Yeah, HT allows truly concurrent processing of 2 threads...
Well said. I guess i should have clarified. Writing multithreaded code isn't intrinsically more difficult, its just that the vast majority of programmers aren't top tier guys who are good at this stuff. They're used to doing brute force methods, using tricks/cheats they've used along the way etc. Whats interesting in Microsoft is actually banking on that with DX12 as far as the low level API programming. They're hoping/assuming that the more talented, higher tier people, will end up working for companies like Crytek, or (whoever makes) Unreal Engine, and they'll be coding the low level api stuff and then the companies making the games, licensing the engines, who might have less talented people won't have to worry about all the low level API coding crap since they licensed the engine.
Anyways, im getting off topic.
The main gist is that We've had multicore CPU's for a long time, and only really in the last 2-3 years have modern games been able to properly utilize them. I remember one early game, i can't rem which, but they were touting how it utilized multiple cores, and id check and see one core at like 95%, 1 core around 10%, and the rest idle. I'm like /facepalm.
"The surest way to corrupt a youth is to instruct him to hold in higher esteem those who think alike than those who think differently."
- Friedrich Nietzsche
From the perspective of someone writing a program in C++ or whatever, that's true. But when writing a program at that level, you don't specify that this thread goes on this core while this other thread goes on that core instead. You really can't do that intelligently as you usually don't know what else is going to be running on the computer at the same time as your program.
Rather, what you do is just say, here are some threads and here's the work that each thread does. The operating system has to pick which thread gets scheduled on which core and when. And the operating system needs to be aware of hyperthreading, as it has to know these two "cores" are two virtual cores that correspond to the same physical core, while these other two "cores" correspond to a different physical core. If you're going to have two threads running, they'll run much better on two different physical cores than on two virtual cores corresponding to the same physical core. But if you've got a lot of threads running, you want to be able to make use of hyperthreading for improved performance. This is not a trivial thing to do intelligently, but neither is it impossible, as it's essentially a solved problem these days.
If a CPU can have multiple threads resident at a time, there are some resources on the CPU shared between multiple threads and some for which each resident thread has its own. What is shared at what level of granularity depends on the architecture. For example, all modern x86 architectures have each core have its own L1 cache, but some give each core its own L2 (AMD Bobcat/Jaguar/Puma, Intel Sandy Bridge/Ivy Bridge/Haswell), while others share L2 cache among all cores on the chip (e.g., Core 2 Duo), or even have multiple L2 caches shared among pairs of cores (Intel Core 2 Quad, AMD Bulldozer and its successors).
The hyperthreading approach is to say, each of the two threads resident on a CPU core can have its own registers and some scheduling stuff, and I'm not sure exactly what else. But each core does not have its own execution resources; those are shared by the two threads on a single core. As only one thread can use execution resources at a time, if they're both ready to do computations in one clock cycle, one of them has to sit and wait. If they were two separate cores, they'd each have their own execution units, and be able to execute computations simultaneously without having to wait.
There's an enormous difference between multi-threading a game when you plan on how you're going to thread it before you've written any code for the game, versus when you've got a game that is already far along as a single-threaded game and then you'd like to go back and change it to be multi-threaded. Even if the former is easy to do, the latter is can be very hard. Depending on how well documented the code is, whether the people who wrote it originally are the same ones trying to modify it, and how careful they were writing it the first time rather than rushing to meet deadlines, going back and making lower level threading changes may be intractable enough as to be a bad idea right from the start.
-----
On offering lower level access to GPUs, the way I'd put it is this:
Do games need atomic counters on a GPU?
There's an obvious answer to this: "no".
So should graphics APIs offer atomic counters?
The obvious answer to this is also "no". But both AMD and Nvidia implemented atomic counters because they could be useful for GPU compute purposes. So if they're already available in all modern GPU architectures anyway, why not expose them via OpenGL in case someone might find some use for them?
It was on this basis that atomic counters were added to the OpenGL specification in OpenGL 4.1. It was never their intention that games should have to use atomic counters. But it's another option in case you happen to be programming a game and come across a situation where atomic counters would be really useful to have.
Low level access to GPUs is like that. It's not something that the expect everyone to need and make extensive use of. But GPU architectures have converged a lot since OpenGL 1.0 released in 1992. No longer do we have game cartridges including a processing chip inside the cartridge that does a lot of the computations for that particular game. Rather, whether you get an AMD video card or Nvidia, a lot of the capabilities will be about the same. If all modern GPUs can do something well, why not offer it in the graphics APIs?
Browsers and audio programs don't really use any significant amount of CPU by today's standards. The exception might be if the browser has a Java game running on it, or a few animated Flash advertisements. An Atom or mobile (phone/tablet) processor might struggle to run a game alongside audio programs, but you shouldn't be depending on those processors for serious PC gaming.
I would rather have a Core i5 than a Core i3. If you want to play a game that needs those extra cores, you will regret purchasing the i3 if it was just to save a small amount of money. I would only use a Core i3 in a system that isn't for gaming.