32-बिट बनाम 64-बिट फ्लोटिंग-पॉइंट प्रदर्शन

Question

मैं एक उत्सुक समस्या में भाग गया हूं। एक एल्गोरिथ्म मैं पर काम कर रहा हूँ इस

q = x(0)*y(0)*z(0) + x(1)*y(1)*z(1) + ... 

जहां योग की लंबाई 4 और 7

के बीच

मूल संगणना सभी 64-बिट परिशुद्धता का उपयोग किया जाता है की तरह संगणना के बहुत सारे के होते हैं। प्रयोग के लिए, मैंने एक्स, वाई, जेड इनपुट मानों के लिए 32-बिट परिशुद्धता का उपयोग करने की कोशिश की (ताकि कंप्यूटेशंस 32-बिट का उपयोग करके किया जा सके), और अंतिम परिणाम को 64-बिट मान (सीधा फॉरवर्ड) के रूप में संग्रहीत किया जा सके।

मुझे 32-बिट प्रदर्शन बेहतर होने की उम्मीद है (कैश आकार, SIMD आकार, आदि), लेकिन मेरे आश्चर्य के लिए प्रदर्शन में कोई अंतर नहीं था, शायद यहां तक ​​कि कमी भी हो सकती है।

प्रश्न में आर्किटेक्चर इंटेल 64, लिनक्स, और GCC है। दोनों कोड SSE का उपयोग करते प्रतीत होते हैं और दोनों मामलों में सरणी 16 बाइट सीमा से गठबंधन होती हैं।

ऐसा क्यों होगा? मेरा अनुमान है कि 32-बिट परिशुद्धता केवल पहले चार तत्वों पर एसएसई का उपयोग कर सकती है, बाकी को कास्ट ओवरहेड द्वारा क्रमबद्ध रूप से मिश्रित किया जा रहा है।

Answer 1

कम से कम x87 पर, सबकुछ आंतरिक रूप से 80-बिट परिशुद्धता में किया जाता है। परिशुद्धता वास्तव में यह निर्धारित करती है कि स्मृति में कितने बिट्स संग्रहीत किए जाते हैं। यह कारण है कि विभिन्न अनुकूलन सेटिंग्स थोड़ा परिणाम क्यों बदल सकती हैं: वे 80-बिट से 32- या 64-बिट तक गोल करने की मात्रा बदलते हैं।

अभ्यास में, 80-बिट चल बिन्दु (C और C++ में long double, real डी में) का उपयोग है, क्योंकि लोड और स्मृति से 80 बिट स्टोर करने के लिए कोई कारगर तरीका आमतौर पर धीमी है। 32- और 64-बिट आमतौर पर समान रूप से तेज़ होते हैं बशर्ते मेमोरी बैंडविड्थ बाधा नहीं है, यानी अगर सबकुछ किसी भी तरह कैश में है। यदि निम्न में से कोई भी होता है तो 64-बिट धीमा हो सकता है:

1. मेमोरी बैंडविड्थ बाधा है।
2. 64-बिट संख्या 8-बाइट सीमाओं पर ठीक तरह से गठबंधन नहीं हैं। 32-बिट संख्याओं को केवल इष्टतम दक्षता के लिए 4-बाइट संरेखण की आवश्यकता होती है, इसलिए वे कम जटिल होते हैं। कुछ कंपाइलर्स (डिजिटल मंगल डी संकलक दिमाग में आता है) स्टैक पर संग्रहीत 64-बिट युगल के लिए हमेशा यह अधिकार नहीं मिलता है। यह एक लोड करने के लिए मेमोरी ऑपरेशंस की मात्रा को दोगुना करने के लिए दो बार होता है, जिसके परिणामस्वरूप ठीक से गठबंधन 64-बिट फ्लोट या 32-बिट फ्लोट की तुलना में लगभग 2x प्रदर्शन हिट होती है।

जहां तक ​​सिम ऑप्टिमाइज़ेशन जाते हैं, यह ध्यान दिया जाना चाहिए कि अधिकांश कंपाइलर ऑटो-वेक्टरिंग कोड पर भयानक हैं। यदि आप सीधे असेंबली भाषा में लिखना नहीं चाहते हैं, तो इन निर्देशों का लाभ उठाने का सबसे अच्छा तरीका सरणी-वार संचालन जैसी चीजों का उपयोग करना है, उदाहरण के लिए, डी में, और एसएसई निर्देशों के संदर्भ में लागू किया गया है। इसी प्रकार, सी या सी ++ में, आप शायद एसएसई-अनुकूलित किए गए कार्यों की एक उच्च स्तरीय लाइब्रेरी का उपयोग करना चाहेंगे, हालांकि मुझे अपने सिर के ऊपर से एक अच्छा पता नहीं है क्योंकि मैं ज्यादातर डी

में प्रोग्राम करता हूं

Answer 2

ऐसा शायद इसलिए है क्योंकि आपका प्रोसेसर अभी भी 64 बिट गिनती करता है और फिर संख्या को ट्रिम करता है। कुछ सीपीयू ध्वज आप बदल सकते थे, लेकिन मुझे याद नहीं है ...

Answer 3

पहले उत्पादित होने वाले एएसएम की जांच करें। ऐसा नहीं हो सकता है कि आप क्या उम्मीद करते हैं।

इसके अलावा एक पाश के रूप में यह लिखने का प्रयास करें:

typedef float fp; 
fp q = 0 
for(int i = 0; i < N; i++) 
    q += x[i]*y[i]*z[i] 

कुछ संकलक पाश और नहीं unrolled रूप नज़र आ सकते हैं।

आखिरकार, आपके कोड के बजाय () का उपयोग किया गया। यदि आपका कोड बहुत से फ़ंक्शन कॉल (12 से 21) बना रहा है, जो एफपी लागत को स्वैप करेगा और साथ ही साथ एफपी गणना को भी हटा देगा, इससे कोई फर्क नहीं पड़ता। ओटीओएच इनलाइन कर सकते हैं।