RayLivingston:
The instruction details are in section 12.9. It does have hardware divide. Of course, as with any cached processor, actual performance depends a LOT on whether the instructions, and data, are cached. Most instructions are single-cycle when cached, but can take many cycles if not. Actual performance is heavily dependant on the actual instruction sequence generated by the compiler, and where things are in memory. Profiling your actual code is by FAR the best way to determine what the performance will be for your application.Regards,
Ray L.
That code is not likely to give you a good idea of the actual arithmetic performance, as it will be spending more time executing the loop than doing the actual division. You need to do enough operations in the loop to swamp the loop overhead.Again, profiling the ACTUAL code is the best way to go. Actual performance will be heavily impacted by the data access patterns, loop overhead, other operations, etc., etc.
Regards,
Ray L.
Hi Ray,
it is simpler than you think, the trick is to make two time measurements after each other.
- one with 2 statements per iteration (e.g. 1000000 = 1M loops)
- one with 1 statement per iteration
subtracting the values would automatically subtract the overhead (which is identical for both loops) ,
leaving the actual time for 1M divisions.
Another trick I once used was the following. If you have a X Mhz processor make a loop of X million iterations. The number of seconds is the number of clock cycles used (including loop overhead). But it is fun to - sort of - count the clock cycles