4 ms·

How big improvements do you feel improved hardware fixed point support could yield, and what form might the improvements take? Imagining for example that Intel

by zurn 11y ago

How big improvements do you feel improved hardware fixed point support could yield, and what form might the improvements take? Imagining for example that Intel decided to make a instruction set extension in their next CPU.

jjuhl 11y ago
I don't know the answer to your question. But if you can get access to a machine with a POWER CPU you could test it, since those CPUs contain hardware fixed-point arithmetic units.
chowells 11y ago
Modern CPUs are already so complex and so fast that I can't imagine the potential speedup would be significant as compared to modern optimized fixed point libraries. Language support is a much bigger issue. Programmers are fundamentally lazy, and will always do the thing that takes the least work (for them, right now). So for fixed point numbers to really be used, that means that they need to be fully first class in the language. Literals need to exist, and with syntax no more complex than it is for other numerical literals. And of course, all operators must use the same syntax for both. This is hard to retrofit into a language. Java and C can't retrofit either in. C++, Python, and Ruby can do operators, but not literals. You have to get into pretty uncommon languages before support for additional numerical types becomes good. Haskell and Scala, for instance, can meet both of the requirements. Given that, I'd say any kind of widespread use of fixed point numbers in the cases where they're more appropriate than floats is at least 30 years away. Maybe 50.
- anon4 11y ago
  Didn't C++ get support for user-defined literals?
  - Someone 11y ago
    Yes. See http://en.cppreference.com/w/cpp/language/user_literal http://en.cppreference.com/w/cpp/language/user_literal
- jacobolus 11y ago
  You should give some more concrete examples of domains where you think fixed point is more appropriate than floating point, but floats are currently used. As it is, your comment can’t really be discussed or disputed, because it’s just an abstract complaint with no substantive evidence/analysis presented. Here are some areas where I think floats are more appropriate than fixed point, given the availability of CPUs and GPUs with native floating point support: computer game physics, any kind of 3d rendering, 2d vector graphics including e.g. map rendering, high dynamic range image/video editing, most types of statistical analysis, ... I’m having trouble thinking of any applications where I think fixed point numbers seem more appropriate than floats or integers, except code running on embedded devices without native floating point. Audio maybe? Image/video decoding for immediate playback?
  - zurn 11y ago
    Floating point is actually a significant source of bugs in 3D graphics and games. And a complex thing you have to constantly keep in mind, taking cognitive resources from other more useful stuff. And a thing you have to code around, increasing the codebase complexity, making changes harder and taking time from programming/debugging/testing useful code. CPUs and GPUs do have support for fixed point (aka integer) data formats, it's been a DX/OpenGL requirement for a while. Though I don't know what API issues you run into if you try to avoid FP altogether.
    - shele 11y ago
      Floating point arithmetic is a significant source of bugs. And if you transition to fixed point arithmetic, you will still have a significant source of same-same-but-different bugs (maybe unless you really only need to add things and not never scale or multiply them).
      - zurn 11y ago
        What kind of bugs do you have in mind for fixed point? While there no doubt would be some, I have a feeling they are a significantly lesser drag (in frequency and debugging complexity) than floating point bugs. Assuming the language supports fixed point. Of course you can imagine error-prone fixed point too. Writing shaders with plain integers while trying to manually keep track heterogenous fixed point scales would be a nightmare for example...
DougBTX 11y ago
Unums could be interesting, more of a GPU answer than a CPU answer though https://github.com/tbreloff/Unums.jl/wiki/Unum-Summary-(in-progress) https://github.com/tbreloff/Unums.jl/wiki/Unum-Summary-(in-p...
- dnautics 11y ago
  You may want to play with a functioning (still early and being debugged) implementation: https://github.com/REX-Computing/unumjl https://github.com/REX-Computing/unumjl Disclaimer: I'm the author
- Someone 11y ago
  But how do you make them efficient? If assignment to any variable can grow or shrink its size requirements, I don't see how you can avoid introducing an indirection that will eat your cache locality, or waste storage by making every variable of maximum size "just in case", in which case you are back to using quad floats throughout.

by zurn 11y ago

jjuhl 11y ago

I don't know the answer to your question. But if you can get access to a machine with a POWER CPU you could test it, since those CPUs contain hardware fixed-point arithmetic units.

chowells 11y ago

Modern CPUs are already so complex and so fast that I can't imagine the potential speedup would be significant as compared to modern optimized fixed point libraries. Language support is a much bigger issue. Programmers are fundamentally lazy, and will always do the thing that takes the least work (for them, right now). So for fixed point numbers to really be used, that means that they need to be fully first class in the language. Literals need to exist, and with syntax no more complex than it is for other numerical literals. And of course, all operators must use the same syntax for both. This is hard to retrofit into a language. Java and C can't retrofit either in. C++, Python, and Ruby can do operators, but not literals. You have to get into pretty uncommon languages before support for additional numerical types becomes good. Haskell and Scala, for instance, can meet both of the requirements. Given that, I'd say any kind of widespread use of fixed point numbers in the cases where they're more appropriate than floats is at least 30 years away. Maybe 50.

anon4 11y ago
Didn't C++ get support for user-defined literals?
- Someone 11y ago
  Yes. See http://en.cppreference.com/w/cpp/language/user_literal http://en.cppreference.com/w/cpp/language/user_literal
jacobolus 11y ago
You should give some more concrete examples of domains where you think fixed point is more appropriate than floating point, but floats are currently used. As it is, your comment can’t really be discussed or disputed, because it’s just an abstract complaint with no substantive evidence/analysis presented. Here are some areas where I think floats are more appropriate than fixed point, given the availability of CPUs and GPUs with native floating point support: computer game physics, any kind of 3d rendering, 2d vector graphics including e.g. map rendering, high dynamic range image/video editing, most types of statistical analysis, ... I’m having trouble thinking of any applications where I think fixed point numbers seem more appropriate than floats or integers, except code running on embedded devices without native floating point. Audio maybe? Image/video decoding for immediate playback?
- zurn 11y ago
  Floating point is actually a significant source of bugs in 3D graphics and games. And a complex thing you have to constantly keep in mind, taking cognitive resources from other more useful stuff. And a thing you have to code around, increasing the codebase complexity, making changes harder and taking time from programming/debugging/testing useful code. CPUs and GPUs do have support for fixed point (aka integer) data formats, it's been a DX/OpenGL requirement for a while. Though I don't know what API issues you run into if you try to avoid FP altogether.
  - shele 11y ago
    Floating point arithmetic is a significant source of bugs. And if you transition to fixed point arithmetic, you will still have a significant source of same-same-but-different bugs (maybe unless you really only need to add things and not never scale or multiply them).
    - zurn 11y ago
      What kind of bugs do you have in mind for fixed point? While there no doubt would be some, I have a feeling they are a significantly lesser drag (in frequency and debugging complexity) than floating point bugs. Assuming the language supports fixed point. Of course you can imagine error-prone fixed point too. Writing shaders with plain integers while trying to manually keep track heterogenous fixed point scales would be a nightmare for example...

DougBTX 11y ago

Unums could be interesting, more of a GPU answer than a CPU answer though https://github.com/tbreloff/Unums.jl/wiki/Unum-Summary-(in-progress) https://github.com/tbreloff/Unums.jl/wiki/Unum-Summary-(in-p...

dnautics 11y ago
You may want to play with a functioning (still early and being debugged) implementation: https://github.com/REX-Computing/unumjl https://github.com/REX-Computing/unumjl Disclaimer: I'm the author
Someone 11y ago
But how do you make them efficient? If assignment to any variable can grow or shrink its size requirements, I don't see how you can avoid introducing an indirection that will eat your cache locality, or waste storage by making every variable of maximum size "just in case", in which case you are back to using quad floats throughout.