why unsigned int?

[James Kanze]

On May 21, 3:34 pm, "Alf P. Steinbach" <[email protected]> wrote:

[...]

Also, by the way, division is generally NOT a single operation
or clock and in fact depends on the inputs.

The last time I ran my benchmarks on a modern Sparc, all four
operations (addition, subtraction, multiplication and division)
took exactly the same time. Regardless of the arguments. (This
wasn't true in the past: +, -, * and all four floating point
operations took the same time, but integral division was slower.
But that was in the past.)

Post the benchmarking code, methods, and results.

I can't, since I didn't save them, and I don't currently have
access to a Sparc.

The code itself is available at my site: the Operator benchmark.

 

[Keith H Duggar]

[...]
Also, by the way, division is generally NOT a single operation
or clock and in fact depends on the inputs.
The last time I ran my benchmarks on a modern Sparc, all four
operations (addition, subtraction, multiplication and division)
took exactly the same time. Regardless of the arguments. (This
wasn't true in the past: +, -, * and all four floating point
operations took the same time, but integral division was slower.
But that was in the past.)

Post the benchmarking code, methods, and results.

I can't, since I didn't save them, and I don't currently have
access to a Sparc.

That's ok. We have the hard facts from the Sun engineers themselves.
For example see Tables 7.2 and 7.3 (and for detail on specifically
division section 7.9) in the SPARC T2 specification:

https://www.opensparc.net/pubs/t2/docs//OpenSPARCT2_Core_Micro_Arch.pdf

Division is many times slower than add, subtract, multiply, etc.
For those that don't want to look here are the throughput numbers:

op : type : clocks
+ : INT : 1
* : INT : 1
/ : INT : 13 to 41 depending on input values
+ : SPF : 1
* : SPF : 1
/ : SPF : 19
/ : DPF : 33

INT = integer, S(D)PF = single(double) precision float. Which
among other things confirms that division is much slower than
other ops and integer division depends on the inputs (as does
float division in some special cases, see the discussion in
section 7.9).

The code itself is available at my site: the Operator benchmark.

Thanks. I've look at your site in the past, lots of nice stuff
there. Still waiting for you to write a book someday about your
C++ career ;-)

Unfortunately, I can see now why you were so mislead regarding
division. The OOness of your benchmarking code might be ok for
slow functions (hundreds or thousands of clocks) however it is
broken for measuring low level single instruction timings. For
one the code measurements are being dominated by the overheads
for example the virtual function calling; and unless I missed
it, no steps are taken to remove this overhead pollution from
the underlying signal. For single ops the signal is going to
be very small by comparison.

Also, I find it interesting that you concluded there is no
dependence on input values when you have hard coded 1 and 2 as
the operands?

There are a number of other problems also. You can look at my
circle drawing profiling code to see examples of the lengths
one must go to in order to accurately profile such tiny low
level functions:

http://www.duggar.org/pub/code/circle/

It's certainly not pretty but it gets the job done accurately.

KHD