"जावा दुनिया में फिर से वही नहीं होगा" - बेल्सॉफ्ट से अलेक्जेंडर बेलोक्रीलोव और एलेक्सी वोइटिलोव के साथ साक्षात्कार

अंतिम दिन जोकर से पहले बने रहे, और मैं वास्तव में हैबर को एक साधारण साक्षात्कार नहीं, बल्कि कुछ शक्तिशाली खेल लाना चाहता था। हाल ही में, लोग आर्म पर सर्वरों में रुचि रखते हैं, और ऐसा हुआ कि हमारे पास इस विषय पर वास्तविक विशेषज्ञ हैं।

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

पिछले वर्ष के दौरान OpenJDK में कमिट्स की मात्रा के अनुसार, वे पांचवें स्थान पर आए, और अब केवल Oracle, Red Hat, SAP और Google आगे हैं:



आपको यह समझने की आवश्यकता है कि बेलसॉफ्ट केवल आर्म नहीं है:

• लाइबेरिका JDK 11 जारी किया गया है , लिनक्स x86_64, विंडोज, लिनक्स ARMv8, लिनक्स ARMv7 (रास्पबेरी पाई सहित) समर्थित हैं। मैक और सोलारिस स्पार्क के लिए बिल्डिंग्स बिछाई जाएंगी।
• सभी आर्किटेक्चर के लिए छवियां डेबियन हब पर डेबियन, सेंटोस, अल्पाइन के लिए प्रकाशित की गई हैं। अल्पाइन के लिए चित्र लाइट संस्करण से बनाया गया है --compress 2 इसलिए सामान्य JDK की तुलना में काफी छोटा है।

इस साक्षात्कार में, हम केवल आर्म पर टच करेंगे, और अगली बार बाकी को छोड़ देंगे।

तो आज हमारे वर्चुअल स्टूडियो में:

अलेक्जेंडर बेलोक्रीलोव

लेशा वॉयलटोव

ओलेग चिरुखिन - JUG.ru समूह के संपादक

---

कंपनी के बारे में अधिक बताएं?

बेल्सॉफ्ट कंपनी कई क्षेत्रों में लगी हुई है। हर कोई शायद जानता है कि ओरेकल क्लाउड-सर्विस सिस्टम को विकसित करने में सेंट पीटर्सबर्ग में ओरेकल को जावा रनटाइम को विकसित करने, संकलक विकसित करने में एक बहुत ही गंभीर निम्न-स्तरीय विशेषज्ञता थी। और ओरेकल से यह विशेषज्ञता बेल्सॉफ्ट में स्थानांतरित हो गई। आज, हमारी कंपनी जावा रनटाइम को विकसित कर रही है, हम एक सक्रिय OpenJDK योगदानकर्ता हैं, हम gcc और llvm कंपाइलर विकसित कर रहे हैं, हम Apache, Graal स्टैक में योगदान करेंगे। हम वास्तविक डेटा से डेटा एकत्र करने के लिए बड़े डेटा विश्लेषण सिस्टम, एडवाइज़र सिस्टम के निर्माण में लगे हैं और IoT पर एक छोटी परियोजना का निर्माण किया है। कुछ बिंदु पर, हमने देखा कि ओरेकल ने आर्म प्लेटफॉर्म के लिए जावा वितरण जारी करना बंद कर दिया था, और हमने अपना स्वयं का वितरण जारी किया, जिसे रास्पबेरी पाई के लिए लाइबेरिका जेडीके कहा जाता था। तब से, हम सफलतापूर्वक इसका समर्थन करते हैं।

---

आइए एक नज़र डालें। उदाहरण के लिए, एक अपाचे स्टैक क्या है?

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

---

यह सब क्यों आवश्यक हो सकता है? उदाहरण के लिए, कुछ कक्षाएं जो उन्हें धीमा करती हैं, क्या उन्हें ओवरक्लॉक किया जा सकता है?

हां, यह उन क्षेत्रों में से एक है जिस पर हम काम कर रहे हैं - उत्पादकता में सुधार। उदाहरण के लिए, प्लेटफ़ॉर्म-विशिष्ट भागों, जिनमें से OpenJDK का त्वरण Hadoop को गति देने में मदद कर सकता है। यदि रुचि है, तो हम इसके बारे में बात कर सकते हैं।

जब आप प्रदर्शन की समस्याओं को हल करते हैं, तो कुछ को देखने के लिए समझ में आता है। शायद वही समस्या कहीं है। आप अक्सर देखते हैं कि एक स्थान पर सही होने के बाद, आपको कुछ स्थानों पर सही करने की आवश्यकता होती है, ताकि सामान्य रूप से यह बेहतर हो सके। कभी-कभी (बहुत और अक्सर) प्रदर्शन अनुकूलन कई परियोजनाओं में योगदान से विघटित हो जाता है। यदि आप सुधार करना चाहते हैं, उदाहरण के लिए, checksum का प्रदर्शन, आप स्टैक के बहुत नीचे देखते हैं। मान लीजिए कि यह जावा है। यदि आप थोड़ा ऊंचा दिखते हैं, तो यह होडोप, स्पार्क या कुछ और होगा। आमतौर पर, एक जगह को कैसे बेहतर बनाया जाए, यह समझकर आप इसे दूसरी जगह कैसे कर सकते हैं बेशक, इस मामले में यह समझ में आता है कि वहां भी जाएं और सुधार करें।

---

हर कोई जानता है कि आप लाइबेरिका हैं। आइए इस बारे में बात करते हैं।

हां, हम लिबरिका जेडीके हैं। लाइबेरिका ने इस तथ्य के साथ शुरू किया कि हमने देखा कि एआरएम 32 के लिए कोई पोर्ट नहीं है, और इसे तत्काल करने की आवश्यकता है, क्योंकि रास्पबेरी पाई को जावा 9 और जावा 10 के बिना छोड़ दिया गया था। यह 2017 में था जब जावा 9 बाहर आया था। अब लिबरिका जेडीआई कई आर्किटेक्चर का समर्थन करता है। और ऑपरेटिंग सिस्टम।

यह स्पष्ट हो गया कि ओरेकल आर्म के लिए कोड को और विकसित नहीं करने जा रहा है, और हमने इस अंतर को बंद करने के लिए सक्रिय रूप से वितरण और जारी करना शुरू कर दिया। यह स्पष्ट हो गया कि लोगों को इसकी आवश्यकता है।

---

तो, अब कई शाखा वितरण हैं?

हां, आर्म के लिए कई जावा डिस्ट्रीब्यूशन हैं, वे अलग हैं। हमारे में, आपको वास्तव में ओरेकल पोर्ट डिस्ट्रीब्यूशन किट का हिस्सा हुआ करता था। हमारे वितरण में JavaFX, डिवाइस इनपुट / आउटपुट और एक एम्बेड करने योग्य API है। यह एक पैकेज है, और यह सभी मॉड्यूल के साथ काम करता है, JDK 9 से शुरू होता है। एक मॉड्यूलर प्रणाली का उपयोग करके, आप अपनी इच्छानुसार रनटाइम का निर्माण कर सकते हैं। यदि आप चाहें, तो आप एक छोटा 16 मेगाबाइट रनटाइम बना सकते हैं। यदि आप अधिक सुविधाओं को सक्षम करना चाहते हैं, उदाहरण के लिए, एक वेब सर्वर, तो आपको लगभग 32 मेगाबाइट स्थिर स्थान खर्च करने की आवश्यकता है। आप अपनी आवश्यकताओं के लिए काम कर रहे रनटाइम प्राप्त कर सकते हैं।

---

जहां तक ​​मैं समझता था, हम सेना के सर्वरों के बारे में बात कर रहे थे। यह कहने के लिए नहीं कि हमने उनका बड़े पैमाने पर उपयोग किया है। सर्वर के बारे में बताएं? वास्तविक जीवन में वे सभी मौजूद हैं?

यह कहानी कई सालों से है। बहुत पहले आर्म सर्वर 32-बिट ARMv7 आर्किटेक्चर के आधार पर बनाया गया था। यह एक बहुत बड़ा शोर बॉक्स था, जो व्यावहारिक रूप से काम नहीं करता था, क्योंकि BIOS, लिनक्स काम नहीं करता था, कुछ घंटों के बाद सब कुछ गायब हो गया। कंपनी ने इसे शुरू किया, कैलक्सेडा, समय के साथ बंद हो गया। लेकिन सर्वरों के लिए एक वैकल्पिक वास्तुकला विकसित करने का विचार समाज में बोया गया था। एआरएम ने अंततः ARMv8 आर्किटेक्चर के लिए एक नया विनिर्देश जारी किया, जो 32 और 64 बिट्स दोनों का समर्थन करता है। इस विनिर्देश के 64-बिट संस्करण के आधार पर, कई निर्माता अब सर्वर के लिए अपने प्रोसेसर कार्यान्वयन का निर्माण कर रहे हैं। उदाहरण के लिए, एम्पीयर कंप्यूटिंग, कैवियम, जिसे अब मार्वेल और क्वालकॉम ने खरीद लिया है। और एक और कंपनी है - एएमडी, कुछ साल पहले, आर्म आर्किटेक्चर के आधार पर सर्वर भी जारी किए। मेरी राय में, वे अभी भी ऐसा करना जारी रखते हैं।

---

यदि आप Marvell से एक अक्षर L हटाते हैं, तो आपको सुपरहीरो मिलते हैं। इन सभी कार्यालयों के नाम याद रखने का एक अच्छा तरीका है।

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

---

सामान्य अनुप्रयोगों के लिए स्केलेबिलिटी सीमा कैसे बढ़ती है? कितना CPU एक सर्वर में छड़ी करने के लिए समझ में आता है?

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

---

क्यों आर्म, इंटेल नहीं? हमारे पास अद्भुत इंटेल सर्वर हैं, क्यों कुछ और के साथ आते हैं?

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

कोई एक एकाधिकारवादी के साथ नहीं रहना चाहता।

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

---

और लागत के बारे में क्या? इंटेल समाधानों की तुलना में कितना अधिक महंगा है?

यह एक कठिन प्रश्न है। सबसे पहले, जैसा कि एलेक्सी ने कहा, निर्माता पर्याप्त हैं। यह स्पष्ट है कि अब आर्म-प्रोसेसर के निर्माता एक-दूसरे के साथ प्रतिस्पर्धा नहीं करते हैं, लेकिन किसी और के साथ प्रतिस्पर्धा करते हैं। वे थोड़ा अलग niches पर कब्जा कर लेते हैं। यदि कैवियम उच्च प्रदर्शन कंप्यूटिंग है, तो क्वालकॉम मिड-रेंज सर्वर है, एम्पियर या तो वर्कस्टेशन या लो-एंड सर्वर हैं।

अगर मुझे सही से याद है, एम्पीयर कम्प्यूटिंग से सीपीयू की कीमत $ 600-900 है, और वे इंटेल के साथ प्रतिस्पर्धा करते हैं, तो सीपीयू की कीमत लगभग 1,500 डॉलर है। कैवियम थोड़ा महंगा है। फिर, वे इंटेल के साथ प्रतिस्पर्धा करेंगे, जो काफी अधिक महंगा है। आपको यह समझने की आवश्यकता है कि सर्वर की कीमत केवल सीपीयू की कीमत नहीं है। सर्वर की कीमत भी मेमोरी, डिस्क, समर्थन, खपत है। यदि आप एक पैरामीटर पर जीतते हैं, उदाहरण के लिए, सीपीयू की लागत - यह ठीक है, लेकिन आप केवल थोड़ा सस्ता होंगे। यदि आप दो तरीकों से जीतते हैं, उदाहरण के लिए, सस्ता होने के बावजूद, बेहतर प्रदर्शन की पेशकश करते हुए, वे आपको और करीब से देखेंगे। और अगर तीन में, उदाहरण के लिए, आप यह सब कम बिजली की खपत के साथ भी कर सकते हैं, तो यह पहले से ही जीत के लिए एक आवेदन है।

---

लोहे और इसके समर्थन के अलावा, सॉफ्टवेयर में समर्थन भी महत्वपूर्ण है। आप उन सभी चीज़ों पर नहीं चल सकते हैं जो अब आप इंटेल पर स्पिन करते हैं।

बेशक। मुझे कहना होगा कि सॉफ्टवेयर का आर्म इकोसिस्टम बहुत आगे बढ़ चुका है। यदि पांच साल पहले लोहे के टुकड़े को उठाने के लिए समस्याएं थीं, तो अब ऐसी समस्याएं नहीं हैं। तुम बस आओ और सब कुछ तुम्हारे लिए बॉक्स से बाहर काम करता है। सब कुछ आप काम करने के लिए उपयोग किया जाता है - लिनक्स, डोकर, कुबेरनेट्स, एक्सएन, जावा, हडोप, स्पार्क, काफ्का, कुछ भी।

---

जावा के बारे में क्या? हमें बताएं कि यह कैसे काम करता है, यह "सामान्य" एक से कैसे अलग है?

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

---

क्या ओरेकल ने आपको अनिवार्य रूप से अपनी पत्रिका में विज्ञापन देने दिया था? गंभीरता से।

जाहिर है, एक मांग है। यह पता चला है कि जावा-वर्कलोड के लिए जावा आर्म-सर्वर काफी अच्छी तरह से काम करते हैं। वे इंटेल के समकक्षों की तुलना में समान हैं, या उससे भी बेहतर हैं।

---

आपके लेख को किसको पढ़ना चाहिए?

उन लोगों के लिए जो नई वास्तुकला का परीक्षण करना चाहते हैं, चाहे वह इसके भार के लिए उपयुक्त हो। जावा और उन्हीं आर्म-सर्वर दोनों की कोशिश करें। Google में आर्म सर्वर क्लाउड को ड्राइव करें, और आपको कई क्लाउड प्रदाता मिलते हैं, आप एक कार्ड पकड़ सकते हैं और कोशिश कर सकते हैं कि आपको क्या चाहिए।

---

क्या जावा पहले से ही वहां स्थापित है?

हां। सादा OpenJDK।

---

क्या रेगुलर OpenJDK और आपकी लिबरिका समान चीज़ का वितरण करते हैं? मैंने देखा कि आपके कमिट हैं - यह है या कुछ और है?

सामान्य तौर पर, आर्म पोर्ट और ओपनजेडके का इतिहास काफी दिलचस्प और अलंकृत है। प्रारंभ में, ओरेकल ने आर्म पोर्ट विकसित किया, और जब आर्म ने ARMv8 आर्किटेक्चर जारी किया, तो इस आर्म पोर्ट में एक अतिरिक्त पोर्ट जोड़ा गया जिसने जावा को ARMv8 पर चलने दिया। इसके समानांतर, रेड हैट ने भी इस दिशा में काम किया और इस वास्तुकला के लिए ओपनजेडीके में अपना पोर्ट डाला। ऐसा हुआ कि समुदाय ने Red Hat पोर्ट पर ध्यान केंद्रित किया। इसलिए, अब हमारे पास एक्सेसरी है जो एआरएम 32 पोर्ट के लिए ओपनजेडके में थी, जिसने वास्तव में अराजकता 64 पोर्ट की कार्यक्षमता को दोहराया था - हम इसे जेडडीके 12 में वहां से हटा देंगे। ऐसा करने से, हमारे पास जेईपी 340 है।

मुझे कहना होगा कि ओरेकल ने समर्थन को रोकने से पहले, सभी आर्म पोर्टों से ओपनजेडीके में अपनी सभी उपलब्धियों को डाला। अब आर्म के लिए सभी सुविधाएँ जो ओरेकल में बनाई गई थीं, उनमें डाली गई हैं।

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

---

मैंने इन्फोग्राफिक्स को हड़ताली आंकड़े दिखाते हुए देखा कि सेंट पीटर्सबर्ग में स्थित एक निश्चित कंपनी बेलसॉफ्ट ने भारी संख्या में आवागमन किया।

हां, हम शीर्ष 5 OpenJDK कमिटर्स में हैं। स्वाभाविक रूप से, ओरेकल प्रतिस्पर्धा से बाहर है, प्रति वर्ष लगभग 4 हजार कमिट्स हैं।

इसके बाद Red Hat, SAP, Google और BellSoft आता है। हम Google तक नहीं पहुँचे। और ठीक हमारे बाद आईबीएम है।

---

ओरेकल में आपके कितने प्रतिशत कर्मचारी काम करते थे?

100 प्रतिशत। बेल्सॉफ्ट पूर्व ओरेकल कर्मचारियों से बना है।

---

यह अनुचित प्रतिस्पर्धा है क्योंकि Google ओरेकल के 100 प्रतिशत कर्मचारियों से नहीं बना है। कैसी लगी, बताओ? ऐसी सफलता कैसे प्राप्त करें? शीर्ष 5 कमिटर्स में कैसे जाएं?

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

---

हमने सर्वर पर 64 बिट्स के बारे में बात की। 32-बिट पोर्ट अभी भी जीवित क्यों है?

क्योंकि यह एम्बेडेड में उपयोग किया जाता है।

क्योंकि कई कंपनियों ने एम्बेडेड अनुप्रयोगों के लिए ARMv7 वास्तुकला के लिए एक सीपीयू लागू किया है। उनके गोदामों में बड़ी संख्या में चिप्स हैं। यदि मेमोरी मुझे सही काम करती है, तो इन चिप्स की पूरी विविधता ARM32 है, सबसे लोकप्रिय ARMv5 है। यह वास्तुकला कई वर्षों से है, लेकिन फिर भी, सीपीयू काफी सस्ते हैं, और निर्माता अभी भी इस वास्तुकला पर नए उपकरण बनाने पर विचार कर रहे हैं।

---

जब हम इमारत के बारे में बात करते हैं तो हम किस मात्रा में बात कर रहे हैं? क्या एक सामान्य व्यक्ति अपने लिए कुछ खरीद सकता है और प्रयोग कर सकता है?

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

शायद आपको खरीदने की जरूरत नहीं है। आप देख सकते हैं कि आपके घर के राउटर में क्या है। यह बहुत संभावना है कि ऐसा कुछ है।

---

डेवलपर कौशल वहां कितना अनुरूप होना चाहिए?

आपको जावा डेवलपर होने की आवश्यकता है।

---

क्या आपको कोड करने के लिए कर्कचॉफ के नियम को जानने के लिए मुश्किल तरीकों की आवश्यकता है?

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

---

और सेंसर के साथ कैसे काम करें? हम बाहरी व्यवस्थाओं के लिए यह सब करते हैं, है ना?

रास्पबेरी पाई में एक GPIO सिस्टम और पिन है जिससे आप कुछ भी कनेक्ट कर सकते हैं। आमतौर पर सभी उत्साही रास्पबेरी पाई से सभी बाह्य उपकरणों को जोड़ते हैं।

---

API कैसा दिखता है? क्या लिखा जाना चाहिए, जैसे, "मुझे थर्मोस्टैट से एक नंबर प्राप्त करें"?

आपको थर्मोस्टैट डेटाशीट को पढ़ने की जरूरत है, और यह समझें कि रजिस्टर क्या हैं, इसे कैसे इनिशियलाइज़ किया जाए, इसे कैसे कॉन्फ़िगर किया जाए। यदि I2C, कॉन्फ़िगरेशन के लिए विधि को कॉल करता है, तो वहां सभी पैरामीटर पास करें। फिर उसे i2c.open बताएं, और इसके साथ जावा ऑब्जेक्ट के रूप में काम करें।

---

क्या विशुद्ध रूप से ऑब्जेक्ट मॉडल में काम करने के लिए थर्मोस्टैट्स के आसपास सुंदर ऑब्जेक्ट रैपर लिखना संभव है? क्या ऐसा किया जा सकता है ताकि डेटाशीट को कभी भी न पढ़ा जा सके, इसे एक पहलू के साथ बंद किया जा सके?

यह अच्छा होगा अगर इस सेंसर के निर्माता ने रेडीमेड कॉन्फिगरेशन बनाया और हम, जावा प्रोग्रामर के रूप में, बस इसे ले लिया और इसका इस्तेमाल किया। लाइब्रेरी एक सेंसर के साथ काम करती है, दूसरे सेंसर के साथ काम करने के लिए लाइब्रेरी। इस तरह की लाइब्रेरी या इसके कुछ पास को Pi4J कहा जाता है। यह अब उतनी तेजी से विकसित नहीं हो रहा है, जितने दिनों में ओरेकल जावा को स्थानांतरित कर रहा था, लेकिन यह अभी भी नहीं मरा, कुछ अपडेट समय-समय पर दिखाई देते हैं। एक विकल्प है: या तो OpenJDK - GPIO में एक चीज़ के साथ काम करें, या Pi4J लाइब्रेरी के साथ काम करें।

---

यदि मैं एक हार्डवेयर निर्माता हूं, तो मुझे जावा के बारे में कुछ भी पता नहीं है, लेकिन मैं चाहूंगा कि जावा प्रोग्रामर इसका उपयोग करें, मुझे किससे संपर्क करना चाहिए? आपसे संपर्क करने के लिए? या ऐसे विशेषज्ञ हैं जो ऐसा करते हैं?

हां, हम ऐसे विशेषज्ञ हैं।

---

अभी तक हम बहुत दूर तक नहीं भागे हैं। मुझे याद है कि आपके पास कुछ JEP थे, है ना?

OpenJDK संस्करण 11 में 17 JEP शामिल हैं। 14 Oracle, 1 - Google, 1 - Red Hat, 1 - BellSoft द्वारा कैवियम के साथ मिलकर बनाया गया था। हमारा JEP विशिष्ट कार्यभार के लिए ARM64 प्लेटफॉर्म पर जावा प्रदर्शन में सुधार का एक हौजपेज है। JEP, क्रमशः, Aarch64 आंतरिकता कहा जाता है। संक्षेप में, हमने स्ट्रिंग के साथ, सरणियों के साथ और गणित और त्रिकोणमिति के साथ संचालन के प्रदर्शन में सुधार किया है।

---

आंतरिक क्या हैं? हर कोई नहीं जानता।

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

---

कौन सी प्रोसेसर को सीधे कॉल करता है जिसमें साइन कमांड है?

जो एक जटिल एल्गोरिथम के अनुसार इसकी गणना करेगा। इंट्रिंसिक्स हैं जो किसी प्रकार के कोडांतरक कमांड को कहते हैं। उदाहरण के लिए, चेकसम की गणना के साथ जुड़े आंतरिक। इस तरह के विधानसभा निर्देश लगभग सभी आर्किटेक्चर के लिए मौजूद हैं। जब एक अच्छा प्रदर्शन को बढ़ावा देने के लिए, कई जटिल इंट्रिंसिक्स हैं, तो कई कोडांतरक पृष्ठ लिखें।

---

और एन्क्रिप्शन, क्या यह हार्डवेयर में है?

हां, यह आमतौर पर किसी विशेष प्रोसेसर के मौजूदा निर्देशों के लिए एक कॉल है। कभी-कभी - उन चिप्स पर एक्सटेंशन के साथ काम करें जहां वे हैं।

---

अपने जेईपी पर लौटना: कैसे निर्धारित किया जाए कि कौन सा कोड इतना गर्म है कि यह इसके लायक है इतना हार्डकोड?

बड़ा सवाल है। जब हमने ARM64 प्लेटफार्मों के लिए कुछ का अनुकूलन करना शुरू किया, तो हमारे पास पूर्ण के अलावा बड़ी संख्या में उपकरण नहीं थे। हां, और उसने हर जगह काम नहीं किया। ARM64 पोर्ट के लिए कोई JFR कार्यान्वयन नहीं था, उस समय तक Oracle ने इसे Open Source में नहीं रखा था। प्रदर्शन को मापने के लिए विभिन्न उपकरण जो हम उपयोग करते थे, उदाहरण के लिए, async-profiler, ईमानदार-प्रोफाइलर - वे ARM64 प्लेटफार्मों के लिए भी काम नहीं करते थे। पहली चीज जो हमने की, वह इस वास्तुकला पर इन सभी उपकरणों को मिला।

---

बॉक्स से बाहर काम क्यों नहीं करते?

क्योंकि किसी प्रकार का CPU-विशिष्ट भाग है।

फिर आप इन उपकरणों को उस वर्कलोड पर लॉन्च करते हैं जिसे आप अनुकूलित करने की कोशिश कर रहे हैं, स्क्रीन को लंबे समय तक देखें, यह समझने की कोशिश करें कि वहां क्या तरीके गर्म हैं, उनमें कौन से स्थान गर्म हैं। ऐसे सरल मामले हैं जब किसी विशिष्ट आर्किटेक्चर के लिए कुछ कोडांतरक आवेषण कार्यान्वित नहीं किए जाते हैं। इस स्थिति में, जावा कोड में कमबैक होता है। बस इन कोडांतरक आवेषण को लागू करने से आप प्रदर्शन में वृद्धि प्राप्त कर सकते हैं। अधिक जटिल स्थान हैं जब आपको यह समझने की आवश्यकता होती है कि सभी आर्किटेक्चर बनाने के लिए जावा में आपको किस नए कोडांतरक की आवश्यकता है। ऐसी नौकरी।

---

सैम डाटासेट कहाँ प्राप्त करने के लिए? पूरे गिथब को परिभाषित करें और इसे जेआईटी के तहत चलाएं?

यह स्पष्ट है कि कुछ बेंचमार्क या वर्कलोड को अनुकूलित किया जा रहा है। प्रसिद्ध बेंचमार्क - SpecJBB, SpecJVM। विशिष्ट वर्कलोड हैं जो विशिष्ट ग्राहकों को रुचि देते हैं। बस इन वर्कलोड को चलाएं और बाधाओं को देखें।

---

ये सभी SpecJVM बहुत पुराने परीक्षण हैं, है ना? नए लंबोदर, धाराओं, बड़ी तारीखों के बारे में क्या?

कोई बात नहीं। यह वहाँ नहीं है।

---

और कहां से लाएं?

नए कार्यभार।

---

उदाहरण के लिए, अपाचेवस्की स्टैक?

हां।Hadoop में एक मानक TeraSort बेंचमार्क है, जिसे हार्डवेयर निर्माता मापना पसंद करते हैं। अनुकूलन के लिए दिलचस्प कार्यों में से एक।

---

अब अनुकूलन करने के लिए शीर्ष सुविधाएँ क्या हैं? उदाहरण के लिए, एक ही JEP से शीर्ष।

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

---

कंपाइलर कैसे देखेगा कि आप क्या कर रहे हैं? अपेक्षाकृत, जादुई रूप से समझता है कि आप कुछ प्रसिद्ध फार्मूले पर विचार करते हैं और अनुकूलन करते हैं?

Math.sin , Java- sin .

---

- , sin ?

हां। , .

---

- , , ?

C2, .

---

- . , ?

.

, Linaro Connect OpenJDK ARM64. Linaro Foundation Arm-.

---

?

Arm, . .

---

?

. . Joker, .

---

!

, . floating point. , , , . — , . , , — . , .

---

. , , ?

हां। Arm … , — . , . - - , — . , , . , , . , Java- , .

---

, - , . ?

OpenJDK BellSoft.

---

, , ? ? Oracle, . JVM-?

, OpenJDK. ()

---

, 250 . ?

, 250 . .

---

— ? .

, . . , — . - .

---

, ?

.

---

?

. . , - , , . , , , . - . , . , , . , OpenJDK .

---

?

Mailing list. - mailing list, .

---

-?

Jira. OpenJDK Jira, , , .

---

Jira Jira, , ?

OpenJDK . , Jira.

---

? , , , , , Arm?

Arm, , , . shared-, , . , . .

---

, . , .

, . HotSpot, , , . , , - — .

---

- ?

हां। HotSpot tiers. smoke- . , , . , performance-, stress-.

---

. , , JDK, . JDK, . , ?

JDK, , JVM. JVM 4 : runtime, serviceability, garbage collector, compiler. - . , runtime. - out of order execution, , GC . , JIT, . community OpenJDK — JIT.

---

, , ?

, . , . . . , -, , .

---

? ? ? , , - ?

. , .

---

, , - , . .

. , OpenJDK Arm. , , IT. -, , Arm . , Arm, Arm , . , OpenJDK, Arm. , , . Arm Intel SPEC-. , . . !

, ?

---

, ?

, .

. . , ARM64? . , Arm .

.

---

— , , -, . ? - , Arm?

, .

---

?

Arm . . , , ? . .

, . , , , . - 10 , GPU - , . Cloud- . , , -. GPU, CPU. -, HTTP 404. , . , .

---

, - , ? - ?

. , . 30 ? . , . - , , . : 20% , 20%, — 10%, - . , Arm .

---

, Java, , . , , .

Arm , BellSoft — Arm, . OpenJDK, - . Liberica Liberica Arm 32 64, Liberica Linux (64 ), Windows Liberica Mac. Liberica Solaris Sparc. .

---

Liberica Mac? -.

? Oracle , … . ?

---

?

, Oracle. , Java- .

---

Java- .

, . , .

---

.

हां। -, support . - — , , Cloud-. , , - , .

---

, Oracle JDK , API. -XX:+UnlockCommercialFeatures . , . , Oracle , .

, Oracle - Oracle, . . Java , .

, , OpenJDK . . BellSoft , , .

---

, , . . , , OpenJDK — .

!

---

. , — . - ?

. , , , . .

- OpenJDK.

---

. ?

Liberica, . Raspberi Pi, Linux-. , Java, -.

---

Joker, , BellSoft — .

. , , . , :-) Joker — .

---

, . !

---

. Joker 2018 «, ARM? , » . .