كيف تنجح في برمجة النظام ، ما تحتاج إلى معرفته وفهمه ، خاصة إذا كنت تعمل في العقد الثالث؟ C # والأداء - هل يستحق إعادة كتابة كل ما تراه في C #؟ ما هو مستقبل تقنيات الترجمة منخفضة المستوى التي تنتظرنا؟
اليوم في الاستوديو الافتراضي لدينا ، يجيب
الكسندر موتيل على الأسئلة.
ألكسندر موتيل هو مهندس برامج رائد في Unity Technologies. بالإضافة إلى ذلك ، فهو مطور معروف مفتوح المصدر يساهم في SharpDX و Markdig و Zio ومشاريع أخرى ، ومنذ 2014 - MVP في فئة Visual Studio and Development Technologies.
يعمل Alexandre على مجموعة متنوعة من المشكلات منخفضة المستوى وعالية المستوى في مجالات عرض الرسومات في الوقت الفعلي ، GPGPU ، تركيب الصوت ، الاستخدام الفعال والهندسة المدارة للغات المدارة ، إنشاء التعليمات البرمجية والتوثيق.
كما هو الحال دائمًا ، يتم إجراء المقابلات من قبل Evgeny Trifonov (
الفلسفة ) و Oleg Chirukhin (
olegchir ) من مجموعة JUG.ru.
في نهاية المنشور هناك مفاجأة من ديلان بيتي (مانح مشهور آخر) - نحن أنفسنا لم نتوقعها.
هاء: لديك مهنة طويلة ، ثلاثة عقود - للمبتدئين ، هل يمكنك التحدث بإيجاز عنها؟بدأ كل شيء في مرحلة الطفولة - حصلت على Amstrad PC 464. عندما بدأت البرمجة على هذا الكمبيوتر ، كان عمري 11 أو 12 عامًا ، لا أتذكر بالضبط. لقد أتقنت برمجة BASIC بسرعة واشتريت كتبًا عن تطوير اللعبة: ثم بدت مثيرة للاهتمام للغاية. لقد لعبت عددًا قليلاً جدًا من الألعاب ، حيث كان من الممتع جدًا تطوير وكتابة التعليمات البرمجية. ثم واصلت كتابة كود المجمع لأمستراد.
في عمر 16 ، حصلت على أميغا 500. قابلت أشخاصًا كانوا يكتبون العروض التوضيحية - لم يكن الأمر على الإطلاق كما هو الآن. الآن هذا WebGL ، وهذا demoscene مختلف تمامًا. لقد بدأت في كتابة الكثير من العروض التوضيحية ، التي لم أظهرها دائمًا ، لكنني أحب فقط الكتابة في المجمع. وكانت بهذه البساطة.
ثم ذهب إلى كلية تكنولوجية ، حيث درس هندسة الكمبيوتر. كان هذا شيئًا مختلفًا تمامًا مقارنة بالألعاب والمجمع. أحببت تعلم أشياء لم أكن أعرف أنها موجودة من قبل: أنظمة التشغيل ، UNIX ، العمل بلغة C (قبل ذلك كنت أستخدم فقط BASIC أو المجمع لأنني لم يكن لدي المال لشراء مترجم C / C ++).
عندما تخرج من الكلية ، بدأ العمل في صناعة سوق العملات. كانت هذه وظيفة لشركة فرنسية في نيويورك. بعد ذلك بعامين ، عدت وذهبت إلى البنك. في الواقع ، لم أكن أرغب في العمل في أحد البنوك ، بل أردت العمل في تطوير اللعبة. ولكن نتيجة لذلك ، تمسك هناك منطقة جديدة ، يمكن تعلم الكثير من الأشياء. لذلك قضيت 8-9 سنوات هناك ، وأتعامل بشكل رئيسي مع Java وقليلاً مع C ++. الكثير من الخوادم الموزعة وقواعد بيانات SQL ، نسخ قواعد البيانات ... لا أفعل على الإطلاق ما أفعله الآن.
ثم أخذت إجازة إبداعية وذهبت في رحلة سياحية حول العالم: كنت في إفريقيا ، في أمريكا الجنوبية ، سنة كاملة في آسيا. الرحلة غيّرتني وهزتني. عندما عدت ، لم يعد بإمكاني العمل مع أجهزة الكمبيوتر ، في مجال تكنولوجيا المعلومات ، لم أستطع العمل في البنك. تركت وظيفتي وقضيت 4 سنوات في دورات الأخصائي الاجتماعي للعمل مع الأطفال والمشردين والمعوقين والمسنين. درست هذا لمدة ثلاث سنوات ، وكانت مثيرة للاهتمام للغاية ، لأن معظم حياتي عملت في مجال العلوم الدقيقة: الرياضيات والمشاريع والتجريد. ثم أخذ فجأة وانتقل إلى منطقة إنسانية للغاية. حتى أنني حاولت العمل في هذا المجال بعد التدريب ، ولكن خلال هذه الفترة فقط ألمح صديق قمت بعمل عروض توضيحية عليه كطفل إلى أنه يمكننا القيام بذلك مرة أخرى.
بدأت في ممارسة العروض التوضيحية طوال وقت فراغي ، وسرعان ما بدأت تستغرق أكثر من العمل مع الأطفال في الشارع. كان ذلك سيئا. قال الناس: "نحن بحاجة إلى محاولة العثور على عمل في تطوير اللعبة ، لماذا لا؟ يمكنك القيام بذلك ". لكنني اعتقدت أن هذا مستحيل ، لأنني لم أعمل مع أجهزة الكمبيوتر لفترة طويلة ، وكان من الصعب العثور على عمل في مجال تكنولوجيا المعلومات مع سيرتي الذاتية.
بدأت العمل على تطبيقات مفتوحة المصدر وأطلقت بضعة مشروعات بدأت الشركات في استخدامها. ذات مرة ، اتصلت بي إحدى هذه الشركات ، واستخدموا أحد أحدث المشاريع المسماة SharpDX. ذهبت إلى اليابان مع عائلتي - لأن لديّ طفلين بالفعل. عشنا 5 سنوات في اليابان. في هذا الوقت ، كنت أعمل على إنشاء محرك لعبة من الصفر في C #.
منذ حوالي عامين ، عدت إلى فرنسا وبدأت العمل في الوحدة. تداخل هذا مع ما فعلته من قبل ، لكنهم عرضوا العمل على مهمة معقدة للغاية ومثيرة للاهتمام ، اختبار حقيقي: لجعل مترجم أصلي يولد كود أصلي من كود IL .NET. كان هذا بالضبط ما كنت أرغب دائمًا في القيام به ، ولكن لم أستطع ذلك ، لأنني لم أكن لأدفع مقابل ذلك. ثم كانت هناك فرصة ، فرصة عظيمة. عملت في هذا المشروع لمدة عامين.
نعم ، يبدو أن القصة ليست قصيرة للغاية.
E: لا شيء ، مثل هذه المهنة تستحق قصة طويلة. بسبب خبرتك ، أود أن أسألك هذا. الآن يقول بعض الناس ، "قانون مور لم يعد يعمل ، أجهزة الكمبيوتر لا تسرع ، كلنا محكوم عليهم بالفشل." يرد آخرون: "هيا ، على الرغم من أنهم لا يتسارعون بنفس الوتيرة ، لا يزال هناك نمو ، لذلك لا يوجد سبب للذعر". بما أن موضوع الإنتاجية قريب منك ، وفي نفس الوقت كنت تتابع الصناعة لفترة طويلة ، فما هو موقفك؟أنا ألتزم بهذا المتوسط الذهبي.
(يضحك) أعتقد أن العديد من التطبيقات التي نقوم بتطويرها ، إن لم يكن معظمها ، تتكيف مع متطلبات الأداء منذ البداية ، مما يؤدي إلى أفضل جودة ممكنة.
شاهد ما حدث في صناعة تكنولوجيا المعلومات أمام أعيننا. على سبيل المثال ، عندما أصبح Windows أبطأ قليلاً على مر السنين - Windows Vista ، إلخ. في الواقع ، تم القيام بعمل طبيعي لتحسين الأداء ، لأنه لسنوات لم يكن قلقًا بشكل خاص. عندما ظهر Windows 8 ، كان بالفعل أفضل قليلاً. ثم خرج Windows 10 وتحسن قليلاً. نتيجة لذلك ، لدينا نظام يعمل بشكل جيد مقارنةً بما كان عليه من قبل. كان من المهم جدًا بالنسبة لهم إجراء هذه التحسينات ، لأنه بمجرد أن "يعيش الناس بالضرورة فوق إمكانياتهم" ويبدأون بالقول: "أوه! لم يعد هذا البرنامج يعمل ، نحن ننتقل إلى Linux ، لأنه أسرع وأقل غباء. "
ويمكن قول الشيء نفسه عن جميع البرامج التي نطورها. وما يثير الدهشة: كان هناك دائمًا اتجاه للعمل مع التعليمات البرمجية الأصلية ، في مرحلة ما حتى في Windows قرروا العودة إلى C ++ ، قالوا: "C ++ هو حل ، .NET بطيء جدًا ، ثم Garbage Collector و blah blah blah ... ". ومرة أخرى ، أصبحت اللغات الأصلية ذات صلة.
في الوقت نفسه ، أعاد V8 في Chrome استخدام JavaScript مرة أخرى بفضل JIT. JS هي لغة برمجة نصية ، وليست فائقة السرعة ، ولكنها تعمل في بعض الأحيان مرتين أسرع من C ++. كان ذلك كافياً بالنسبة له للبقاء على قيد الحياة ولنا استخدامه الآن لأشياء مثل كتابة التعليمات البرمجية في Visual Studio Code. ولكن إذا نظرت عن كثب ، كل هذا لأنه تم وضع متطلبات الأداء هناك من البداية. حتى في VSCode ، على الرغم من وجود الكثير من رموز جافا سكريبت والنص البرمجي بشكل عام ، كل شيء آخر - V8 ، مكدس التقديم ، JIT - كل هذا مكتوب بلغة مصممة لتحقيق أقصى أداء ، أي في C ++. يمكن كتابة كل شيء بلغة أخرى ، وليس بالضرورة C ++ ، ولكن الحقيقة هي أن كل هذا البرنامج تم تطويره مع مراعاة الأداء منذ البداية.
لذا نعم ، يمكننا استخدام لغات أقل كفاءة وإنتاجية ، ولكن فقط لأن جميع التقنيات الأساسية تم تطويرها بهدف الحصول على
تجربة مستخدم رائعة. على سبيل المثال ، يعد Visual Studio Code برنامجًا رائعًا يعمل جيدًا للمطورين ويحل مشاكلهم. يقول الكثير من الناس: "على الرغم من أننا نرغب في استخدام المزيد من برامج تحرير التعليمات البرمجية الأصلية ، إلا أننا ننتقل الآن إلى Visual Studio Code" - لأنهم يعتبرونها فعالة جدًا. الأداء موجود في كل مكان ، ولكن في بعض الأحيان لا نراه لأنه مضمن بالفعل في كل شيء نستخدمه.
نعتقد: أنه مكتوب بلغة جافا سكريبت ، لأنه سريع بما فيه الكفاية. لكن JavaScript سريع جدًا لمجرد أن مئات مئات مهندسي التطوير عملوا لسنوات لتحسين JIT. الآن يمكننا استخدام لغات البرمجة النصية حتى لكتابة تطبيقات معقدة للغاية. لغات البرمجة النصية التي لولا هذا العمل التحضيري لكانت أبطأ بكثير. نحن نعيش في أوقات غريبة. لدينا خيار ، ولكن لا تزال هناك قصة الأداء هذه التي تكرر نفسها مرارًا وتكرارًا لكل لغة.
لذا فإن .NET مثال نموذجي. لقد تم إنجاز عمل ضخم هناك على مدى السنوات الثلاث إلى الأربع الماضية. إذا نظرت إلى ASP.NET Core في وقت ما ، إذا نظرت إلى كل العمل المنجز مع CoreCLR ... الأداء هو شيء جيد البيع ، فإنه يكلف المال ويسمح لك بتحقيق المزيد. في محاولة لتلبية المتطلبات الصارمة ، يمكنك محاولة أن تصبح أكثر إنتاجية ، يمكنك توفير الطاقة ، وتوفير بعض المال في نهاية الشهر - يؤثر الأداء على كل شيء. عندما أسمع الناس يقولون: "كل شيء على ما يرام ، أقوم بتطوير تطبيقي ، ولديه متوسط إنتاجية ، وسيعمل ..." ما الذي يفكرون فيه؟ تحتاج إلى تخصيص بعض الوقت للتحقق مما إذا كان يمكنك جعل تطبيقك أكثر إنتاجية. إذا كان بإمكانك توفير الموارد أو وقت التطبيق بما لا يقل عن العشر ، فهذا جيد.
هاء: هناك سؤال فلسفي جزئيا. تعتقد أن Slack ليس أفضل مكان للحلول التقنية ، ولكن على موقعك تعرض الاشتراك في خدمة RSS القديمة. هل تعتقد أن العصر الجديد للرسائل الفورية يجعل المطورين أقل إنتاجية؟لا ، لا أعتقد ذلك. الآن أعمل عن بعد. في العمل ، في Unity ، يمكننا العمل عن بعد ، لذلك أستخدم Slack باستمرار للتواصل مع الزملاء. هذه هي أفضل طريقة لأكون على اتصال وأبقى منتجًا. يستغرق هذا الكثير من الوقت من العمل ، لأنك تحتاج إلى التحقق من القنوات وما إلى ذلك ، ولكن يمكنني مؤقتًا إيقاف تشغيل Slack والتركيز على العمل. بينما كنت أعمل في الشركة في مكان مفتوح ، لم يكن لدي أي خيار: إذا كان شخص ما يريد طرح سؤال ، عليك الإجابة على الفور ، فهذا أكثر تعقيدًا.
أما بالنسبة إلى تويتر والبريد الإلكتروني ، فأنا لا أتحقق منها كثيرًا. مرة أو مرتين في اليوم أقرأ تويتر ، هذا يعتمد على عوامل مختلفة: ما إذا كنت أشارك في أي مناقشات وما أناقش. إذا كنت تستخدم شيئًا مثل Slack ، يمكنك الانضمام إلى قنوات مختلفة في الشركة ، يمكنك متابعة العديد من المواضيع التي لن تتمكن من متابعتها إذا عملت بمفردك. نحن بحاجة إلى إيجاد حل وسط: فنحن جميعاً قلقون بشأن الكثير من الأشياء التي تحدث في الشركة ، لكننا بحاجة إلى أن نكون انتقائيين ، لأنه لا يمكنك المشاركة في جميع المناقشات في نفس الوقت. يمكن لبعض الناس قراءة العديد من القنوات التي أنا ببساطة مندهش من قدراتهم ، وأنا نفسي لست كذلك. اليوم قرأت حوالي 30 قناة ، هذا ليس كثيرًا.
هاء: شكرا لك ، حان الوقت لأسئلة أوليغ!جواب: مسيرتي شبيهة إلى حد ما بحياتك المهنية: لقد عملت في أحد البنوك ، والآن في مجال مختلف تمامًا - تنظيم المؤتمرات ، وفي نفس الوقت أحاول معرفة كيفية بناء المجمعين. ماذا يمكنك أن تنصح أولئك الذين يحاولون التبديل إلى برمجة النظام من مطوري الويب للمؤسسات البسيطة ، هل هناك أي نصائح لمثل هذا الانتقال؟ أنا متأكد من أنه لا يوجد ما يكفي منا هنا ، بما يكفي.لست متأكدًا مما إذا كان هناك مسار معد لمثل هذا الانتقال. إذا كنت مهتمًا بمثل هذه التقنيات ، فأنت تقوم ببعض الواجبات المنزلية العادية. في المنزل ، تكتب المحللون والأشياء المتعلقة بالمترجمين. ليس من الضروري كتابة المترجم بأكمله من البداية إلى النهاية ، حتى إنشاء كود الآلة. تصبح مهتمًا بكتابة البنية التحتية للمترجم. هذا ما كنت أفعله في السنوات الأخيرة وأنا أعمل في الوحدة. إذا كنت شغوفًا بالأشياء ذات المستوى المنخفض ، فهذه واحدة من تلك الأماكن حيث يمكنك فهم كيفية عمل كل شيء في الواقع. كيفية تحسين العمل ، حيث يستحق تحسين الأداء ، وحيث لم يتم ذلك بعد. إذا كنت قلقًا بشأن الأداء ، فمن المهم جدًا أن تكون على دراية بما سيتم تشغيل التطبيق في النهاية.
الأداء هو موضوعي ، وقد أصبح كل هذا فرصة عظيمة بالنسبة لي. أود أن أتناول حل المشكلة في صميمها ، أي على مستوى المترجم. من هنا يمكننا زيادة الإنتاجية عشرات المرات في تلك الأماكن حيث يكون ذلك ضروريًا لمستخدمينا. إذا قمنا بتشغيل ألعاب أو تطبيقات أو أفلام أو شيء من هذا القبيل ، فقد يكون من السهل نسبيًا في بعض الأحيان تحقيق مثل هذه النتائج.
قادني شغفي بالأشياء ذات المستوى المنخفض ومكونات المترجم إلى وظيفتي الحالية. لكن ذلك لم يكن شيئًا أردت القيام به على وجه التحديد. في بعض الأحيان ، عندما تحصل على الكثير من الخبرة بلغات مختلفة ، تكتب التطبيقات - حتى أنك تريد ابتكار لغتك الخاصة. لقد بدأت في فعل ذلك ، ولكن توقفت لأنه عمل كثير للغاية ، ولدي القليل من وقت الفراغ. لكن لديك رغبة لا شعورية للعودة "إلى الجذور" ، حاول أن تفعل شيئًا بنفسك لفهم كل شيء. بالطبع ، فهمت كيف يعمل المترجمون وكل ذلك ، لكنني لم أفهم تعقيد المتطلبات. مقايضات معقدة للتعامل معها ، على سبيل المثال ، في مجال إدارة الذاكرة. من الصعب جدًا اختيار ما سيعطي في نفس الوقت إنتاجية أكبر لمطور التطبيق وسيكون فعالًا. هذه المشكلة لا تزال لم تحل حتى النهاية. الصدأ أو .NET لن يحل هذا. الصدأ جميل ومذهل ، ولكن من الصعب العمل معه ، خاصة إذا كنت تتحول إليه بشيء مثل JavaScript. ومع ذلك ، هناك أمثلة على مطوري Python أو JavaScript الذين يهاجرون إلى Rust ، على الرغم من أن هذا أمر مثير للدهشة إلى حد ما.
ج: ذكرت أنك قمت بالبرمجة في C # خلال السنوات العشر الماضية ، فما هو الجيد في C #؟ لماذا لا C ++ ، على سبيل المثال؟ يبدو أن لغة C ++ أكثر نظامية.لنكون صادقين ، أنا أكره C ++ ، أكره C ، لكني أعمل معهم. أعتقد بصدق أنها تؤدي إلى مجموعة من الأخطاء ، إلى عدم كفاءة تطوير ضخمة. يعتقد الكثير من الناس أنه نظرًا لأنك تقوم بالبرمجة في لغة C ، فأنت بالفعل تكتب رمزًا سريعًا بحكم الواقع أن برنامجك سيكون موجهًا نحو الأداء. هذا ليس صحيحا. إذا قمت بنحت أكوام من malloc وكل ذلك ، فسيكون بطيئًا حتى مقارنة بما هو مكتوب في .NET. يضطر مطورو C / C ++ الجيدون إلى استخدام الحيل مثل
مخصص ذاكرة المنطقة . عليك أن تدفن نفسك في مجموعة من الأشياء الغريبة التي لم يسمع بها أحد. على الرغم من أن مطوري الألعاب هنا يعرفون عادة عن مثل هذه الأشياء. كحد أدنى ، مطوري AAA أو الأشخاص الذين يصنعون الألعاب في أطر C / C ++. تنبع بعض المشاكل من تعقيد اللغة نفسها. في السابق ، لم أقرأ الكتب على C ++ على الإطلاق ، وقبل ثلاث أو أربع سنوات فقط بدأت في قراءة الكتب فقط على C ++ ، فقط لأشعر باللغة. لقد قمت ببرمجتها ، لكن لم يكن لدي نهج منهجي رسمي ، وقد أدهشني تعقيدها ، عدد الأشياء التي يمكنك تدميرها إذا لم تكتب كل شيء بشكل صحيح.
منذ بضعة أشهر مضت ، كان هناك خطأ في Unity ، شخص ما أخطأ في قطعة من كود C ++ ، كان في المنشئ ، تم تمرير شيء ما بالقيمة ، ونتيجة لذلك ، أخذنا العنوان من هذه القيمة ونظرنا في ذاكرة التخزين المؤقت. في الواقع ، لقد أشرنا إلى قيمة لم تعد موجودة في الذاكرة. وكل هذا بسبب اختلاط المؤشرات مع غير المؤشرات ، ولم يقم الشخص الذي قام بإعادة الهيكلة بالتحقق من جميع أماكن الاستخدام. توقف رمز مختلف تمامًا يعمل بشكل مفاجئ عن العمل. يبدو أنه خطأ صغير ، لكنه كسر كل شيء. في الواقع ، هذا خطأ في العمل مع الذاكرة. لذا نعم ، عندما أرى مثل هذه الأشياء ، أنا مقتنع بأنه يجب علينا تقييد الوصول إلى العمل في C و C ++ ، وتقليل استخدامها. في الجزء .NET ، اقتصرت حقًا على استخدامها للأشياء الخاصة بالنظام الأساسي فقط. لكن كتابة كل شيء في C # هو كئيب جدا. من أجل الوصول إلى API ، تحتاج إلى القيام بمجموعة من dlopen. على سبيل المثال ، يمكنك محاولة تغليف كل هذا في غلاف في C وتنظيم الوصول من خلال وظيفة واحدة فقط. أفضل عزل هذه الأشياء وتطويرها بشكل أكبر في C و C ++. لكن هذا موضوع ضيق حول interop ، وبعد ذلك تبقى مع لغة عادية يتم التحكم فيها ، وتستخدمها معظم الوقت ، وتستمتع بتجميع أسرع.
أنا أكره أخطاء المترجم والرابط C ++ ، أكره الحاجة إلى العمل مع منصات مختلفة ، كل هذا صعب للغاية. تبدأ في التجميع على MSVC ، ثم يجب عليك التبديل إلى Clang ، ثم إلى GCC. على Linux و Mac و Windows و Android و iOS وما إلى ذلك. العمل مع C ++ هو كابوس!
أكره الفصل بين الملفات في المحرر وملفات h. و cpp. يتم الخلط بين الناس تمامًا في اللغة ويبدأون في البرمجة على وحدات الماكرو. أنا أحب البرمجة التخطيطية ، ولكن في لغة C ++ الحديثة ، يمكننا القيام بجنون كامل. هذه الأشياء في حد ذاتها مذهلة ، لكنها في الواقع كثيرة للغاية.
لتلخيص: نعم ، أعتقد أنه يمكننا تطوير برامج فعالة في C #. ربما ليس بالسرعة كما هو الحال في C ++ ، ولكن يمكننا ذلك. هذا هو بالضبط ما نحاول القيام به في Unity - على سبيل المثال ، نقوم بعمل مترجم متتابع لتجميع مجموعة فرعية معينة من C # ، وتحقيق أقصى أداء ، حتى في الأماكن أكثر مما كان سيحدث في C ++ - ولكن يبقى في C #. إنه آمن تمامًا. بالنسبة للمؤشرات ، تحتاج إلى التصريح بعدم الأمان ، ولا ترمي الاستثناءات ، وتفعل كل شيء بشكل صريح. وهذه تجربة مريرة. ولكن لا يزال بإمكانك كتابة التعليمات البرمجية التي ستكون بنفس سرعة C ++. أعتقد أن هذا هو بالضبط الاتجاه الذي يستحقه .NET وأين يجب أن نذهب.
ج: إذا تحدثنا عن رمز مفتوح المصدر ، على سبيل المثال ، لدينا جامع قمامة في .NET Core ، وهو ملف C كبير ومخيف. ميغا بايت من القمامة ، على الأرجح ولدت من نوع من lisp (بالكاد كان العديد من الحروف تستحق الكتابة يدويًا). ربما يكون من المنطقي إعادة كتابة كل شيء هنا في C #؟نعم فعلا! أدردش مع الأشخاص الذين يعملون على JIT في كل من Microsoft والمجتمع. هناك شيء أؤمن به حقًا. أعتقد أن هناك لحظة تصبح فيها لغتك أكثر نضجًا وأساسية ، ومن ثم عليك أن تتحدىها ، واختبرها من أجل القوة. يجب أن تكون قادرًا على استخدامه كأساس. أثبت أنه يمكنك حتى استخدامه لخلق شيء متطلب للغاية على الأداء. وهذه هي قصة جامع القمامة و JIT. يمكن تنفيذ نسبة كبيرة جدًا من الأنظمة الفرعية لوقت تشغيل .NET ، بما في ذلك JIT و GC ، في C #. إذا وضعت قاعدة في C ++ يمكنك فقط وصف ملخصات النظام الأساسي الأساسي ، فإن هذا سيجعل معظم منصة وقت التشغيل مستقلة. سأكون سعيدا جدا إذا حدث هذا. لكن هذه مهمة ضخمة.
هناك سبب واحد يجعلني أحب هذه الفكرة بشكل خاص.
لقد تحدثت بالفعل عن هذا الأمر ، فإن إعادة بناء وتحسين قاعدة التعليمات البرمجية في C / C ++ أمر معقد للغاية لدرجة أنك في مرحلة ما تتوقف عن القيام بإعادة البيع هذه. يؤلمك كثيرًا لدرجة أنك لن تلمسها بعد الآن. سيتعين عليك نقل بعض الملفات وتغييرها يدويًا ، لأن إعادة البناء في IDE ستعمل بشكل سيئ ، على سبيل المثال ، نظرًا لوجود عدد كبير جدًا من القوالب - وهكذا دواليك. عند التطوير في C # ، قد تكون أكثر طموحًا بشأن رغباتك. يمكن إضافة تحسينات جديدة بشكل أسرع وأسهل بكثير ، ببساطة لأن وقت التجميع قد انخفض. تقليل وقت التكرار للاختبار وما إلى ذلك. من الجميل أن يحاولوا ، على سبيل المثال ، في CoreRT استخدام C # قدر الإمكان بدلاً من C ++. الوضع يتغير.لكننا ما زلنا في منتصف الطريق من إعادة كتابة .NET GC في C #. لكننا استطعنا. على سبيل المثال ، أعلم أنه يمكنني إعادة كتابة .NET GC ، وإعادة كتابته بشكل مختلف. قبل بضع سنوات ، أصبحت مهتمًا جدًا ب GC ، وقرأت كتبًا عنه ، وكتبت شيئًا مثل نموذج أولي لتطبيق GC. لقد دهشت من عمل مجتمع Java على Jikes RVM - لقد قاموا بهذه المهمة في Java. في وقت لاحق ، اكتشفت أنه في Golang ، كتب المترجم لأول مرة في C ، ثم في Golang. عندما بدأت في قراءة الكود المصدري لمترجم Golang ، فوجئت بتنظيم قاعدة الكود وكيفية تنظيم التحسينات. على سبيل المثال ، هناك ملف ضخم يصف التحسينات المسموح بها والتي يمكن تطبيقها على بعض التعليمات. يمكن تعيين التعليمات إلى تعليمات أصلية أسرع ، ويتم وصف كل هذا في ملف نصي ضخم. لم أر هذا في LLVM أو في .NET JIT.تلخيص ، نعم ، يجب أن يمنحنا استخدام اللغة المُدارة المزيد من الفرص لكتابة وقت تشغيل أفضل.جواب: لقد تحدثت عن تعقيد الكود وخطورة الأخطاء وما إلى ذلك. بالنسبة لي ، الجزء الأصعب هو قراءة مصادر المترجم وفهمها. على سبيل المثال ، هنا ملف كبير جدًا يحتوي على عشرات الآلاف من خطوط تحويلات AST والتمثيلات الوسيطة. هنا هذا الملف من Golang بمحبة ، على سبيل المثال. ما رأيك في كتابة كود جيد وواضح لأجزاء النظام؟ كيف تكتبها؟ها ، كما تقول ، كما لو كان هناك شيء مُعد مسبقًا لأي شيء! المترجمون أكثر طلبًا على الكود البرمجي من التطبيقات العادية. أولاً: يجب أن تكون حذرًا للغاية عند تصميم البنية الأساسية. تحتاج إلى مراقبة إعادة الاستخدام والعزل بعناية: إذا قمت بتغيير شيء ما ، في أماكن أخرى لا يجب أن يرش شيء ويدمر بقية التعليمات البرمجية.ثانيًا: أنا مقتنع بأنه يجب أن نرفق الشفرة بعدد كبير من التعليقات لشرح التبعيات الداخلية غير الواضحة عندما تنظر إلى الرمز. أنا حقًا لا أحبها عندما يقولون: "يجب أن تصف الشفرة نفسها! يجب أن تكون واضحة! " هذا خطأ كاذب ومضلل. يحب المهندسون أن يروا مثل هذه الحكايات للمطورين الشباب ، ويجب ألا تفعل ذلك.عندما أرى ملف تعليمات برمجية مثل LLVM ، على سبيل المثال - قد يكون غير كامل ، ولكن هناك الكثير من التعليقات هناك. على سبيل المثال ، عندما يكون هناك هيكل في ملف الرأس ، يمكن للتعليقات أن توضح مكان الإعلان عن هذه البنية ، ولماذا تم الإعلان عنها ، ولماذا توجد مثل هذه الحقول. هناك سبب لكل هذه الأشياء. إذا لم تفسر هذا السبب ، فلن يفهم أحد لماذا فعلت ذلك بهذه الطريقة. إذا قرأت الرمز للتو ، فلن يتضح شيء. على سبيل المثال ، محاذاة البيانات للتخزين المؤقت الفعال ، إذا لم تشرح ذلك في تعليق ، كيف سيفهم الآخرون أن كل هذا تم من أجل الكفاءة؟ ربما في وقت لاحق ، حتى أنت بنفسك سوف تضطر إلى إعادة قراءة التعليمات البرمجية بالكامل ، واستعادة بنية التطبيق بالكامل وتخطيط البيانات في الذاكرة ، وبعد ذلك سوف تأتي البصيرة. ولكن إذا لم تضف تعليقات إلى الشفرة وشرحها ،ثم سينظر شخص آخر في كل هذا ويقول: "رائع ، هذا الحقل مسمر ، إنه غير قابل للاستخدام كثيرًا ، سأضع فصلًا آخر هنا وأضيف مؤشرًا" - وبالتالي كسر كل شيء ، لأنني لا أفهم ، لماذا تم ذلك هنا فقط.وأنا أقول هذا ليس فقط عن العمل الجيد ، ولكن أيضًا عن العمل السيئ. اضطررت أكثر من مرة إلى إدراج تعليق في الرمز لأقول أنني لم أقم بهذا الجزء بشكل جيد للغاية ، لست فخورًا به ، هذا المكان بحاجة إلى الإصلاح ، والآن سنتركه في شكله الحالي ، ولكن في يوم من الأيام سيكون من الضروري العودة إليه واصلاحها. وأوضح سبب القيام بذلك على هذا النحو: على سبيل المثال ، لم يكن هناك وقت كاف للقيام بعمل جيد. لقد وثقت أنك لم تفعل سوى جزء صغير من الضروري ، وهذا أمر طبيعي. لقد استخدمت مثل هذا العكاز هنا ، وإذا حاولت القيام بذلك بشكل صحيح ، لكانت قد كسرت كل شيء. ولكن عليك أن تشرحها حتى لتلك الأقسام من التعليمات البرمجية التي لا تعمل بشكل جيد للغاية. لذا ، التعليقات هي الثانية.والثالث بالنسبة لي هو الاختبار. تحتاج إلى إجراء المزيد من اختبارات الوحدة. ليست اختبارات تكامل كبيرة ، أي اختبارات الوحدات الصغيرة ، والتحقق من أجزاء واجهة برمجة التطبيقات ، بدءًا من المستويات الدنيا. لذلك سوف يتحسن تطبيقك بمرور الوقت. على سبيل المثال ، كتبت SharpDX مع عدم وجود اختبارات على الإطلاق. وفي وقت كتابة هذا التقرير ، لم يكن سيئًا. لكن الحقيقة هي أنني لم أخلقها للناس ، ولكن لنفسي ، في وقت فراغي. كنت أرغب في الوصول إلى واجهة برمجة التطبيقات DirectX C ++ ، والتي كانت متاحة بالفعل في C ++. على مر السنين ، لقد تحققت من أن كل شيء يعمل. ولكن في كل مرة أجري فيها أي تغييرات ، كان علي التحقق من الوظيفة مرة أخرى. في السنوات القليلة الماضية تحولت إلى مشاريع أخرى: لم يعد هناك وقت ، ولم أعد أستخدمها. ثم جاء أحد المطورين من مجتمع المصادر المفتوحة ،تخصيص المحول البرمجي في حزمة منفصلة وحاول القيام بشيء منفصل عن SharpDX في هذا الشأن. الشيء هو أنني لم أختبر هذه العلاقات العامة بالكامل ، لأننا لم نقم باختبار واحد. جمدت فقط طلب سحبه (بدا مثاليًا). بدأ في إجراء اختبارات صغيرة في مستودعه على طلبه المنفصل. لكننا لم نأخذ في الاعتبار شيئًا ، وتم كسر SharpDX نفسه تمامًا في بعض الإصدارات. على الفور ، ظهر أشخاص يعانون من مشاكل في النموذج: "لماذا تسبب هذه الطريقة استثناءً؟" في المشاريع اللاحقة (مفتوحة المصدر والعمال) ، حاولت أن أكون واعيًا جدًا من حيث الاختبار ، حتى بشكل دوري أحاول زيادة التغطية. لكن محاولة الوصول إلى تغطية بنسبة 90 بالمائة أمر كئيب للغاية. في بعض الأحيان ، تكون الاختبارات الحقيقية غريبة جدًا ، فقد كتبتها لمجرد تصحيح الأخطاء ولا يمكنك إيداعها تحت الغطاء ،لا تريد سحب هذا إلى رمزك.بشكل عام ، نعم ، أعتقد أن هذه ثلاثة أشياء يجب تناولها بعناية فائقة: الهندسة المعمارية ، التعليقات ، الاختبار.ج: المترجمون مجال قديم تمامًا ، أليس كذلك؟ تبدأ القصة في منتصف القرن الماضي. برأيك ، ما هي أهم التحديات التي تواجه المطورين وشركات الترجمة الحديثة؟أعتقد أن التحدي الرئيسي اليوم هو إنشاء مترجم يكون فعالاً في العمل مع SIMD. وهذا في الحقيقة تحد يصعب على المترجمين الإجابة عنه لأن SIMD والتحسينات المماثلة تضاف عادة لاحقًا ، وليس بالضرورة من بداية المترجم. (في حالة LLVM ، ربما كانوا من البداية). والحقيقة هي أن هذا يجلب العديد من المشاكل الجديدة إلى المُحسّن ، ويجب أن يكون قادرًا على تنفيذها بشكل صحيح. كما ترى ، يجد المترجمون الآن صعوبة ، على سبيل المثال ، في تحويل التعليمات البرمجية تلقائيًا. في شكل ما ، يمكنهم القيام بذلك ، ولكن في بعض الأحيان يكون من الأسهل القيام بذلك يدويًا. لا يستطيع المترجمون تحديد جميع أماكن التحسين ، ونتيجة لذلك ، يتم إنشاء كود غير فعال. هذا موضوع صعب تعمل بعض شركات Intel على إضافة تقنية التحويل إلى LLVM.كان المشروع قيد التطوير لعدة سنوات ، وبشكل عام فهو مجرد إعداد لإجراء هذه التغييرات على المنبع LLVM. إنهم لم يصلوا بعد ، إنه صعب للغاية ، وسيستغرق الأمر سنوات. يعد LLVM نظامًا جيدًا جدًا ، فقط لأنه يحتوي على أشياء مفقودة من .NET. الاستفادة من SIMD و CPU والنوى المختلفة - سيكون هذا أكبر تحد حديث. لهذا السبب ، على سبيل المثال ، تتم إضافة الجوهر الداخلي للمتجه إلى لغات .NET. - يمكنك استخدام تعليمات Vectorizer و SIMD بشكل صريح. ولكن في كثير من الحالات ، مثل الحلقات ، يمكن للمرء أن يتوقع التحويل التلقائي.وحدة المعالجة المركزية والنوى المختلفة - سيكون هذا أكبر تحد حديث. لهذا السبب ، على سبيل المثال ، تتم إضافة الجوهر الداخلي للمتجه إلى لغات .NET. - يمكنك استخدام تعليمات Vectorizer و SIMD بشكل صريح. ولكن في كثير من الحالات ، مثل الحلقات ، يمكن للمرء أن يتوقع التحويل التلقائي.وحدة المعالجة المركزية والنوى المختلفة - سيكون هذا أكبر تحد حديث. لهذا السبب ، على سبيل المثال ، تتم إضافة الجوهر الداخلي للمتجه إلى لغات .NET. - يمكنك استخدام تعليمات Vectorizer و SIMD بشكل صريح. ولكن في كثير من الحالات ، مثل الحلقات ، يمكن للمرء أن يتوقع التحويل التلقائي.قبل ذلك ، أود أن أقول: "نحن بحاجة إلى مترجمين كخدمات ومجمعين كمكتبات". اليوم لم تعد مشكلة. أصبح الناس مقتنعين بفائدة هذه الأفكار. لذلك ، أصبح LLVM شيئًا مشهورًا: تم تطويره منذ البداية كمكتبة مترجم حيث يمكنك استخدام أي لغة تريدها. نفس الشيء ، على سبيل المثال ، مع Roslyn في C # ، هناك أيضًا مترجم. بالطبع ، هذا المترجم ليس من نفس النوع ، ولكن مع ذلك ، يمكن استخدامه في التعليمات البرمجية الأصلية. أعتقد أن الجميع الآن على اطلاع على هذه الأشياء ، يدرك الناس أن المترجم مفيد. بالنسبة لي ، يعد الرمز المتوافق مع SIMD أكثر أهمية. البرمجة مع التركيز على GPU ، CPU ، عدد النوى المستخدم هو مجرد البداية. لدينا 6 ، 8 ، 16 ، 42 نواة. في مرحلة ما ، ستبدأ الزيادة ، يجب أن نكون مستعدين لهذا ،لاستخدام كل هذه القوة بأكبر قدر ممكن من الكفاءة..: Markdown Markdig, ? , Markdown? , ?نعم ، بالنسبة لي Markdown هي طريقة لكتابة الوثائق التي يحبها المطورون. على الأرجح ، هذا ليس للأشخاص العاديين الذين ما زالوا يجدون من الأسهل استخدام Word أو شيء من هذا القبيل. ولكن بالنسبة للمطورين ، هذا جيد. على مر السنين ، هل استخدم المطورون ماذا؟ الملفات النصية ، بطرق مختلفة ، ميزت الرؤوس الموجودة فيها ، وما إلى ذلك. وكان ذلك طبيعيًا. تعلمون ، هذه هي كيفية قراءة RFC على الإنترنت - هناك مجموعة من تنسيقات الملفات النصية ، محدودة للغاية ، صنعت بشكل جيد للغاية ، ولكنها غير رسمية. لم يكن من السهل دائمًا قراءتها ، ولم تكن هناك صور ، وكان الأمر جنونيًا. ولكن لم يكن لدينا خيار ، بل كان علينا استخدام فن ASCII. ثم جاء Word و PDF وما شابه ذلك. في عام 2000 ، كانت مجموعة من الوثائق في Word.لم يكن من السهل على المطورين إقناعهم بالعمل مع مثل هذه المستندات - لم يكن من المألوف. كان من غير اللائق رؤية التغييرات في الوثائق عند إجراء تغييرات على التعليمات البرمجية المرتبطة والعكس صحيح. عندما ظهر Markdown ، كان مذهلاً ، أصبح من الممكن إنتاج شيء لطيف جدًا منه - على سبيل المثال ، HTML. ولا يزال هذا هو تنسيق النص الذي يسهل قراءته وإضافته إلى قاعدة التعليمات البرمجية الخاصة بك. حتى إذا لم يكن لديك HTML تم إنشاؤه ، يمكن قراءة ماركدوون بسهولة في محرر النصوص. الآن ، عندما تفتح مشروعًا على Github ، فإنه يحدد ملفات Markdown ويعرضها بشكل جميل من تلقاء نفسها. وكل هذا بجانب رمزك. التوثيق بين الكود هو أفضل شكل للتوثيق الفني. على سبيل المثال ، نقلت Microsoft جميع الوثائق الفنية إلى Markdown ، والآن يمكن قراءة الوثائق مباشرة على GitHub ،إنهم يقبلون العلاقات العامة - وهذه طريقة رائعة لمنح حق الوصول إلى الوثائق وتنظيم عملية إجراء التغييرات التي يمكن للجميع استخدامها.فيما يتعلق بتطبيع Markdown ، هناك مشروع يسمى CommonMark ، تم إطلاقه قبل عدة سنوات ، هدفه هو توحيد Markdown. أعتقد أن CommonMark اليوم هو المعيار. يبدأ الناس في احترامه ، ويتبعونه ، ولكن هناك العديد من الإنجازات الأخرى. على سبيل المثال ، تحول Github إلى CommonMarkالعام الماضي. لم يلاحظ أحد ذلك - وهذا أمر جيد. لكنهم كانوا قادرين على التحول إليه. كما قامت Microsoft بترجمة الوثائق إلى CommonMark لأنهم استخدموا Markdig الخاص بي. بدأوا العمل على كيفية استخدام Markdig منذ سنوات عديدة ، وقبل ذلك أخذوا محرك Markdown الذي يعمل بنظام الدفع الذاتي ، والذي يستخدم النظامي في الداخل. هذا ليس سيئًا ، ولكن على حد علمي ، لم يتبعوا مواصفات CommonMark في هذا المحرك ، لذلك تحولوا إلى Markdig نتيجة لذلك. اتصلوا بي ، وكان ذلك رائعا. لقد كتبت Markdig لاستخدامه ، وأردت استخدامه في مشروعي الخاص ، ولكن بعد ذلك وضعته جانباً لفترة طويلة. أنا سعيد جدًا لأن شركة مثل Microsoft قررت استلامها..: , ? ?لا ينطبق هذا على البرمجة فحسب ، بل ينطبق أيضًا على أي مجال. الشيء الرئيسي هو أن تقوم بأداء واجبك ، وتعلم الأشياء بنفسك. من المهم طرح الأسئلة. ليس من الضروري قبول لغة برمجة كما هي. ليس الأمر أنك بحاجة إلى تغييره ، ولكن من المهم أن تفهم سبب عمل الأشياء المختلفة بالطريقة التي تعمل بها. يجب أن تكون فضوليًا ومفتوحًا لدراسة الأسباب ، يجب أن تطرح أسئلة جيدة. "أنا لا أفهم كيف يعمل ، لكني أريد أن أفهمه." ماذا ستفعل لتحسين لغتك؟ كلما زاد عدد الأسئلة التي تطرحها على اللغة التي تستخدمها ، زادت فرص المساعدة ، وتحسينها ، وتعلم أشياء جديدة واكتشاف سبب تنفيذ شيء ما في البرنامج بطريقة معينة. حتى تتمكن من معرفة المزيدمن مجرد قيادة "أريد جعل X" في Google والعثور على المشاريع النهائية من وظيفة "فعل الخير" على github. عندما نكتب تطبيقًا حقيقيًا ، سيكون من الصعب للغاية الدخول في تفاصيل كل تبعية مستخدمة - سيكون من الصعب اختيار التفاصيل. ولكن في الجزء الذي يهتم بك ، وهو أمر مثير للاهتمام بالنسبة لك شخصيًا ، يجدر بك التعمق أكثر وطرح الأسئلة. كيف يعمل ، ما إذا كان يمكن القيام به بشكل أسرع ، لماذا لا يعمل شيء جيد جدًا - يجب أن تفهم السبب. "ربما يمكنني كتابة شيء أفضل؟"يجدر الغوص أعمق وطرح الأسئلة. كيف يعمل ، ما إذا كان يمكن القيام به بشكل أسرع ، لماذا لا يعمل شيء جيد جدًا - يجب أن تفهم السبب. "ربما يمكنني كتابة شيء أفضل؟"يجدر الغوص أعمق وطرح الأسئلة. كيف يعمل ، ما إذا كان يمكن القيام به بشكل أسرع ، لماذا لا يعمل شيء جيد جدًا - يجب أن تفهم السبب. "ربما يمكنني كتابة شيء أفضل؟"معظم المشاريع التي عملت معها اكتملت في الغالب. في بعض الأحيان لم يرغب أصحاب المشروع في تغييره. هذا أمر محزن ، لأنك تتوقع أن يتعاون الجميع في المصدر المفتوح مع بعضهم البعض. واقع المصدر المفتوح هو أنه في بعض الأحيان تحتاج إلى القيام بشيء آخر. أحيانًا ما تقدمه جيد ، لكنه يؤدي إلى الكثير من التغيير. قد يكون من الصعب على الناس قبول مثل هذه المقترحات - ربما لن تجلب سوى المزيد من الأخطاء والمزيد من الدعم ، ومن سيدعم كل هذا؟ أي شخص جاء بهذا العرض؟ ربما لا.أحيانًا أنسى أيضًا أنني بحاجة إلى طرح أسئلة مختلفة. أسئلة بسيطة. هل يمكننا القيام بذلك بشكل أسرع؟ أليس كذلك؟ أنت بحاجة إلى التصرف بدلاً من مجرد استخدام الأشياء البطيئة والشتائم ، وعدم القيام بأي شيء حيال ذلك. تحتاج إلى حفر ، إصلاح ... افعل شيئًا في المنزل ، تعامل مع الألم. في كل مرة تصبح أكثر استعدادًا لفهم التحديات وتطوير برامج أكثر تعقيدًا. وربما في النهاية ستشعر بخيبة أمل أقل من رد فعل الآخرين ، لأنك ستبدأ في فهم حدودهم بشكل أفضل.وشيء آخر مهم. لا تخجل. جربها! حاول أن تفعل ما تريد. إذا كانت لديك فكرة ، فحاول أن تدركها. حتى لو كانت هذه الفكرة مجنونة ، وأحيانًا يمكنك الحصول على نتائج مجنونة قليلاً - هناك أيضًا شيء ما لها. أثناء قيامك بمثل هذه الأشياء ، يمكنك مقابلة العديد من الأشخاص الغريبين والمجنون الذين يمكنك من خلالهم الحصول على أفكار رائعة حول كيفية تطويرك. يجب أن تكون منتبهًا جدًا لما يقولونه ، وكيف يعملون ، وما يعتقدون. لا تنسخها ، لأن لديك مسارك الخاص ومستقبلك. إنه لأمر رائع عندما يمكنك مقابلة مثل هؤلاء الأشخاص في مسار حياتك المهنية. كان لدي العديد من هؤلاء الناس. لم أكن أدرك هذا دائمًا ، ولكن بعد مرور بعض الوقت فهمت: "لماذا ، كان هذا الشاب رائعًا!" لقد تعلمت شيئًا منهم ، ولكن ربمايمكن معرفة المزيد. هذه هي منتصف الطريق بين محاولة التفكير في نفسك والاستفادة من أفضل العقول من حولك. يمكنهم التأثير عليك بطريقة جيدة ويمكن أن تساعدك على تطوير أشياء أكثر برودة.هذه قصة حول تطوير الذات ، وطرح أكبر عدد ممكن من الأسئلة ، ومحاولة الانفتاح على الأشخاص الذين تقابلهم ، وحول الأحداث التي يمكنك استخدامها ، والمشاركة في شيء أكثر من أنفسنا.
يوم الجمعة المقبل ، ستقدم ألكسندرا عرضًا تقديميًا "خلف مترجم الاندفاع ، وتحويل .NET IL إلى كود أصلي محسن للغاية باستخدام LLVM" في DotNext 2018 موسكو . سيعقد المؤتمر في 22-23 نوفمبر في موسكو ، ويبدو أنه سيكون DotNext الأكبر على الإطلاق. نود أن نخبرك بما يمكن توقعه من المؤتمر ، ولكن من الأفضل أن يتم ذلك لنا من قبل المتحدث الآخر ، ديلان بيتي - لقد سجل الأغنية بأكملها: