Quote:
Originally posted by charliex
oberon, not quite, modern processors have multiple pipelines and hardly anyone uses clocks per instructions timing anymore since you can't easily predict it (not a PC , since P3) since you generally don't know the answer till it runs and by sampling it, and even then its not always the same.
the second part doesn't quite work either as its very unlikely you'd have a machine with the same style of CPU that had less cycles per instruction compared against a CPU with the same instruction set with more cycles at a higher clock speed.
say a RISC Vs CISC a lower cycle count for a RISC (generally 1 ) requires more instructions, but it can be beat out by a CISC with a higher number of cycles per instruction and a higher clock speed, which is typical these days.
Your formula for execution time is way off, at the very least its 6 years out of date. , i'm not even sure i understand it whats "seconds per clock cycle"?
[edit] i think i might see what you mean by seconds per clock cycle, how long it takes to execute one cycle ? , which would be a . followed by a lof of zeros and a number, but either way its still way off.
|
It's from my book, "Computer Organization & Design", published in 1998, which discusses pipelining in chapter 5 (pipelining first appeared in 1985 in the 80486 & MIPS R2000 CPUs). It's a little old, but I think the principle still applies. Sure "seconds per clock cycle" is a pretty small number and would be better represented inversely. But then it wouldn't work in the formula.
You're right about pipelining though, it does complicate the matter a little bit. My studies of this subject are incomplete, but I think my original point remains intact: clock cycles tell only part of the story.