Clock Speed vs Performance (split)

[EtherealN]

EDIT

This is a thread split, from here: http://forums.eagle.ru/showthread.php?t=85961

The below is in response to this post: http://forums.eagle.ru/showpost.php?p=1414055&postcount=10

/EDIT

 

Meh, who cares about what the stock speed of a CPU is? The clock is just a clock. What matters is what is done during each clock cycle. Indeed, there's a reason why the gigahertz race stopped - there's just diminishing returns once you get past a certain point and it's solved through making other things more efficient, having more logic units in each core etcetera etcetera.

Edited March 9, 2012 by EtherealN

[4c Hajduk Veljko]

Meh, who cares about what the stock speed of a CPU is? The clock is just a clock. What matters is what is done during each clock cycle. Indeed, there's a reason why the gigahertz race stopped - there's just diminishing returns once you get past a certain point and it's solved through making other things more efficient, having more logic units in each core etcetera etcetera.

 

Increase in CPU clock produces linear increase in FPS. While new processors offer more cores, threads and efficiency, it appears that it is very difficult to code application to fully utilize those features.

 

I don't need more then four cores, but I do need more clock speed. Gimmi MHz's ...

[EtherealN]

Actually, no it doesn't. It's a lot more complicated than that. For example, your i7-920 running at 4GHz very nicely outperforms my previous machine, which was an e8500 also running at 4GHz. Further, you can only clock up so far before other things start bottlenecking or, for that matter, you might already have performance bottlenecks introduced by long pipelines and bad branch prediction. For example, remember the old "speed-deamon" Pentiums? They achieved this speed through introducing a miles long pipeline, which in many cases caused clock cycles to run empty because it didn't predict branches right. An architecture with a shorter pipeline can outperform high clock speeds even if it is substantially "slower".

 

Add to this that they're not "just" adding cores. Also relevant is the number of actual execution units inside the core - when I say "logic unit" I don't mean additional cores, I mean components within each core. If you have 4 integer units and a dedicated FPU in the core you'll do things a lot faster than having 2 integer units and a shared FPU, for example.

 

The clock is only relevant for comparison when looking at the same architecture. You can get a 5GHz stock speed CPU if you like, but it'll most likely not perform as well as, say, a 3.4GHz Sandy, even for single-thread applications. Like I said - there's a reason why they stopped the blind gigahertz race. Also, remember when AMD started quoting "equivalence" figures for their processors to highlight the fact that a 1.8GHz Athlon would equal a substantially "faster" Pentium? And that's in the days when multiprocessor systems were pretty much workstation and server only. And of course, the concept of "stock" really doesn't have much at all to do with what the silicon can do - it's just what they package it as. They could take the exact same silicon we have in Sandy, bin it for the top performers, and sell it as a "5GHz edition" or something. It would be 5GHz stock, but you wouldn't be overclocking it much, if at all, because it's already at it's limits.

Edited March 8, 2012 by EtherealN

[4c Hajduk Veljko]

The clock is only relevant for comparison when looking at the same architecture.

 

That is the part I did not mention in my post, but I assumed it is given.

 

However, the advanced CPU architecture, including increasing the number of cores is not resulting in huge increase of FPS in FC and DCS series.

 

What we need is raw power, GHz's, of course with the latest architecture.

[EtherealN]

Well, you're not going to see a 5GHz stock Nehalem. Ever. So no, it's not a given. :P

 

And again, Gigahertz is NOT raw power. It's just the clock. Nothing more. If you have more execution resources in a single core, you'll get more performance. You do NOT need more gigahertz - again, compare an e8500 with an i7-920. The latter runs considerably slower in stock, but still outperforms the former quite noticeably. Same thing with the step from Nehalem to Sandy.

 

Forget the gigahertz completely. It's not relevant, since you'll be comparing apples to organges when new hardware comes out.

[4c Hajduk Veljko]

I doubt that i7-920 at stock speed is much better the e8500 at stock speed for FC and DCS series. I don't care about any other application and anything else these new processor have or do. All I care is FC and DCS. And FC and DCS without any applications running in background. For a long time the FC and DCS bottleneck was (probably still is) CPU, and mostly GHz-wise.

 

Now, if you throw other applications to simultaneously run with FC/DCS (movie making software and etc) the new CPU's, mostly due to OS ability to use multiple core/thread CPU's, will run overall better.

[sebbomann]

I doubt that i7-920 at stock speed is much better the e8500 at stock speed for FC and DCS series. I don't care about any other application and anything else these new processor have or do. All I care is FC and DCS. And FC and DCS without any applications running in background. For a long time the FC and DCS bottleneck was (probably still is) CPU, and mostly GHz-wise.

 

Now, if you throw other applications to simultaneously run with FC/DCS (movie making software and etc) the new CPU's, mostly due to OS ability to use multiple core/thread CPU's, will run overall better.

 

http://en.wikipedia.org/wiki/Megahertz_myth

 

go there, read and learn. ;)

[EtherealN]

You're not getting the point I'm making. The clock does not do any computation. It does exactly the same thing as a metronome when you're playing the piano - keeps the pace. But it does not govern how many notes you hit in a given unit of time - if you have a fast metronome but only use one finger, you won't be hitting many notes. But if you use all five fingers...

 

That's the point you don't seem to be understanding: modern processors typically do not perform one operation per clock cycle. Different processors do different amounts of operations per cycle, and different types of operations require different amounts of clock cycles. Let's compare x86 to graphics processors for example - which one does a square root fastest - a 1GHz x86 implementation with one execution unit (again, execution unit is NOT the same thing as a "core"!), or a 100MHz GPU (that only gets to use a single execution unit for the job)? The fictional x86 would do roughly 66 million of them per second, and the fictional GPU would do 100 million of them.

 

It does however get more complicated than that - I used the standard conversion from stanford, but since the x86 is usually implemented with microcode, two different x86 implementations might do their calculations in completely different ways. So one processor might end up spending 50 000 operations to figure out what your plane's vector is at a given simulation frame, while another processor only has to do 10 000 operations. Or, the other processor might perhaps also need 50 000 operations, but it has two execution units available and splits the job (again - NOT the same thing as multithreading, this happens all inside the core) according to the dependencies it can manage to figure out, and spreads the job on both execution units - it can then either be twice as efficient at computing your aircraft vector if at the same clock speed, or equally effective at it if it is at half the clock speed.

 

In reality things are of course way more complex. There's also differences in branch prediction, which means one processor can spend more time idle because it made a mistake than another (and the longer your pipeline, the larger the risk for those mistakes and the larger a portion of your gigahertz you will spend doing absolutely nothing since the execution units are sitting there waiting for the gigantic pipeline to feed them input). You might remember the "old days" when Apple didn't use x86 processors - their clock speeds were always way lower than Intels, yet they did the same job in the same time. You also end up having to consider memory access issues - both as far as on-die caches go and, in those cases they're not big enough, latencies on traffic to and from the RAM. (Remember, Nehalem architecture has RAM controller on-die, while Wolfdales (like the e8500) has to send signals off of the chip to a secondary controller to get anything at all from memory.

 

Basically, you are way too simplistic in your analysis of what makes a processor run a simulator well. It's not gigahertz. The clock is only a metronome, it does no computation. What it does do is keep the things that do the actual computation coordinated - but the clock frequency itself obviously is completely agnostic to how much computation is being done. It doesn't know or care if there's one or ten integer units following it's rhythm. You cannot draw performance conclusions based on gigahertz only any more than you can judge how fast an automobile is capable of going based solely on how many RPM it's engine can take.

 

Now, if everything else is know to be exactly the same, then sure. Like, when you overclock a given processor, you know it's going to be faster than stock because in both the before and after you have exactly the same resources - just running at different speeds. But switch from that Nehalem of yours to a Sandy and suddenly they have very very little in common. You wouldn't judge top speed of aircraft based solely on engine RPM without checking what they are and if those engines are piston or turbine, right? :)

Edited March 9, 2012 by EtherealN

[Kuky]

Both MHz and architecture add to better performance... but unless the game code is not written to use more than 1 cpu it doesn't matter how many cores the CPU has.

 

It is true that newer architectures add to efficiency and by shrinking the transistors means you can put more of them into same surface area, hence add more calculations per CPU/core cycle... but these do not increase a lot.

 

So you can and will have older generation (not too old though) with higher clock rate do same ammount of work of newer architecture with stock clock... it is absurd to say higher clock does not matter, if it didn't people would not overclock and companies would not sell CPU's with different speeds.

 

It is also wrong to think that by doubling 1 part of the CPU to give double the performance... this is only 1 part in the chain and unless you double every part of the rest of the chain you will never get double the performance... perfect example... some video card have double the shaders etc but they do not give double the FPS, why... because shaders are only 1 part of the process and there will be bottleneck somewhere else.

Edited March 10, 2012 by Kuky

[EtherealN]

Both MHz and architecture add to better performance... but unless the game code is not written to use more than 1 cpu it doesn't matter how many cores the CPU has.

 

At no point in this discussion have I mentioned anything at all about multi-core, except to highlight the fact that I am explicitly NOT talking about multi-core. :)

 

It is true that newer architectures add to efficiency and by shrinking the transistors means you can put more of them into same surface area, hence add more calculations per CPU/core cycle... but these do not increase a lot.

 

New architectures don't only "add to efficiency" or "have more transistors". They often do this, of course, but that's not the point. The point is that they (might) do things - all things - in completely different ways. At which point comparisons between two using the clock frequency as a sort of poor man's benchmark is 100% useless and misleading.

 

So you can and will have older generation (not too old though) with higher clock rate do same ammount of work of newer architecture with stock clock...

 

And the opposite can happen too. You can have a new, high-clock, architecture do the same amount of work as an old, low-clock, architecture. And this is where using the megahertz myth becomes dangerous - and in fact is exactly what Intel tried to use back in the days when Apple used the 68's and AMD were the kings of gaming processors. Intel would have significantly higher clock speeds than either alternative - but wouldn't do more work than either.

 

it is absurd to say higher clock does not matter, if it didn't people would not overclock and companies would not sell CPU's with different speeds.

 

Not sure what you are responding to here, unfortunately.

 

I'll quote myself from this thread:

"The clock is only relevant for comparison when looking at the same architecture."

"Forget the gigahertz completely. It's not relevant, since you'll be comparing apples to organges when new hardware comes out."

"Now, if everything else is know to be exactly the same, then sure. Like, when you overclock a given processor, you know it's going to be faster than stock because in both the before and after you have exactly the same resources - just running at different speeds."

 

It is also wrong to think that by doubling 1 part of the CPU to give double the performance... this is only 1 part in the chain and unless you double every part of the rest of the chain you will never get double the performance... perfect example... some video card have double the shaders etc but they do not give double the FPS, why... because shaders are only 1 part of the process and there will be bottleneck somewhere else.

 

Both true and not true - this does of course depend a LOT on what the application is. If what you need is a lot of floating point throughput, then adding integer resources isn't going to help you. And the opposite, of course. There is also the possibility of increasing efficiency without actually "adding" anything - instead you might have found a more efficient way to do a given operation, leading your square roots to be done in 8 cycles instead of the "x86-default" 16. With things like that in play, you can have a new processor running on the same fab node, same speed, same amount of computation resources "on paper" inside each core, yet it will still be way more effective than the alternative.

Edited March 10, 2012 by EtherealN

[Kuky]

And the opposite can happen too. You can have a new, high-clock, architecture do the same amount of work as an old, low-clock, architecture

Well actually it can be true if you take low-end newer core CPU vs high-end previous gen CPU... now I realise we are both right. Anyway my whole point of the post was that MHz still DO matter and you are saying in your post that is doesn't... MHz matter, architecture matters also... they both matter and they will matter as long as applications are not coded for multi-core. Edited March 10, 2012 by Kuky

[4c Hajduk Veljko]

"The clock is only relevant for comparison when looking at the same architecture."

"Now, if everything else is know to be exactly the same, then sure. Like, when you overclock a given processor, you know it's going to be faster than stock because in both the before and after you have exactly the same resources - just running at different speeds."

 

You've made my case. That's pretty much what I said in the beginning.

[EtherealN]

No, you said:

"At this point, I am waiting for is a 5GHz stock sped CPU. Then I'll OC it to 6GHz ..."

 

So you are waiting for a 5GHz stock Nehalem? Like I said, not going to happen, Nehalem is being phased out for both consumer and enterprise markets, being replaced by Sandy Bridge, Sandy Bridge-E and (soon) Ivy Bridge. Sandy (and it's Ivy die shrink) is not a relabeling of Nehalem silicon, it's a separate development that had been cooking in Intel's israeli facilities for quite some time - with work starting well before Nehalem was released.

 

Now, if you had said something like:

"At this point, I am waiting for something that is the equivalent of a 5GHz i7-920."

...then it would have been fine. :)

But waiting for a 5GHz Nehalem is pointless, because it's just never ever going to happen. Nehalem is old and obsolete and won't be used in the future same way Wolfdale is all passé.

 

We saw this same attitude back during the Nehalem launch as well - people would look at the i7-920, see it's low clock speed compared to something like the Wolfdale C2D's (e8xxx), and be like "why is it slower?". Well, it wasn't "slower", not if what you count is the work it actually does (as opposed to something as simple as how fast the metronome is ticking along) - and this includes single-threaded applications. The megahertz myth is silly and harmful since people actually base purchasing decisions on it - and they shouldn't. Ever. Base purchasing decisions on actual benchmarks that are aligned with your intended use. Sometimes the "slower" processor actually gets things done faster.

 

Example - Intel i3-2100 (3.1GHz, no Turbo) scores 1.25 in a single-thread Cinebench, while an AMD FX-8150 (3.6GHz, 4.2GHz Turbo) only scores 1.03. So here we have one processor that marks up by about 20% in spite of being ~20% "slower". In fact, Bulldozer lost the single-thread operation there to even the older Phenom II X6 1100 (a 3.3GHz chip), and only narrowly beats the 6-core and slower Phenom when allowed to use all of it's 8 cores on the task. (But the epic failure that is Bulldozer is a separate discussion, and it is certainly nice for server applications - but do note how they "did an Intel" and made this specifically a speed-demon architecture; that way they can talk loud of the high clock speeds and pretend that this translates to actual performance... Unfortunate that AMD didn't learn from when Intel did their own Epic-fails in the P4 days.)

 

Thus, I believe it eminently well shown that as soon as you leave a single, specific, architecture, the clock speed is of little help when discerning which one is "better". Now, if we are comparing, say, an i5-2400 to an i5-2500, we know that the only difference between them is clock, so the 2500 wins. But when comparing an i7-920 with anything that's made in the future, the clock speed is no longer useful as a guide. For reasons I've already explained. :)

Edited March 10, 2012 by EtherealN