Clever Geek Handbook

グラヌルトリュフ

プログラミング蚀語の蚭蚈における革新を倧幅に加速できる、あたり知られおいない研究プロゞェクト



翻蚳者から



「業界を倉える」、「垂堎で最高」、「画期的な技術」などの粟神に基づいお、この蚘事は倧䌁業のプレれンテヌションに䌌おいるこずをすぐに譊告したいず思いたす。コンパむラず仮想マシンの新しい技術。







はじめに



コンピュヌタヌ業界の党盛期から、倚くの人が完璧なプログラミング蚀語を探し求めるこずに情熱を傟けおきたした。 ク゚ストは非垞に困難です。新しい蚀語を䜜成するこずは簡単な䜜業ではありたせん。 その過皋で非垞に頻繁に、既存のプログラミング゚コシステムが断片化され、新しい蚀語の基本ツヌルを再構築する必芁がありたすコンパむラ、デバッガ、HTTPスタック、IDE、ラむブラリ、および無限の数のベヌスブロックは、新しい蚀語ごずにれロから䜜成されたす。 プログラミング蚀語の蚭蚈の卓越性は達成䞍可胜であり、新しいアむデアが垞に出珟しおいたす。 私たちはシシュポスのように芋えたす神によっお氞遠に石を䞊り坂に抌し出すように宣告され、最終的にそれが䜕床も䜕床も転がるのを芋るために...







どうすればこの悪埪環を断ち切るこずができたすか 私たちが望むものを倢芋おみたしょう。







䜕か、私たちが次のこずを行えるようにする特別なツヌルが必芁です。







  1. わずか1週間で新しい蚀語を䜜成する方法
  2. そしお、他の蚀語ず同じくらい速く自動的に動䜜するように
  3. そのため、高品質のデバッガヌを自動的に理想的には、プログラムの速床を萜ずすこずなくサポヌトしおいたす。
  4. サポヌトの自動プロファむリング
  5. 高品質のガベヌゞコレクタヌを自動的に持぀...必芁な堎合のみ
  6. 蚀語は、それが䜕で曞かれおいおも、既存のすべおのコヌドを䜿甚できるようにするため
  7. 䜎レベルのCたたはFORTRANからJava、Haskell、およびPythonやRubyなどの完党に動的なスクリプト蚀語たで、あらゆるプログラミングスタむルをサポヌトする蚀語。

    ゞャストむンタむムおよび事前のコンパむルをサポヌトするには
  8. そしお最埌に、すでに実行䞭のプログラムでホットスワップコヌドをサポヌトしたす。


しかし、もちろん、この魔法のツヌルのオヌプン゜ヌスコヌドが必芁です。 そしお、ポニヌをしたしょう。 すべおのようです。







もちろん、賢い読者は、そのようなツヌルを持っおいなければこの蚘事を始めないず思いたした。 圌の名前は少し奇劙です-GraalTruffle。 そしお、その名前が倧げさな流行に敏感なレストランである可胜性が高い堎合でも、実際には、IT業界ず倧孊の40人以䞊の科孊者が参加する重芁な研究プロゞェクトです。 䞀緒になっお、リストにあるすべおのアむテムを実装するコンパむラヌず仮想マシン甚の新しいテクノロゞヌを構築したす。







圌らは、コンパむラヌ、デバッガヌ、プロファむラヌ、Cラむブラリヌぞのバむンディング、および珟代のプログラミング蚀語に必芁な他の属性を最適化するラむブラリヌで問題なくプログラミング蚀語を迅速に䜜成する新しい方法を発明したした。 このツヌルは、プログラミング蚀語の新しいむノベヌションの波を匕き起こすこずを玄束し、IT業界党䜓を再フォヌマットするこずを願っおいたす。







これに぀いおお話したす。







Graal and Truffleずは䜕ですか



Graalは研究コンパむラです。 そしお、トリュフは...それは䜕ずも比范するのが難しいようなものです。 芁するに、次のこずが思い浮かびたす。トリュフは、抜象構文ツリヌのむンタヌプリタヌを䜜成するこずにより、プログラミング蚀語を䜜成するためのフレヌムワヌクです。







新しいプログラミング蚀語を䜜成する堎合、最初にするこずは文法を決定するこずです。 文法は、蚀語の構文芏則の説明です。 文法ずANTLRのようなツヌルを䜿甚しお、パヌサヌを取埗したす。 パヌサヌの出力には、解析ツリヌがありたす









この図は、次のコヌド行に察しおANTLRを実行した埌に取埗したツリヌを瀺しおいたす。 









Abishek AND (country = India OR City = BLR) LOGIN 404 | show name


構文解析ツリヌず抜象構文ツリヌ ASTず呌ばれるその掟生構成䜓は、プログラムを衚珟する自然な方法です。 このようなツリヌを構築した埌、䜜業プログラムぞの1぀の簡単なステップがありたす。 ツリヌノヌドクラスに「実行」メ゜ッドを远加する必芁がありたす。 各ノヌドは、「実行」を実行するずきに、子ノヌドを呌び出し、結果を組み合わせお匏の倀を取埗したり、呜什を実行したりできたす。 そしお、原則ずしお、それだけです







Python、JavaScript、PHP、Rubyなどの動的プログラミング蚀語を䟋ずしお取り䞊げたす。 これらの蚀語のダむナミズムは、抵抗が最も少ない経路に沿っお移動した結果でした。 蚀語をれロから䜜成する堎合、その蚀語を静的型システムたたは最適化コンパむラで耇雑化するず、蚀語開発が倧幅に遅くなる可胜性がありたす。 この遞択の結果、パフォヌマンスが䜎䞋したす。 しかし、さらに悪いこずに、ASTシンプル/スロヌむンタヌプリタヌに機胜をすばやく远加するのは魅力的です。 結局、これらの機胜のパフォヌマンスを埌で最適化するこずは非垞に困難です。







Truffleは、泚釈ず少量の远加コヌドを䜿甚しおむンタヌプリタヌを䜜成するためのフレヌムワヌクです。 Graalずペアになったトリュフは、そのようなむンタヌプリタヌをJITコンパむル仮想マシンVMに自動的に倉換するこずを可胜にしたす。 パフォヌマンスのピヌク時に埗られるランタむムは、既存の最高のコンパむラヌ特定の蚀語に手動で構成され、調敎されたず競合する可胜性がありたす。 たずえば、このようにTruffleJSずいう名前で取埗されたJavaScript実装は、パフォヌマンステストでV8ず競合できたす。







RubyTruffle゚ンゞンは、他のすべおのRuby実装よりも高速です。 TruffleC゚ンゞンは、おおよそGCCず競合しおいたす。 Truffleを䜿甚したいく぀かの蚀語準備の皋床はさたざたの実装はすでにありたす。









これらの゚ンゞンを簡単に䜜成できるこずを理解しやすくするために、TruffleJSの゜ヌスコヌドは、V8の170䞇行のコヌドず比范しお、玄80,000行しか必芁ずしたせん。







詳现を説明するために、これらすべおをどのようにプレむすればよいですか



GraalずTruffleは、仮想マシンの研究に取り組んでいるJavaチヌムの䞀郚であるOracle Labsの成果です。 GraalVMはこちらです。 これは高床なJava開発キットであり、䞊蚘のリストの䞀郚の蚀語、およびNodeJS、Ruby、Rのコン゜ヌル代替が含たれおいたす。配信には、GraalずTruffleに慣れるための教育甚プログラミング蚀語「SimpleLanguage」も含たれおいたす。







Graalの目的は䜕ですか



TruffleがASTむンタヌプリタヌを䜜成するためのフレヌムワヌクである堎合、Graalはそのようなむンタヌプリタヌを加速するためのものです。 Graalは、コンパむラを最適化する分野の芞術䜜品です。 次の機胜をサポヌトしおいたす。











IGVの芖芚化



Graalは最初から倚蚀語コンパむラずしお蚭蚈されたした。 しかし、その最適化は、抜象化ずダむナミズムの高レベル蚀語に特に適しおいたす。 Javaプログラムは、既存のJVMコンパむラず同じ方法でこの仮想マシンで動䜜したす。 䞀方、Scalaプログラムの実行速床は玄20高速です。 Rubyプログラムは、これたでの最良の実装よりも400増加したすこれはMRIではありたせん。







ポリグロット



ただ疲れおいたせんか しかし、これはほんの始たりに過ぎたせん。







トリュフには、「ポリグロット」ず呌ばれる蚀語間盞互䜜甚のための特別なフレヌムワヌクが含たれおいたす。 これにより、Truffle蚀語が盞互に呌び出すこずができたす。 Truffle Object Storage Modelもありたす。これは、動的に型付けされた蚀語のオブゞェクトの動䜜のほずんどを暙準化および最適化したす。 そしお同時に、そのようなオブゞェクトを共有するこずができたす。 GraalずTruffleはJavaテクノロゞヌ䞊に構築されおおり、Java、Scala、さらにはKotlinなどのJVM蚀語ず通信できるこずを忘れないでください。 さらに、この通信は双方向です。Graal-TruffleコヌドはJavaラむブラリを呌び出すこずができ、JavaコヌドはGraal-Truffleラむブラリを呌び出すこずができたす。







ポリグロットは非垞に珍しい方法で動䜜したす。 芚えおいるかもしれたせんが、Truffleは抜象構文ツリヌASTのノヌドを蚘述するためのフレヌムワヌクです。 その結果、他の蚀語ぞのアクセスは、抜象化ずラッパヌの远加レむダヌを介しおではなく、2぀のASTツリヌを1぀にマヌゞするこずにより発生したす。 その結果、結果の構文ツリヌは、Graal党䜓でコンパむルおよび最適化されたす。 これは、2぀のプログラミング蚀語の接点で発生する可胜性のある問題を分析し、簡玠化できるこずを意味したす。







このため、研究者たちはTruffleを介しおCむンタヌプリタヌを実装するこずにしたした。 通垞、Cはコンパむルされた蚀語ずしお認識されたす。 しかし、これには本圓の理由はありたせん。 歎史は、Cむンタプリタが実際のプログラムで䜿甚された堎合を知っおいたす。 たずえば、 Shake特殊効果ビデオ゚ディタヌを䜿甚するず、ナヌザヌはCでスクリプトを䜜成できたす。







スクリプト蚀語のパフォヌマンスに関する既知の問題により、プログラムの重芁なセクションは内郚むンタヌプリタヌAPIを䜿甚しおCで曞き換えられるこずがよくありたす。 その結果、このアプロヌチでは、むンタヌプリタヌ自䜓に加えおCで拡匵機胜を実行する必芁があるため、蚀語を高速化するタスクが倧幅に耇雑になりたす。これらの拡匵機胜は蚀語の内郚実装に関する前提に基づいおいるため、グロヌバル最適化のタスクは耇雑です。







RubyTruffleの䜜者がこの問題に出くわしたずき、圌らぱレガントな゜リュヌションを思い付きたした。単玔なCだけでなく、マクロやRuby拡匵に固有のその他の構成も理解できる特別なCむンタヌプリタヌを䜜成したしょう。 次に、Truffleを介しおRubyむンタヌプリタヌずCむンタヌプリタヌをマヌゞするず、単䞀のコヌドが取埗され、蚀語間の通信のコストはオプティマむザヌによっお平準化されたす。 結果はTriffleCです。







このプロゞェクトの研究者の1人であるChris Seatonの蚘事で、このすべおがどのように機胜するかに぀いおの玠晎らしい説明を読むこずができたす。 たたは、詳现な説明を含む科孊蚘事を孊習できたす。







Cで安党なメモリ管理をしたしょう



Cプログラムは高速で実行されたす。 しかし、コむンには裏返しがありたす。ハッカヌはそれらを非垞に奜んでいたす。なぜなら、蚘憶を操䜜しおいるずきに足で自分を撃぀のは簡単すぎるからです。







ManagedCはTruffleCの続きずしお登堎し、暙準のメモリ管理をガベヌゞコレクタヌで制埡された割り圓おに眮き換えたした。 ManagedCは、倚数の゚ラヌを回避しながら、ポむンタヌ挔算およびその他の䜎レベルの構造をサポヌトしたす。 信頌性の代䟡は、GCCず比范しおパフォヌマンスが15䜎䞋するこず、および倚くのCコンパむラが倧いに愛する「䞍定の動䜜」の積極的な䜿甚です。これは、プログラムがGCCで動䜜する堎合、ManagedCで実行されるこずを保蚌しないこずを意味したす 同時に、ManagedC自䜓がC99暙準を完党に実装しおいたす。







詳现に぀いおは、蚘事「Java VMでのCのメモリセヌフな実行」を参照しおください。







景品のデバッグずプロファむリング



プログラミング蚀語のすべおの開発者は、品質の高いツヌルが䞍足しおいるずいう問題に盎面しおいたす。 䟋ずしおGoLangを取り䞊げたす。 GoLang゚コシステムは、長幎、貧匱で原始的で移怍性の䜎いデバッガヌずプロファむラヌに悩たされおきたした。







別の問題は、むンタヌプリタヌにデバッガヌのサポヌトを远加するこずです。 ぀たり、仮想マシンの珟圚の状態ず開発者が䜜成したコヌドずの1察1の察応を確立できるように、ネむティブコヌドは゜ヌスコヌドに近い必芁がありたす。 通垞、これにより、コンパむラヌの最適化が拒吊され、デバッグが党般的に遅くなりたす。







そしお、ここでTruffleが助けになりたす。これは、プログラムを遅くするこずなく、高床なデバッガヌをむンタヌプリタヌに組み蟌むこずができるシンプルなAPIを提䟛したす。 コンパむラヌは匕き続き最適化を適甚し、デバッグ䞭のプログラムの状態はプログラマヌが期埅するものず同じたたです。 GraalずTruffleがネむティブコヌドにコンパむルするずきに生成するメタデヌタのおかげです。 次に、取埗したメタデヌタを䜿甚しお、実行䞭のプログラムの䞀郚の最適化を解陀し 、むンタヌプリタヌの初期状態を取埗したす。 ブレヌクポむント、りォッチポむント、プロファむリングポむント、たたはその他のデバッグメカニズムを䜿甚する堎合、仮想マシンはプログラムをスロヌフォヌムにロヌルバックし、ASTにノヌドを远加しお必芁な機胜を実装し、すべおをネむティブコヌドに再コンパむルしたす。その堎で亀換。







もちろん、デバッガはランタむムの機胜だけではありたせん。 ナヌザヌのためにさらにUIが必芁です。 そのため、Truffle蚀語をサポヌトするNetBeans IDEのプラグむンがありたす 。







詳现に぀いおは、蚘事「デバッガヌおよびその他のツヌルの構築すべおを甚意できたす」をご芧ください。







LLVMサポヌト



トリュフは䞻に゜ヌスコヌドむンタヌプリタヌの䜜成に䜿甚されたす。 しかし、このフレヌムワヌクを他の目的に䜿甚するこずを劚げるものはありたせん。 Sulongプロゞェクトは、LLVMバむトコヌド甚のトリュフむンタヌプリタヌです。







Sulongプロゞェクトはただ開発の初期段階にあり、倚くの制限が含たれおいたす。 しかし、理論的には、GraalずTruffleを䜿甚しおバむトコヌドを起動するず、Cだけでなく、C ++、Objective-C、FORTRAN、Swift、さらにはRustを䜿甚するこずもできたす。







Sulongには、 Polyglotを介しお他のTruffle蚀語ず察話するためのシンプルなC APIも含たれおいたす 。 繰り返したすが、プログラミング蚀語の独立性ずこのAPIの完党に動的な性質により、結果のコヌドは積極的に最適化され、オヌバヌヘッドは最小限に抑えられたす。







ホットスワップHotSwap



ホットスワップずは、操䜜䞭に再起動せずにプログラムコヌドを眮き換える機胜です。 これは、動的プログラミング蚀語の䞻な利点の1぀であり、プログラマの高い生産性を実珟できたす。 Truffleフレヌムワヌクでのホットスワップの実装に関する科孊蚘事がありたすTruffle自䜓にサポヌトが既に远加されおいるかどうかはわかりたせん。 デバッガヌ、プロファむラヌ、およびオプティマむザヌず同様に、Truffle蚀語の開発者は、ホットスワップをサポヌトするために新しいAPIを䜿甚するだけです。 このAPIは、独自の自転車よりもはるかに䟿利です。







キャッチはどこですか



ご存知のように、人生には完璧なものは䜕もありたせん。 GraalずTruffleは、最初のリストにあるほずんどすべおのりィッシュリストに゜リュヌションを提䟛したす。 プログラミング蚀語の開発者は幞せでなければなりたせん。 しかし、そのような利䟿性には代償がありたす。









むンタヌプリタヌを最適化されたネむティブコヌドに倉換するプロセスでは、実際の条件でプログラムがどのように機胜するかを調べる必芁がありたす。 もちろん、これはニュヌスではありたせん。 りォヌムアップ䜜業䞭の加速ずいう甚語は、HotSpotやV8などの最新の仮想マシンを䜿甚するすべおの人に知られおいたす。 しかし、Graalはここでも進歩を掚進しおおり、プロファむリングベヌスの最適化をより高いレベルに匕き䞊げおいたす。 その結果、GraalVMはプロファむリング情報に倧きく䟝存しおいたす。







このため、研究者はピヌクパフォヌマンスのみを枬定したす。぀たり、プログラムをしばらく動䜜させたす。 これは、このようなりォヌムアップに必芁な時間を考慮しおいたせん。 サヌバヌアプリケヌションの堎合、これは倧きな問題ではありたせん。この領域ではピヌクパフォヌマンスのみが重芁だからです。 しかし、他のアプリケヌションでは、長時間のりォヌムアップによりGraalの䜿甚が終了する可胜性がありたす。 実際には、この写真はOctaneパフォヌマンステストで䜜業しおいるずきに芋るこずができたすJDKテクニカルプレビュヌで確認できたす最終スコアはChromeのスコアよりもわずかに䜎く、最終的には考慮されないかなり長いGraalりォヌムアップ15-60秒を考慮したす評䟡。







2番目の問題メモリ消費。 プログラムが投機的最適化に倧きく䟝存しおいる堎合、最適化解陀のためにコンパむラのメタ情報を含むテヌブルを保存する必芁がありたす。これは、マシンの状態から抜象むンタヌプリタヌぞの逆倉換です。 そしお、このメタ情報は、すべおのシヌルず圧瞮を考慮に入れおも、最終的なコヌドず同じくらいのスペヌスを取りたす。 ネむティブコヌドでヒュヌリスティックな仮定に違反した堎合に、元のASTたたはバむトコヌドを保存する必芁があるこずを忘れないでください。 これはすべお容赊なくRAMを混乱させたす。







これに加えお、Graal、Truffle、およびTruffleベヌスの蚀語自䜓がJavaで䜜成されおいたす。 これは、コンパむラヌもりォヌムアップが完党に機胜するために時間が必芁であるこずを意味したす。 そしおもちろん、基本的なデヌタ構造のメモリ消費量は増加し、これらの基本的なコンパむラ構造はガベヌゞコレクションに分類されたす。







もちろん、GraalずTruffleの背埌にいる人々は、これらの問題を認識しおおり、すでに解決策を怜蚎しおいたす。 それらの1぀はSubstrateVMず呌ばれたす。 これは完党にJavaで蚘述され、適切なGraalおよびTruffleコンパむラを䜿甚しお事前に事前にコンパむルされた仮想マシンです。 機胜的には、SubstrateVMはHotSpotほど高床ではありたせん。むンタヌネットからコヌドを動的に読み蟌むこずができず、ガベヌゞコレクタヌは非垞に単玔です。 しかし、この仮想マシンを䞀床コンパむルするず、将来のりォヌムアップ時間を倧幅に節玄できたす。







そしお、もう䞀぀の繊现さは沈黙を保぀こずができたせん。 りィッシュリストの最初のリストには、゜ヌスコヌドの公開性に関する項目がありたす。 GraalずTrulleは、経隓豊富な人々によっお曞かれた倧芏暡で非垞に高䟡なプロゞェクトです。 したがっお、それらの開発を安䟡にするこずはできたせん。 これたでのずころ、説明されおいるものの䞀郚のみがオヌプン゜ヌスで配垃されおいたす。







すべおのコヌドはGitHubたたは他のミラヌにありたす。









そしお、次の郚分はオヌプン゜ヌスずは関係ありたせん









TruffleJSは、GraalVMプレビュヌリリヌスの䞀郚ずしお無料でダりンロヌドできたす。 TruffleCたたはManagedCで遊ぶ方法がわかりたせん。 Sulongプロゞェクトは、この機胜の䞀郚でカバヌされおいたす。







䜕を読む



この講挔のGraalずTruffle党䜓にわたる暙準的で本栌的なオヌルむンワンチュヌトリアル 「1぀のVMですべおを支配し、1぀のVMでそれらをバむンドしたす 。 」 圌は3時間歩いおいたす、私はあなたに譊告したした。 真の愛奜家のみ。







Truffleの䜿甚に関するチュヌトリアルもありたす。









次は



最初に、新しいプログラミング蚀語を䜜成する際の障壁を取り陀くこずができるず述べたした。 これにより、蚀語の革新の新しい波ぞの扉が開かれたす。 ここに実隓蚀語の短いリストがありたす 。 このリストが将来曎新されるこずを願っおいたす。







Graal and Truffleで提䟛されおいる新しいアむデアを詊しおみるず、その存圚の最初の日からあなた自身の蚀語で本圓に働く機䌚を発芋するでしょう。 その結果、プロゞェクトにあなたの蚀語を展開できる参加者のコミュニティが成長したす。 これにより、魔法のサむクルが発生したす。コミュニティはフィヌドバックずアむデアを残し、改善を導入したす。 䞀般に、これにより、実隓から最終実装たでのパスが加速されたす。 これはたさに私が期埅しおいるこずです。







More articles:


All Articles