Why Is Every Obsessed With Mhz Values?


mafia-man

Member
Joined
Nov 11, 2007
Messages
268
Never understood this to be honest, but why is every one so obsesed with the Mhz rating of a processor surely the MIPS value would be a better indicator of performance, especialy when comparing different arcitectures and also whether the processor has a FP unit and how many calculations that can perform per second.

I really do belive that Mhz is becoming less and less relevant these days which is one of the reasons AMD moved away from using the Mhz value in the name of a processor and why Intel have followed suit.
 
Agree with you, too difficult to compare different processors with only Mhz

I prefer Mips or benchmark for different things : pure calculation, reading/writing memory, render POV (simple scene and complicated too :) ), FPS for animation 3D (of course for device not only processor )
 
MIPS is better but since intel started making a big deal out of clock-speed it's kinda become a standard.
Still MIPS can be misleading, especially with more complex processors. It depends a lot on the instruction set and architecture of the processor.
Benchmark tests are the best way, but anyone who really needs to know the processor speed that accurately should be able to read the spec sheet and judge themselves by looking at the features etc.
 
liquidphantom said:
Never understood this to be honest, but why is every one so obsesed with the Mhz rating of a processor surely the MIPS value would be a better indicator of performance, especialy when comparing different arcitectures and also whether the processor has a FP unit and how many calculations that can perform per second.

I really do belive that Mhz is becoming less and less relevant these days which is one of the reasons AMD moved away from using the Mhz value in the name of a processor and why Intel have followed suit.
MHz can be an indicator of latency as well. If you have a 600MHz device that can do 3 instructions per clock cycle and an 1800MHz CPU that can do one instruction per clock cycle, they will both do the same amount of work in a second, but the first instruction will have happened in 1/3rd of the time on the 1800MHz CPU.

Try this: a 1Hz processor that does 2 billion instructions in a clock cycle wouldn't nearly be as useful as a 2GHz processor that does one instruction per clock!
 
Last edited by a moderator:
MHz is, and will probably forever be, the way to identify the faster of 2 CPU's. This has some prerequisites tho. They have to be the same architecture. Just as you don't compare apples to watermelons you can't compare different architecture CPU's with one and other based on frequency. You never could.
The only reason it caught on was simply since AMD, Cyrix, and Intel all licensed the same architecture and with very few exceptions made the same CPU's.
I can't believe this is still an issue.
B!
 
AireTamStorm said:
MHz can be an indicator of latency as well. If you have a 600MHz device that can do 3 instructions per clock cycle and an 1800MHz CPU that can do one instruction per clock cycle, they will both do the same amount of work in a second, but the first instruction will have happened in 1/3rd of the time on the 1800MHz CPU.
Oh, that's so very wrong. For that to work, you must make a lot of assumptions about the microarchitectures being compared. That 1800 MHz CPU likely has a much deeper pipeline (more stages), which makes its first instruction take just as long or longer than the 600 MHz one. Clock speed is not an indicator of latency--it is an indicator of maximum throughput when used in conjunction with the issue width.

Moreover, neither MIPS (which is the unit of IPC--instructions per clock) nor clock speed are (by themselves) valid indicators of performance. The Iron Law of Processor Performance gives you what you want:
(useful work / time) = (work per instruction) * (instructions per cycle) * (clock rate)

Note that work per instruction and instructions per cycle are averages, so they depend on your benchmark. If you are comparing processors with the exact same ISA, you don't need to worry about work per instruction, but you'll have to keep in mind that the IPC for the two may vary with different benchmarks.
 
Last edited by a moderator:
Intel has already stopped the MHz madness. Don't you remember they were selling 3.8 GHz P4? Now their top speed is 3.2 GHz. They suddenly realized MHz is useless, what matters is efficiency. I guess they also had to change their marketing teams or at least reeducate them :D

Now they are entering even more the efficiency territory and attack ARM; they are now realizing the embedded market that relies on batteries is an interesting place to be. Interesting times :p

For people that don't understand how silly the MHz race is, I invite them to read and understand Computer Architecture: A Quantitative Approach.

Arialia said:
reading/writing memory

How true that is... And alas, the OMAP3530 bandwidth is not very good :(
Scores I have seen are 250 MB/s for reads and 440 MB/s for writes (to main memory) for 166 MHz LP DDR.
It remains to be seen what the bottleneck is but that certainly doesn't look pretty when you realize the frame buffer is about 768,000 bytes @ 16 bpp...
 
Last edited by a moderator:
Laurent said:
Scores I have seen are 250 MB/s for reads and 440 MB/s for writes (to main memory) for 166 MHz LP DDR.
It remains to be seen what the bottleneck is but that certainly doesn't look pretty when you realize the frame buffer is about 768,000 bytes @ 16 bpp...
That is still fast enough to give you hundreds of FPS :p.
 
Last edited by a moderator:
Laurent:

I scan the Beagleboard IRC logs when I can and I was wondering something about those memory tests. Are they turning the frame buffer off before running them? People who use Beagle use the DVI output and run at resolutions much higher than Pandora. Jason likes to set his as high as possible while maintaining the pixel clock limitation and at that level, the frame buffer can use up to 247MB/s all by itself! Pandora requires around 88MB/s at 24-bit (uncompressed) video. Some of those users use 1024x768x24b which is 180MB/s so in any case, we will see better performance from this system based on the numbers.

I hope my math was right :)

EDIT: I wonder if this is proven by the lower read speeds than write speeds? Perhaps write back buffering keeps the writes high, but reads seem low because DMA transfers are switching between user space tests and frame buffer updates?
 
Laurent said:
Intel has already stopped the MHz madness. Don't you remember they were selling 3.8 GHz P4? Now their top speed is 3.2 GHz. They suddenly realized MHz is useless, what matters is efficiency. I guess they also had to change their marketing teams or at least reeducate them :D

Now they are entering even more the efficiency territory and attack ARM; they are now realizing the embedded market that relies on batteries is an interesting place to be. Interesting times :p

For people that don't understand how silly the MHz race is, I invite them to read and understand Computer Architecture: A Quantitative Approach.

Arialia said:
reading/writing memory

How true that is... And alas, the OMAP3530 bandwidth is not very good :(
Scores I have seen are 250 MB/s for reads and 440 MB/s for writes (to main memory) for 166 MHz LP DDR.
It remains to be seen what the bottleneck is but that certainly doesn't look pretty when you realize the frame buffer is about 768,000 bytes @ 16 bpp...
I've got that book :D (standard reading material for Computer Engineering Master)
 
Last edited by a moderator:
MWeston said:
I scan the Beagleboard IRC logs when I can and I was wondering something about those memory tests. Are they turning the frame buffer off before running them? People who use Beagle use the DVI output and run at resolutions much higher than Pandora. Jason likes to set his as high as possible while maintaining the pixel clock limitation and at that level, the frame buffer can use up to 247MB/s all by itself! Pandora requires around 88MB/s at 24-bit (uncompressed) video. Some of those users use 1024x768x24b which is 180MB/s so in any case, we will see better performance from this system based on the numbers.

I hope my math was right :)

EDIT: I wonder if this is proven by the lower read speeds than write speeds? Perhaps write back buffering keeps the writes high, but reads seem low because DMA transfers are switching between user space tests and frame buffer updates?
If you keep on reading the IRC logs then you will notice I have asked *three* times about that: twice about the L3 interconnect congestion and once asking if their RAM settings were correct or too cautious. I am afraid the FB is eating much of the bandwidth and is given priority on reads no matter. I'm still waiting for an answer :)

Sakoman killed x11 before running his lmbench test (ref).

Their resolution (1024x768) would eat about twice the BW needed by the Pandora, which should be not that much anyway: 1024x768x16 bpp x 60 Hz = 94 MB/s while theoretical BW is 166 MHz * 2 (DDR) * 4 (32 bit wide interface) = 1328 MB/s.

As far as write speed is concerned, as you noticed Cortex-A8 data cache is write-through so writing is more efficient because it directly goes to memory without needing to fill the d-cache, while for a read you need to load a full d-cache line. However a full d-cache line load should only reduce latency not bandwidth...

Something looks wrong definitely. If only I had access to HW I could check a few things and compare to the data I have access to...

PS - I don't agree with your maths unless there's some info I lack: 800x480x32 bpp x 60 Hz = 92 MB/s (were MB = 10^9 not 2^30 :))

PPS - In case it matters, I have run lmbench on my DDR system and I got what I would expect as far as bandwidth is concerned. This only means my understanding of lmbench results seems correct ;)
 
Last edited by a moderator:
Laurent said:
As far as write speed is concerned, as you noticed Cortex-A8 data cache is write-through so writing is more efficient because it directly goes to memory without needing to fill the d-cache, while for a read you need to load a full d-cache line. However a full d-cache line load should only reduce latency not bandwidth...
You mean it doesn't do write-allocate, right? Write-through would just mean it doesn't wait for a line to be evicted to write back to main memory. While it is kind of strange to have a cache that is both write-allocate and write-through, it can be done. ;)
 
Last edited by a moderator:
proflogic said:
Laurent said:
As far as write speed is concerned, as you noticed Cortex-A8 data cache is write-through so writing is more efficient because it directly goes to memory without needing to fill the d-cache, while for a read you need to load a full d-cache line. However a full d-cache line load should only reduce latency not bandwidth...
You mean it doesn't do write-allocate, right? Write-through would just mean it doesn't wait for a line to be evicted to write back to main memory. While it is kind of strange to have a cache that is both write-allocate and write-through, it can be done. ;)

Heh you've really been reading the P&H book :D
But you did not read carefully what I wrote : I basically told the cache is write-through, read-allocate ;)
 
Last edited by a moderator:
QUOTE

PS - I don't agree with your maths unless there's some info I lack: 800x480x32 bpp x 60 Hz = 92 MB/s (were MB = 10^9 not 2^30 smile.gif)


I get 800x480x4x60 to be 87.89MiB/s like MWeston said, thats assuming that there are 8 padded bits to make it a 32-bit framebuffer. But I think the 92 is just cause you used 10^9 not 2^30, still whats wrong with his maths.
 
flatmush said:
I get 800x480x4x60 to be 87.89MiB/s like MWeston said, thats assuming that there are 8 padded bits to make it a 32-bit framebuffer. But I think the 92 is just cause you used 10^9 not 2^30, still whats wrong with his maths.

You're right, he was right and so was I except when saying I did not agree with his maths :)

Anyway even at max pixel clock of 65 MHz the maximum bandwidth would be 260 MB/s (or 247 MB/s for 2^30, as MWeston wrote) which should leave 1328 - 260 = 1068 MB/s. So basically we are at 1/4th of the theoretical max read BW which is bad.
 
Last edited by a moderator:
Laurent said:
Heh you've really been reading the P&H book :D
But you did not read carefully what I wrote : I basically told the cache is write-through, read-allocate ;)
I just finished the undergraduate course on computer architecture at UC Berkeley, after taking the last quiz on synchronization and cache coherency protocols on Thursday. So yes, I am quite familiar with the book. :)

flatmush said:
I get 800x480x4x60 to be 87.89MiB/s like MWeston said, thats assuming that there are 8 padded bits to make it a 32-bit framebuffer. But I think the 92 is just cause you used 10^9 not 2^30, still whats wrong with his maths.

All this silly ambiguity... Hopefully the IEC binary prefixes will gain widespread adoption eventually. They are taught here at UCB, at least, so some of the new guys ought to be using them. ;)
 
Last edited by a moderator:
Back
Top