شكرا استاذ اتمنى منك تعطينا معلومات اكثر او تدلنا على مصارد مناسبة لانه شات جي بي تي ما جاب خبر عم يخلط بين التقنيات احيانا يقول ان لغة سي مبنية على لغة اسمبلي واحيانا يقول انها مبنية على التصميم المنطفي ولي اسمبلي 😂 ويقول انه فيه لغات ما تمر بمرحلة الاسمبلي وانما تترجم مباشرة الى لغة الالة 😢 وكمان اللغات المفسرة .... ياليت تدلني علي مصدر كويس من اجل افهم شوي
Computer Systems: a programmers prespective by Randal Bryant خصوصا أول الأقسام part1 & 2: program structure and execution / running programs on a system
لا أتفق معك ان تريد كسب سرعة باستبدال كتابة المفسر الـ Interpreter المطور بـ ++C بلغة الـ Assembly الفكرة غير مجدية، للأسباب التالية: - المترجمات الـ Compilers الحالية اسرع وافضل من البرمجة اليدوية بكثير واذا كان هناك مجال للـ Optimization فسيكون بقدر لايذكر, في النهاية المفسر سيمر بمرحلة الـ Assemble سواء كتب يدوياً او عن طريق Compiler - مشكلة بطأ لغات السكربت ليست بسبب سرعة المفسر المكتوب بلغة ++C المشكلة وجود خطوة اضافية عند تفسير سطر السكربت قبل التنفيذ ,لغات السكربت صممت بهذا الشكل لاسباب كثيرة. - Portability احد اهم اسباب وجود لغات السكربت, اذا اردت للغة السكربت ان تعمل على اي معمارية يكفي ان تعمل Compile للمفسر المكتوب بلغة ++C يستهدف تلك المعمارية وبذلك ستتمكن من تشغيل البرنامج المكتوب بلغة السكربت على اي معمارية باستخدام المفسر الـ Interpreter المناسب "write once run anywhere", لكن اقتراحك سيصعب هذه الفكرة لانك تريد كتابة المفسر مباشراً بلغة الـ Assembly لكل معمارية على حدا, هذا سيكون مكلفاً من ناحية الصيانة والتطوير بدون اي فائدة تذكر.
كل ما ذكرته يعتبر اضافة على اساس تصميم و فكرة المفسر الاصلية. المفسر يشغل عالطاير و بس. هذه هي فكرته الاصلية. فكرة ان يكون كود المفسر يعمل على عدد من المنصات هذه اضافة و ليست من اصل التعريف للمفسر. و التحسينات التي تتكلم عنها ليست شرط التصميم. كرمال هيك انا لي الحق في ان اصمم المفسر بالتعريف الأساسي.
@@superlinux تم اختراع فكرة لغات السكربت لتحقيق امور لاتستطيع تحقيقها اللغات المترجمة لكن على حساب السرعة لوجود خطوة التفسير، لكل نوع من اللغات مكان للإستخدام والموضوع ليس منافسة بين اللغات المترجمة واللغات المفسرة، اما فكرة كسب سرعة بسيطة في في مرحلة التفسير لن تلغي هذه المرحلة، فائدة استخدام اللغات المترجمة لكتابة المفسرات بدل لغة التجميع يفوق كثيراً الـ overhead البسيط، حيث ان المفسر يعتبر برنامج معقد ويحتاج للمرونة في التطوير والصيانة.
@@superlinux فينا نحويل الكود المصدري للغة المفسرة للغة مترجمة متل سي أو سي بلس بلس ، بعدين منترجمها بمترجم هديك اللغة ( مثل GCC ) هاد الحكي يمكن يحسن الأداء بشكل كبير ، متل HipHop الخاص بفيسبوك يلي بيترجم بي أتش بي لسي بلس بلس ، بس بالرغم من هيدا التحسينات ، لازم نلاحظ أنو هناك حد للأداء فينا نصلو باللغات المفسرة مقارنة باللغات المترجمة مباشرة إلى كود لغة الآلة ، إضافة لهيك اللغات المترجمة مثل سي و سي بلس بلس عندها أداء عالي بسبب طبيعتها المباشرة بالترجمة لكود لغة الآلة و تنفيذها بدون طبقات إضافية من التفسير
شكرا لك الاستاذ راني على هذا الفيديو
👍👍👍👍👍👍👍
شكرا استاذ اتمنى منك تعطينا معلومات اكثر
او تدلنا على مصارد مناسبة
لانه شات جي بي تي ما جاب خبر
عم يخلط بين التقنيات
احيانا يقول ان لغة سي مبنية على لغة اسمبلي
واحيانا يقول انها مبنية على التصميم المنطفي ولي اسمبلي 😂
ويقول انه فيه لغات ما تمر بمرحلة الاسمبلي وانما تترجم مباشرة الى لغة الالة
😢
وكمان اللغات المفسرة ....
ياليت تدلني علي مصدر كويس من اجل افهم شوي
Computer Systems: a programmers prespective by Randal Bryant
خصوصا أول الأقسام
part1 & 2: program structure and execution / running programs on a system
@@xycs الف شكر
لا أتفق معك
ان تريد كسب سرعة باستبدال كتابة المفسر الـ Interpreter المطور بـ ++C بلغة الـ Assembly
الفكرة غير مجدية، للأسباب التالية:
- المترجمات الـ Compilers الحالية اسرع وافضل من البرمجة اليدوية بكثير واذا كان هناك مجال للـ Optimization فسيكون بقدر لايذكر, في النهاية المفسر سيمر بمرحلة الـ Assemble سواء كتب يدوياً او عن طريق Compiler
- مشكلة بطأ لغات السكربت ليست بسبب سرعة المفسر المكتوب بلغة ++C المشكلة وجود خطوة اضافية عند تفسير سطر السكربت قبل التنفيذ ,لغات السكربت صممت بهذا الشكل لاسباب كثيرة.
- Portability احد اهم اسباب وجود لغات السكربت, اذا اردت للغة السكربت ان تعمل على اي معمارية يكفي ان تعمل Compile للمفسر المكتوب بلغة ++C يستهدف تلك المعمارية وبذلك ستتمكن من تشغيل البرنامج المكتوب بلغة السكربت على اي معمارية باستخدام المفسر الـ Interpreter المناسب "write once run anywhere", لكن اقتراحك سيصعب هذه الفكرة لانك تريد كتابة المفسر مباشراً بلغة الـ Assembly لكل معمارية على حدا, هذا سيكون مكلفاً من ناحية الصيانة والتطوير بدون اي فائدة تذكر.
كل ما ذكرته يعتبر اضافة على اساس تصميم و فكرة المفسر الاصلية.
المفسر يشغل عالطاير و بس. هذه هي فكرته الاصلية. فكرة ان يكون كود المفسر يعمل على عدد من المنصات هذه اضافة و ليست من اصل التعريف للمفسر. و التحسينات التي تتكلم عنها ليست شرط التصميم.
كرمال هيك انا لي الحق في ان اصمم المفسر بالتعريف الأساسي.
@@superlinux
تم اختراع فكرة لغات السكربت لتحقيق امور لاتستطيع تحقيقها اللغات المترجمة لكن على حساب السرعة لوجود خطوة التفسير، لكل نوع من اللغات مكان للإستخدام والموضوع ليس منافسة بين اللغات المترجمة واللغات المفسرة، اما فكرة كسب سرعة بسيطة في في مرحلة التفسير لن تلغي هذه المرحلة، فائدة استخدام اللغات المترجمة لكتابة المفسرات بدل لغة التجميع يفوق كثيراً الـ overhead البسيط، حيث ان المفسر يعتبر برنامج معقد ويحتاج للمرونة في التطوير والصيانة.
لغة Python أسرع منها حتى
لغة بايثون اسرع من مين؟ لم افهم.
و بعدين موضوعنا هنا ليس بايثون.
@@superlinux
أسرع من JS ( كلا اللغتين
scripting languages
لكن مقارنة من ناحية السرعة Python أسرع منها )
حتى ولو هذه اللغة اسرع من تلك. اخي! موضوعنا كان (يمكن جعل اللغة المفسرة السكريبت بسرعة اللغة المترجمة ؟!) هل تقدر على الاجابة على هذا السؤال.
@@superlinux فينا نحويل الكود المصدري للغة المفسرة للغة مترجمة متل سي أو سي بلس بلس ، بعدين منترجمها بمترجم هديك اللغة
( مثل GCC )
هاد الحكي يمكن يحسن الأداء بشكل كبير ، متل
HipHop
الخاص بفيسبوك يلي بيترجم بي أتش بي لسي بلس بلس ، بس بالرغم من هيدا التحسينات ، لازم نلاحظ أنو هناك حد للأداء فينا نصلو باللغات المفسرة مقارنة باللغات المترجمة مباشرة إلى كود لغة الآلة ، إضافة لهيك اللغات المترجمة مثل سي و سي بلس بلس عندها أداء عالي بسبب طبيعتها المباشرة بالترجمة لكود لغة الآلة و تنفيذها بدون طبقات إضافية من التفسير