3 ms·

> Does seem like AMD has scared Intel into over drive. Seems like all price points are likely going to get significantly more cores in the next generation after

> Does seem like AMD has scared Intel into over drive. Seems like all price points are likely going to get significantly more cores in the next generation after stagnating for what a decade? Another factor might be that the software industry is finally adapting to multi-core being the new normal. I mean sure, server software's been forking or multi-threading for ages, but I get the impression the bulk of desktop software did most of its work in a single thread until fairly recently - so having more than 2-4 cores wasn't really worth it, it would just have increased cost without making things feel that much faster for the average user.

paulmd 10y ago
Not only that, but going with more cores hurts in a variety of ways. It's harder to get a wider chip clocked up as far, so single-thread performance tends to suffer. It's hard to manage clocks and scheduling appropriately especially when you have non-uniform processors, like different turbo capability (max multiplier) between cores or even worse big.LITTLE type architectures. It's very easy to end up ping-ponging between high power/low power modes, and battery life suffers. If it were physically possible, it would have been strongly preferable to have just kept increasing clocks instead of going wider. That was a decision made out of necessity, not choice. You see big gains from being able to multitask a little, past that it's really diminishing. All things being equal, a 2C2T or 2C4T at 6+ GHz would be strongly preferable to 4C4T or 4C8T at 4-4.5 GHz for most desktop use. The gains aren't that steep in the real world, of course. The reality is that it's more like a choice between 2C2T at 4.7 GHz (G3258, being a bit gracious here), 4C8T at 4.4 GHz (6700K) or 6C12T at 4.1 GHz (5820K). You can push all of those numbers up a little bit farther by pushing the voltage, but that's roughly the shape of things at stock-ish voltages. I diverge from the common wisdom here, given those numbers I think the 50% increase in real cores from jumping to 6C12T justifies a 10% loss in single-thread performance for many users, especially given that they're essentially the same price. In the threaded tasks where Hyperthreading provides gains, the extra cores will really push you ahead. If you're just gaming or browsing, a 4C4T is really all you'll ever need (and realistically many people will be fine with a 2C4T or 2C2T anyway). So the 4C8T are really an awkward in-between to me, I really think it's mostly that people don't realize that the 6700K isn't "top of the line" and there's a whole other enthusiast socket out there. The server market's a little different of course, you can go much wider, but good single-thread performance still beats parallelism in response times. Really wide architectures like Qualcomm's 24-wide ARM server chips still have yet to really prove themselves except in throughput-oriented/latency-insensitive applications (which are the easy gimmie for slow-and-wide designs).
- dom0 10y ago
  I very much agree with you. Another interesting observation is that, on cache-coherent systems, the maximum possible clock rate also tends to go down as soon as more than one socket is used. > (which are the easy gimmie for slow-and-wide designs) Nowadays they are more of an historical anecdote, but some time ago Sun created the "niagara" line of barrel processors - a technique that is a form of simultaneous multi-threading, like Hyper-Threading, just with 8-16 threads / core. These UltraSparc T1, T2, ... processors held quite some throughput benchmarks - but were obviously not feasible and not meant for general purpose use.
  - paulmd 10y ago
    > Another interesting observation is that, on cache-coherent systems, the maximum possible clock rate also tends to go down as soon as more than one socket is used. Which is perfectly sensible if you think about it. No matter how fast your cache coherence mechanism is, it's slower than not sharing cache between two chips. It's fine if you are storing program code or independent data, but if you are operating on the same cache lines as another processor you have to flush the dirty lines over and possibly roll back a whole bunch of execution that might have been done there. Sometimes this even happens when the data you are working on is different but shares a cache line (false sharing). > Nowadays they are more of an historical anecdote, but some time ago Sun created the "niagara" line of barrel processors - a technique that is a form of simultaneous multi-threading, like Hyper-Threading, just with 8-16 threads / core. We do a lot of contracting with a state government and I'm pretty sure they're still running these in their datacenter. It's some flavor of SPARC for sure, and I was talking to our sysadmin and he mentioned that they used a processor that I remember was a lot wider than hyperthreading, which sounds a lot like UltraSPARC. From what my guy explained they are pretty nice in database workloads especially since they're also an Oracle DB shop. They are locked into Oracle products seriously hard and they're unwilling to contemplate moving to commodity products. Probably unable to, given their staff's skillset and in-house operating procedures. It shouldn't take a tiger team for someone to suggest restarting a misbehaving server. You get what you pay for though. The state doesn't pay much and people who have other options don't stay in that kind of work environment.

paulmd 10y ago

Not only that, but going with more cores hurts in a variety of ways. It's harder to get a wider chip clocked up as far, so single-thread performance tends to suffer. It's hard to manage clocks and scheduling appropriately especially when you have non-uniform processors, like different turbo capability (max multiplier) between cores or even worse big.LITTLE type architectures. It's very easy to end up ping-ponging between high power/low power modes, and battery life suffers. If it were physically possible, it would have been strongly preferable to have just kept increasing clocks instead of going wider. That was a decision made out of necessity, not choice. You see big gains from being able to multitask a little, past that it's really diminishing. All things being equal, a 2C2T or 2C4T at 6+ GHz would be strongly preferable to 4C4T or 4C8T at 4-4.5 GHz for most desktop use. The gains aren't that steep in the real world, of course. The reality is that it's more like a choice between 2C2T at 4.7 GHz (G3258, being a bit gracious here), 4C8T at 4.4 GHz (6700K) or 6C12T at 4.1 GHz (5820K). You can push all of those numbers up a little bit farther by pushing the voltage, but that's roughly the shape of things at stock-ish voltages. I diverge from the common wisdom here, given those numbers I think the 50% increase in real cores from jumping to 6C12T justifies a 10% loss in single-thread performance for many users, especially given that they're essentially the same price. In the threaded tasks where Hyperthreading provides gains, the extra cores will really push you ahead. If you're just gaming or browsing, a 4C4T is really all you'll ever need (and realistically many people will be fine with a 2C4T or 2C2T anyway). So the 4C8T are really an awkward in-between to me, I really think it's mostly that people don't realize that the 6700K isn't "top of the line" and there's a whole other enthusiast socket out there. The server market's a little different of course, you can go much wider, but good single-thread performance still beats parallelism in response times. Really wide architectures like Qualcomm's 24-wide ARM server chips still have yet to really prove themselves except in throughput-oriented/latency-insensitive applications (which are the easy gimmie for slow-and-wide designs).

dom0 10y ago
I very much agree with you. Another interesting observation is that, on cache-coherent systems, the maximum possible clock rate also tends to go down as soon as more than one socket is used. > (which are the easy gimmie for slow-and-wide designs) Nowadays they are more of an historical anecdote, but some time ago Sun created the "niagara" line of barrel processors - a technique that is a form of simultaneous multi-threading, like Hyper-Threading, just with 8-16 threads / core. These UltraSparc T1, T2, ... processors held quite some throughput benchmarks - but were obviously not feasible and not meant for general purpose use.
- paulmd 10y ago
  > Another interesting observation is that, on cache-coherent systems, the maximum possible clock rate also tends to go down as soon as more than one socket is used. Which is perfectly sensible if you think about it. No matter how fast your cache coherence mechanism is, it's slower than not sharing cache between two chips. It's fine if you are storing program code or independent data, but if you are operating on the same cache lines as another processor you have to flush the dirty lines over and possibly roll back a whole bunch of execution that might have been done there. Sometimes this even happens when the data you are working on is different but shares a cache line (false sharing). > Nowadays they are more of an historical anecdote, but some time ago Sun created the "niagara" line of barrel processors - a technique that is a form of simultaneous multi-threading, like Hyper-Threading, just with 8-16 threads / core. We do a lot of contracting with a state government and I'm pretty sure they're still running these in their datacenter. It's some flavor of SPARC for sure, and I was talking to our sysadmin and he mentioned that they used a processor that I remember was a lot wider than hyperthreading, which sounds a lot like UltraSPARC. From what my guy explained they are pretty nice in database workloads especially since they're also an Oracle DB shop. They are locked into Oracle products seriously hard and they're unwilling to contemplate moving to commodity products. Probably unable to, given their staff's skillset and in-house operating procedures. It shouldn't take a tiger team for someone to suggest restarting a misbehaving server. You get what you pay for though. The state doesn't pay much and people who have other options don't stay in that kind of work environment.