جافا التلقائي إلى C ++ تحويل [مكررة

Question

هذا السؤال لديه بالفعل إجابة هنا:

• هل محول / أداة جافا إلى C ++ موجودة؟ [مغلق 10 إجابات

هل حاول أي شخص جافا التلقائي تحويل C ++ للتحسينات السريعة؟ هل هو كابوس صيانة على المدى الطويل؟ فقط اقرأ هذا يستخدم لتوليد محرك تحليل HTML5 في أبو بريص http://ejohn.org/blog/html-5-parsing/

Answer 1

بشكل عام، لن تكون التحويلات التلقائية من لغة واحدة إلى أخرى تحسنا. لغات مختلفة لها تصريحات مختلفة تؤثر على الأداء.

أبسط مثال هو الحلقات وإنشاء متغير. في عالم Java GC، خلق كائنات مع جديد مجاني تقريبا، ويغوصون في النسيان بسهولة. في تخصيص ذاكرة C ++ (بشكل عام) باهظ الثمن:

// Sample java code
for ( int i = 0; i < 10000000; ++i )
{
   String str = new String( "hi" ); // new is free, GC is almost free for young objects
}

سيؤدي التحويل المباشر إلى C ++ إلى أداء سيء (استخدم TR1 Shared_PTR كمعالج الذاكرة بدلا من GC):

for ( int i = 0; i < 10000000; ++i )
{
   std::shared_ptr< std::string > str( new std::string( "hi" ) );
}

ستكون الحلقة المكافئة المكتوبة في C ++:

for ( int i = 0; i < 10000000; ++i )
{
   std::string str( "hi" );
}

الترجمة المباشرة من لغة إلى أخرى تنتهي عادة مع أسوأ من كل من العالمين وأصعب الحفاظ على الكود.

Answer 2

النقطة الإيجابية لهذا التحويل هو أنك سوف تحتاج إلى تصميم موجه نحو كائن مناسب من أجل التبديل من جافا إلى C ++ (تقاطع النموذج).

ومع ذلك، يقول بعض الناس أن الترميز C ++ لا يجلب تحسن السرعة مقارنة ب Code Java.

Answer 3

حتى لو كان ذلك يعمل، لست متأكدا من أنك سترى تحسنا بسرعة كبيرة. أصبح مترجم JAVA Hotspot Jit جيد جدا.

Answer 4

يكاد يكون من المستحيل استبدال إدارة الذاكرة التلقائية بجافا بإدارة الذاكرة اليدوية عبر برنامج. بحيث تكون على الأرجح ستنتهي مع برنامج، يحتوي على تسرب الذاكرة أو مع رمز C ++ الذي يستخدم جامع القمامة. لكن جامع القمامة في Java لديه أشياء أكثر بكثير من الاعتماد عليها (على سبيل المثال لا توجد مؤشر عريثم أو etics)، لذلك جامع القمامة في C ++ لتكون آمنة لها أداء انخفاض. لذلك فإن التحويل التلقائي الخاص بك سوف يقلل من الأقدار.

بدلا من ذلك، حاول أن يقوم بمنفذها باليد إلى C ++ أو تحسين رمز Java.

Answer 5

لا توجد فرصة أن هذا النوع من قذيفة التحويل يؤدي إلى أداء أفضل. عادة عندما تعمل JVM، فإنه يحول معظم التعليمات البرمجية إلى رمز الجهاز الأصلي. ما تقترحه هو تحويل رمز الههر إلى C ++ ومن هناك إلى رمز الجهاز الأصلي، أي إضافة مرحلة إضافية. ومع ذلك، هناك بعض الحالات التافهة التي يمكن فيها تحقيق بعض المكاسب بسبب حقيقة أن:

1) يستغرق بعض الوقت لتحميل JVM من الصفر.

2) يستغرق الأمر بعض الوقت للقيام بالجيت، عند تشغيل برنامج قصير جدا، في كثير من الأحيان، قد تفضل إضاعة هذا الوقت قبل التشغيل.

3) قد لا تحصل على نفس مستوى رمز الجهاز على جافا، إذا كنت لا تعمل على وضع الخادم. (عند وضع الخادم، من المتوقع أن تحصل على رمز آلة الشق الأعلى، وأيضا من الأنسب لوحدة المعالجة المركزية الخاصة بك كما اكتشفت في وقت التشغيل، وعادة ما يفتقر عادة إلى معظم زرع C / C ++ للبرامج، وعلاوة على ذلك رمز الجهاز الأمثل في وقت التشغيل)

Answer 6

اللغات لديها مثل هذه الأنماط المختلفة في الاستخدام أن التحويل الطائش سيكون من الاستخدام القليل. سيكون المحول الذكي بجوار غير قادرين على الكتابة بسبب الأنماط المختلفة المستخدمة.

بعض مجالات المشاكل:

• يتم التحكم في تخصيص الموارد بواسطة "جرب {} أخيرا {}" كتل في Java أثناء استخدام C ++ Raii.
• يقوم Java بفحص استثناء في وقت إعادة ترجمة وقت C ++.
• يتم التعامل مع الاستثناءات بشكل مختلف. استثناءان:
  • في Java (يتم نشر رمي الأخير)
  • في تطبيق C ++ إنهاء.
• جافا لديها مكتبة قياسية ضخمة
  C ++ لديه كل نفس الوظيفة التي تحتاجها فقط للعثور عليه على الويب [وهو ألم].
• يستخدم جافا مؤشرات لكل شيء.
  • سيتركك تحويل مستقيم غير مرئي ببرنامج يتكون من كائنات Shared_ptr فقط.

على أي حال مع JIT Compilation Java قابلة للمقارنة مع C ++ في السرعة.

Answer 7

في حديثه عن مثل هذه المحولات بشكل عام، لا يتوقع من المتوقع أن تنتج إما كود إضافي أو عالي الأداء، لأن تلك تتطلب عموما وجود إنسان فعلي يفهم اللغة كتابة التعليمات البرمجية. ما هم مفيدون للغاية لأنه يجعل من السهل لغات المنازل. يمكن تنفيذ أي لغة مع محول إلى C، على سبيل المثال، بسرعة على مجموعة واسعة من اللغات. لقد استخدمت F2C في منتصف التسعينيات لتشغيل روتين فورتران على ماكنتوش.

يمكنك أو لا يكون لديك تحسينات للأداء إذا قمت بإعادة كتابة التعليمات البرمجية في C ++. ربما ستحصل على تباطؤ إذا كنت تستخدم محول تلقائي.