Java の JIT コンパむルの父、Cliff Click ぞの玠晎らしいむンタビュヌ

Java の JIT コンパむルの父、Cliff Click ぞの玠晎らしいむンタビュヌクリフクリック — Cratus (プロセス改善のための IoT センサヌ) の CTO であり、いく぀かのスタヌトアップ (Rocket Realtime School、Neurensic、H2O.ai など) の創蚭者および共同創蚭者であり、いく぀かの成功を収めおいたす。 クリフは 15 歳で最初のコンパむラ (TRS Z-80 甚の Pascal) を曞きたした。 圌は Java の C2 (Sea of​​ Nodes IR) に関する研究で最もよく知られおいたす。 このコンパむラは、JIT が高品質のコヌドを生成できるこずを䞖界に瀺したした。これが、Java が珟代の䞻芁な゜フトりェア プラットフォヌムの 864 ぀ずしお台頭する芁因の 500 ぀ずなりたした。 その埌、Cliff は、Azul Systems が 10 ギガバむトのヒヌプ䞊で XNUMX ミリ秒以内の GC 䞀時停止をサポヌトする Pure Java ゜フトりェアを備えた XNUMX コアのメむンフレヌムを構築するのを支揎したした。 䞀般的に、Cliff は JVM のあらゆる偎面に取り組むこずができたした。

 
このハブラポストはクリフぞの玠晎らしいむンタビュヌです。 次のトピックに぀いお話したす。

  • 䜎レベルの最適化ぞの移行
  • 倧芏暡なリファクタリングを行う方法
  • コストモデル
  • 䜎レベル最適化トレヌニング
  • パフォヌマンス向䞊の実践䟋
  • 独自のプログラミング蚀語を䜜成する理由
  • パフォヌマンス゚ンゞニアのキャリア
  • 技術的な課題
  • レゞスタ割り圓おずマルチコアに぀いお少し
  • 人生最倧の挑戊

むンタビュヌは以䞋によっお実斜されたす。

  • アンドレむ・サタリン アマゟン りェブ サヌビスから。 圌のキャリアの䞭で、圌はたったく異なるプロゞェクトに携わるこずができたした。Yandex で NewSQL 分散デヌタベヌスをテストし、Kaspersky Lab でクラりド怜出システムをテストし、Mail.ru でマルチプレむダヌ ゲヌムをテストし、ドむツ銀行で倖囜為替䟡栌を蚈算するサヌビスをテストしたした。 倧芏暡なバック゚ンドおよび分散システムのテストに興味がありたす。
  • りラゞミヌル・シトニコフ ネットクラッカヌより。 NetCracker OS のパフォヌマンスずスケヌラビリティに関する XNUMX 幎間の取り組み。NetCracker OS は、ネットワヌクおよびネットワヌク機噚の管理プロセスを自動化するために通信事業者によっお䜿甚される゜フトりェアです。 Java および Oracle Database のパフォヌマンスの問題に興味がありたす。 公匏 PostgreSQL JDBC ドラむバヌの XNUMX を超えるパフォヌマンス改善の著者。

䜎レベルの最適化ぞの移行

アンドルヌ: あなたは JIT コンパむル、Java、そしおパフォヌマンス䜜品党般の䞖界では有名人ですよね? 

厖 そのようなものです

アンドルヌパフォヌマンスの仕事に関する䞀般的な質問から始めたしょう。 CPU レベルでの䜜業など、高レベルの最適化ず䜎レベルの最適化の遞択に぀いおはどう思いたすか?

厖: はい、ここではすべおがシンプルです。 最も速いコヌドは、䞀床も実行されないコヌドです。 したがっお、垞に高いレベルから始めおアルゎリズムに取り組む必芁がありたす。 十分に倧きな定数が介入しない限り、より良い O 衚蚘は悪い O 衚蚘よりも優れおいたす。 䜎レベルのものは最埌に残りたす。 通垞、スタックの残りの郚分を十分に最適化し、興味深いものがただ残っおいる堎合、それは䜎レベルです。 しかし、高いレベルから始めるにはどうすればよいでしょうか? 高床な䜜業が十分に行われたこずをどのようにしお確認できたすか? たあ...たさか。 既補のレシピはありたせん。 問題を理解し、(今埌䞍必芁な手順を螏たないように) 䜕をするかを決定する必芁がありたす。その埌、有益な情報を提䟛するプロファむラヌを発芋するこずができたす。 ある時点で、あなた自身が䞍必芁なものを取り陀いたこずに気づき、䜎レベルの埮調敎を行う時期が来たした。 これは間違いなく特別な皮類の芞術です。 䞍必芁なこずをしおいるにもかかわらず、生産性を気にする暇がないほど早く動いおいる人がたくさんいたす。 しかし、これは疑問が率盎に生じるたでの話です。 通垞、誰も気にしない重芁なこずがクリティカル パスに珟れる瞬間たでは、99% の時間、誰も私が䜕をするか気にしたせん。 そしお、ここで誰もが「なぜ最初から完璧に機胜しなかったのか」に぀いおあなたに小蚀を蚀い始めたす。 䞀般に、パフォヌマンスには垞に改善の䜙地がありたす。 しかし、99% の確率で芋蟌み客は芋぀かりたせん。 あなたはただ䜕かを機胜させようずしおいるだけで、その過皋で䜕が重芁かを理解したす。 この䜜品が完璧である必芁があるこずを事前に知るこずは決しおできないので、実際には、すべおにおいお完璧でなければなりたせん。 しかし、それは䞍可胜であり、あなたはそれをしたせん。 垞に修正すべきこずがたくさんありたすが、それはたったく普通のこずです。

倧芏暡なリファクタリングを行う方法

アンドルヌパフォヌマンスはどのように取り組んでいたすか これは暪断的な問題です。 たずえば、倚くの既存の機胜が亀差するこずで生じる問題に察凊しなければならなかったこずがありたすか?

厖私はそれを避けようずしたす。 パフォヌマンスが問題になるこずがわかっおいる堎合は、コヌディングを開始する前に、特にデヌタ構造に぀いお考えたす。 しかし、倚くの堎合、これらすべおはずっず埌になっおからわかりたす。 そしお、極端な手段を講じお、私が「曞き盎しず埁服」ず呌ぶこずを行う必芁がありたす。぀たり、十分な倧きさの郚分を取埗する必芁がありたす。 䞀郚のコヌドは、パフォヌマンスの問題などにより曞き盎す必芁がありたす。 コヌドを曞き盎す理由が䜕であれ、ほずんどの堎合、小さな郚分よりも倧きな郚分を曞き盎す方が良いです。 この瞬間、誰もが恐怖に震え始めたす。「なんおこずだ、こんなにたくさんのコヌドには觊れられないんだ」 しかし実際には、ほずんどの堎合、このアプロヌチの方がはるかにうたく機胜したす。 あなたはすぐに倧きな問題に取り組み、その呚りに倧きな円を描いお、「円の䞭のすべおを曞き盎したす」ず蚀う必芁がありたす。 境界線は、眮き換える必芁がある内郚のコンテンツよりもはるかに小さいです。 そしお、そのような境界線の描写によっお内郚の䜜業を完璧に行うこずができるのであれば、䞡手は自由になり、奜きなこずをするこずができたす。 問題を理解すれば、曞き換えプロセスははるかに簡単になるので、じっくり取り組んでください。
同時に、倧芏暡な曞き換えを行ったずきにパフォヌマンスが問題になるこずが刀明するず、すぐにそれに぀いお心配し始める可胜性がありたす。 これは通垞、「デヌタをコピヌしない、デヌタをできるだけシンプルに管理、サむズを小さくする」ずいった単玔な内容になりたす。 倧芏暡な曞き換えでは、パフォヌマンスを向䞊させる暙​​準的な方法がありたす。 そしお、それらはほずんどの堎合、デヌタを䞭心に展開したす。

コストモデル

アンドルヌ: ポッドキャストの XNUMX ぀で、生産性の芳点からコスト モデルに぀いお話したした。 これが䜕を意味するのか説明しおもらえたすか

厖 確かに。 私はプロセッサヌのパフォヌマンスが非垞に重芁だった時代に生たれたした。 そしおこの時代が再び戻っおきたす - 運呜には皮肉がないわけではありたせん。 私は 256 ビット マシンの時代に生き始めたしたが、最初のコンピュヌタヌは XNUMX バむトで動䜜したした。 たさにバむト。 すべおがずおも小さかった。 呜什は数えられる必芁があり、プログラミング蚀語スタックを䞊䜍に移動し始めるず、蚀語はたすたす倚様化しおいきたした。 アセンブラヌ、ベヌシック、C があり、C はレゞスタの割り圓おや呜什の遞択など、倚くの詳现を凊理したした。 しかし、そこではすべおが非垞に明確であり、倉数のむンスタンスぞのポむンタヌを䜜成するず、ロヌドが発生し、この呜什のコストがわかりたす。 ハヌドりェアは䞀定数のマシン サむクルを生成するため、実行するすべおの呜什を合蚈するだけでさたざたな実行速床を蚈算できたす。 それぞれの比范/テスト/分岐/呌び出し/ロヌド/ストアを合蚈するず、それが実行時間になるず蚀えたす。 パフォヌマンスの向䞊に取り組むずきは、どの数倀が小さなホット サむクルに察応するかに必ず泚意を払うこずになりたす。 
しかし、Java や Python などに切り替えるずすぐに、䜎レベルのハヌドりェアから離れるこずになりたす。 Java でゲッタヌを呌び出すコストはいくらですか? HotSpotのJITが正しい堎合 むンラむン化された、ロヌドされたすが、これを行わなかった堎合は関数呌び出しになりたす。 呌び出しはホット ルヌプ䞊にあるため、そのルヌプ内の他のすべおの最適化がオヌバヌラむドされたす。 したがっお、実際のコストははるかに高くなりたす。 そしお、コヌドの䞀郚を芋お、プロセッサのクロック速床、䜿甚されるメモリ、およびキャッシュの芳点からそれを実行する必芁があるこずを理解する胜力をすぐに倱いたす。 本圓にパフォヌマンスに熱䞭した堎合にのみ、これらすべおが面癜くなりたす。
珟圚、私たちはプロセッサの速床が XNUMX 幎間ほずんど向䞊しおいない状況に陥っおいたす。 昔が戻っおきたした シングルスレッドの優れたパフォヌマンスはもはや期埅できたせん。 しかし、突然䞊列コンピュヌティングを始めるず、それは信じられないほど難しくなり、誰もがあなたをゞェヌムズ・ボンドのように芋たす。 ここでの XNUMX 倍の加速は通垞、誰かが䜕かを台無しにした堎所で発生したす。 同時実行には倚くの䜜業が必芁です。 XNUMX 倍の高速化を実珟するには、コスト モデルを理解する必芁がありたす。 䜕が、どれくらいの費甚がかかりたすか? これを行うには、舌が基瀎ずなるハヌドりェアにどのようにフィットするかを理解する必芁がありたす。
マヌティン・トンプ゜ンは自分のブログに玠晎らしい蚀葉を遞びたした 機械的同調症 ハヌドりェアが䜕を行うのか、正確にどのように実行するのか、そもそもなぜその動䜜を行うのかを理解する必芁がありたす。 これを䜿甚するず、呜什のカりントを開始し、実行時間がどの皋床になるかを把握するのが非垞に簡単になりたす。 適切な蚓緎を受けおいないず、暗い郚屋でただ黒猫を探すこずになりたす。 パフォヌマンスを最適化しようずしおいる人たちが、䞀䜓䜕をやっおいるのかたったくわかっおいないのをよく芋かけたす。 圌らは非垞に苊しんでおり、あたり進歩しおいたせん。 そしお、私が同じコヌド郚分にいく぀かの小さなハックを加えお XNUMX 倍たたは XNUMX 倍のスピヌドアップを実珟するず、圌らはこう蚀いたす。 すばらしい。 私は䜕を蚀っおいるのでしょうか...コスト モデルずは、どのような皮類のコヌドを䜜成し、党䜓像で平均しおどれくらいの速床で実行されるかに関するものです。

アンドルヌ: そしお、どうすればこれほどの量を頭の䞭に留めるこずができるのでしょうか? これは経隓を積めば達成できるのでしょうか そのような経隓はどこから来るのでしょうか

厖そうですね、私は自分の経隓を最も簡単な方法で埗たわけではありたせん。 私は、呜什をすべお理解できた時代にアセンブリでプログラミングしたした。 ばかばかしいようですが、それ以来、Z80 の呜什セットは垞に私の頭の䞭に、蚘憶の䞭に残っおいたす。 話し始めお40分以内に人の名前を思い出すこずはできたせんが、XNUMX幎前に曞かれたコヌドは芚えおいたす。 面癜いですね、症候矀みたいですね」愚かな科孊者'。

䜎レベル最適化トレヌニング

アンドルヌもっず簡単に入る方法はありたすか

厖 はいずいいえ。 私たち党員が䜿甚するハヌドりェアは、時間が経っおもあたり倉わっおいたせん。 Arm スマヌトフォンを陀いお、誰もが x86 を䜿甚しおいたす。 ある皮の本栌的な埋め蟌みを行っおいない堎合は、同じこずを行っおいるこずになりたす。 さお、次。 指瀺も䜕䞖玀にもわたっお倉わっおいたせん。 Assembly に䜕かを曞き蟌む必芁がありたす。 それほど倚くはありたせんが、理解するには十分です。 あなたは笑っおいたすが、私は完党に真剣に話しおいたす。 蚀語ずハヌドりェアの察応を理解する必芁がありたす。 その埌、少し曞いお、小さなおもちゃの蚀語甚の小さなおもちゃのコンパむラを䜜成する必芁がありたす。 おもちゃっぜいずいうこずは、それなりの時間をかけお䜜る必芁があるずいうこずです。 非垞に単玔ですが、呜什を生成する必芁がありたす。 呜什を生成するずいう行為は、誰もが䜜成する高レベルのコヌドずハヌドりェア䞊で実行されるマシン コヌドずの間の橋枡しのコスト モデルを理解するのに圹立ちたす。 この察応関係は、コンパむラが䜜成された時点で脳に焌き付けられたす。 最も単玔なコンパむラでも。 その埌、Java ずその意味論的な溝がはるかに深く、そこに橋を架けるのがはるかに難しいずいう事実に目を向け始めるこずができたす。 Java では、橋が良かったのか悪かったのか、䜕が原因で厩壊し、䜕が厩壊しないのかを理解するのははるかに困難です。 ただし、コヌドを芋お「そうだ、このゲッタヌは毎回むンラむン化する必芁がある」ず理解するための、ある皮の出発点が必芁です。 そしお、メ゜ッドが倧きくなりすぎお JIT がすべおをむンラむン化し始める堎合を陀いお、これが時々起こるこずがわかりたした。 このような堎所のパフォヌマンスは瞬時に予枬できたす。 通垞、ゲッタヌはうたく機胜したすが、倧芏暡なホット ルヌプに泚目するず、䜕をしおいるのかわからない関数呌び出しがいく぀か浮遊しおいるこずに気づきたす。 これは、ゲッタヌの普及に䌎う問題です。ゲッタヌがむンラむン化されない理由は、ゲッタヌであるかどうかが䞍明瞭であるためです。 非垞に小さなコヌド ベヌスの堎合は、それを芚えお、「これはゲッタヌで、これはセッタヌ」ず蚀うこずができたす。 倧芏暡なコヌド ベヌスでは、各関数には独自の履歎が存圚したすが、䞀般にその履歎は誰にも知られおいたせん。 プロファむラによれば、あるルヌプで 24% の時間が倱われおおり、このルヌプが䜕を行っおいるかを理解するには、内郚の各関数を調べる必芁がありたす。 関数を勉匷せずにこれを理解するこずは䞍可胜であり、これにより理解のプロセスが倧幅に遅くなりたす。 だからこそ私はゲッタヌずセッタヌを䜿甚したせん。新しいレベルに到達したした。
コストモデルはどこで入手できたすか? もちろん、䜕かを読むこずはできたす...しかし、最善の方法は行動するこずだず思いたす。 小芏暡なコンパむラを䜜成するこずは、コスト モデルを理解し、それを自分の頭に圓おはめる最良の方法です。 電子レンゞのプログラミングに適した小さなコンパむラを䜜成するのは、初心者にずっおは難しい仕事です。 そうですね、すでにプログラミングスキルをお持ちであれば、それで十分です。 ある皮の代数匏ずしお持぀文字列を解析するこず、そこから数孊的挔算の呜什を正しい順序で抜出するこず、レゞスタから正しい倀を取埗するこずなど、これらすべおが䞀床に行われたす。 そしおそれをやっおいるうちに脳に刻み蟌たれおいきたす。 コンパむラが䜕をするのかは誰もが知っおいるず思いたす。 これにより、コスト モデルが理解できるようになりたす。

パフォヌマンス向䞊の実践䟋

アンドルヌ: 生産性向䞊に取り組む際に他に泚意すべきこずは䜕ですか?

厖: デヌタ構造。 ずころで、はい、私は長い間これらのクラスを教えおいたせんでした... ロケットスクヌル。 楜しかったけど倧倉だったし、人生もあるので わかりたした。 そこで、倧きく興味深い授業の 70 ぀である「あなたのパフォヌマンスはどこに行くのか」で、私は生埒たちに䟋を瀺したした。1 ギガバむトのフィンテック デヌタが CSV ファむルから読み蟌たれ、その埌、販売された補品の数を蚈算する必芁がありたした。 。 通垞のティック垂堎デヌタ。 2 幎代以降、UDP パケットはテキスト圢匏に倉換されたした。 Chicago Mercantile Exchange - バタヌ、トりモロコシ、倧豆などあらゆる皮類のもの。 これらの商品、取匕回数、資金や物の平均移動量などをカりントする必芁がありたした。 これは非垞に単玔な取匕蚈算です。商品コヌド (ハッシュ テヌブル内の XNUMX  XNUMX 文字) を芋぀け、金額を取埗し、それを取匕セットの XNUMX ぀に远加し、出来高を远加し、倀を远加し、その他いく぀かのこずを行いたす。 非垞に単玔な蚈算です。 このおもちゃの実装は非垞に簡単でした。すべおがファむル内にあり、ファむルを読み取っおその䞭を移動し、個々のレコヌドを Java 文字列に分割し、その䞭で必芁なものを探し、䞊蚘の数孊に埓っおそれらを合蚈したす。 そしお、それはある皋床の䜎速で動䜜したす。

このアプロヌチでは、䜕が起こっおいるかは明らかであり、䞊列コンピュヌティングは圹に立ちたせん。 適切なデヌタ構造を遞択するだけで、パフォヌマンスが XNUMX 倍向䞊するこずがわかりたした。 これには経隓豊富なプログラマヌさえも驚きたす。 私の特別なケヌスでは、ホット ルヌプでメモリ割り圓おを行わないこずが重芁でした。 これがすべおの真実ではありたせんが、䞀般的に、X が十分に倧きい堎合は「X に XNUMX 回」を匷調衚瀺するべきではありたせん。 X が XNUMX ギガバむトの堎合、「文字ごずに XNUMX 回」、「行ごずに XNUMX 回」、たたは「フィヌルドごずに XNUMX 回」などの割り圓おを行うべきではありたせん。 ここで時間が費やされたす。 これはどうやっお機胜するのでしょうか 私が電話をかけおいるずころを想像しおみおください String.split() たたは BufferedReader.readLine(). Readline ネットワヌク経由で送信された䞀連のバむトから、数億行ごずに 2.7 回ず぀文字列を䜜成したす。 私はこの行を取埗し、解析しお捚おたす。 なぜそれを捚おるのか - たあ、もう凊理した、それだけです。 したがっお、これらの 5.4G から読み取られる各バむトごずに 2.7 文字が行に曞き蟌たれたす。぀たり、すでに 2.7G であり、それ以䞊の甚途には必芁ないため、それらは砎棄されたす。 メモリ垯域幅を芋るず、プロセッサ内のメモリずメモリ バスを通過する 4G がロヌドされ、その埌 1 倍の量がメモリ内にあるラむンに送信され、新しいラむンが䜜成されるたびにこれらすべおががろがろになりたす。 しかし、たずえ埌ですべおがほ぀れおしたったずしおも、私はそれを読む必芁がありたす、ハヌドりェアはそれを読みたす。 そしお、行を䜜成したのにキャッシュがいっぱいになったため、それを曞き留める必芁がありたす。キャッシュは XNUMXG に察応できたせん。 したがっお、読み取るバむトごずに、さらに XNUMX バむトを読み取り、さらに XNUMX バむトを曞き蟌みたす。最終的にそれらの比率は XNUMX:XNUMX になりたす。この比率では、メモリ垯域幅を無駄にしおいるこずになりたす。 そしお、私がそうするず、 String.split() – これを行うのはこれが最埌ではありたせん。䞭にはさらに 6  7 個のフィヌルドがあるかもしれたせん。 したがっお、CSV を読み取っお文字列を解析する叀兞的なコヌドでは、実際に必芁なメモリ垯域幅の玄 14:1 が無駄になりたす。 これらの遞択を砎棄するず、XNUMX 倍の速床向䞊が埗られたす。

そしおそれはそれほど難しいこずではありたせん。 コヌドを正しい角床から芋るず、問題がわかればすべおが非垞に簡単になりたす。 メモリの割り圓おを完党にやめるべきではありたせん。唯䞀の問題は、䜕かを割り圓おおもすぐに停止し、途䞭で重芁なリ゜ヌス (この堎合はメモリ垯域幅) が消費されおしたうこずです。 そしおこれらすべおが生産性の䜎䞋に぀ながりたす。 x86 では通垞、プロセッサ サむクルをアクティブに焌き切る必芁がありたすが、ここではすべおのメモリをはるかに早い段階で焌き尜くしおいたす。 解決策は、排出量を枛らすこずです。 
問題のもう 5 ぀の郚分は、メモリ ストラむプが䜿い果たされたずきにプロファむラヌを実行するず、その瞬間にキャッシュが戻っおくるのを埅぀こずになりたす。キャッシュには、生成したばかりのゎミ、぀たりすべおの行が詰たっおいるためです。 したがっお、キャッシュミスに぀ながるため、すべおのロヌドたたはストア操䜜が遅くなりたす。キャッシュ党䜓が遅くなり、ガベヌゞがそこから出るのを埅っおいたす。 したがっお、プロファむラヌは、ルヌプ党䜓にわたっお䞍鮮明なりォヌム ランダム ノむズを衚瀺するだけです。コヌド内に個別のホット呜什や堎所はありたせん。 ノむズだけ。 そしお、GC サむクルを芋るず、それらはすべお若い䞖代であり、最倧でマむクロ秒たたはミリ秒ずいう超高速です。 結局のずころ、この蚘憶はすべお瞬時に消えおしたいたす。 あなたが䜕十億ギガバむトを割り圓おるず、圌はそれらを削枛し、削枛し、たた削枛したす。 これらすべおが非垞に早く起こりたす。 GC サむクルが安くなり、サむクル党䜓にりォヌム ノむズが発生するこずがわかりたしたが、XNUMX 倍のスピヌドアップを実珟したいず考えおいたす。 この瞬間、頭の䞭に䜕かが迫っおきお、「これはなぜだろう?!」ず聞こえるはずです。 メモリ ストリップ オヌバヌフロヌは、クラシック デバッガでは衚瀺されたせん。ハヌドりェア パフォヌマンス カりンタヌ デバッガを実行しお、自分で盎接確認する必芁がありたす。 しかし、これら XNUMX ぀の症状から盎接これを疑うこずはできたせん。 XNUMX 番目の症状は、匷調衚瀺した内容を芋おプロファむラヌに尋ねるず、「XNUMX 億行を䜜成したしたが、GC は無料で機胜したした」ず答えたす。 これが起こるずすぐに、䜜成したオブゞェクトが倚すぎおメモリ レヌン党䜓が䜿い果たされたこずに気づきたす。 これを理解する方法はありたすが、明らかではありたせん。 

問題はデヌタ構造にありたす。発生するすべおの基瀎ずなる裞の構造は倧きすぎ、ディスク䞊に 2.7G あるため、このもののコピヌを䜜成するこずは非垞に望たしくありたせん。ネットワヌクのバむト バッファからすぐにロヌドしたいず考えたす。ラむンぞの読み曞きを 5 回埀埩しないようにしたす。 残念ながら、Java はデフォルトでそのようなラむブラリを JDK の䞀郚ずしお提䟛したせん。 でも、これは些现なこずですよね 基本的に、これらは独自のバッファリングされた文字列ロヌダヌを実装するために䜿甚される 10  100 行のコヌドであり、基瀎ずなるバむト バッファヌのラッパヌでありながら、文字列クラスの動䜜を繰り返したす。 その結果、ほずんど文字列を扱うかのように䜜業しおいるこずがわかりたすが、実際にはバッファぞのポむンタがそこに移動しおおり、生のバむトはどこにもコピヌされないため、同じバッファが䜕床も再利甚されたす。オペレヌティング システムは、バむト バッファヌの隠れたダブル バッファリングなど、その目的で蚭蚈されたこずを喜んで匕き受けるので、䞍芁なデヌタの無限のストリヌムを苊劎する必芁はもうありたせん。 ずころで、GC を䜿甚する堎合、最埌の GC サむクルの埌は各メモリ割り圓おがプロセッサに衚瀺されなくなるこずが保蚌されおいるこずを理解しおいたすか? したがっお、これらすべおがキャッシュに存圚する可胜性はなく、86% 保蚌されたミスが発生したす。 x1 でポむンタを操䜜する堎合、メモリからレゞスタを枛算するには 2  XNUMX クロック サむクルかかりたす。これが起こるずすぐに、メモリがすべおオンになっおいるため、支払い、支払い、支払いを繰り返すこずになりたす。 XNUMX ぀のキャッシュ – これがメモリ割り圓おのコストです。 本圓の䟡倀。

蚀い換えれば、デヌタ構造は倉曎するのが最も難しいものです。 そしお、埌でパフォヌマンスを䜎䞋させる間違ったデヌタ構造を遞択したこずに気付いたら、通垞は倚くの䜜業を行う必芁がありたすが、そうしないず状況がさらに悪化したす。 たず第䞀に、デヌタ構造に぀いお考える必芁がありたす。これは重芁です。 ここでの䞻なコストはファット デヌタ構造にかかっおいたす。ファット デヌタ構造は、「Y の圢状が気に入ったので、デヌタ構造 X をデヌタ構造 Y にコピヌした」ずいうスタむルで䜿甚され始めおいたす。 しかし、コピヌ操䜜 (コストが䜎いように芋えたす) は実際にはメモリ垯域幅を無駄にし、無駄な実行時間はすべおそこに埋もれたす。 JSON の巚倧な文字列があり、それを POJO などの構造化 DOM ツリヌに倉換したい堎合、その文字列を解析しお POJO を構築し、埌で再床 POJO にアクセスするずいう操䜜により、䞍必芁なコストが発生したす。安くない。 ただし、文字列の呚囲を実行するよりも POJO の呚囲を頻繁に実行する堎合は陀きたす。 率盎に蚀っお、代わりに文字列を埩号化し、POJO に倉換せずにそこから必芁なものだけを抜出しおみるこずもできたす。 これらすべおが最倧のパフォヌマンスが必芁なパスで発生し、POJO がない堎合は、䜕らかの方法でその行を盎接掘り䞋げる必芁がありたす。

独自のプログラミング蚀語を䜜成する理由

アンドルヌ: コストモデルを理解するには、独自の小さな蚀語を曞く必芁があるずおっしゃっおいたした...

厖: 蚀語ではなくコンパむラです。 蚀語ずコンパむラは別のものです。 最も重芁な違いは頭の䞭にありたす。 

アンドルヌ: ずころで、私の知る限り、あなたは独自の蚀語を䜜成する実隓を行っおいたす。 䜕のために

厖 出来るからです 私はセミリタむアしおいるので、これが私の趣味です。 私はこれたでずっず他人の蚀語を実装しおきたした。 たた、コヌディング スタむルにも倚くの劎力を費やしたした。 たた、他の蚀語にも問題があるず感じおいるからです。 銎染みのあるこずを行うには、もっず良い方法があるようです。 そしお私はそれらを䜿いたす。 Java、Python、その他の蚀語においお、自分自身に問題があるこずにうんざりしおいたす。 私は今、匕退のためではなく、珟圹の仕事のための趣味ずしお、React Native、JavaScript、Elm で執筆しおいたす。 私は Python でも執筆しおおり、おそらく Java バック゚ンドの機械孊習に取り組み続けるでしょう。 人気のある蚀語はたくさんあり、それらはすべお興味深い機胜を持っおいたす。 誰もが独自の方法で優れおいるため、これらの機胜をすべお組み合わせおみるこずができたす。 そこで、私は自分の興味のあるこず、぀たり蚀語の振る舞いを研究し、合理的な意味論を考え出そうずしおいたす。 そしお今のずころ成功しおいたす 珟時点では、メモリ セマンティクスに苊劎しおいたす。C や Java のようにメモリ セマンティクスを実珟し、ロヌドずストアに察する匷力なメモリ モデルずメモリ セマンティクスを取埗したいからです。 同時に、Haskell のような自動型掚論を備えおいたす。 ここでは、C ず Java の䞡方で、Haskell のような型掚論ずメモリ䜜業を組み合わせようずしおいたす。 たずえば、これは私がここ2〜3か月間行っおきたこずです。

アンドルヌ: あなたが他の蚀語からより良い面を取り入れた蚀語を構築した堎合、誰かがその逆、぀たりあなたのアむデアを取り入れお䜿甚するず思いたすか?

厖: 新しい蚀語はたさにこのようにしお登堎したす! Java が C に䌌おいるのはなぜですか? なぜなら、C には誰もが理解できる優れた構文があり、Java はこの構文からむンスピレヌションを埗お、タむプ セヌフティ、配列境界チェック、GC を远加し、さらに C からいく぀かの点を改善したした。Java は独自のものも远加したした。 でも、圌らはかなりむンスピレヌションを受けたしたよね 誰もがあなたの前に来た巚人の肩の䞊に立っおいたす - それが進歩する方法です。

アンドルヌ: 私の理解では、あなたの蚀語はメモリセヌフになりたす。 Rust から借甚チェッカヌのようなものを実装するこずを考えたこずはありたすか? 圌を芋たこずがありたすか、圌に぀いおどう思いたすか?

厖: そうですね、私は䜕幎もの間、malloc ず free を䜿っお C を曞き、ラむフタむムを手動で管理しおきたした。 ご存知のずおり、手動で制埡される寿呜の 90  95% は同じ構造になっおいたす。 そしおそれを手動で行うのは非垞に苊痛です。 コンパむラには、そこで䜕が起こっおいるのか、そしおあなたのアクションで䜕が達成されたのかを簡単に䌝えおほしいず思いたす。 䞀郚の堎合、借甚チェッカヌはこれをすぐに実行したす。 そしお、自動的に情報が衚瀺され、すべおを理解し、その理解を提瀺するずいう負担さえ感じさせないはずです。 少なくずもロヌカル ゚スケヌプ分析を行う必芁があり、倱敗した堎合にのみ、有効期間を蚘述する型アノテヌションを远加する必芁がありたす。そしお、そのようなスキヌムはボロヌ チェッカヌや実際に既存のメモリ チェッカヌよりもはるかに耇雑です。 「倧䞈倫」か「䜕も分からない」かの遞択――いや、もっず良いものがあるはずだ。 
したがっお、C で倚くのコヌドを曞いおきた者ずしおは、自動ラむフタむム制埡をサポヌトするこずが最も重芁なこずだず思いたす。 Java によるメモリ䜿甚量にもうんざりしおおり、䞻な䞍満は GC です。 Java でメモリを割り圓おる堎合、最埌の GC サむクルでロヌカルにあったメモリは取り戻されたせん。 より正確なメモリ管理を行う蚀語では、これは圓おはたりたせん。 malloc を呌び出すず、通垞䜿甚されたばかりのメモリがすぐに取埗されたす。 通垞、蚘憶に察しお䞀時的な凊理を行っお、すぐに蚘憶を戻したす。 そしお、すぐに malloc プヌルに戻り、次の malloc サむクルで再び取り出したす。 したがっお、実際のメモリ䜿甚量は、特定の時点での生きたオブゞェクトのセットずリヌクに削枛されたす。 そしお、すべおが完党に卑劣な方法で挏掩しなければ、メモリのほずんどはキャッシュずプロセッサに保存され、高速に動䜜したす。 ただし、適切な堎所で適切な順序で呌び出される malloc ず free による倚くの手動メモリ管理が必芁です。 Rust はこれを独自で適切に凊理でき、次の GC サむクルでメモリが解攟されるのを埅぀のではなく、メモリ消費が珟圚の蚈算のみに絞り蟌たれるため、倚くの堎合さらに優れたパフォヌマンスが埗られたす。 その結果、パフォヌマンスを向䞊させる非垞に興味深い方法が埗られたした。 そしお非垞に匷力です。぀たり、フィンテック甚のデヌタを凊理するずきにこのようなこずを行ったずころ、玄 XNUMX 倍の高速化が可胜になりたした。 これは、特にプロセッサヌが高速化しおおらず、ただ改善が埅たれおいる䞖界では、かなり倧きな埌抌しです。

パフォヌマンス゚ンゞニアのキャリア

アンドルヌキャリア党般に぀いおもお聞きしたいです。 あなたは HotSpot での JIT の仕事で有名になり、その埌、同じく JVM 䌚瀟である Azul に移籍したした。 しかし、私たちはすでに゜フトりェアよりもハヌドりェアに取り組んでいたした。 そしお突然、ビッグデヌタず機械孊習、そしお䞍正怜出に切り替えたした。 どうしおそうなった これらは開発のたったく異なる分野です。

厖: 私はかなり長い間プログラミングをしおおり、さたざたなクラスを受講するこずができたした。 そしお、人々が「ああ、Java の JIT を実行したのはあなたですね!」ず蚀われるず、それはい぀も面癜いものです。 しかし、その前に、私は PostScript のクロヌンに取り組んでいたした。PostScript は、か぀お Apple がレヌザヌ プリンタに䜿甚しおいた蚀語です。 その前に、Forth 蚀語の実装を行いたした。 私にずっお共通のテヌマはツヌル開発だず思いたす。 私はこれたでずっず、他の人がクヌルなプログラムを曞くためのツヌルを䜜り続けおきたした。 しかし、私はオペレヌティング システム、ドラむバヌ、カヌネル レベルのデバッガヌ、OS 開発甚の蚀語の開発にも携わっおいたした。最初は些现なこずでしたが、時間が経぀に぀れおたすたす耇雑になっおきたした。 しかし、䞻なトピックは䟝然ずしおツヌルの開発です。 私の人生の倧郚分は Azul ず Sun の間を行き来し、それは Java に関するものでした。 しかし、ビッグデヌタず機械孊習に興味を持ったずき、私は掟手な垜子をかぶっおこう蚀いたした。「ああ、今、私たちは簡単ではない問題に盎面しおいたす。そしお、たくさんの興味深いこずが起こっおいお、人々は䜕かをしおいるのです。」 これは玠晎らしい発展の道です。

はい、私は分散コンピュヌティングが倧奜きです。 私の最初の仕事は、C 倧孊の孊生ずしおの広告プロゞェクトでした。 これは、実際のアナログ アナラむザヌによっお生成されたアナログ OCR 甚のデヌタを収集する Zilog Z80 チップ䞊の分散コンピュヌティングでした。 それはクヌルで完党にクレむゞヌなトピックでした。 しかし、問題があり、䞀郚の郚分が正しく認識されなかったため、写真を取り出しお、目で読んで内容を報告できる人に芋せお、デヌタを䜿甚する仕事がありたした。独自の蚀語を持っおいたした。 これらすべおを凊理するバック゚ンドがありたした - Z80 は vt100 端末ず䞊行しお実行されたす - 80 人あたり 80 ぀であり、Z80 には䞊列プログラミング モデルがありたした。 スタヌ構成内のすべおの ZXNUMX によっお共有される共通のメモリ。 バックプレヌンも共有され、RAM の半分はネットワヌク内で共有され、残りの半分はプラむベヌトか別のものに䜿甚されたした。 共有...半共有メモリを備えた、非垞に耇雑な䞊列分散システム。 い぀だったか 思い出せたせんが、XNUMX幎代半ばのどこかでした。 かなり昔のこず。 
はい、30 幎ずいうのはかなり昔のこずだず仮定したしょう。分散コンピュヌティングに関連する問題はかなり長い間存圚しおおり、人々は長い間戊争を続けおきたした。 ベオりルフ/呪われし勇者-クラスタヌ。 このようなクラスタヌは次のようになりたす... たずえば、むヌサネットがあり、高速 x86 がこのむヌサネットに接続されおおり、今床は停の共有メモリを取埗したいずしたす。圓時は誰も分散コンピュヌティングのコヌディングができなかったので、難しすぎたため、ここにありたした。これは、x86 䞊の保護メモリ ペヌゞを備えた停の共有メモリであり、このペヌゞに曞き蟌んだ堎合、他のプロセッサに、同じ共有メモリにアクセスする堎合は、その共有メモリをあなたからロヌドする必芁があるこずを䌝え、したがっお、サポヌトするためのプロトコルのようなものを甚意したした。キャッシュコヒヌレンスずそのための゜フトりェアが登堎したした。 興味深いコンセプトです。 もちろん、本圓の問題は別のずころにありたした。 これはすべおうたくいきたしたが、すぐにパフォヌマンスの問題が発生したす。なぜなら、どのようなメモリ アクセス パタヌンがあるのか​​、ノヌドが盞互に際限なく ping を送信しないようにする方法など、パフォヌマンス モデルを十分なレベルで理解しおいる人がいなかったからです。

H2O に関しお私が思い぀いたのは、䞊列凊理がどこに隠され、どこに隠されないかを刀断する責任は開発者自身にあるずいうこずです。 私は、高パフォヌマンスのコヌドを簡単か぀シンプルに䜜成できるコヌディング モデルを思い぀きたした。 しかし、実行速床の遅いコヌドを曞くのは難しく、芋た目も悪くなりたす。 遅いコヌドを真剣に曞く必芁があり、非暙準的な方法を䜿甚する必芁がありたす。 ブレヌキコヌドは䞀目でわかりたす。 その結果、通垞は高速に実行されるコヌドを䜜成できたすが、共有メモリの堎合はどうすればよいかを理解する必芁がありたす。 これらすべおは倧きな配列に関連付けられおおり、そこでの動䜜は䞊列 Java における䞍揮発性の倧きな配列に䌌おいたす。 ぀たり、1 ぀のスレッドが䞊列配列に曞き蟌み、そのうちの 2 ぀が勝ち、それに応じおもう 2 ぀が負け、どちらがどちらであるかわからないず想像しおください。 それらが揮発性でない堎合、順序は任意で構いたせん。これは非垞にうたく機胜したす。 人々は操䜜の順序を非垞に気にしおおり、適切な堎所に volatile を配眮し、適切な堎所にメモリ関連のパフォヌマンスの問題が発生するこずを期埅しおいたす。 それ以倖の堎合は、すべおの耇雑なケヌスが自動的に䞊列になるこずを期埅しお、2 から N (N は数兆) たでのルヌプ圢匏でコヌドを蚘述するだけですが、そこでは機胜したせん。 しかし、HXNUMXO では、これは Java でも Scala でもありたせん。必芁に応じお、「Java マむナス マむナス」ず考えるこずができたす。 これは非垞に明確なプログラミング スタむルであり、ルヌプや配列を䜿甚した単玔な C たたは Java コヌドを蚘述するのず䌌おいたす。 しかし同時に、メモリはテラバむト単䜍で凊理できたす。 今でもHXNUMXOを䜿っおいたす。 私はさたざたなプロゞェクトで時々これを䜿甚したすが、それでもこれが最も高速であり、競合他瀟よりも数十倍高速です。 列圢匏のデヌタを䜿甚しおビッグ デヌタを実行しおいる堎合、HXNUMXO に勝぀のは非垞に困難です。

技術的な課題

アンドルヌ: あなたのキャリア党䜓の䞭で最倧の課題は䜕ですか?

厖: 私たちが議論しおいるのは、問題の技術的な郚分ですか、それずも非技術的な郚分ですか? 最倧の課題は技術的なものではないず思いたす。 
技術的な課題に関しおは。 私はただ圌らを倒しただけです。 䜕が最倧のものだったのかさえわかりたせんが、非垞に興味深いものがいく぀かあり、かなりの時間がかかり、粟神的な闘いでした。 サンに行ったずき、私は高速なコンパむラを䜜るだろうず確信しおいたしたが、倚くの先茩たちは私が成功するこずはないず蚀いたした。 しかし、私はこのパスに埓い、レゞスタ アロケヌタたでコンパむラを䜜成したずころ、非垞に高速でした。 これは珟圚の C1 ず同じくらい高速でしたが、圓時のアロケヌタヌははるかに遅かったので、埌から考えるず、これは倧芏暡なデヌタ構造の問題でした。 グラフィカル レゞスタ アロケヌタを䜜成するために必芁でしたが、圓時存圚し、非垞に重芁であったコヌドの衚珟力ず速床の間のゞレンマを理解しおいたせんでした。 デヌタ構造は通垞、圓時の x86 のキャッシュ サむズを超えおいるこずが刀明したした。そのため、最初はレゞスタ アロケヌタが総ゞッタヌ時間の 5  10 パヌセントを解決するず仮定しおいたら、実際にはそうであったこずが刀明したした。 50パヌセント。

時間が経぀に぀れお、コンパむラはよりクリヌンで効率的になり、ひどいコヌドを生成するケヌスが増えなくなり、パフォヌマンスはたすたす C コンパむラが生成するものに䌌おきたした。 。 C のようなコヌドを曞けば、より倚くの堎合、C のようなパフォヌマンスが埗られたす。 そしお、さらに進めば進むほど、挞近的にレベル C に䞀臎するコヌドが埗られるこずが倚くなり、コヌドの実行が速いか遅いかに関係なく、レゞスタ アロケヌタは完党なもののように芋え始めたした。 私はアロケヌタがより適切に遞択できるようにするために䜜業を続けたした。 圌はたすたす遅くなりたしたが、他の誰も察凊できない堎合には、たすたす優れたパフォヌマンスを発揮したした。 レゞスタ アロケヌタに飛び蟌み、そこに 5 か月分の䜜業を埋め蟌むず、突然コヌド党䜓の実行が XNUMX% 速くなりたす。 このようなこずは䜕床も起こり、レゞスタ アロケヌタは䞀皮の芞術䜜品ずなりたした。誰もがそれを奜むか嫌うかが決たり、アカデミヌの人々は「なぜすべおがこのように行われるのか」、「なぜそうしないのか」ずいうテヌマに぀いお質問したした。 ラむンスキャン、その違いは䜕ですか。 答えは䟝然ずしお同じです。グラフ ペむントに基づくアロケヌタヌずバッファヌ コヌドの非垞に慎重な䜜業は、勝利の歊噚ず同等であり、誰も倒すこずができない最良の組み合わせです。 そしお、これはかなり明癜ではないこずです。 コンパむラヌがそこで行うその他の凊理はすべお、かなりよく研究されたものですが、芞術のレベルにも達しおいたす。 私はい぀も、コンパむラヌを芞術䜜品に倉えるようなこずをしおいたした。 しかし、レゞスタ アロケヌタを陀いお、これは䜕も特別なものではありたせんでした。 コツは泚意するこずです 切り倒す これは、パフォヌマンス スケゞュヌルのねじれに陥るリスクなしに、より積極的にむンラむン化できるこずを意味したす。 圓時、レゞスタヌ・アロケヌタヌを備えた、぀たらないものやホむッスルをぶら䞋げた本栌的なコンパむラヌがたくさんありたしたが、他の誰もそれを行うこずができたせんでした。

問題は、むンラむン化察象のメ゜ッドを远加しおむンラむン化領域を増やしおいくず、䜿甚される倀のセットが瞬時にレゞスタ数を超えおしたい、それらを削陀しなければならないこずです。 通垞、臚界レベルはアロケヌタヌが諊めたずきに起こり、流出の有力な候補の XNUMX ぀が別の候補の䟡倀を持぀ようになり、䞀般に荒っぜいものを売るこずになりたす。 ここでのむンラむン化の䟡倀は、オヌバヌヘッドの䞀郚 (呌び出しず保存のオヌバヌヘッド) が倱われ、内郚の倀を確認しおさらに最適化できるこずです。 むンラむン化のコストは、倚数のラむブ倀が圢成されるこずであり、レゞスタ アロケヌタヌが必芁以䞊に燃え尜きおしたうず、すぐに倱われたす。 したがっお、ほずんどのアロケヌタヌは問題を抱えおいたす。むンラむン化が特定の線を超えるず、䞖界䞭のすべおが削枛され始め、生産性がトむレに流される可胜性がありたす。 コンパむラを実装する人は、いく぀かのヒュヌリスティックを远加したす。たずえば、割り圓おによっおすべおが台無しになっおしたうため、十分に倧きなサむズからむンラむン化を停止するなどです。 これが、パフォヌマンス グラフのねじれがどのようにしお圢成されるかです。むンラむン化、むンラむン化するず、パフォヌマンスはゆっくりず成長し、その埌ブヌムが起こりたす。 – 䞊びすぎたせいでアマツバメのように倒れおしたいたす。 Java が登堎する前は、すべおがこのように機胜しおいたした。 Java ではさらに倚くのむンラむン化が必芁ずなるため、アロケヌタがクラッシュせずに平準化するようにアロケヌタをより積極的にする必芁がありたした。むンラむン化が倚すぎるず流出し始めたすが、それでも「もう流出しなくなる」瞬間は来たす。 これは興味深い芳察であり、どこからずもなく思い぀いただけで、自明ではありたせんが、うたくいきたした。 私は積極的なむンラむン化を取り䞊げ、Java ず C のパフォヌマンスが䞊行しお機胜する堎所に連れお行きたした。 これらは非垞に近いものであり、私は C コヌドなどよりもはるかに高速な Java コヌドを曞くこずができたすが、平均しお、物事の党䜓像から芋るず、ほが同等です。 この利点の䞀郚は、可胜な限り愚かなむンラむン化を可胜にするレゞスタ アロケヌタだず思いたす。 目に芋えるものすべおをむンラむン化するだけです。 ここで問題ずなるのは、アロケヌタヌがうたく機胜するかどうか、結果ずしおむンテリゞェントに動䜜するコヌドが埗られるかどうかです。 これは倧きな課題でした。これらすべおを理解し、それを機胜させるのです。

レゞスタ割り圓おずマルチコアに぀いお少し

りラゞミヌル: レゞスタ割り圓おのような問題は、ある皮の氞遠の終わりのないテヌマのように思えたす。 有望に思えたアむデアが実際には倱敗したこずがこれたでにあったでしょうか?

厖 確かに レゞスタ割り圓おは、NP 完党問題を解決するためのヒュヌリスティックを芋぀けようずする領域です。 そしお完璧な解決策を達成するこずは決しお䞍可胜ですよね? これはたったく䞍可胜です。 芋おください、Ahead of Time コンパむル - これもうたく動䜜したせん。 ここでの䌚話は、いく぀かの平均的なケヌスに぀いおです。 兞型的なパフォヌマンスに぀いおは、良いず思われる兞型的なパフォヌマンスを枬定しおみおください。結局のずころ、それを改善するために取り組んでいるのです。 レゞスタ割り圓おはパフォヌマンスに関わるトピックです。 最初のプロトタむプが完成したら、それが動䜜し、必芁なものをペむントしお、パフォヌマンスの䜜業が始たりたす。 䞊手に枬る方法を孊ぶ必芁がありたす。 どうしおそれが重芁ですか 明確なデヌタがあれば、さたざたな領域を調べお、「ああ、ここでは圹に立ったが、ここですべおが壊れた」こずがわかりたす。 いく぀かの良いアむデアが思い぀き、新しいヒュヌリスティックを远加するず、突然すべおが平均しおもう少しうたく機胜し始めたす。 もしくは始たらない。 以前のアロケヌタヌず開発を差別化する XNUMX% のパフォヌマンスを争うケヌスが䜕床もありたした。 そしお、毎回次のようになりたす。どこかで勝ち、どこかで負けたす。 優れたパフォヌマンス分析ツヌルがあれば、倱われたアむデアを芋぀けお、倱敗の理由を理解するこずができたす。 おそらく、すべおを珟状のたたにしおおく䟡倀があるかもしれたせん。あるいは、より真剣に埮調敎するアプロヌチを取るか、それずも別の䜕かを修正するこずに取り組む䟡倀があるかもしれたせん。 それはたくさんのこずです このクヌルなハックを䜜成したしたが、これずこれずこれも必芁です。これらを合蚈するず、いく぀かの改善が埗られたす。 そしお孀独な人は倱敗する可胜性がありたす。 これは、NP 完党問題に察するパフォヌマンス䜜業の性質です。

りラゞミヌル: アロケヌタでのペむントなどはすでに解決された問題であるような気がしたす。 たあ、あなたの蚀っおいるこずから刀断するず、それがあなたに決たっおいるので、それはそれで䟡倀がありたすか...

厖それ自䜓は解決されおいたせん。 それを「解決」に倉えるのはあなた自身です。 難しい問題があり、解決する必芁がありたす。 これが完了したら、生産性の向䞊に取り組みたす。 この䜜業にはそれに応じおアプロヌチする必芁がありたす。ベンチマヌクを実行し、メトリクスを収集し、前のバヌゞョンにロヌルバックしたずきに叀いハックが再び動䜜し始めた (たたはその逆で停止した) 状況を説明したす。 そしお䜕かを達成するたで諊めないでください。 すでに述べたように、うたくいかなかったクヌルなアむデアはありたすが、アむデアのレゞスタの割り圓おの分野では、それはほが無限にありたす。 たずえば、科孊出版物を読むこずができたす。 珟圚、この領域ははるかにゆっくりず動き始めおおり、若い頃よりもより明確になりたした。 しかし、この分野では無数の人々が働いおおり、圌らのアむデアはすべお詊しおみる䟡倀があり、党員が埅機䞭です。 そしお、詊しおみないずその良さはわかりたせん。 アロケヌタは倚くのこずを実行し、䞀郚のアむデアは特定のアロケヌタでは機胜したせんが、別のアロケヌタでは簡単に機胜するため、それらはアロケヌタ内の他のすべおずどの皋床うたく統合されたすか。 アロケヌタが勝぀ための䞻な方法は、䜎速パスをメむン パスの倖偎に匕き出し、䜎速パスの境界に沿っお匷制的に分割するこずです。 したがっお、GC を実行したい堎合は、䜎速のパスを遞択し、最適化を解陀し、䟋倖をスロヌするなど、これらすべおのこずは比范的たれであるこずがわかりたす。 そしお、それらは本圓に珍しいです、私は調べたした。 远加の䜜業を行うず、これらの遅いパスの倚くの制限が解陀されたすが、これらのパスは遅く、めったに移動しないため、実際には問題になりたせん。 たずえば、null ポむンタヌ - それは決しお起こりたせんよね? さたざたなこずのために耇数のパスが必芁ですが、それらがメむンのパスを劚げおはなりたせん。 

りラゞミヌル: 䞀床に䜕千ものコアがあるマルチコアに぀いおはどう思いたすか? これは䟿利なものですか

厖: GPU の成功は、GPU が非垞に䟿利であるこずを瀺しおいたす。

りラゞミヌルかなり専門的ですね。 汎甚プロセッサに぀いおはどうですか?

厖そうですね、それがAzulのビゞネスモデルでした。 その答えは、人々が予枬可胜なパフォヌマンスを本圓に重芖しおいた時代に戻っおきたした。 圓時、䞊列コヌドを曞くのは困難でした。 H2O コヌディング モデルは拡匵性が高くなりたすが、汎甚モデルではありたせん。 おそらく GPU を䜿甚する堎合よりももう少し䞀般的です。 私たちはそのようなものを開発するこずの耇雑さに぀いお話しおいるのでしょうか、それずもそれを䜿甚するこずの耇雑さに぀いお話しおいるのでしょうか たずえば、Azul は、キャッシュが小さいのは正垞であるずいう、あたり明癜ではない興味深い教蚓を私に教えおくれたした。 

人生最倧の挑戊

りラゞミヌル: 技術的以倖の課題に぀いおはどうですか?

厖: 最倧の課題は、人に芪切で芪切にならないこずでした。 その結果、私は垞に極床の察立状況に陥っおいたした。 物事がうたくいかないこずはわかっおいたしたが、それらの問題をどのように進めるかがわからず、察凊できなかったものです。 このようにしお、䜕十幎にもわたる長期的な問題の倚くが発生したした。 Java に C1 および C2 コンパむラがあるずいう事実は、これの盎接の結果です。 Java でマルチレベルのコンパむルが XNUMX 幎連続で行われなかったずいう事実も、盎接の結果です。 このようなシステムが必芁だったこずは明らかですが、なぜそれが存圚しなかったのかは明らかではありたせん。 䞀人の゚ンゞニア、たたぱンゞニアのグルヌプに問題がありたした。 か぀お、私が Sun で働き始めたずき、私は... そうですね、圓時に限らず、私は通垞、すべおのこずに぀いお垞に自分の意芋を持っおいたした。 そしお、あなたは自分のこの真実を受け止めお、それを正面から䌝えるこずができるのは本圓だず思いたした。 特に私はほずんどの堎合、驚くほど正しかったので。 そしお、このアプロヌチが気に入らない堎合は...特に、明らかに間違っおいおナンセンスなこずをしおいる堎合は...䞀般に、この圢匏のコミュニケヌションを蚱容できる人はほずんどいたせん。 私のようにできる人もいたすが。 私は自分の人生党䜓を実力䞻矩の原則に基づいお築いおきたした。 もしあなたが䜕か間違ったこずを私に芋せたら、私はすぐに振り返っお「あなたはナンセンスなこずを蚀った」ず蚀うでしょう。 同時に、もちろん謝眪し、メリットがあればそれを考慮し、他の正しい行動を取る぀もりです。 䞀方で、総時間の驚くほど倧きな割合に぀いおは、私は驚くほど正しいです。 そしお人間関係もうたくいきたせん。 芪切にする぀もりはありたせんが、率盎に質問しおいたす。 「これは決しおうたくいきたせん。なぜなら、XNUMX、XNUMX、XNUMXだからです。」 そしお圌らは「ああ」ずいう感じでした。 おそらく無芖したほうがよい圱響は他にもありたした。たずえば、劻ずの離婚ずその埌の XNUMX 幎間のう぀病に぀ながった結果です。

チャレンゞずは、䜕ができるかできないか、䜕が重芁で䜕がそうでないかに぀いおの人々の認識ずの闘いです。 コヌディングスタむルに関しおは倚くの課題がありたした。 私は今でも倚くのコヌドを曞いおいたすが、圓時は 2 ぀のタスクに集䞭するのではなく、䞊列タスクが倚すぎお効率が悪かったため、速床が䜎䞋するこずさえありたした。 振り返っおみるず、Java JIT コマンドである CXNUMX コマンドのコヌドの半分を私が曞きたした。 次に速いプログラマは半分の速床で曞き、その次のプログラマは半分ほど遅くなり、指数関数的に枛少したした。 この列の XNUMX 人目の人はずおもずおも遅かったです - それはい぀も起こるこずです! たくさんのコヌドに觊れたした。 私は誰が䜕を曞いたかを芳察し、䟋倖なく圌らのコヌドを芋぀め、それぞれをレビュヌし、それでも圌らの誰よりも自分自身を曞き続けたした。 このアプロヌチは人々に察しおあたりうたくいきたせん。 これを奜たない人もいたす。 そしお、それに耐えられなくなるず、あらゆる皮類の苊情が始たりたす。 たずえば、コヌドを曞きすぎおチヌムに危険が及ぶからコヌディングをやめろず蚀われたこずがありたすが、私にはすべおが冗談のように聞こえたした。チヌムの残りのメンバヌがいなくなっお、私がコヌドを曞き続けたら、あなたはあなたです。負けるのはチヌムの半分だけだ。 䞀方で、私がコヌドを曞き続けおチヌムの半分を倱うずしたら、それは非垞に悪い管理のように思えたす。 それに぀いお深く考えたこずも、話したこずもありたせんでしたが、それでも頭のどこかにありたした。 「冗談ですか」ずいう考えが頭の片隅でぐるぐる回っおいたした。 ぀たり、最倧の問題は私自身ず人々ずの関係でした。 今では自分自身のこずをよりよく理解できたした。私は長い間プログラマヌのチヌムリヌダヌを務めおいたしたが、今では人々に盎接こう蚀いたす。「ご存知のずおり、私は私であり、あなたは私に察凊しなければなりたせん - 私が立っおいおも倧䞈倫ですか」ここ そしお圌らがそれに察凊し始めたずき、すべおがうたくいきたした。 実際、私は悪い人でも良い人でもありたせん。悪意や利己的な願望も持っおいたせん。それはただ私の本質であり、䜕ずかそれずずもに生きおいく必芁がありたす。

アンドルヌ぀い最近、内向的な人の自己認識や゜フトスキル党般に぀いお誰もが話し始めたした。 これに぀いお䜕ず蚀えたすか?

厖はい、それが私が劻ずの離婚から孊んだ掞察ず教蚓でした。 離婚から孊んだこずは自分自身を理解するこずでした。 このようにしお私は他の人々を理解するようになりたした。 この盞互䜜甚がどのように機胜するかを理解しおください。 それによっお次々ず発芋が生たれたした。 自分が誰なのか、自分が䜕を代衚しおいるのかずいう認識がありたした。 私は䜕をしおいるのでしょうか。その仕事に倢䞭になっおいるか、察立を避けおいるか、あるいは他の䜕かをしおいるかのどちらかです。このレベルの自己認識は、自分をコントロヌルし続けるのに非垞に圹立ちたす。 この埌、すべおがはるかに簡単になりたす。 私自身だけでなく、他のプログラマヌにもわかったこずの XNUMX ぀は、感情的なストレス状態にあるずきは考えを蚀語化できないずいうこずです。 たずえば、あなたがフロヌ状態で座っおコヌディングしおいるず、圌らがあなたのずころに駆け寄っおきお、䜕かが壊れたのであなたに察しお極端な措眮が取られるずヒステリックに叫び始めたす。 そしお、粟神的なストレス状態にあるため、䜕も蚀えなくなりたす。 獲埗した知識により、この瞬間に備えお生き残り、撀退蚈画に進むこずができ、その埌、䜕かを行うこずができたす。 ですから、すべおがどのように機胜するかを理解し始めるず、それは人生を倉える倧きな出来事になりたす。 
私自身、適切な蚀葉は芋぀かりたせんでしたが、䞀連の動䜜を思い出したした。 重芁なのは、この反応は蚀葉であるのず同じくらい身䜓的なものであり、スペヌスが必芁であるずいうこずです。 犅的な意味でいうず、そういう空間。 これはたさに説明する必芁があるこずです。その埌、すぐに脇ぞ、玔粋に物理的に離れおください。 蚀葉で沈黙しおいるず、感情的に状況を凊理できたす。 アドレナリンが脳に到達し、戊闘モヌドたたは逃走モヌドに切り替わるず、あなたはもう䜕も蚀えなくなりたす、いいえ、今ではあなたは愚か者、むち打ちの゚ンゞニアであり、たずもな反応も攻撃を止めるこずさえできず、攻撃者は自由になりたす䜕床も䜕床も攻撃するこず。 たず自分自身に戻り、コントロヌルを取り戻し、「戊うか逃げるか」モヌドから抜け出す必芁がありたす。

そしおそのためには蚀語空間が必芁です。 ただの空きスペヌス。 少しでも䜕かを蚀うなら、そのこずを正確に蚀っおから、実際に自分のための「スペヌス」を芋぀けおください。公園を散歩したり、シャワヌに閉じこもったりしおください。それは問題ではありたせん。 重芁なのは、その状況から䞀時的に切り離すこずです。 少なくずも数秒間スむッチを切るずすぐに制埡が戻り、冷静に考え始めたす。 「わかった、私はバカじゃないし、バカなこずはしないし、かなり圹に立぀人間だよ。」 自分自身を玍埗させるこずができたら、次の段階、぀たり䜕が起こったのかを理解する段階に進みたす。 あなたは攻撃されたした、その攻撃は予期せぬずころから来たした、それは䞍誠実で卑劣な埅ち䌏せでした。 これは悪いです。 次のステップは、攻撃者がなぜこれを必芁ずしたのかを理解するこずです。 ほんずになんで おそらく圌自身が激怒しおいるからでしょうか なぜ圌は怒っおいるのですか たずえば、自分が倱敗しお責任をずれないから これが状況党䜓を慎重に凊理する方法です。 しかし、これには操䜜の䜙地、぀たり蚀葉のスペヌスが必芁です。 䞀番最初のステップは、口頭での接觊を断぀こずです。 蚀葉による議論は避けおください。 キャンセルしお、できるだけ早く立ち去っおください。 電話での䌚話の堎合は、ただ切りたしょう。これは私が元劻ずのコミュニケヌションから孊んだスキルです。 䌚話がうたく進たない堎合は、「さようなら」ず蚀っお電話を切りたしょう。 電話の向こうから「䜕ずか䜕ずか」ず蚀うず、あなたは「はい、さようなら」ず答えたす。 そしお電話を切りたす。 䌚話を終了するだけです。 XNUMX分埌、理性的に考える胜力が戻り、少し冷静になり、䜕が起こったのか、そしお次に䜕が起こるのか、すべおに぀いお考えるこずができるようになりたす。 そしお、ただ感情的に反応するのではなく、思慮深い察応を緎り始めたしょう。 私にずっお、自己認識の画期的な進歩は、たさに、感情的なストレスがあるず話すこずができなくなるずいう事実でした。 この状態から抜け出し、どのように察応し、問題を補うかを考え、蚈画するこずは、話すこずができない堎合の正しい手順です。 最も簡単な方法は、感情的なストレスが珟れる状況から逃げお、このストレスに参加するのをやめるこずです。 その埌は考えるこずができるようになり、考えるこずができるようになるず話せるようになり、ずいうようになりたす。

ちなみに、法廷で盞手方の匁護士があなたに同じこずをしようずしたすが、その理由は明らかです。 なぜなら、圌はあなたを、䟋えば自分の名前さえ発音できないような状態にたで抑圧する胜力を持っおいるからです。 本圓の意味で、話すこずができなくなりたす。 このようなこずがあなたに起こり、法廷のような堎所で激しい口論が繰り広げられるこずが分かっおいるのであれば、匁護士ず䞀緒に来おください。 匁護士があなたに代わっお蚀葉による攻撃を止め、完党に合法的な方法で止めお、倱われた犅の空間があなたに戻っおきたす。 たずえば、私は家族に䜕床か電話しなければなりたせんでしたが、裁刀官はこの件に関しお非垞に友奜的に察応しおくれたしたが、盞手方の匁護士は私に怒鳎っお怒鳎ったため、私は䞀蚀も聞き取るこずができたせんでした。 このような堎合、仲介者を䜿甚するのが私にずっお最も効果的です。 調停者は、絶えずあなたに降り泚ぐこのすべおのプレッシャヌを止め、あなたは必芁な犅の空間を芋぀け、それずずもに話す胜力を取り戻したす。 これは知識の分野党䜓であり、孊ぶべきこず、自分自身の䞭で発芋すべきこずがたくさんあり、これらすべおが人によっお異なる高レベルの戊略的決定に倉わりたす。 䞊蚘の問題を抱えおいない人もいたすが、通垞、プロの営業マンにはこれらの問題はありたせん。 有名な歌手、詩人、宗教指導者、政治家など、蚀葉で生蚈を立おおいる人々は皆、垞に蚀いたいこずを持っおいたす。 圌らにはそのような問題はありたせんが、私には問題がありたす。

アンドルヌそれは 予想倖でした。 わかりたした。すでにたくさん話したしたが、このむンタビュヌを終了する時間になりたした。 私たちは必ず䌚議でお䌚いし、この察話を続けるこずができるでしょう。 ヒドラでお䌚いしたしょう

2019 幎 11 月 12  2019 日にサンクトペテルブルクで開催される Hydra XNUMX カンファレンスで、クリフずの䌚話を続けるこずができたす。 圌は報告曞を持っお来るでしょう 「Azul ハヌドりェア トランザクション メモリ ゚クスペリ゚ンス」。 チケットは賌入できたす 公匏りェブサむト䞊で.

出所 habr.com

コメントを远加したす