On 13-Jul-08 13:10, Orchid XP v8 wrote:
>>> That's true. But assuming we want, say, a normal "double precision" 
>>> floating point number, how many clock cycles would you estimate it 
>>> takes to operation on? A dozen? A hundred?
>>
>>   A lot. I don't believe *any* existing program for those processors
>> does double precision floating point calculations.
> 
> You're probably right about that. (Just moving 8 bytes around has to 
> take a minimum of 8 instructions, before you *do* anything to those 
> bytes.) Just wanted to make it a like-for-like comparison. ;-)
8 cycles to read, 8 to write and some more to fetch all the read and 
write opcodes plus some overhead.

> 
>>   As he said, I don't think the term FLOPS even applies if floating point
>> calculations are done in software instead of in hardware.
> 
> Floating-point operations per second. Does it matter *how* it does them? 
> Surely the important point is how many of 'em it can do.
It does. Multiplication is much slower than addition. Some operation's 
timing also depend on the specific bit patterns and overflows 
encountered during the processing. Best case and worst case could easily 
differ by a factor of 2 or more for one operation. So what time are you 
going to use?
> 
>>>> Both had a variable instruction set that took a variable amount of 
>>>> cycles to execute and therefor the number of instruction processed 
>>>> depended on the program and especially on the addressing modes used.
>>
>>> I thought this was true for *all* processors?
>>
>>   No. The idea with RISC processors is that each opcode has the same size
>> and takes exactly 1 clock cycle to execute.
> 
> Interesting. I was under the impression that processors such as the 
> Pentium can execute multiple instructions in parallel, and therefore 
> several instructions can reach the "completed" stage in a single given 
> clock cycle, but that each individual instruction still takes multiple 
> cycles from start to finish.
> 
yes? The number of FLOPS are given by the producer for the optimal case 
of completely filled pipelines so effectively 1 operation finished per 
cycle per core (for an arbitrary value of core). In benchmarks they use 
a more typical case yet still the pipelines will make a good contribution.

Post a reply to this message