2009-09-12 14 views
16

मुझे इसमें रुचि है यदि कोई आम एल्गोरिदम (, छंटाई खोज, रेखांकन, आदि) OpenCL (या किसी भी GPU भाषा) में पोर्ट दिया गया है पता करने के लिए, और कैसे प्रदर्शन एक ही की तुलना सीपीयू द्वारा निष्पादित एल्गोरिदम। मैं विशेष रूप से परिणामों (संख्याओं) में रुचि रखते हैं।GPU बनाम आम एल्गोरिदम के लिए CPU प्रदर्शन

धन्यवाद!

उत्तर

3

एनवीडिया की वेबसाइट पर इस तरह की चीज के quite a few samples हैं। ध्यान रखें कि सॉर्टिंग जैसी कुछ चीजें कुशल समांतरता के लिए विशेष एल्गोरिदम की आवश्यकता होती हैं और एक कोर पर गैर-थ्रेडेड एल्गोरिदम के रूप में काफी कुशल नहीं हो सकती हैं।

9

GPUs अति विशिष्ट बहुत अच्छी तरह से और अत्यधिक parallelized कार्यों का एक छोटा सेट करने के लिए तैयार हार्डवेयर कर रहे हैं। यह मूल रूप से अंकगणित (विशेष रूप से एकल परिशुद्धता फ़्लोटिंग पॉइंट गणित है हालांकि नए जीपीयू डबल परिशुद्धता के साथ काफी अच्छा करते हैं)। इस तरह वे केवल विशेष एल्गोरिदम के लिए उपयुक्त हैं। मुझे यकीन नहीं है कि सॉर्टिंग उस श्रेणी में फिट बैठती है (सामान्य मामले में कम से कम)।

अधिक आम उदाहरण वित्तीय उपकरणों की कीमत, मैट्रिक्स गणित की बड़ी मात्रा और यहां तक ​​कि defeating encryption (ब्रूट फोर्स द्वारा) हैं। कहा जा रहा है, मुझे Fast parallel GPU-sorting using a hybrid algorithm मिला।

एक और अधिक उद्धृत उदाहरण running [email protected] on an Nvidia GPU है लेकिन यह संतरे के लिए सेब की तुलना है। जीपीयू के लिए काम की इकाइयां सामान्य रूप से सीपीयू की तुलना में अलग (और अत्यधिक सीमित) होती हैं।

5

thrust पर एक नज़र डालें:

थ्रस्ट एक अंतरफलक जैसी सी ++ स्टैंडर्ड खाका लाइब्रेरी (एसटीएल) के साथ समानांतर एल्गोरिदम के एक CUDA पुस्तकालय है। जोर GPU प्रोग्रामिंग के लिए लचीला उच्च स्तरीय इंटरफ़ेस प्रदान करता है जो डेवलपर उत्पादकता को काफी बढ़ाता है।

+0

जोर ने संस्करण 1.1 जारी किया है। – Eric

4

सावधान रहना, GPGPU के लिए उद्धृत किसी भी प्रदर्शन संख्या के बहुत सावधान। बहुत से लोग वास्तव में प्रभावशाली संख्या पोस्ट करना पसंद करते हैं जो CPUI से इनपुट डेटा प्राप्त करने के लिए आवश्यक स्थानांतरण समय को ध्यान में रखते हैं और आउटपुट डेटा को वापस लेते हैं, दोनों पीसीआई बाधाओं पर जा रहे हैं।

+0

धन्यवाद-अच्छा बिंदु। – Chris

+3

यह सच है, लेकिन एनवीआईडीआईए के वेबपृष्ठ पर कई उदाहरण पूर्ण अनुप्रयोग हैं और निश्चित रूप से इन स्थानांतरण समयों को शामिल करते हैं। असली चिंता यह है कि बेंचमार्क में सीपीयू संस्करण कितना अनुकूलित है? – Eric

0

छवि का आकार बदलने के कई वेबसाइटों है कि छवि अपलोड स्वीकार पर आम होना चाहिए।

2600ish x 2000ish 2 एमबी जेपीईजी छवि (512x512) का आकार बदलकर पूर्णतम निम्नतम विकल्पों और निकटतम पड़ोसी नमूने के साथ सी # में 23.5 मिलीसेकंड ले लिया। प्रयुक्त फ़ंक्शन graphics.DrawImage() आधारित था। सीपीयू उपयोग भी% 21.5 था।

सी # पक्ष पर "आरजीबीए बाइट सरणी" निष्कर्षण प्राप्त करना और इसे जीपीयू में भेजना और जीपीयू में आकार बदलना और एक छवि में परिणाम प्राप्त करना 6.3 मिलीसेकंड और सीपीयू उपयोग% 12.7 था। यह केवल 320 कोर के साथ एक 55 55 सस्ता जीपीयू के साथ किया गया था।

केवल 3.73 एक्स स्पीडअप गुणक।

सीमित कारक यहाँ था, GPU को निकाले 20MB rgb डेटा (jpeg केवल 2 एमबी है!) भेज दिया। उस समय उपभोग करने वाला हिस्सा कुल समय का लगभग 9 0% था, जिसमें सी # साइड बाइट सरणी निष्कर्षण शामिल था! इसलिए मैं अनुमान लगाता हूं कि जीपीयू में निष्कर्षण भाग भी किया जा सकता है, तो कम से कम 30 एक्स स्पीडअप होगा।

30X खराब नहीं है।

फिर आप और अधिक गति प्राप्त करने के लिए मेमोरी कॉपी विलंबता को छिपाने के लिए आकार बदलने वाली परत के साथ निष्कर्षण परत पाइपलाइन कर सकते हैं! यह 40X-50X हो सकता है।

फिर नमूना की गुणवत्ता में वृद्धि करें (जैसे निकटतम पड़ोसी के बजाय बाइबिक), आपके पास GPU पक्ष में और भी अधिक लाभ है। 5x5 गॉसियन फ़िल्टर जोड़ने से केवल 0.77 मिलीसेन्ड जोड़े गए। सीपीयू को इसके ऊपर कुछ उच्च समय मिलेगा, खासकर यदि गॉसियन पैरामीटर की आवश्यकता सी # .Net कार्यान्वयन से अलग है।


भले ही आप speedup अनुपात से संतुष्ट नहीं हैं, GPU को उतारने और सीपीयू पर एक "मुक्त मूल" होने में अभी भी उस सर्वर से अधिक काम को आगे बढ़ाने के लिए लाभदायक है।

अब GPU पावर खपत के स्तर (30W बनाम 125W बनाम इस उदाहरण में) का तथ्य जोड़ें, यह अधिक फायदेमंद है। जब दोनों पक्षों अनुकूलित कोड पर चलने


सीपीयू शायद ही

C[i]=A[i]+B[i] 

मानक में जीत सकता है और आप अभी भी GPU को सरणियों के आधे बेचने और एक ही समय में सीपीयू + GPU का उपयोग करके जल्दी समाप्त कर सकते हैं।


जीपीयू गैर वर्दी कार्यों के लिए नहीं बनाया गया है। जीपीयू की शाखाओं की वजह से स्टॉल के बाद गहरी पाइपलाइनें खड़ी होती हैं, बहुत लंबी लगती है। सिमड टाइप हार्डवेयर भी इसे सभी वर्कटाइम पर एक ही काम करने के लिए मजबूर करता है। जब एक वर्कटाइम समूह की तुलना में एक अलग चीज करता है, तो यह ट्रैक खो देता है और पूरे सिम पाइपलाइन में बुलबुले जोड़ता है या बस अन्य सिंक पॉइंट की प्रतीक्षा करते हैं। तो ब्रांसिंग गहरे और चौड़े पाइपलाइन क्षेत्रों दोनों को प्रभावित करता है और इसे पूरी तरह से अराजक स्थितियों में सीपीयू से भी धीमा कर देता है।

संबंधित मुद्दे