2
$\begingroup$

I writing some robust geometric algorithms using quantization + integer arithmetic for evaluating exact predicates. However, since BlueGene's integer support is so terrible, it occurred to me that the use of integer math may (weirdly) kill the portability of the library in terms of performance.

How worried should I be about this? Are future HPC systems likely to have similar issues? I realize that a question about predicting the future may be difficult or impossible to answer, but this seems like an important design decision to get right. Any thoughts are appreciated.

In this case, there's an easy fallback: I can run an initial filtering step using floating point interval arithmetic (assuming the architecture has "round to $-\infty$" support). This has zero effect on the results since I'd fall back to integers if the filter fails. Other integer-based algorithms may not be so lucky, however.

Improve this question
$\endgroup$
3
  • $\begingroup$ I often see people using a type called real which they define as float or double or whatever. GPU Hardware is often benchmarked in floating point operations. For scientific computing double seems to be more important. When you need integer operations, you have no choice anyway. $\endgroup$
    – vanCompute
    Commented Feb 20, 2013 at 12:53
  • $\begingroup$ Would you mind being more specific about what you mean by its integer support being "terrible"? $\endgroup$
    – Jack Poulson
    Commented Feb 20, 2013 at 15:55
  • $\begingroup$ If you max out the number of threads on a BGQ node, each thread gets to do 1 integer op every other cycle, since four threads share a dual issue integer ALU. $\endgroup$
    – Geoffrey Irving
    Commented Feb 20, 2013 at 17:30

2 Answers 2

Reset to default
2
$\begingroup$

Different vendors have different paths forward on this, and most of it is under NDA. If you really want to know, ask Intel, AMD, IBM, ARM, and maybe NVIDIA for briefings under NDA. Some of these vendors will have full support for vectorized integer instructions in the future so that integer will keep up with floating-point, and some of them may not. For those that don't, you will most likely see performance at the single add, multiply, or logical operation per clock level with divide and remainder operations taking many cycles.

Improve this answer
$\endgroup$
1
  • $\begingroup$ Thanks. I'll make sure to keep the floating point filter available as a compile time choice. $\endgroup$
    – Geoffrey Irving
    Commented Feb 20, 2013 at 17:31
0
$\begingroup$

To answer your first question: I wouldn't worry about floating-point being faster than integers. If floating point operations are faster than regular integer operations, I don't see why you shouldn't use them. If you stay within 23 bits, all single-precision floating-point operations on integer values should be identical to the integer operations on the same values.

Improve this answer
$\endgroup$
1
  • 2
    $\begingroup$ I would worry. Some integer operations are used for subsequent indexing. Using floats for these operations requires type conversion and limits you to 23-bit indices. There are plenty of codes that need more than that. $\endgroup$
    – Bill Barth
    Commented Feb 20, 2013 at 14:36

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.