كيف يمكن لتطبيقات JVM مثل Jython و Jruby التغلب على نظرائهم الأصلية؟

Question

كنت أشاهد هذا الفيديو هنا, ، حيث يناقش روبرت نيكولسون P8 ، وهو تطبيق PHP على JVM. في مرحلة ما يذكر أنهم يهدفون إلى تجاوز PHP الأصلي في الأداء في وقت ما في المستقبل.

يذكر Jruby و Jython ، التي بدأت أبطأ من نظرائهما الأصليين ، لكنه تجاوزهما في النهاية. Quercus ، يدعي مترجم PHP آخر على JVM أنه 4x أسرع من mod_php ويستحق أيضا ملاحظة.

هل هذا يعني أن الفكرة العامة أن JVM أبطأ من C هي خاطئة ، أم أن هناك عيوب في تطبيقات C الأصلية؟

Answer 1

هل هذا يعني أن الفكرة العامة أن JVM أبطأ من C هي خاطئة ، أم أن هناك عيوب في تطبيقات C الأصلية؟

القليل من كليهما

كان JVM موجودًا لفترة طويلة وحقق تقدمًا كبيرًا في الكفاءة. تعد مجموعة القمامة ، والتخزين المؤقت ، والتخزين المؤقت وغيرها من المناطق أكثر تقدمًا من التطبيقات "المرجعية" مثل PHP.

أي شخص يلق نظرة تحت غطاء محرك السيارة PHP سوف يفهم لماذا يسهل تحقيق مكاسب الكفاءة.

أنا شخصياً أشك في أن JVM يمكن أن يتفوق على cpython ولكن ... ولكنني يمكن أن تكون خاطئة ... أنا ، هذا يرجع إلى أن يكون JVM GC أسرع ، و Ironpython أيضًا. قد تكون تحسينات الأداء بمثابة عدم الاعتماد على مكدس الدعوة C كما هو الحال في Python بدون تكديس. دول موقع جيثون

Jython يسرع تقريبًا مثل Cpython-في بعض الأحيان أسرع ، وأحيانًا أبطأ. نظرًا لأن معظم JVMS-من المؤكد أن أسرعها-على المدى الطويل ، سيتم تشغيل الكود الساخن بشكل أسرع.

التي يمكنني أن أؤكد أنها حقيقة لأن JVM سوف تصل إلى مستويات أداء C كما تنشئ ذاكرة التخزين المؤقت ، وهكذا تنفي بشكل أساسي الجوانب ذات المستوى الأعلى لرمز تنفيذ VM (جزء كبير منها مكتوب في C على أي حال)

في العديد من اللغات المفسرة مثل PHP و Python هي مجرد جسور لمكالمات C والغوص في رمز الجهاز. في JVM ، يقوم Jitter بوظيفة مماثلة عن طريق تقليل رمز BYTECODE إلى مكافئات الرموز الماكينة. في النهاية ، عادة ما يتم تقليل التمثيلات الوسيطة مثل بناء الجملة عالي المستوى وبلد بايت إلى عمليات CPU أو أسرع على أي حال ... لذلك كلها متشابهة ، فقط المزيد من الخطوات الوسيطة وهو ما يؤثر فقط على الكمون إلى الكفاءة الكاملة عند تحميل رمز جديد. هناك نقطة في رام حيث تقول "ما هو الفرق الحقيقي؟" والإجابة هي فقط العملية التي تحصل عليها هناك والتمثيل النهائي الذي يحدد سرعة تعويذة المكدس ، وخوارزميات جمع القمامة ، وتسجيل الاستخدام وتمثيل المنطق مثل الحساب.

Answer 2

إنه ليس صعبًا جدًا. إذا كتبت تنفيذك في C ، فيجب عليك كتابة GC الخاصة بك و JIT والمزيد (لتكون سريعًا وفعالًا). للقيام بذلك جيدًا ، تحتاج إلى أشخاص أذكياء حقًا يتمتعون بخبرة كبيرة ومنحهم الكثير من الوقت.

سوف أخرج على أحد الأطراف هنا وأقول إن التنفيذ الحالي لـ PHP (لا يعتمد على معرفة العمل الداخلي ، بل على المعايير التي رأيتها وعلى الأشياء التي يعرفها المزيد عن PHP) من الفن. يحاول Facebook معالجة هذا ولكنهم يفعلون ذلك بطريقة غير شائعة (بسبب الاحتياجات الخاصة والاستخدام النموذجي لـ PHP انظر http://www.stanford.edu/class/EE380/abstracts/100505.html).

ملخص:لذا ، إذا قام شخص ما بتنفيذ PHP في Java (أو على أي VM سريع) ، فلا يحتاج إلى كتابة GC Super أو JIT ليكون سريعًا "فقط" مترجم (والذي يمكن أن يكون بسيطًا).

Answer 3

هناك بعض التلميحات حول ما يفعله الجهاز الظاهري هنا. على سبيل المثال ، يبدو أن جهاز Java Virtual يتحقق أولاً من أي أجزاء من رمز Bytecode يتم تنفيذها في أغلب الأحيان ثم يقوم بتجميع الأجزاء ذات الصلة في الكود الأصلي (والتي يجب أن تنفذ بعد ذلك بسرعة مماثلة مثل رمز C EG).

بالمناسبة ، هل يتم تجميع PHP إلى رمز bytecode أم أنه يتم تفسيره فقط باستخدام بنية بيانات في الذاكرة؟ من خلال ترجمة PHP أولاً إلى Bytecode قابلة للتنفيذ بواسطة الجهاز الظاهري Java ، يستفيد أحدهما تلقائيًا من التحسينات الحالية (الغنية) بتنفيذ رمز Bytecution.