2011-02-04 7 views

उत्तर

22

उत्तर कई चरों पर निर्भर करता है।

लेकिन आम तौर पर रूबी 1.9 जेआरबी से तेज है, लेकिन रूबी 1.8 जेआरबी से धीमी है।

उदा। Computer Language Benchmarks Game के अनुसार:

इसके अलावा, आपके आवेदन मल्टी-थ्रेडेड है अगर, JRuby may have some advantages over standard Ruby
(यानी एमआरआई)], आप कितने कोर के आधार पर।

+1

ruby ​​1.9 parrallel में बहु थ्रेडिंग का समर्थन करता है? – JohnMerlino

+2

रूबी 1.9 समर्थन * समवर्ती * लेकिन * समांतरता * नहीं। यदि आप समांतरता चाहते हैं तो आपके दो विकल्प जर्बी और रूबिनीस हैं। –

+0

यह सबसे महत्वपूर्ण चर है जो संस्करण पर निर्भर करता है। आपने JRuby के संस्करण की सूची नहीं बनाई है। ये बेंचमार्क हर समय बदलते हैं क्योंकि सुधार किए जाते हैं। – bridiver

2

ईमानदारी से, यह आपके कोड पर निर्भर करता है। अपनी मशीन पर आरवीएम या पिक स्थापित करें, रूबी के विभिन्न संस्करणों का एक समूह स्थापित करें, और अपने कोड को चलाने का प्रयास करें।

उदाहरण के लिए: एक एप्लिकेशन जो अक्सर पुनरारंभ होता है वह जेआरबी के लिए एक महान उम्मीदवार नहीं है क्योंकि हॉटस्पॉट आपके कोड को प्रभावी ढंग से अनुकूलित करने में सक्षम होने से पहले कुछ रैंप-अप समय है। इसी प्रकार, थ्रेड पर निर्भर एक आवेदन रूबी 1.8.7 के लिए एक महान उम्मीदवार नहीं है क्योंकि रूबी 1.8.एक्स आपके प्रोसेसर पर 1 से अधिक कोर का उपयोग नहीं कर सकता है और इस प्रकार एक समय में एक से अधिक धागे पर निष्पादित नहीं कर सकता है।

+0

रुबी 1.9.2 के बजाय रुबी 1.8.7 का उपयोग करने का क्या कारण होगा? – igouy

+3

जेम संगतता। – rogerdpack

+0

न केवल मणि संगतता, बल्कि पूर्ण अनुप्रयोग संगतता। कुछ ऐप्स जो पुराने नहीं हैं वे 1.9.एक्स के साथ काम नहीं करेंगे। – PatrickTulskie

2

प्रोग्रामिंगजन.com पर लोगों द्वारा किया गया एक बहुत अच्छा लेख है जो रूबी के कई अलग-अलग स्वादों की तुलना करता है। जुलाई में पिछले साल तो अभी भी यथोचित हाल ही में प्रकाशित किया गया था;) वहाँ पेज इन तुलना:

* Ruby 1.8.7 p299 
* Ruby 1.9.1 p378 
* Ruby 1.9.2 RC2 
* IronRuby 1.0 (Mono 2.4.4) 
* JRuby 1.5.1 (Java HotSpot(TM) 64-Bit Server VM 1.6.0_20) 
* MagLev (rev 23832) 
* Ruby Enterprise Edition 2010.02 
* Rubinius 1.0.1 

आप के लिए वहाँ

http://programmingzen.com/2010/07/19/the-great-ruby-shootout-july-2010/

+0

1) वे अब नवीनतम संस्करण नहीं हैं। 2) दुर्भाग्य से कई माप सारांश से बाहर किए गए हैं क्योंकि एक कार्यान्वयन का समय समाप्त हो गया है या कोई त्रुटि हुई है - जो 30 में से 10 को हटा देता है। – igouy

+0

धन्यवाद igouy .. उपयोगकर्ताओं के प्रश्न का उत्तर देने का प्रयास कर रहा था, सोचा कि यह एक बहुत अच्छा संकेत था और क्या करना है उम्मीद करते हैं। आप इस लेख को पढ़ सकते हैं कि आप कैसा पसंद करते हैं, लेकिन मैंने सोचा होगा कि किसी भी टाइमआउट और त्रुटियों को निश्चित रूप से प्रकाशित किया जाना चाहिए जब इन तुलनाओं की तुलना में ..? – 2potatocakes

+0

>> लेकिन मैंने सोचा होगा << अनुमान लगाने के बजाय, मैंने लेख के लेखक से पूछा - "कौन सा डेटा सारांश में बना है - केवल पंक्तियों से डेटा जिसमें कोई टाइमआउट या त्रुटि नहीं थी?" और उसने जवाब दिया "हां।" टिप्पणियां पढ़ें। – igouy

22

हाल मानक से ढूंढ कर सकता है में JRuby डाल लीड, मैग्लेव, रूबिनीस, फिर एमआरआई के बाद।

बेंचमार्किंग मुश्किल है। Ruby Benchmark Suite रूबी बेंचमार्क के लिए सबसे अधिक उपयोग करता है। यदि आप किसी भी कार्यान्वयन में विफल होने वाले किसी भी मानक को हटाते हैं, तो आपको निम्न ग्राफ मिलता है।

RBS

सूचना मैं ज्यामितीय माध्य इस्तेमाल किया। यह औसत प्रदर्शन का एक बेहतर संकेतक है क्योंकि यह आउटलाइजर्स और मशीन चश्मे को सामान्य करता है।

आपके द्वारा चलाए जाने वाले सर्वोत्तम बेंचमार्क आपके ऐप के लिए विशिष्ट होंगे। यदि आप समग्र प्रदर्शन की तलाश में हैं, तो आप वास्तविक धागे का उपयोग करना चाहेंगे, इसलिए रूबिनीस या जेआरबी आपके एकमात्र असली विकल्प हैं।

इसके अलावा, प्रत्येक कार्यान्वयन अलग-अलग चीजों पर तेज़ है। एमआरआई बहुत शुरू होने पर तेज़ है, इसलिए यह स्क्रिप्ट के लिए अच्छा है। लंबे समय से चलने वाले अनुप्रयोगों (जैसे वेब अनुप्रयोग) के लिए रूबिनीस या जेआरबी आमतौर पर एमआरआई से बेहतर प्रदर्शन करेंगे।

+1

एक टिप्पणी हेडियास (मुझे लगता है) अपनी वार्ता में से एक में सार्थक है। JRuby बस के रूप में रह सकता है और JVM में किए गए सुधारों के कारण प्रदर्शन अभी भी बढ़ेगा। और उन्हें मुफ्त में सर्वश्रेष्ठ कचरा संग्रह एल्गोरिदम भी मिलते हैं। जावा की तरह या नहीं, JVM पर काम कर रहे बहुत से स्मार्ट लोग हैं। – mrbrdo

+0

पूरी तरह से, और रूबिनीस के लिए वीएम और एलएलवीएम में सुधार से भी यही कहा जा सकता है। रोमांचक समय! एक ज्यामितीय माध्य का उपयोग करने के लिए – jc00ke

+0

+1। मैंने विकिपीडिया पर ज्यामितीय अर्थ देखा और यह वास्तव में आयाम को कम करने का एक अद्भुत तरीका है। – seo

2

वास्तव में उपरोक्त उत्तर मिकेल के जवाब को छोड़कर सही नहीं है, अगर आपने जेवीएम के लिए कोई बेंचमार्क देखा है तो आपको यह धीमा लगेगा कि क्रूबी की तुलना में जेआरबी के प्रदर्शन की कल्पना करें।

व्यक्तिगत रूप से मैं एक एमआरआई रूबी योगदानकर्ता हूं और मुझे लगता है कि एमआरआई रूबी के याएआरवी वीएम की शुरूआत के बाद उपरोक्त बेंचमार्क चार्ट सत्य नहीं है, यह संस्करण सबसे तेज़ हो गया है और बहुत सारे मानक साबित हुए हैं "देखें पैट शॉन्गेसी के बेंचमार्किंग और तीन प्रसिद्ध रूबी दुभाषियों एमआरआई रूबी, जेआरबी और रूबिनीस के बारे में टिप्पणियां "। तो मेरी राय में निम्नलिखित तार्किक बिंदुओं के कारण तुलना की कोई बात नहीं है: -

1- सी जावा से बहुत तेज है क्योंकि यह सीधे हार्डवेयर पर चलता है और मशीन कोड उत्पन्न करता है। जबकि जेवीएम बाइटकोड उत्पन्न करता है जिसे इंटरमीडिएट कोड माना जाता है।

2- जेआरबीबी में एमआरआई रूबी "टोकनाइजेशन, पार्सिंग, एएसटी पार्सिंग और वाईएआरवी निर्देश" कोड जनरेशन "और अंत में कोड निष्पादन के विपरीत एक अतिरिक्त व्याख्या कदम है" जबकि जेआरबी में एक अतिरिक्त चरण होता है।

3- एमआरआई रूबी में कचरा संग्रह जेआरबी में कचरा संग्रह से बहुत तेज है, फिर भी जब यह मार्क में कुछ बदलाव पेश करता है और कचरा संग्रह तकनीक को साफ़ करता है तो यह बेहतर होता है।

4- यदि आपने अधिकांश कंपनियों और प्रौद्योगिकियों का उपयोग किया है, तो वे हमेशा एमआरआई रूबी का इस्तेमाल करते हैं, विशेष रूप से रूबी 1.9, मैंने शायद ही कभी कंपनी को जेआरबीई का उपयोग करके देखा या एमआरआई रूबी के विपरीत इसमें बहुत से एक्सटेंशन या योगदान भी देखा।

अंत में रूबी 1.8 हाँ यह धीमा है क्योंकि वे एएसटी पर कोड निष्पादित कर रहे थे ताकि वे कोड निष्पादित करने के लिए एएसटी को कई बार पार्स कर सकें।

यदि मैं कुछ भी गलत हूं तो मुझे उम्मीद है कि कोई मुझे सुधार देगा।

आरवीएम या स्रोत से एमआरआई रूबी दोस्त स्थापित करें। आपको

+2

1. जेवीएम मूल मशीन कोड के लिए सबसे आसान तरीकों को संकलित करता है। यह प्रोफाइल अनुकूलन करता है जो इसे आक्रामक रूप से इनलाइन करने की अनुमति देता है। यदि आपका सी कंपाइलर गलत विकल्प बनाता है तो जेवीएम सी से तेज़ी से समाप्त होता है। आमतौर पर स्ट्रिंग प्रदर्शन को छोड़कर जेवीएम और सी गति के मामले में बहुत करीब है। –

+1

क्रूड क्षमा करें मेरा मतलब 1 पर समाप्त नहीं होना चाहिए :) 2. जेआरबी और एमआरआई दोनों के पास एएसटी पीढ़ी के बाद एक अतिरिक्त कदम है। JRuby 9000 में कि अंतिम चरण substeps में तोड़ दिया गया है, लेकिन अभी भी मूल रूप से वही है। 3. एमआरआई में जीसी निश्चित रूप से जावा के किसी भी जीसी से तेज नहीं है। मैंने कभी भी किसी को भी इस दावे को पहले कभी नहीं देखा है। 4. ज्यादातर कंपनियां वास्तव में जेआरबीआई पर एमआरआई का उपयोग करती हैं। ज्यादातर लोग जो एमआरआई से स्विच करते हैं, उससे बात करते हैं, खराब जीसी की वजह से और बहु-थ्रेडिंग में जाने से बड़ी जीत होती है। एमआरआई अब अपने ऐप के लिए स्केल नहीं कर सकता है, तो हमारे ज्यादातर उपयोगकर्ता प्रभावी रूप से हमें उपयोग करते हैं। –

+0

वास्तव में आप का दावा कर रहे हैं एमआरआई में है कि जी सी JRuby की तुलना में धीमी है, क्योंकि "किसी ने मेरी राय से सहमत नहीं था" वास्तव में मैं 1.9 की तुलना में अधिक संस्करणों के बारे में बात कर रहा हूँ एमआरआई में जीसी कि JRuby में की तुलना में बेहतर हो गया। और मेरा मानना ​​है कि एमआरआई जेआरबी से भी ज्यादा विस्तार कर रहा है। जेआईटी "बस समय" संकलन के लिए प्रतीक्षा करें :)। – user3719235

2

के साथ काम करने के लिए बहुत सारे रत्न और एक्सटेंशन मिलेंगे। कई उपयोगकर्ताओं ने पहले ही बेंचमार्क के संबंध में उत्तर दिया है। आपका प्रश्न विशेष रूप से रेल के उपयोग के लिए है।

मुझे यह असामान्य लगता है क्योंकि मुझे स्पष्ट रूप से प्रश्न का लक्ष्य दिखाई नहीं देता है। वहां एमआरआई और कई लोग जेआरबीई और कई अन्य लोगों का उपयोग कर बहुत से हैं। मैं उस सम्मान में स्थिरता और सुरक्षा और रखरखाव के लिए जाना चाहूंगा, गति नहीं।

हालांकि, एमआरआई और जेआरबी के बीच एक महत्वपूर्ण अंतर है।

एमआरआई एक जीआईएल का उपयोग करता है। इसका मतलब है, हालांकि आपके पास एकाधिक धागे हो सकते हैं, एक समय में केवल एक धागा सक्रिय हो सकता है। विभिन्न रूबी संस्करणों में धागे का कार्यान्वयन भी भिन्न हो सकता है। नए संस्करण ओएस थ्रेड्स (अच्छे चरण आगे) का उपयोग करते हैं, पुराने संस्करण इसके बजाय हरे धागे का उपयोग करते हैं।

एमआरआई में कोई वास्तविक समांतरता नहीं है।

एमआरआई बहु थ्रेडेड है, थ्रेड सुरक्षित नहीं है और समानांतर नहीं है।

जेआरबीई बहु-थ्रेडेड है, थ्रेड सुरक्षित और समांतर नहीं है।

समांतरता गति में अंतर डाल सकती है। दोनों धागे सुरक्षित नहीं हैं, इसलिए आपको वैसे भी इसका ख्याल रखना होगा। यदि आप गति की तलाश करते हैं और समांतरता का फायदा उठा सकते हैं, तो मैं जेआरबी को एक निश्चित हां दूंगा।

फिर से, मुझे यकीन नहीं है कि एमआरआई और जेआरबी के बीच निर्णय लेने पर गति सबसे महत्वपूर्ण कारक है या नहीं। यह पारिस्थितिकी तंत्र है। चूंकि आपने गति की मांग की है, इसलिए मैं इसमें आगे नहीं जाऊंगा।