- To: O Plameras <oscarp@xxxxxxxxxxx>
- Subject: Re: [SLUG] Re: pentium M series
- From: Crossfire <xfire@xxxxxxxx>
- Date: Sun, 25 Dec 2005 19:43:06 +1100
- Cc: slug@xxxxxxxxxxx, Robert Collins <robertc@xxxxxxxxxxxxxxxxx>
- User-agent: Mutt/1.5.6+20040907i
O Plameras was once rumoured to have said:
> Robert Collins wrote:
>> Holy shit! You are soooo off base here its not funny. 'More than one
>> thing per clock cycle' -> What do clock cycles have to do with
>> parallelism? Nothing.
>
> Clock cycles has everything to do in the analysis of CPUs. It is the
> basic measure of CPU performance.
Wrong. The basic measure of performance is the time required to
complete an operation, not the length of a clock cycle. Clock rate
and operation speed are very orthogonal things.
> In fact you'd be a lot better as a programmer if you do understand
> clock cycles. For example, codes expend clock cycles when data are
> moved around memory; no clock cycles are expended when data are
> moved around certain registers. In this view, you'd learn what
> codes in C to avoid and what codes to use.
Actuallly, he knows better than you do.
10 years ago, most machines couldn't even fetch data from L1 cache in
a single clock cycle -- some of the earier PPCs were a good exception
there, but the x86 certainly was not a fast machine when it comes to
average cycles per op.
(I can't speak for now - nor do I care to - but I'd be amazed if intel
has mysteriously revamped their processor to complete all operations
in a single cycle though - all of a sudden, all the collected x86
optimisation technique would go to waste).
C.