我的定點算術實現是否正確？

Question

不久前，我創建了一堆用於定點值操作的C宏。受到SO上幾個問題和答案的鼓舞，我希望在計算密集型計劃中獲得性能提升。雖然代碼看起來能產生正確的結果，但我想知道它是不是太天真/過於簡化了，因爲它實際上比我的例程的常規浮點版本（我在Wintel上進行雙三次圖像插值）運行速度慢。您能否看看這段包含我的宏的代碼並提出一些改進建議，特別是在性能方面？謝謝。

// these are architecture-dependent 
typedef short int fixed16; 
typedef int fixed32; 
typedef __int64 fixed64; 

// value of 2^n 
#define POW2(n) (1 << n) 

// create 16bit integer-based fixed point value from a floating point value, n is the number of bits reserved for the fractional part 
#define FP_MAKE16(x, n) ((x) > 0.0 ? static_cast<fixed16>(floor((x) * POW2(n) + 0.5)) : static_cast<fixed16>(ceil((x) * POW2(n) - 0.5))) 
// the same, 32bit 
#define FP_MAKE32(x, n) ((x) > 0.0 ? static_cast<fixed32>(floor((x) * POW2(n) + 0.5)) : static_cast<fixed32>(ceil((x) * POW2(n) - 0.5))) 
// and 64bit 
#define FP_MAKE64(x, n) ((x) > 0.0 ? static_cast<fixed64>(floor((x) * POW2(n) + 0.5)) : static_cast<fixed64>(ceil((x) * POW2(n) - 0.5))) 

// convert a fixed-point integer from one (n) format to another (m) assuming n < m 
#define FP_CONVERT_UP(x, n, m) ((x) << (m-n)) 
// same for n > m 
#define FP_CONVERT_DOWN(x, n, m) ((x) >> (n-m)) 

// convert floating-point value back to float 
#define FP_FLOAT(x, n) (static_cast<float>(x)/POW2(n)) 
// same for double 
#define FP_DOUBLE(x, n) (static_cast<double>(x)/POW2(n)) 
// and for int. fractional part will be discarded! 
#define FP_INT(x, n) ((x) >> n) 

// arithmetic operations for same-format numbers 
#define FP_NEG(a) ((~a)+1) 
#define FP_ADD(a, b) ((a) + (b)) 
#define FP_SUB(a, b) ((a) + FP_NEG(b)) 
#define FP_MUL(a, b, n) (((a) * (b)) >> n) 
#define FP_DIV(a, b, n) (((a) << n)/(b)) 
#define FP_POW2(a, n) (((a) * (a)) >> n) 
#define FP_POW3(a, n) (((((a) * (a)) >> n)*(a)) >> n) 

// arithmetic for different-format numbers, assuming n is the target (result) format and n > m 
#define FP_ADD_UP(a, b, n, m) ((a) + ((b) << (n-m))) 
#define FP_SUB_UP(a, b, n, m) ((a) + FP_NEG((b) << (n-m))) 
#define FP_MUL_UP(a, b, n, m) (((a) * (b)) >> m) 
#define FP_DIV_UP(a, b, n, m) (((a) << m)/(b)) 

// same for n < m 
#define FP_ADD_DOWN(a, b, n, m) ((a) + ((b) >> (m-n))) 
#define FP_SUB_DOWN(a, b, n, m) ((a) + FP_NEG((b) >> (m-n))) 
#define FP_MUL_DOWN(a, b, n, m) (((a) * (b)) >> m) 
#define FP_DIV_DOWN(a, b, n, m) (((a) << m)/(b)) 

編輯：基本上，答案和註釋轉向這兩點：

• 的代碼是可怕的，很難使用和維護：我wholehartedly同意並會花時間把它封裝在一個類中。我對一些表現出色的問題表示了一些擔憂，並且我確信它們是毫無根據的，我毫不知情地付出了所有的麻煩。 :)
• 無論如何，固定點並不值得麻煩：儘管在我的平臺上這可能是正確的，但我創建這個來提高我的代碼在沒有浮點硬件的平臺上的執行速度。在那裏，浮點操作耗時過長，固定是要走的路。我只在英特爾測試了這個，因爲目前我無法訪問目標硬件

雖然我非常感謝迄今爲止提供的洞察力，但我希望聽到某個實際做了一些計算的人定點告訴我這些算術運算是否確實是要走的路。也許還有一些我沒有意識到的額外的點點滴滴，這會對性能或精度產生影響嗎？換句話說，如果我要封裝這些代碼，我可以在內聯運算符函數中保留基本相同的算術指令，還是應該以某種方式更改它們？

Answer 1

內聯函數。使用它們。不是宏。使用一個類，超載它的操作符。並且static_cast在C中不存在。如果您使用它發佈代碼示例，那麼這個代碼非常糟糕，這將是完全不可讀的。

請記住，浮點操作是在硬件中實現的，而您實現的定點操作是用軟件實現的。對於這種變化將會有一定的懲罰，而且很可能你的代碼在算法層面上不夠快，無法克服這種變化。

Answer 2

你可以通過編寫一個unit test找到你的實現。直到你確信你的代碼

assert(FP_ADD(7, 5) == 12) 
assert(FP_SUB(7, 5) == 2) 

等

覆蓋足夠用例：一個簡單的實現可以連續assertations來實現。此外，不要忘記比較double s和float s在一個小的epsilon。由於位表示限制，平等可能無法按預期工作。

Answer 3

您應該從C++委員會 - 「C++性能技術報告」中閱讀本文。

http://www.open-std.org/jtc1/sc22/wg21/docs/TR18015.pdf

它有效地殺死一些神話。

Answer 4

這是對@ neuviemeporte關於表現的評論的迴應。我正在做這個答案，而不是評論，所以我可以更容易地格式化代碼。你說，「AFAIK它們實際上被實現爲具有調用開銷的函數」，並且「我猜結構成員也必須被某種指針引用;你不能從'this'中逃脫。這些擔憂都是有效的，但讓我們進一步調查。

我在Linux/x86上使用gcc。考慮這個程序：

typedef int fixed32; 
#define FP_ADD(a,b) ((a)+(b)) 
#define FP_NEG(a) ((~a)+1) 
#define FP_SUB(a,b) ((a)+FP_NEG(b)) 
#define FP_INT(x,n) ((x)>>n) 
#define FP_MUL(a,b,n) (((a)*(b))>>n) 
#define FP_DIV(a,b,n) (((a)<<n)/(b)) 

template<class T, unsigned n> 
struct Fixed { 
private: 
    T theBits; 

public: 
    Fixed(T t = T()) : theBits(t) {} 

    Fixed operator+(const Fixed& rhs) const { 
     return Fixed(theBits + rhs.theBits); 
    } 

    Fixed operator-(const Fixed& rhs) const { 
     return Fixed(theBits - rhs.theBits); 
    } 

    Fixed operator~() const { 
     return Fixed(~theBits); 
    } 

    Fixed operator*(const Fixed& rhs) const { 
     return Fixed((theBits*rhs.theBits)>>n); 
    } 

    Fixed operator/(const Fixed& rhs) const { 
     return Fixed((theBits<<n)/rhs.theBits); 
    } 

    operator T() const { 
     return theBits >> n; 
    } 
}; 

int DoFpAdd(const fixed32 a, const fixed32 b) { 
    fixed32 result = FP_ADD(a, b); 
    return FP_INT(result, 16); 
} 

int DoFixedAdd(const Fixed<int, 16> a, const Fixed<int, 16> b) { 
    return a+b; 
} 


int DoFpSub(const fixed32 a, const fixed32 b) { 
    fixed32 result = FP_SUB(a, b); 
    return FP_INT(result, 16); 
} 

int DoFixedSub(const Fixed<int, 16> a, const Fixed<int, 16> b) { 
    return a-b; 
} 

int DoFpMul(const fixed32 a, const fixed32 b) { 
    fixed32 result = FP_MUL(a, b, 16); 
    return FP_INT(result, 16); 
} 

int DoFixedMul(const Fixed<int, 16> a, const Fixed<int, 16> b) { 
    return a*b; 
} 

int DoFpDiv(const fixed32 a, const fixed32 b) { 
    fixed32 result = FP_DIV(a, b, 16); 
    return FP_INT(result, 16); 
} 
int DoFixedDiv(const Fixed<int, 16> a, const Fixed<int, 16> b) { 
    return a/b; 
} 

我編譯它與此命令行g++ -O4 -Wall -pedantic -ansi -S x.cc && c++filt <x.s > x.S。

您可能會驚訝地發現，類似命名的函數產生相同的彙編語言。是的，FP_ADD（）和Fixed <> :: operator +是相同的。沒有函數調用（全部內聯）no this指針，只是指令指令相同的彙編語言。

執行速度沒有區別。可用性，可維護性和可讀性存在巨大差異。我建議你在你使用的任何平臺上進行類似的實驗，然後切換到類接口。