higher clocks vs more cores

[Idontcare]

This is brilliant, since Intel has pretty much demolished any reason for an AMD fanboy camp to continue to exist we are seeing the emergence of a division within the ranks from the Intel fanboy camp - now we get to witness threads of gnashing fanboys from the "moar coars" contingent going toe-to-toe with the "moore GHz" crowd

Drama, its never ending

 

[aigomorla]

This is brilliant, since Intel has pretty much demolished any reason for an AMD fanboy camp to continue to exist we are seeing the emergence of a division within the ranks from the Intel fanboy camp - now we get to witness threads of gnashing fanboys from the "moar coars" contingent going toe-to-toe with the "moore GHz" crowd

Drama, its never ending

<--- president of the more cores foundation.. and im an addict. :biggrin:

 

[Idontcare]

 

[soccerballtux]

^^^lol

if Blizzard keeps releasing games that can only fully load up 2 cores (WoW, SC2, Diablo 3? I bet Diablo 3 too) then we're going to be needing the higher clocks.

 

[BrightCandle]

Going beyond a few cores with game design is tricky. I know everyone keeps blaming the software guys for not writing the games right but after writing multicore enabled software for a decade I can tell you its not as simple as just doing it.

Many software problems don't naturally fall into multithreading algorithms and games have no natural parallel split that scales well. The current system of splitting physics, graphics, sound and AI is natural but doesn't go past a few cores before it hits a limit. Its the algorithms within these pieces that need to get parallel, and that is much much harder and very expensive. We don't really have the language yet to do it safely, and the languages that do help do not have games libraries built for them yet and aren't used by many people.

More cores is only going to help a few programs and the more cores we have the fewer programs and problems that will utilise them. Is anyone else noticing that even video encoding and ray traced rendering isn't scaling linearly with cores already? We are at 6 cores, but with a promised future of hundreds - thousands this is not a good sign.

 

[Idontcare]

Going beyond a few cores with game design is tricky. I know everyone keeps blaming the software guys for not writing the games right but after writing multicore enabled software for a decade I can tell you its not as simple as just doing it.

Many software problems don't naturally fall into multithreading algorithms and games have no natural parallel split that scales well. The current system of splitting physics, graphics, sound and AI is natural but doesn't go past a few cores before it hits a limit. Its the algorithms within these pieces that need to get parallel, and that is much much harder and very expensive. We don't really have the language yet to do it safely, and the languages that do help do not have games libraries built for them yet and aren't used by many people.

More cores is only going to help a few programs and the more cores we have the fewer programs and problems that will utilise them. Is anyone else noticing that even video encoding and ray traced rendering isn't scaling linearly with cores already? We are at 6 cores, but with a promised future of hundreds - thousands this is not a good sign.

So true, especially the bolded part.

Typically we see these massively threaded applications which are really only threaded at the data crunching level, but the algorithms themselves are still serial.

It gets immensely challenging to program your algos to be functional in parallel schemes.

And even more challenging still is the verification and debug phase.

I've wasted more time thinking I was developing the next best thing since slices bread only to spend months tearing my hair out trying to figure out why it compiles fine but spits out garbage results...only to then toss the whole darned thing and go back to my previous versions that worked fine all along but much slower because of the lack of parallelism.

I know the limitation is me, I'm just not all that great of a coder, but the problem is more endemic of the industry in that there really isn't a plethora of really great coders out there to go around in the first place.

When your industry is comprised of a bevy of mediocre coders you need to dance with the one who brought you and recognize that reality is not forged in powerpoint slides, its forged in the cubicles.

 

[mrjoltcola]

Yeh, I have to bite my tongue on here everytime I see a thread where "lazy programmers" are mentioned. I've actually written a couple of game engines, and also used threads in them, and the fact is, multithreaded software is hard (as already stated) and buggy when done with C/C++ (which is what most games are written in), and doesn't always lend itself to single user applications. There are only so many ways you can parallelize a single user experience. At some point, it comes back to IPC. The one place I can see more cores being exploited is game AI, it is inherently parallel, but it is one area that the user doesn't get to "tweak" (ie. nobody goes to the Options screen and picks "AI -> Dumb", we all want a smart enemy. But this is about mainstream. You can't write a game for 6 cores right now, you won't sell enough titles to stay in business. Two-three years from now, probably. For now, the challenge is to exploit 4 cores completely, I don't even see that happening yet, because if it were, people with dual cores would be out.

 

[Grooveriding]

Yeh, I have to bite my tongue on here everytime I see a thread where "lazy programmers" are mentioned. I've actually written a couple of game engines, and also used threads in them, and the fact is, multithreaded software is hard (as already stated) and buggy when done with C/C++ (which is what most games are written in), and doesn't always lend itself to single user applications. There are only so many ways you can parallelize a single user experience. At some point, it comes back to IPC. The one place I can see more cores being exploited is game AI, it is inherently parallel, but it is one area that the user doesn't get to "tweak" (ie. nobody goes to the Options screen and picks "AI -> Dumb", we all want a smart enemy. But this is about mainstream. You can't write a game for 6 cores right now, you won't sell enough titles to stay in business. Two-three years from now, probably. For now, the challenge is to exploit 4 cores completely, I don't even see that happening yet, because if it were, people with dual cores would be out.

Am I understanding this right in that you could fairly 'easily' write a game specifically for a set number of cores, say 8, but if you wanted to also have the game be for 1,2,4 etc. cores as well - it then becomes difficult ?

Or is it the foundation from the start ? Meaning someone would have to develop a whole new language/program to code games with so they could be written to more easily exploit more cores ?

Reading this sounds like an epic ball drop on someone's part with the increasing core count in processors and just a small niche of applications that make use of them.

 

[mrjoltcola]

Replying to OP:

It isn't like just because I bought SB-E, I'm somehow in a different camp than Sandy Bridge owners, or upcoming Ivy Bridge owners.

Taking sides is for school time. I have a Core2Duo, a few Xeons, a 2500K, a 2600K, a 2700K and a 3930K, and a few AMD chips... (I'll stop now before I reveal just how much of a case I am) so who's side am I on? I'll have an Ivy Bridge in my stable when they arrive, but I'm not sitting here waiting on it. I'll have enjoyed my SB-E machine for quite a while by then, just like the guys running their 990X have been enjoying and making use of their 6-core rigs for quite a while now, and will continue to run them long after Ivy Bridge arrives.

You know what I need 6 cores for? Well one of those things is to actually research and design multi-threaded software and to understand how best to scale software to more than 3-4 cores. So please stop these posts about how noone here needs 6-cores and that anyone buying SB-E did it to brag; you've posted this in several threads now and it is far from the truth. Actually so far, SB-E owners have kept to their own threads, but have had to deal with a lot of childish comments in those threads from passerby, and I think everyone has been pretty polite in dealing with it.

I agree, sounds a bit like sour grapes.

 

[mrjoltcola]

Am I understanding this right in that you could fairly 'easily' write a game specifically for a set number of cores, say 8, but if you wanted to also have the game be for 1,2,4 etc. cores as well - it then becomes difficult ?

Or is it the foundation from the start ? Meaning someone would have to develop a whole new language/program to code games with so they could be written to more easily exploit more cores ?

Reading this sounds like an epic ball drop on someone's part with the increasing core count in processors and just a small niche of applications that make use of them.

I wouldn't say easily, but if I get the point of your question, then, yes. If you set out to write a given application, and you are guaranteed 8 cores of a given IPC capability, then you've just simplified a lot of the architectural decisions and throw tradeoffs out the window.

This is basically what consoles are about. Fixed platforms.

I don't see it as a ball drop, since multi-tasking OS became mainstream, uniprocessor has been less than ideal. It was about economics and technology. There was a time when noone could afford multi-processor, and the only SMP stuff was in research facilities, labs and big corps. The first dual-proc box I ever saw was a SUN Station that probably cost $25000 at the time.

It isn't that we can't use multi-core, it is that you can't just design and write games that assume the highest end hardware, because you need mainstream to be able to run it. Enthusiasts blaze the trail, but you have to wait for mainstream to catch up.

To your other point, mom-and-pop really don't need more than 2-cores for a smooth user experience. But that is the only way left to market processors right now. At some point, multi-core was the path of least resistance to continue scaling, now it is swinging back to IPC.

 

[Rifter]

I think as of now 4 is the sweet spot. Alot of programs will use 2-4 cores very well but dont scale well to 6+.

So as of right now i would take 4 fast cores over 6-8 slower cores, look at SB beating the hell out of the AMD thubans and BD and you will see more cores is not always the answer.

 

[grkM3]

Guys I love having more cores and the s2011 platform,I dont know why someone said I keep saying things about quads being better as this is the first time I have ever compared them.

I am asking if the higher clocked 1155 ivys from going 22nm would beat out the sandy Es we have today once people clock them.

Would you take a 6.2ghz quad 22nm ivy or a 4.8ghz hex on 32nm.I think clock speed will beat them out until we see 22nm ivy Es but those are a long wait and will cost a lot more for giving someone an extra few cores.

Some of you are acting like 8 threads is nothing.more cores were the thing when we hit a clock wall and needed them to add performance but now with how well chips clock we are back to getting more mhz and ipc vs more cores and less clocks.

 

[AdamK47]

Guys I love having more cores and the s2011 platform,I dont know why someone said I keep saying things about quads being better as this is the first time I have ever compared them.

I am asking if the higher clocked 1155 ivys from going 22nm would beat out the sandy Es we have today once people clock them.

Would you take a 6.2ghz quad 22nm ivy or a 4.8ghz hex on 32nm.I think clock speed will beat them out until we see 22nm ivy Es but those are a long wait and will cost a lot more for giving someone an extra few cores.

Some of you are acting like 8 threads is nothing.more cores were the thing when we hit a clock wall and needed them to add performance but now with how well chips clock we are back to getting more mhz and ipc vs more cores and less clocks.

6.2GHz huh? That's some bold predicting right there.

You were comparing a 4.6GHz SB-E to your 5.5GHz SB earlier. The big difference here is that the 4.6GHz SB-E is 24/7 stable while your 5.5GHz would fall flat on its face within 10 seconds running Prime95. I'm sure I could bench at 5.0GHz, but I know it wouldn't be stable for 24/7 use. I tend to torture/stress test my systems beyond what others would use to determine stability.

 

[Grooveriding]

Guys I love having more cores and the s2011 platform,I dont know why someone said I keep saying things about quads being better as this is the first time I have ever compared them.

I am asking if the higher clocked 1155 ivys from going 22nm would beat out the sandy Es we have today once people clock them.

Would you take a 6.2ghz quad 22nm ivy or a 4.8ghz hex on 32nm.I think clock speed will beat them out until we see 22nm ivy Es but those are a long wait and will cost a lot more for giving someone an extra few cores.

Some of you are acting like 8 threads is nothing.more cores were the thing when we hit a clock wall and needed them to add performance but now with how well chips clock we are back to getting more mhz and ipc vs more cores and less clocks.

I think 6.2ghz is overly optimistic, maybe for the crazies using ln2 cooling. I think 5.2-5.5 will be the 'average' top-end overclock on really good air-cooling.

Bloomfields were fairly easily doing 4 to 4.2, some even 4.4 on air. SB only managed to knock that up to around 4.6 to 5 on air. Before Bloomfield, Kentsfield would do 3.6 to 4.0 usually on good air.

I think it will pan out similarly to the way SB did against Gulftown. For users who make use of those cores or benchmark enthusiasts the SB-E will perform better than IB in those tasks where the cores and cache make it excel. They'll hold out until IB-E comes out like many 980X/990X owners did with waiting on SB-E.

 

[ThatsABigOne]

Guys I love having more cores and the s2011 platform,I dont know why someone said I keep saying things about quads being better as this is the first time I have ever compared them.

I am asking if the higher clocked 1155 ivys from going 22nm would beat out the sandy Es we have today once people clock them.

Would you take a 6.2ghz quad 22nm ivy or a 4.8ghz hex on 32nm.I think clock speed will beat them out until we see 22nm ivy Es but those are a long wait and will cost a lot more for giving someone an extra few cores.

Some of you are acting like 8 threads is nothing.more cores were the thing when we hit a clock wall and needed them to add performance but now with how well chips clock we are back to getting more mhz and ipc vs more cores and less clocks.

Stop right there! :whiste:

Anything after just does not make any sense and contrary to what many people are saying.

 

[grkM3]

Stop right there! :whiste:

Anything after just does not make any sense and contrary to what many people are saying.

right because 22nm wont clock higher than 32nm :whiste:

 

[exar333]

Guys I love having more cores and the s2011 platform,I dont know why someone said I keep saying things about quads being better as this is the first time I have ever compared them.

I am asking if the higher clocked 1155 ivys from going 22nm would beat out the sandy Es we have today once people clock them.

Would you take a 6.2ghz quad 22nm ivy or a 4.8ghz hex on 32nm.I think clock speed will beat them out until we see 22nm ivy Es but those are a long wait and will cost a lot more for giving someone an extra few cores.

Some of you are acting like 8 threads is nothing.more cores were the thing when we hit a clock wall and needed them to add performance but now with how well chips clock we are back to getting more mhz and ipc vs more cores and less clocks.

It's a 'few more cores' now. What about when IB-E has 8 or 10 cores?

 

[MrTransistorm]

I agree with mrjoltcola about this recent divide among Intel users. Why are there so many SB owners suddenly giving SB-E owners/potential buyers grief about their choice of platform? I've seen this phenomenon on several different fora now.

right because 22nm wont clock higher than 32nm :whiste:

Who said it won't?

The point is that you're expecting too much out of Ivy Bridge. 6.2 GHz? Sure. Even if it could clock that high on average, it still probably wouldn't be enough to beat 6-core SB-E in well-threaded tasks.

And then IB-E comes out. Then what? Proclaim that Broadwell will clock high enough to beat IB-E?

 

[BrightCandle]

Am I understanding this right in that you could fairly 'easily' write a game specifically for a set number of cores, say 8, but if you wanted to also have the game be for 1,2,4 etc. cores as well - it then becomes difficult ?

Or is it the foundation from the start ? Meaning someone would have to develop a whole new language/program to code games with so they could be written to more easily exploit more cores ?

Reading this sounds like an epic ball drop on someone's part with the increasing core count in processors and just a small niche of applications that make use of them.

Parallel programming is a current area of research, the languages and approaches are somewhat experimental. Today the only really common approach is the use of multiple threads. Its pretty basic and it introduces a whole raft of problems if your code isn't designed for it and that is really hard. In any real project its impossible to retrofit parallel computation.

There is an approach (known as functional programming) which solves many of the problems we have, but then proceeds to make certain common things we do much harder/impossible. It also carries with it a performance hit due to the repeated copying of information and in many cases its an order of magnitude slower. Sometimes it comes out faster as well but most of the time it involves some extra overhead. Given enough CPUs the overhead becomes less of a problem, but you have to cross the chasm of 4 cores to 40(say) before the trade off makes sense.

Parallel code often costs more CPU time in overhead, but given a large enough problem can overall end up running faster. So the challenge with scaling from 2-8 cores is that on the lower end of that you might choose to use Course grained (AI, Graphics, Sound etc) threading model but for 8 cores you might switch to task based (Player Action, Update AI of model, Render Model, change position etc) as it scales better across the cores, but introduces too much overhead on dual core systems to work. You waste too much time setting up and combining the results and loose time for the actual tasks. Tasks being smaller result in more cache thrashing and hence are heavier on memory bandwidth, cause more stalls etc etc. You need enough of them running in parallel with the memory architecture to cope to be worth while, otherwise its just much slower.

Even once you go through the process of cutting up your problem into tasks or changing the underlying algorithms to use multiple threads and you have dealt with upwards and downwards scaling you are still going to hit the problem that DirectX isn't really a parallel API. You are going to face the real possibility that despite your cutting up your problem at enormous expense it doesn't scale as well as you like because 10&#37; of all your code time is working on a problem that can only work on 1 CPU. We might not know a parallel algorithm for that problem, so given infinite cores this would still only go 10x faster.

So all in all its part of the nature of machine computation. What can be done is limited by maths and the algorithms humanity has discovered. Right now parallel programming in all but a few estoric languages produces a lot of bugs and only moderate increases in performance. But given we may all be running machines capable of competing with todays super computers in about 20 years time its a problem that needs to get solved or we just stop scaling single machines and bring an end to the growth of the information age. Alas researchers have been cracking at it for 40 years so far and its just a very hard problem.

 

[BrightCandle]

One of my favourite examples of parallel programming being just plan wicked is the adding up of a list of numbers. Lets say I want to add 10 numbers across 1 core - its easy I just do 1+2+3+...+10. But to make some of the computation be done in parallel, say 2 cores I can split it into 2 problems - (1+2+..+5) and (6+7+..+10). Then I need to combine them with a single addition (15+40).

Well it turns out that at 4 cpus we have at the bottom the problem split into 4 pieces to run in parallel, but then we are left with 4 numbers to sum, we can do 2 additions in parallel so we do that and then combine the 2 results into 1. It looks something like this:
(15+40)
(3+12) (21+19)
(1+2) (3+4+5) (6+7+8) (9+10)

At the bottom level we can utilise 4 cores, but the mid level only uses 2 and the top only 1 core. It has to be done in order so the cost of the problem to the user running it is the height of the tree created, in this case 3. We double the problem size and we add another layer to that tree.

Despite the simplicity of the problem this does not scale well with cores. Its an O(log n) problem in its parallel form, which means that given 1024 cores crunching 2048 numbers at the same speed as 1 core it will be just 10 times faster. The average CPU utilisation is terrible as well, only for 1 of the 10 steps is it 100&#37;, then its 50%, then 25% down and down until its 1/1024th % for the last step. The algorithm is much more complicated, uneven as you can see above (some are 3 numbers some are 2) and the overhead of combining the numbers across cores thrashes memory in a way that a serial computation just wouldn't.

In this case the parallel problem is slower, we'd set a minumum number of numbers to add up on a core to reduce the overhead of the combining. That adds yet further complexity to the problem and all the while we're not getting much return. Not that this is a hard enough problem to require parallel code per say, its just a simple example that shows why more cores doesn't actually produce more performance.

Saying all this I personally just got a SB-E. My work does scale to potentially hundreds of cores. The extra IPC, clock speed and cores will all benefit the activities I do, as will the additional RAM. I don't expect it to improving my gaming much if at all, it might even hurt it a little but a few fps here and there is nothing compared to minutes reduction in the build of a project.

 

[Puppies04]

Guys I love having more cores and the s2011 platform,I dont know why someone said I keep saying things about quads being better as this is the first time I have ever compared them.

I am asking if the higher clocked 1155 ivys from going 22nm would beat out the sandy Es we have today once people clock them.

Would you take a 6.2ghz quad 22nm ivy or a 4.8ghz hex on 32nm.I think clock speed will beat them out until we see 22nm ivy Es but those are a long wait and will cost a lot more for giving someone an extra few cores.

Some of you are acting like 8 threads is nothing.more cores were the thing when we hit a clock wall and needed them to add performance but now with how well chips clock we are back to getting more mhz and ipc vs more cores and less clocks.

Stop. Just stop.

Any program that can utilise 6 cores would require a 4 core to be clocked 50% faster to even keep up, so that 4.8ghz hex would require your SB cpu to hit 7.2ghz and an IB chip to hit somewhere in the region of 6.8-7ghz. You are living in a fantasy world if you think IB will run at 6ghz stable under water and claiming you can bench at 5.5ghz without any proof is very dubious.

 

[ed29a]

Guys I love having more cores and the s2011 platform,I dont know why someone said I keep saying things about quads being better as this is the first time I have ever compared them.

I am asking if the higher clocked 1155 ivys from going 22nm would beat out the sandy Es we have today once people clock them.

Would you take a 6.2ghz quad 22nm ivy or a 4.8ghz hex on 32nm.I think clock speed will beat them out until we see 22nm ivy Es but those are a long wait and will cost a lot more for giving someone an extra few cores.

Some of you are acting like 8 threads is nothing.more cores were the thing when we hit a clock wall and needed them to add performance but now with how well chips clock we are back to getting more mhz and ipc vs more cores and less clocks.

Man, AMD vs Intel fanboys was fun, but this is even better. Need more popcorn! 6.2 GHZ Ivy? Why stop there? Go for one beeeelllliiiioooon gigahurtz!111oneone!!!eleventy111one!

 

[RavenSEAL]

Man, AMD vs Intel fanboys was fun, but this is even better. Need more popcorn! 6.2 GHZ Ivy? Why stop there? Go for one beeeelllliiiioooon gigahurtz!111oneone!!!eleventy111one!

A beeeelllliiiioooon gigahurtz!? What is this, 1999?!?

 

[exar333]

I agree with mrjoltcola about this recent divide among Intel users. Why are there so many SB owners suddenly giving SB-E owners/potential buyers grief about their choice of platform? I've seen this phenomenon on several different fora now.


Who said it won't?

The point is that you're expecting too much out of Ivy Bridge. 6.2 GHz? Sure. Even if it could clock that high on average, it still probably wouldn't be enough to beat 6-core SB-E in well-threaded tasks.

And then IB-E comes out. Then what? Proclaim that Broadwell will clock high enough to beat IB-E?

I think it really comes down to budget users vs. non-budget users. For newcomers to the CPU world, $300 is 'a lot' for a CPU. I suspent a lot of folks that used to be using AMD CPUs have recently upgraded to 2500k setups especially.

I don't even think SB-E is all that expensive. Look at all the hardware we are spoiled with these days:

MB: $100 or less
CPU: $200 or less
memory: $50 or less
HDD $50 or less (assuming you buillt before the Thai flooding...)
HSF: $30 or less for some great coolers

Thats for a 2500k build that would have 8GB RAM and hit 4-4.6ghz. :awe:

Let's jump back 10-12 years: mid-range CPUs were between $400-500 (PIII for example). Sure there were budget gems like the Celeron A300, but for most folks the cheapest CPUs were $200-300.

Memory, your also shelling-out a couple hundred for a good build. MB and HDD prices I would say have been relatively constant, although the 'high end' MBs these days ($300+) definitely have a much higher ceiling.

Now back to the present...DDR3, PSUs, cases, and HDDs have hardly changed in the past couple years. Most new builds are usually just a new MB + CPU or just a new CPU). I can walk into MC today, spend $250-300 and come out with a 2500k and MB that I can plug into my existing build, tweak with for an hour or two, and viola! have a screaming rig.

I digress....anyway, the point I am making is that CPU components are CHEAP these days. The dollar buys less, but parts still have decreased. It's not 1992 anymore where an entry-level system (sans monitor) is $1000-1500. Lots of people balk at spending more than a 2500k on a system. Sure, a $500 CPU isn't 100&#37; faster than a $220 2500K, but no one is expecting it to.

 

[Idontcare]

right because 22nm wont clock higher than 32nm :whiste:

How'd that 90nm Prescott work out for you? Or your 2.9GHz max-clock Llano compared to an 1100T?

If you are looking for suicide peak clocks, then sure, every node has impressed in this regard.

But looking at 24x7 stable clocks, my 32nm 2600K does 5GHz whereas my 65nm QX6700 did 4GHz.

I'm not expecting a 3770K to do much more than 5.3-5.5GHz 24x7 stable. But no doubt you'll be able to take it to 6GHz on some silly stupid Vcc and without any serious stability testing.

But be smart about this discussion and recognize you are talking about something that is very different from what the rest of us are talking about. It is your loss if you refuse to acknowledge this reality, the rest of us have no problem recognizing it for what it is.