「恥ずかしがらないでください。 やってみて！」 Unity Alexandre Mutelとの生活、コンパイラー、コンパイラーの生活に関するインタビュー

システムプログラミングで成功する方法、知っておく必要があること、特に30年以上働いている場合はどうすればよいですか？ C＃とパフォーマンス-C＃に表示されるすべてを書き換える価値はありますか？ 私たちを待っている低レベルのコンパイラ技術に関して、将来はどうなりますか？



今日、私たちの仮想スタジオでは、 Alexandre Mutelが質問に答えます。



Alexandre Mutelは、Unity Technologiesのリードソフトウェアアーキテクトです。 さらに、SharpDX、Markdig、Zioなどのプロジェクトに貢献する有名なオープンソース開発者であり、2014年以降はVisual Studioおよび開発テクノロジカテゴリのMVPです。



Alexandreは、リアルタイムグラフィックスレンダリング、GPGPU、サウンド合成、マネージ言語の効率的な使用とアーキテクチャ、コード生成、ドキュメントの分野で、さまざまな低レベルおよび高レベルの問題に取り組んでいます。


いつものように、インタビューはJUG.ruグループのEvgeny Trifonov（ phillennium ）とOleg Chirukhin（ olegchir ）によって行われます。

投稿の最後に、ディラン・ビーティ（別の有名なドナー）からの驚きがあります-私たちはそれを期待していませんでした。

E。：あなたは30年の長いキャリアを持っています-手始めに、それについて簡単に話せますか？



それはすべて幼少期に始まりました。私はAmstrad PC 464を手に入れました。このコンピューターでプログラミングを始めたとき、私は11歳か12歳でした。正確に覚えていません。 私はすぐにBASICプログラミングを習得し、ゲーム開発の本を購入しました。 コードを開発して書くほうが面白いゲームはほとんどありませんでした。 それから私はアムストラッドのアセンブラーコードを書き続けました。



16時に、Amiga 500を手に入れました。デモを書いていた人に会いました。今はまったくありませんでした。 これがWebGLであり、これはまったく異なるデモシーンです。 私は多くのデモを書き始めましたが、それはいつも見せたわけではありませんが、アセンブラーで書くのが好きでした。 そして、それはとても簡単でした。



それから彼は高等専門学校に行き、そこでコンピューター工学を学びました。 これはすでにゲームやアセンブラーと比較してまったく異なるものでした。 以前は存在していなかったとさえ知らなかったものを学ぶのが大好きでした：オペレーティングシステム、UNIX、C言語での作業（C / C ++コンパイラを購入するお金がなかったのでBASICまたはアセンブラーのみを使用していました）。



彼は大学を卒業したとき、通貨市場業界で働き始めました。 これはニューヨークのフランス企業の仕事でした。 2年後、私は戻って銀行に行きました。 実際、銀行で働きたくなかったので、ゲーム開発者で働きたかったのです。 しかし、その結果、そこにとどまりました-新しい領域、学ぶべき多くのこと。 そこで私はそこで8〜9年を過ごしました。主にJavaを扱い、C ++を少し扱いました。 多くの分散サーバーとSQLデータベース、データベースのコピー...私が今していることはまったくありません。



それから私は創造的な休暇を取り、世界中の観光旅行に行きました。私はアフリカ、南アメリカ、アジアで一年過ごしました。 旅は私を変え、私を揺さぶりました。 戻ったとき、私はもはやコンピューターを扱うことができませんでした。ITの分野では、銀行で働くことができませんでした。 私は仕事を辞め、子供、ホームレス、障害者、高齢者と働くためにソーシャルワーカーコースに4年間を費やしました。 私はこれを3年間勉強しましたが、非常に興味深かったです。なぜなら、私の人生のほとんどは、数学、プロジェクト、抽象化という正確な科学の分野で働いていたからです。 そして、彼は突然、非常に人道的な地域に連れて行きました。 トレーニング後にこの分野で仕事をしようとさえしましたが、この期間中に、子供の頃にデモを行った友人が、これをもう一度できるとほのめかしました。



私は自由な時間にデモを練習し始めましたが、すぐに路上で子供たちと仕事をする以上の時間がかかり始めました。 それは悪かった。 人々は言った：「私たちはゲーム開発で仕事を見つけようとする必要がある、どうして？ できます。」 しかし、私はそれが不可能だと思った。なぜなら私は長い間コンピューターを使っていなかったし、履歴書でITの仕事を見つけるのが難しいからだ。



私はオープンソースアプリケーションに取り組み始め、企業が使用し始めたいくつかのプロジェクトをリリースしました。 これらの会社の1つから連絡があったとき、SharpDXと呼ばれる最新のプロジェクトの1つを使用しました。 私は家族と一緒に日本に行きました-私はすでに2人の子供がいたからです。 私たちは日本に5年間住んでいました。 このとき、私はC＃でゼロからゲームエンジンを作成することに取り組んでいました。



約2年前、私はフランスに戻り、Unityで働き始めました。 これは私が前にやったことを妨げましたが、彼らはIL .NETコードからネイティブコードを生成するネイティブコンパイラを作成するという非常に複雑で興味深いタスク、実際のテストで働くことを申し出ました。 これは私がいつもやりたかったことでしたが、できませんでした。 そして、チャンス、素晴らしいチャンスがありました。 私はこのプロジェクトに2年間携わりました。



はい、物語はそれほど短くなかったようです。



E。：何もない、そのようなキャリアは長い話の価値がある。 あなたの経験から、これをお聞きしたいと思います。 今では、「ムーアの法則はもはや機能せず、コンピューターは速くならない、私たちはすべて運命だ」と言う人もいます。 他の人は答えます：「さあ、彼らは同じペースで加速していませんが、まだ成長しているので、パニックする理由はありません。」 生産性のトピックはあなたに近く、同時にあなたは長い間業界をフォローしているので、あなたの立場は何ですか？



私はこの黄金の意味に固執しています。 （笑）私たちが開発するアプリケーションのほとんどではないにしても、多くのアプリケーションが最初からパフォーマンス要件に適応しているため、可能な限り最高の品質が得られると思います。



目の前でIT業界で何が起こったのかをご覧ください。 たとえば、Windows Vistaなどのように、Windowsが数年かけて少し遅くなったとき 実際、パフォーマンスを改善するために自然な作業が行われました。何年もそれについて特に心配していなかったからです。 Windows 8が登場したとき、それはもう少し良くなりました。 その後、Windows 10が登場し、少し良くなりました。 その結果、以前と比較して非常にうまく機能するシステムができました。 これらの最適化を行うことは彼らにとって本当に重要でした。なぜなら、人々は必然的に「彼らの手段を超えて生き」、「ああ！ このソフトウェアは機能しなくなりました。Linuxに切り替えています。なぜなら、それはより速くて愚かではないからです。」



私たちが開発するすべてのソフトウェアについても同じことが言えます。 そして驚くべきこと：ネイティブコードを使用する傾向が常にあり、WindowsでもC ++に戻ることを決めた時点で、「C ++は解決策です。 「。 そして再び、母国語が関連するようになりました。



同時に、ChromeのV8はJITのおかげでJavaScriptを使用できるようにしました。 JSはスクリプト言語であり、超高速ではありませんが、C ++の2倍の速度で動作する場合があります。 Visual Studio Codeでのコードの作成など、彼が生き残り、今すぐ使用するのに十分でした。 しかし、よく見ると、それはすべて、最初からパフォーマンス要件が定められているためです。 VSCodeでさえ、一般に多くのJavaScriptおよびスクリプトコードがありますが、他のすべて（V8、レンダリングスタック、JIT）はすべて、最高のパフォーマンスのために設計された言語、つまりC ++で記述されています。 すべてをC ++とは限らない別の言語で書くこともできますが、実際には、このソフトウェアはすべて最初からパフォーマンスを考慮して開発されたものです。



確かに、効率の悪い生産的な言語を使用できますが、それは基礎となるすべてのテクノロジーが素晴らしいユーザーエクスペリエンスを獲得することを目的として開発されているためです。 たとえば、Visual Studio Codeは開発者にとって非常にうまく機能し、問題を解決する素晴らしいソフトウェアです。 多くの人は、「より多くのネイティブコードエディターを使用したいのですが、今はVisual Studio Codeに切り替えています」と言っています。 パフォーマンスはどこにでもありますが、使用するすべてのものに既に組み込まれているために表示されない場合があります。



私たちは思う：それはJavaScriptで書かれている、なぜならそれは十分に速いからだ。 しかし、何百人もの開発エンジニアが何年もJITを最適化するために働いてきたという理由だけで、JavaScriptは非常に高速です。 非常に複雑なアプリケーションを作成する場合でも、スクリプト言語を使用できるようになりました。 このすべての準備作業がなければ、スクリプト言語ははるかに遅くなります。 私たちは奇妙な時代に生きています。 私たちには選択肢がありますが、それでもすべての言語で何度も繰り返されるパフォーマンスの物語があります。



.NETは典型的な例です。 過去3〜4年にわたって、膨大な作業が行われました。 いつかASP.NET Coreを見て、CoreCLRで行われたすべての作業を見ると...パフォーマンスは売れ行きが良く、お金がかかり、より多くを達成できます。 厳しい要件を満たそうとすると、生産性を高め、電力を節約し、月末にお金を節約できます。パフォーマンスはすべてに影響します。 「すべてが順調です。アプリケーションを開発しています。平均的なパフォーマンスがありますが、そうなります...」と人々が言っ​​ているのを聞いたとき、彼らは何を考えていますか？ アプリケーションの生産性をもう少し高めることができるかどうかを確認するには、少し時間をかける必要があります。 リソースまたはアプリケーションのランタイムを10分の1でも節約できる場合は、それで十分です。



E。：哲学的な質問が部分的にあります。 Slackは技術的な解決策として最適な場所ではないと考えていますが、サイトでは古い学校のRSSを購読することを提案しています。 インスタントメッセージングの新しい時代が開発者の生産性を低下させていると思いますか？



いいえ、そうは思いません。 今、私はリモートで作業しています。 Unityの職場では、リモートで作業できるため、私は常にSlackを使用して同僚と通信しています。 これは私が連絡を取り合い、生産性を維持するための最良の方法です。 チャンネルなどを確認する必要があるため、これには仕事から多くの時間がかかりますが、一時的にSlackをオフにして仕事に集中することができます。 私はオープンスペースで会社に勤めていましたが、選択の余地はありませんでした。誰かが質問をしたい場合、すぐに答えなければなりません。それははるかに複雑です。



Twitterとメールについては、あまり頻繁にチェックしません。 Twitterを1日に1〜2回読むのは、さまざまな要因に依存します。議論に参加するかどうか、議論することです。 Slackのようなものを使用すると、社内のさまざまなチャネルに参加したり、単独で作業した場合には従うことができない多くのトピックに従うことができます。 妥協点を見つける必要があります。私たちは皆、会社で起こる多くのことを心配していますが、すべての議論に同時に参加することはできないので、選択する必要があります。 何人かの人々は非常に多くのチャンネルを読むことができるので、私は彼らの能力に単に驚いています。私自身はそうではありません。 今日、私は約30のチャンネルを読みましたが、これはそれほど多くありません。



E。：オレグの質問の時間をありがとう！



A。：私のキャリアはあなたのキャリアといくらか似ています。私は銀行で働いていましたが、現在はまったく異なる分野で会議を開催し、同時にコンパイラーの構築方法を見つけようとしています。 単純なエンタープライズWeb開発者からシステムプログラミングに切り替えようとしている人に、何をアドバイスできますか。そのような移行に関するヒントはありますか。 ここには、十分な数の人はいないと思います。



そのような移行のための準備されたパスがあるかどうかはわかりません。 そのような技術に興味があるなら、普通の宿題をします。 自宅では、パーサーやコンパイラに関連するものを書きます。 最初から最後まで、コンパイラー全体をマシンコードの生成まで書く必要はありません。 コンパイラインフラストラクチャの作成に興味を持つようになります。 これが私が近年Unityで働いていることです。 あなたが低レベルのものに情熱を持っているなら、これはそれがすべて実際にどのように機能するかを理解できる場所の1つです。 作業を改善する方法、パフォーマンスを改善する価値がある場所、およびこれがまだ行われていない場所。 パフォーマンスが心配な場合は、アプリケーションが最終的に実行されるものを認識することが非常に重要です。



パフォーマンスは私のテーマであり、これはすべて私にとって素晴らしい機会になりました。 私は、コア、つまりコンパイラレベルで問題の解決策にアプローチしたいと思います。 ユーザーにとって必要な場所で生産性を数十倍に高めることができるのはここです。 ゲーム、アプリケーション、映画などを実行する場合、そのような結果を達成するのは比較的簡単な場合があります。



低レベルのものとコンパイラーコンポーネントに対する私の情熱は、現在の仕事に私を導きました。 しかし、それは私が特にやりたかったことではありませんでした。 時には、異なる言語で多くの経験を積んだら、アプリケーションを作成します-あなた自身の言語を考え出しさえしたいのです。 私はこれを始めましたが、仕事が多すぎるのでやめました。 しかし、あなたは「根に」戻り、すべてを理解するために自分で何かをしようとする潜在意識の欲求を持っています。 もちろん、コンパイラーがどのように機能するかは理解していましたが、要件の複雑さは理解していませんでした。 たとえば、メモリ管理の分野で対処する複雑なトレードオフ。 アプリケーション開発者の生産性を高め、効果的なものを同時に選択することは非常に困難です。 この問題はまだ最後まで解決されていません。 Rustまたは.NETはこれを決して解決しません。 Rustは素晴らしく、驚くべきものですが、特にJavaScriptのようなもので切り替える場合は、作業が困難です。 ただし、Rustに移行しているPythonまたはJavaScript開発者の例がありますが、これは多少驚くべきことです。



A。：過去10年間C＃でプログラミングしたとおっしゃいましたが、C＃では何が良いのでしょうか？ たとえば、なぜC ++ではないのですか？ C ++はより体系的な言語のようです。



正直に言うと、私はC ++が嫌いで、Cは嫌いですが、私は彼らと一緒に働いています。 私はそれらが多くのバグ、巨大な開発の非効率性につながると心から信じています。 多くの人は、Cでプログラミングしているので、プログラムがパフォーマンス指向であるという事実上のコードをすでに事実上書いていると考えています。 これは真実ではありません。 mallocなどのヒープをスカルプトすると、.NETで記述されたものと比較しても遅くなります。 優れたC / C ++開発者は、 リージョンメモリアロケーターのようなトリックを使用せざるを得ません。 誰も聞いたことのないたくさんの奇妙なことに自分自身を埋めなければなりません。 ここでは、ゲーム開発者は通常そのようなことを知っています。 少なくとも、AAA開発者またはC / C ++フレームワークでゲームを作成する人々。 問題の一部は、言語自体の複雑さに起因しています。 以前は、C ++の本をまったく読んでいませんでしたが、ほんの3、4年前に、言語を感じるためだけにC ++の本だけを読み始めました。 私はそれをプログラムしましたが、体系的で正式なアプローチがありませんでした。その複雑さ、すべてを正しく書かないと破滅することのあるものの数に驚かされました。



数か月前にUnityにバグがありましたが、誰かがC ++コードでミスを犯しました。それはコンストラクターにあり、何かが値で渡されたため、この値からアドレスを取得してキャッシュで探しました。 実際、メモリになくなった値を参照しました。 これはすべて、ポインターが非インジケーターと混同され、このリファクタリングを行った人がすべての使用場所をチェックしなかったためです。 完全に機能するまったく異なるコードが突然機能しなくなりました。 それは小さな間違いのようですが、すべてを壊しました。 実際、これはメモリの操作における間違いです。 そうです、そういうものを見たとき、私はCとC ++での作業へのアクセスを制限し、それらの使用を最小限にしなければならないと確信しています。 .NETの部分では、使用をプラットフォーム固有のものにのみ制限しました。 しかし、すべてをC＃で書くのはかなり面倒です。 APIにアクセスするには、たくさんのdlopenを実行する必要があります。 ただし、たとえば、これらすべてをCのラッパーにカプセル化し、1つの関数だけでアクセスを整理することができます。 そのようなものを分離し、CおよびC ++でさらに開発したいと思います。 しかし、これは相互運用性に関する非常に狭いトピックであり、その後、通常の制御言語にとどまり、ほとんどの場合それを使用し、より高速なコンパイルをお楽しみください。



C ++コンパイラとリンカのエラーが嫌いです。異なるプラットフォームで作業する必要が嫌いです。これはすべて非常に難しいことです。 MSVCでコンパイルを開始したら、Clangに切り替えてからGCCに切り替える必要があります。 Linux、Mac、Windows、Android、iOSなどで。 C ++での作業は悪夢です！



エディターファイル、.hファイル、およびcpp。ファイルの分離は嫌いです。 人々は言語に完全に混乱し、マクロでプログラムを開始します。 私はメタプログラミングが大好きですが、現代のC ++では完全に狂気に陥ります。 これらのこと自体は素晴らしいですが、実際にはすでに多すぎます。



要約すると、はい、C＃で効果的なソフトウェアを開発できると思います。 C ++ほど高速ではないかもしれませんが、可能です。 これはまさにUnityでやろうとしていることです-たとえば、C ++の場合よりもさらに多くの場所で最大のパフォーマンスを達成するために、C＃の特定のサブセットをコンパイルするバーストコンパイラを実行していますが、C＃に残ります。 それは完全に安全です。 ポインターについては、安全でないと宣言し、例外をスローせず、すべてを明示的に行う必要があります。 そして、これは苦い経験です。 ただし、C ++と同じくらい高速なコードを作成できます。 これはまさに.NETが進む価値のある方向であり、私たちが進むべき方向だと思います。



A。：たとえば、オープンソースコードについて話すと、非常に大きくて恐ろしいCファイルである.NET Coreにガベージコレクターがあります。 おそらく、ある種のLispから生成された2メガバイトのゴミです（手作業で書く価値のある文字はほとんどありませんでした）。 おそらくここですべてをC＃で書き直すのが理にかなっていますか？



はい！ 私は、Microsoftとコミュニティの両方でJITに携わっている人々とチャットしています。 私が本当に信じているものがあります。 あなたの言語がより成熟し、基本的になった瞬間があると信じています。そして、あなたはそれに挑戦し、強さをテストしなければなりません。 基盤として使用できる必要があります。 パフォーマンスを非常に要求するものを作成するためにも使用できることを証明してください。 これがガベージコレクターとJITの物語です。 JITやGCなど、非常に大きな割合の.NETランタイムサブシステムをC＃で実行できます。 C ++で基本プラットフォームの抽象化しか記述できないというルールを作成すると、ほとんどのランタイムプラットフォームが独立します。 これが起こったらとてもうれしいです。 しかし、これは大きな仕事です。



私がこのアイデアが特に好きな理由が1つあります。 , 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, — , . , , , , , . . , , . , . , , , , ? , , , . , - : «, , , - » — , , , .



, . , , , , , , - . , : , , . , , . , , . , . , — .



— . -. , -, API, . . , SharpDX . . , , , . DirectX C++ API, C++. , . , - , . : , . , SharpDX. , PR, . pull request ( ). - . - , SharpDX - . : « ?» ( , ) , . 90- — . , , .



, , , , : , , .



.: — , ? . , , ?



, — , SIMD. , , SIMD , . ( LLVM, , ). , , . , , , . - , . , . . - Intel LLVM. , , LLVM. , , . LLVM — , , , .NET. SIMD, CPU — . , , .NET — SIMD- . , , .



: « ». . . LLVM : -, , . , , Roslyn C#, . , , . , , , . SIMD — . GPU, CPU, — . 6, 8, 16, 42 . - , , .



.: Markdown Markdig, ? , Markdown? , ?



, Markdown — , . , , Word - . . ? , , . . , RFC — , , , . , , . , ASCII-art. Word, PDF . Word. - — . , . Markdown, , - — , HTML. , . HTML, Markdown . , Github, Markdown- . . — . , Microsoft Markdown, GitHub, PR — , .



Markdown, CommonMark, , Markdown. , CommonMark — . , , . , Github CommonMark . — . . Microsoft CommonMark, Markdig. , Markdig , Markdown-, . , , , CommonMark, Markdig. , . Markdig , , , . , Microsoft .



.: , ? ?



, . — , . . , . , , , . , . « , , ». , ? , , , , , - . , Google « X» « ». , — . , , , . , , - — , . « , - ?»



, , . . , , . , - . , , , . — , , ? , ? おそらくない。



, . . ? ? , , . , … - , . . , , , .



. . ! , . — . , — - . , , , . , , , . , . , . . , - : « !». -, , , . , . .



, , , , , , , - , .

---

«Behind the burst compiler, converting .NET IL to highly optimized native code by using LLVM» DotNext 2018 Moscow . 22-23 , , DotNext . , , , — :