|
|
Re: integer Vs floating point efficiency?
Posted:
Dec 3, 2012 1:47 PM
|
|
On 2012-12-03, Gordon Sande <Gordon.Sande@gmail.com> wrote:
> On 2012-12-03 06:03:24 -0400, Rui Maciel said:
>> Gordon Sande wrote:
>>> On 2012-12-01 08:41:21 -0400, Rui Maciel said:
>>> Instruction timings etc are to be found in the processor's data sheets.
>>> Ask the manufacturer of one. The web sites will have copies or request
>>> pages.
>> I've followed your advice, and I'm in the process of digesting AMD and
>> Intel's docs that cover this subject. If anyone is interested, the
>> documents are available at:
>> http://support.amd.com/us/psearch/Pages/psearch.aspx?type=2.1%3b2.12&product=2.1.2&contentType=Tech%20Doc%20Processor
>> http://www.intel.com/content/www/us/en/processors/architectures-software-
>> developer-manuals.html
>> Unfortunately, the information isn't compiled or easily accessible. To make
>> matters worse, I've stumbled on a claim that Intel's docs have been
>> "incomplete and full of errors", which isn't very reassuring.
>> Nevertheless, some info on this subject has been compiled by third parties,
>> such as the following article:
>> http://www.agner.org/optimize/instruction_tables.pdf
>> As should be expected, latency varies with the make and model of the
>> processor, and instruction latency alone doesn't say everything there is to
>> say (or, possibly, anything) about the inherent efficiency of integer Vs
>> floating point data types. In addition, there are more than a way to skin
>> some numerical cats with the AMD64 platform, which adds to the complexity of
>> this issue.
>> Nevertheless, from what I gathered so far it appears that, in general,
>> integer operations do present a small, but possibly entirely meaningless,
>> efficiency advantage.
>> Rui Maciel
> Modern processors have the joys of pipelines so timing depends on what
> happened before
> as well as the joys of hierarchical memories. Sometimes the processor
> times are completely
> swamped by memory costs with extreme cases of requiring extra
> processing to reduce
> memory traffic. Early lierature was for simple machines with uniform
> memory faster than
> the processor so is completley misleading for current technology of
> processors faster than
> memory amd memory of varying speed.
> Micro optimization is rarely of great importance as the effects of
> large scale algorithm
> issues dominate in virtually all situations. If you had one of the
> situations where
> instruction timing was an issue you probaly would not have asked the
> question. Is the old
> story of the price of yachts. If you have to ask then you probably can
> not afford one!
There are more problems with the choice of algorithms than
appears on the surface. This is especially the case with
random number processing, and is unfortunately too often
ignored. But it can occur elsewhere; due to pipelining
problems, an "inefficient" algorithm can beat an efficient
one by better overlapping of instructions. Tranfers, even
local ones, can be very difficult to evaluate from timing
considerations, and may be completely unavoidable. Here,
gotos may greatly outdo "structured" programming.
--
This address is for information only. I do not claim that these views
are those of the Statistics Department or of Purdue University.
Herman Rubin, Department of Statistics, Purdue University
hrubin@stat.purdue.edu Phone: (765)494-6054 FAX: (765)494-0558
|
|
