حقيقة أن معالجات ARM64 منخفضة الطاقة من حيث استهلاك الطاقة تعني أنه يمكن حشر المزيد من الخوادم في نفس الحجم من مساحة مركز البيانات مقارنة بأجهزة x86.
إذا كان من الممكن تشغيل أحمال العمل على أجهزة ARM64، فمن المحتمل أن تتوفر طاقة معالجة أكبر لكل حامل مركز بيانات. على سبيل المثال، يستهلك كل حامل قائم على ARM طاقة أقل ويتطلب بنية تحتية أقل للتبريد مقارنة باحتياجات مركز البيانات من الطاقة والتبريد لرفوف الخادم x86.
سكوت سيلرز هو الرئيس التنفيذي لشركة”https://www.computerweekly.com/microscope/news/366612716/Azul-benefits-from-indirect-strategy”> ازول، وهي الشركة التي تقدم بديلاً لأوراكل”https://www.theserverside.com/definition/Java-Development-Kit-JDK”> مجموعة أدوات تطوير جافا (JDK) مُسَمًّى”https://www.computerweekly.com/news/366603154/Newcastle-City-Council-swaps-out-Oracle-Java-for-Azul”> منصة أزور الأساسية لتطوير وتشغيل تطبيقات Java للمؤسسات. في مقابلة مع مجلة كمبيوتر ويكلي، يناقش سيلرز تأثير بنيات المعالج على”https://www.computerweekly.com/resources/Software-development-tools”> تطوير برمجيات المؤسسة ولماذا أصبح شعار Java الأصلي “الكتابة مرة واحدة والتشغيل في أي مكان” أكثر أهمية من أي وقت مضى.
لم يعد النظام الأساسي المستهدف الوحيد لتطبيقات المؤسسات هو خادم Intel أو AMD x86. إن وحدات معالجة الرسومات (GPUs) من Nvidia ووجود شرائح خادم بديلة من ARM يعني أن اختيار النظام الأساسي للخادم المستهدف يعد قرارًا مهمًا عند نشر تطبيقات المؤسسات.
صعود أرمينيا
“ليس هناك شك في أن الابتكار على”https://www.techtarget.com/searchdatacenter/news/366613916/Intel-AMD-form-x86-group-in-effort-to-combat-Arm”>إن بنية ARM64 لها تأثير عميق على السوق”، يقول البائعين. على سبيل المثال، يشير إلى أن أمازون قامت باستثمارات كبيرة في تطوير بنيات الخادم المستندة إلى ARM64 لخدمات Amazon Web Services (AWS)، في حين أن لدى Microsoft وGoogle أيضًا مبادرات خادم ARM.
ويضيف: “إنها بطبيعتها منصة أكثر فعالية من حيث التكلفة مقارنة بخوادم x86”. “في هذه المرحلة، يكون الأداء مساويًا لـ x86، إن لم يكن أفضل منه، كما أن كفاءة الطاقة الإجمالية أفضل ماديًا.”
وفقًا لسيلرز، هناك الكثير من الزخم وراء أعباء عمل ARM64. في حين أن السحابة العامة تدعم عمومًا لغات برمجة متعددة، بما في ذلك Python وJava وC++ وRust، فإن استخدام لغات البرمجة التي تحتاج إلى تجميع لمنصة مستهدفة سيعني إعادة النظر في التعليمات البرمجية المصدر عند الترحيل بين الخوادم المستندة إلى x86 والخوادم المستندة إلى ARM. اللغات المترجمة مثل Python وJava، والتي يتم تجميعها “في الوقت المناسب” عند تشغيل التطبيق، لا تتطلب إعادة ترجمة التطبيقات.
جمال Java هو أن التطبيق لا يحتاج إلى تعديل. لا توجد تغييرات ضرورية. انها حقا تعمل فقطسكوت سيلرز، ازول
“إن جمال Java هو أن التطبيق لا يحتاج إلى تعديل. لا توجد تغييرات ضرورية. يقول: “إنها حقًا تعمل”.
وفقًا لسيلرز، عادةً ما تتضمن جهود إعادة النظام الأساسي الكثير من العمل والكثير من الاختبارات، مما يجعل الأمر أكثر صعوبة بالنسبة لهم لترحيل أحمال العمل السحابية من خوادم x86 إلى ARM64. “إذا قمت ببناء تطبيقاتك على Java، فلن تضطر إلى القيام بهذه الرهانات. ويقول: “يمكنك جعلها ديناميكيًا بناءً على ما هو متاح”.
وهذا يعني بشكل فعال أنه في البنية التحتية السحابية العامة كخدمة، يقوم مطور Java ببساطة بكتابة التعليمات البرمجية مرة واحدة ويقوم مترجم وقت تشغيل Java بإنشاء تعليمات تعليمات برمجية للجهاز للمعالج المستهدف عند تشغيل التعليمات البرمجية. يمكن لصناع القرار في مجال تكنولوجيا المعلومات تقييم التكلفة والأداء ديناميكيًا، واختيار بنية المعالج بناءً على التكلفة أو مستوى الأداء الذي يحتاجونه.
يدعي البائعون أن Java تعمل بشكل جيد للغاية على منصات x86 وARM64. ويقول إن عملاء Azul يشهدون فائدة أداء تتراوح بين 30% إلى 40% باستخدام محرك وقت تشغيل Java الخاص بالشركة. ويضيف: “وهذا ينطبق على كل من x86 وARM64”.
يقول سيلرز إن قادة تكنولوجيا المعلومات يمكنهم الاستفادة من تعزيز الأداء والكفاءة المتاح على منصة ARM64 دون الحاجة إلى إجراء أي تغييرات على عبء العمل المستهدف. وفي السحابة العامة، يقول إن هذا لا يوفر المال فحسب – نظرًا لأن عبء العمل يستخدم معالجة مستندة إلى السحابة أقل لتحقيق نفس المستوى من الأداء – ولكن عبء العمل يعمل أيضًا بشكل أسرع.
إن القرار بشأن النظام الأساسي لنشر عبء العمل هو أمر يشعر البائعون بأنه يجب تقييمه كجزء من حساب العائد على الاستثمار. ويقول: “بالنسبة لنفس القدر من الذاكرة وقدرة المعالجة، تكون عقدة الحوسبة ARM64 عادةً أرخص بنحو 20% من نظيرتها x86”. ويضيف أن هذا أمر جيد لقطاع التكنولوجيا. “بصراحة، هذا يحافظ على صدق Intel وAMD.”
ويضيف: “بعض عملائنا الكبار لديهم الآن عمليات نشر هجينة في السحابة، وما أعنيه بالهجين هو أنهم يقومون بتشغيل x86 وARM64 في وقت واحد للحصول على أفضل ما في جميع العوالم.”
ما يشير إليه البائعون هو حقيقة أنه على الرغم من أن العملاء قد يرغبون بالفعل في تشغيل أعباء العمل على البنية التحتية لـ ARM64، إلا أن هناك عددًا أكبر بكثير من أدوات x86 المنتشرة في البنية التحتية السحابية العامة.
في حين أن هذا من المقرر أن يتغير بمرور الوقت، وفقًا لسيلرز، فإن العديد من أكبر عملاء Azul لا يمكنهم شراء ما يكفي من عقد حوسبة ARM64 من موفري الخدمات السحابية العامة، مما يعني أنه يتعين عليهم التحوط على رهاناتهم قليلاً. ومع ذلك، يعتبر البائعون أن ARM64 هو الشيء الذي سيصبح حتماً”https://www.techtarget.com/searchdatacenter/news/252522071/New-HPE-ProLiant-servers-with-Arm-target-energy-savings”> القوة المهيمنة في البنية التحتية للحوسبة السحابية العامة.
لماذا لا يتعلق الأمر دائمًا بوحدات معالجة الرسومات
شهدت شركة Nvidia طلبًا كبيرًا على وحدات معالجة الرسومات (GPUs) الخاصة بها لتشغيل أعباء عمل الذكاء الاصطناعي (AI) في مركز البيانات. تجمع وحدات معالجة الرسومات المئات من نوى المعالج البسيطة نسبيًا في جهاز واحد، والتي يمكن بعد ذلك برمجتها للعمل بالتوازي، مما يحقق التسارع المطلوب في استدلال الذكاء الاصطناعي وأعباء عمل التعلم الآلي.
يصف سيلرز الذكاء الاصطناعي بأنه مشكلة “متوازية بشكل محرج”، والتي يمكن حلها باستخدام عدد كبير من نوى معالجة وحدة معالجة الرسومات، كل منها يقوم بتشغيل مجموعة بسيطة نسبيًا من التعليمات. ولهذا السبب أصبحت وحدة معالجة الرسومات محرك الذكاء الاصطناعي. لكن هذا لا يجعله مناسبًا لجميع التطبيقات التي تتطلب درجة عالية من التوازي، حيث تتم برمجة العديد من المهام المعقدة لتعمل في وقت واحد.
لأحد عملاء Azul،”https://www.computerweekly.com/feature/CTO-interview-Budgeting-in-nanaoseconds”> البورصة المالية مجموعة LMAXيقول البائعون إن وحدات معالجة الرسومات لن تعمل أبدًا. “ستكون بطيئة للغاية، وحالة استخدام LMAX ليست قريبة من التوازي بطبيعتها مع الذكاء الاصطناعي.”
ويقول إن وحدات معالجة الرسومات مفيدة في تسريع نوع محدد جدًا من التطبيقات، حيث يمكن توزيع جزء بسيط نسبيًا من المعالجة عبر العديد من نوى المعالج. لكن وحدة معالجة الرسومات ليست مناسبة لتطبيقات المؤسسات التي تتطلب تشغيل تعليمات برمجية معقدة بالتوازي عبر معالجات متعددة.
وبعيدًا عن الجدل حول الأجهزة حول ما إذا كان سيتم استخدام وحدات معالجة الرسومات في تطبيقات المؤسسات، يعتقد سيلرز أن اختيار لغة البرمجة يعد أحد الاعتبارات المهمة عند برمجة برامج الذكاء الاصطناعي التي تستهدف وحدات معالجة الرسومات.
وفي حين أن الناس على دراية ببرمجة تطبيقات الذكاء الاصطناعي بلغة بايثون، إلا أنه يقول: “ما لا يدركه الناس هو أن كود بايثون لا يفعل أي شيء حقًا. بايثون هي مجرد الواجهة الأمامية لتفريغ العمل إلى وحدات معالجة الرسومات.
يقول سيلرز إن لغة Java مناسبة أكثر من لغات البرمجة الأخرى لتطوير وتشغيل تطبيقات المؤسسات التقليدية التي تتطلب درجة عالية من التوازي.
بينما تقدم نفيديا”https://www.techtarget.com/searchdatacenter/news/365533073/Nvidia-DGX-Quantum-system-blends-CPUs-GPUs-with-CUDA”> لغة وحدة معالجة الرسومات CUDAعند كتابة تطبيقات المؤسسات التقليدية، يقول سيلرز إن Java هي لغة البرمجة الوحيدة التي تتمتع بقدرات متجهة حقيقية وقدرات هائلة في تعدد مؤشرات الترابط. وفقًا لسيلرز، فإن هذا يجعل Java لغة أفضل لتطبيقات البرمجة التي تتطلب قدرات حوسبة متوازية. مع الترابط الافتراضي، الذي تم طرحه مع Java 21، أصبح من الأسهل كتابة التطبيقات المتزامنة عالية الإنتاجية وصيانتها وتصحيح أخطائها.
ويضيف: “لقد أصبحت عمليات الترابط، وكذلك التوجيه، التي تتيح تشغيل أكثر من عملية كمبيوتر واحدة في وقت واحد، أفضل كثيرًا خلال إصدارات Java القليلة الماضية”.
نظرًا لعروض منتجات Azul، فمن الواضح أن البائعين سوف يمجدون فضائل لغة برمجة Java. ومع ذلك، هناك خيط مشترك واحد في المحادثة يجب على صناع القرار في مجال تكنولوجيا المعلومات أخذه في الاعتبار. بافتراض أن مستقبل تكنولوجيا المعلومات للمؤسسات هو مستقبل تهيمن عليه البنية السحابية الأصلية، حتى عندما يجب تشغيل بعض أعباء العمل داخل المؤسسة، يحتاج قادة تكنولوجيا المعلومات إلى معالجة حقيقة جديدة مفادها أن x86 ليست اللعبة الوحيدة في المدينة.
