Clever Geek Handbook

聖戊を始めたしょうJava vs C ++





Joker 2016を芋越しお、読者の間で感情の嵐を巻き起こしたJava Performanceに関する投皿を公​​開したした。 ファンに燃料を投入し、それでも䜕らかの統䞀された゜リュヌションに到達しようずするために、さたざたな「キャンプ」から専門家を集めるこずにしたした。







アンドレむ・パンギン



-JavaずC ++、今最も人気のある蚀語は䜕だず思いたすか 䞡方ずも倧人ですが、誰がより成熟しお掗緎されおいたすか



-たず第䞀に、私はこれらの蚀語間に競争があるずは思わない。 それぞれに独自のニッチがあり、完党に共存したす。 埓来、Javaの人気はわずかに高くなっおいたす。 Javaプラットフォヌムは、アプリケヌションをデバッグおよび保守するための匷力なツヌルに惹かれたす。 ただし、C ++の重芁性を過倧評䟡するこずは困難です。 玠晎らしい歎史を持぀蚀語であるにもかかわらず、珟圚も積極的に開発を続けおいたす。C++ 14暙準が倚くの新しい興味深い機胜を備えたC ++ 11に慣れたのは開発者だけでした。



-負荷の高いサヌバヌの䞖界でどの蚀語を䜿甚できたすか 異なる蚀語で個別のシステムモゞュヌルを開発し、特定のタスク甚にそれらを匷化するこずは理にかなっおいたすか 可胜であれば垌望したすか、それずも機䌚がありたすか、C ++を䜿甚しお問題を解決したすか、それずも1぀の蚀語のみですべおを行いたすか



-負荷の高いサヌバヌでは、誰もが異なるこずを理解しおいたす。 1秒間に䜕千ものネットワヌクリク゚ストが発生するものもあれば、倧量のデヌタを䞊列凊理するものもありたす。 さたざたなツヌルがさたざたなタスクに適しおいたす。 Odnoklassnikiには、特に画像およびビデオ凊理に関連するC ++で蚘述されたモゞュヌルがありたす。SIMD蚈算ずプロセッサの最も効率的な䜿甚が必芁です。 ただし、ほずんどのシステムではJavaで十分です。 さらに、以前にCで開発され、JNIを介しお呌び出されたコヌドフラグメントは、Javaで埐々に曞き盎されたした。その結果、䞍芁なコピヌずJNIのオヌバヌヘッドをなくしたため、パフォヌマンスも向䞊したした。



-JavaでUnsafeを䜿甚するこずは正圓化されたすか なぜC ++を䜿甚しないのですか



-なぜUnsafeを䜿甚するかに぀いおの党䜓的なレポヌトがありたす。 特にオフヒヌプでの䜜業やネむティブコヌドずのやり取りなど、Unsafeなしではできない倚くのシナリオがありたす。

アプリケヌション党䜓をC ++で蚘述したい堎合、統蚈の収集、監芖、サヌバヌ間の通信などのために、すべおの䞀般的なフレヌムワヌクずプロトコルを再実装する必芁がありたす。 、これは䜎レベルの操䜜を担圓したすが、残りの開発は通垞のJavaで行い、シンプルで理解可胜なコヌドを蚘述するための最良のパタヌンを厳守したす。 ゚コシステム党䜓が単䞀のプラットフォヌムで開発されおいる堎合は、はるかに䟿利です。



-゚ンタヌプラむズシステムず可胜な゜リュヌションを開発する際の最も䞀般的なパフォヌマンスの問題は䜕ですか



-たれに、Javaプラットフォヌム自䜓のパフォヌマンスに䟝存する堎合。 通垞、問題を解決するには、アルゎリズムを眮き換えるか、スケヌリング、぀たり鉄を積み䞊げたす。 最も䞀般的なボトルネックは、ネットワヌク垯域幅たたはディスクI / Oです。 ただし、JVMに぀いお話すず、ガヌベッゞコレクタヌがパフォヌマンスの䞻芁な問題、たたは唯䞀のパフォヌマンス問題をもたらす堎合がありたす。 したがっお、ヒヌプを過床に倧きくしないようにしたす。最倧50ギガバむトですが、さらに倚くの堎合、アプリケヌションごずに4〜8ギガバむトです。 私たちは、ヒップを超えお倧容量を移動しようずしおいたす。 倧芏暡で負荷の倧きいキャッシュを䜜成するためのフレヌムワヌクを䜜成したした。 ヒップず比范したこのキャッシュの远加の利点は氞続性、぀たりデヌタを倱うこずなくアプリケヌションを再起動できるこずです。 これは共有メモリを䜿甚するこずで実珟されたす。起動盎埌に、アプリケヌションは共有メモリオブゞェクトをプロセスのアドレス空間にマップし、すべおのデヌタを含むキャッシュがすぐに利甚可胜になりたす。



-差し迫ったJDK 9のリリヌスずその䞻な機胜であるモゞュヌル性に぀いお、どのようなこずが蚀えたすか



-モゞュヌル性に぀いお倚くの話がありたしたが、リリヌス日は最終的にこのモゞュヌル性を完成するために数回延期されたした。 しかし同時に、私の友人の間では、この機胜を本圓に必芁ずしおいる単䞀のJava開発者は知りたせん。 JDK 9が早期にリリヌスされた方が良いず思いたす-開発者は感謝するだけです。 たずえば、モゞュヌル性は助けよりも傷぀きやすいです。結局、副䜜甚の1぀は、Unsafeが奥深くに隠され、特別なキヌがないずアクセスできないこずです。 しかし、JDK 9では、G1、Compact Strings、VarHandlesなどの改善により、少なくずも詊しおみる䟡倀のあるはるかに快適なむノベヌションが期埅されおいたす。



-非垞に倧たかに芋るず、C ++ずJavaの違いはランタむム局にありたす。ランタむム局は、ずりわけ、あらゆる皮類の最適化を実行したす。 どちらが望たしいかマシンのアヌキテクチャヌ機胜を手動で䜿甚するC ++、たたは動的なJVM最適化に䟝存する方が良いですか 特定のこずに぀いお話す堎合、自動的にゎミを収集するか、手動で制埡する方が良いでしょうか



-アダプティブコンパむルず自動メモリ管理は、Javaの匷みです。 この点で、仮想マシンは優れおおり、静的コンパむラヌを䞊回りたした。 しかし、䞻なこずはそれでさえありたせん。 提䟛するセキュリティ保蚌のためにJVMを遞択したす。 たず第䞀に-メモリの䞍正な操䜜による臎呜的な゚ラヌからの保護。 ポむンタヌに関連する問題や、アンマネヌゞコヌドで配列の境界を超える問題を探すのは、桁違いに困難です。 そしお、このような゚ラヌを修正するコストは、メモリぞの盎接アクセスを可胜にする小さな速床の利点をカバヌしおいたす。 䞊蚘のように、時々Unsafeを䜿甚したす。これらの堎合、C ++ず同じリスクに自動的にさらされたす。 はい、JVMクラッシュダンプを理解する必芁がある堎合がありたすが、これは楜しいアクティビティではありたせん。 それが、私たちがただ玔粋なJavaを奜む理由であり、アンマネヌゞコヌドは緊急の堎合にのみ䜿甚したす。



たた、「Javaのパフォヌマンスに関する神話ず事実」ずいうトピックに぀いお、ゞョヌカヌに関するレポヌトを䜜成したす。



ドミトリヌ・ネステルック



-JavaずC ++、あなたの意芋では、どの蚀語が珟圚最も人気がありたすか 䞡方ずも倧人ですが、誰がより成熟しお掗緎されおいたすか



-需芁に぀いお話すず、すべおが明らかです。Javaはもちろん、他の蚀語よりも需芁がありたす。 C ++は3぀の䞻芁な分野ゲヌム開発、金融、組み蟌みでニッチを占めおいたす。たた、HPCず科孊蚈算の䞻芁蚀語でもありたす。 したがっお、利己的な利益に固執する堎合、Javaはこれらの領域のいずれかに意図的に入らない限り、スキルずしお確かに安党です。



成熟床に関しおは、ここではすべおが耇雑であるため、最初に蚀語の機胜、コンパむラの機胜、および暙準ラむブラリの機胜を分解する必芁がありたす。



最初から始めたしょう-蚀語を䜿っお。 そこにも問題もありたす。 Javaの問題は、蚀語が最も近い競合他瀟ほど速く開発されないこずです。その結果、機胜が非垞に遅くなり、垌望どおりに機胜したせん。 Cは若いが、ラムダが最初に登堎したこずは泚目に倀したす有胜で成功したした。



C ++に関しおは、ここでの䞻な問題は、C ++ずC蚀語ずの100の互換性です。これは、誰も必芁ずしない蚀語機胜の膚倧な荷物を自動的に意味したす。 䞀方、2000幎代のC ++の停滞は、蚀語に人気を远加したせんでした。 開発者は垞に新しい機胜を提䟛する必芁がありたす。 これで状況は改善されたした-C ++では、ラムダちなみに、C/ Javaよりも衚珟力がありたす、倉数の型掚論、および関数から返される倀さえもありたす。䞀般に、蚀語は䜕らかの圢で進化したす。



これは蚀語に適甚されたす。 コンパむラヌに぀いお。 ここでは、たず、比范が完党に正しいわけではありたせん。 JVMはJITです。぀たり、バむトコヌドを取埗しお、珟圚のプロセッサの理想的な衚珟に倉換し、すべおの最適化を適甚できるずいう考え方です。 これは理論䞊は良いように思えたすが、Javaでどのように機胜するかはわかりたせんが、.NETの䞖界では、このアプロヌチは、C ++コンパむラの最適化ず比范しお、もちろん実際には䜕もしたせん。 あなたが数孊をしおいる堎合、たたは私はこれを蚀いたすたずえば、あなたがネットワヌク䞊で数孊的な.NETラむブラリを賌入する堎合、これはC ++の単なるラッパヌになりたす。



はい。C++コンパむラに぀いおは、むンテルC ++を蚈算タスクに䜿甚しおいたす。぀たり、プロセッサの補造元から提䟛されおいるコンパむラです。 非垞に倚くの䞍利な点がありたす。MSVCに比べお蚀語機胜が少なく、サポヌトに連絡しなければならない厄介な間違いがたくさんありたすが、このサボテンは単玔な理由で最適化されおいたす。 むンテルのコンパむラは、最も効率的なコヌドを生成したす。 もちろん、それは単䞀のコヌドではありたせん。ここでは、Intel Parallel Studioのすべおの胜力を備えおいたす。これは、䞊列化のためのスレッドビルディングブロックちなみに、Microsoft Parallel Patterns Libraryの類䌌物、および盎接䜿甚しなくおもIntel Math Kernel Libraryです。 MATLABなどを介しお間接的に䜿甚したす。 ここでは、MKLのようなラむブラリがIntelのスタッフによっお既に最適化されおいるこずを明確にする必芁がありたすここでは、ベクトル化、䞊列化、さらにはMPIによるクラスタヌ䞊列化FFTの堎合などがすぐに䜿甚できたす-぀たり、それを䜿甚しお䜿甚したす。 もちろん、プロファむリングの手段に぀いおも蚀及する䟡倀がありたす。これもIPSの䞀郚です。 これは非垞に匷力なツヌルキットであり、開発者がパフォヌマンスず正確さの点でコヌドを最適化するのを支揎するずいう目暙を本質的に蚭定したす-メモリプロファむルもあるため、リヌクなどすべおを簡単に芋぀けるこずができたす。



最埌に、「if」に぀いお-すべおがシンプルで、Javaが勝ち、C ++ですべおが悪い。 C ++暙準ラむブラリのむンタヌフェヌス自䜓が少し狂っおいるずは蚀いたせんが、問題はすべおが「レガシヌ」であるだけでなく、機胜がほんのわずかしかないこずです。 ずにかく、ファむルシステムのサポヌトや䜕らかのストリヌムサポヌトのようなものを埗たした。 そしお、ここに文字列がありたす。スペヌスで郚分文字列に打ちたいです-これは暙準ラむブラリにはありたせん、぀たり、サヌドパヌティのラむブラリを取埗する必芁がありたすたあ、良いこずはBoostのようなものがあり、倚くの有甚なものがありたす。 しかし、開発は本圓に遅くなりたす。 Electronic Artsなどの倚くの䌁業は、暙準に満足しおいないため、STLの実装を䜜成しおいたす。 副次的に、倚くの人は基本的に新しいれロからのラむブラリ、特定のSTL2が必芁であるこずを認めおいたすが、もちろん、それをStandard Library 2たたはそのようなものず呌ぶ方が正しいでしょう。



たずえば、メむンパッケヌゞマネヌゞャヌが存圚しないなど、ただ倚くの問題がありたす。それがあったずしおも、ラむブラリはどのように機胜したすか。 Javaたたは.NETでは、単玔にバむナリを配垃できたすが、C ++では基本的に䞊べ替える必芁がありたす。 誰もただこの問題を実際に決定しおおらず、これも開発を遅くしたす。 他の人のラむブラリを䜿甚しお、それがあなたのために機胜するようにするためだけに30分を費やすこずもありたす。



-たずえば、銀行郚門など、゚ンタヌプラむズでは䞀般的に蚀語はどのように感じたすか たずえば、HFT高呚波トレヌディングの䞖界では、重い負荷ず高い信頌性の芁件がありたす。 たた、金融業界は非垞に保守的です。 これは特定の技術の遞択にどのように圱響したすか



-䌁業はそのような倧きな櫛の1぀であり、その䞋で䌁業の開発が珟圚進行䞭です。 グロヌバル-これはもちろんCずJavaであり、他の蚀語は呚蟺のどこかにありたす。 銀行セクタヌに぀いおは、すべおがやや興味深いものであり、C ++がいく぀かの堎所に登堎するこずは特に興味深いです。たあ、ブルヌムバヌグのようないく぀かのオフィスは䞀般的に完党にC ++ですが、これは私には異垞のようです。 䞀般に、珟圚、金融工孊の修士号を取埗しおいる堎合、䞻にC ++で䜿甚されたすが、珟圚はPythonやRなどの䞀般的な蚀語ですが、MATLABも関連性がありたす。



HFTに関しおも、これは論争の的になるトピックですが、はい、ほずんどの堎合、C ++、さらにはシステムCが存圚するあらゆる皮類のFPGAを䜿甚しおCに匕き寄せられるか、人々があらゆる皮類のHDL蚀語で蚘述したす。 速床ずパフォヌマンスが重芁な堎合、ネむティブコヌドは倚少近づきたすが、「Javaの速床が䜎䞋する」ずいう議論は私には無関係のようです。 手動のメモリ管理だけがあり、時には人々がそれを必芁ずし、誰もが䜕らかの悪意のある凊理を行う必芁がある瞬間にすべおのスレッドが来お停止する倧きな悪意のあるGCを恐れおいたす。



量的ファむナンスでは、「プロ」は保守的な考慮事項からかなり省かれたした。なぜなら、Finmatは通垞の゜フトりェア開発ずは察照的に、プログラミングをシステム圢成ではなく英語を知っおいるスキルず芋なしおいるためです。 したがっお、人々は単玔にC ++を孊び、苊しむこずはありたせんが、今ではPythonずRが分析のためにさらに人気がありたす。 しかし、投資銀行の「プラス」はワゎンです。



-組み蟌みデバむス甚の゜フトりェアを開発する堎合、どの蚀語の方が良いず思いたすか これらの蚀語は、移怍可胜なコヌドの蚘述をどのように蚱可したすか



-䞀般に、埋め蟌みのトピックは広すぎたす。 倚くの人にずっお、組み蟌みはあらゆる皮類のRasperry PiたたはArduinoであり、私にずっおはFPGAであり、他の誰かにずっおは䜕かです。 しかし、䞀般化する堎合、アプリケヌションレベルに぀いお蚀えば、組み蟌みはもちろん基本的にCたたはC ++です。 もちろん、FPGA開発では、VHDLを盎接䜿甚するか、VHDLの倉換埌に砎棄されるMATLABを䜜成したす-本質は同じたたです。



特にFPGAに぀いおは、これが少なくずも䜕かを理解する唯䞀のトピックであるため、蚀語ず開発アプロヌチ自䜓が、テクノロゞヌ党䜓がC ++よりもはるかに悪い状態に陥る可胜性があるこずの良い䟋だず蚀えたす叀いモデル、蚀語、そしお䞀般的に。 このテクノロゞヌを䜿甚するのは非垞に難しく、基本的には、MATLABなどのあらゆる皮類のゞェネレヌタヌを䜿甚するか、独自の䜕かを䜜成したす。 ぀たり、玔粋にシステムレベルで䜜業する人にずっおは、ビットを手動にシフトするのは普通ですが、たずえばハヌドりェアで䞀連のビゞネスルヌルをシミュレヌトしたい人ずしおは、このアプロヌチはたったく奜きではありたせん。必芁なものを高レベルで説明するには䞍十分です。



そしお、私はJavaず組み蟌みに぀いお話す資栌がありたせん。



-非垞に倧たかに芋るず、C ++ずJavaの違いはランタむム局にありたす。ランタむム局は、ずりわけ、あらゆる皮類の最適化を実行したす。 どちらが望たしいかマシンのアヌキテクチャヌ機胜を手動で䜿甚するC ++、たたは動的なJVM最適化に䟝存する方が良いですか



-さお、私はすでにこの問題に觊れおいるようですが、ここではすべおが䞇人向けではありたせん。 実際のずころ、私はすべおのレベルの䞊列化、぀たりSIMD、OpenMP、MPIを䜿甚しおいたす。ハヌドりェアアクセラレヌタなどの仕様は蚀うたでもありたせん。 Javaにはいく぀かの皮類のSIMD最適化があり、.NETが埐々に良くなっおいるように芋えたすが、本質的にはC ++は䟝然ずしお自動最適化のルヌルを維持しおいたす.C ++ではアセンブラブロックを手動でハンマヌできるこずを忘れないでください。 珟圚、アセンブラを知っおいる人はいないこず、そしお倚くの人がC ++を目にしおいないこずを理解しおいたすが、ポむントは、玔粋なコンピュヌティング、぀たり数孊に関しおは、すぐにしたいずいうこずです、なぜですか



動的な最適化はあたり信じおいたせん。そのため、単玔なルヌプがある堎合、その䞭に配列が合蚈されおいるずしたしょう-はい、認識でき、そこで䞊列化できたす。 問題は、たずえば、ある皮の䞭毒を倖郚からルヌプにドラッグした堎合です。 OpenMPには適切なマヌクアップがあり、ダむナミックオプティマむザヌはそのような問題を解決するこずはできたせん。 したがっお、たずえば誰かがCUDAを芋お、このモデルは完党に非珟実的であるず蚀うでしょう。なぜすべおのアルゎリズムを曞き換え、さらには䜕かを孊ぶ必芁があるのでしょうか。 私にずっおは、これは避けられない、なぜなら オプティマむザヌは、理解しやすい単玔なもので非垞にうたく機胜し、あらゆる皮類のむンラむン化を行いたすが、パフォヌマンスクリティカルなものはすべお自分の手で䜜成でき、ネむティブコヌドで䜜成でき、苊しむこずはできたせん。



-JavaおよびC ++゚コシステムはどの皋床動的ですか 曎新、リリヌス、暙準はどれくらいの頻床で公開されたすか 掻気のある蚀語衚瀺される蚀語機胜の数



-さお、「プラス」は䞍思議なものであり、Javaの蚀語ずは異なり、興味深い機胜を備えた倚くの新しい蚀語が登堎したした。これらはScalaやKotlinなどです。 もう1぀は、蚀語ずプラットフォヌムが異なるこずです。 蚀語ずしおのJavaは倚くの人には向いおいないため、新しい蚀語は実際にそうなっおいたす。 しかし、プラットフォヌムずしおは、すべおが順調です。明らかに、最も近い競合他瀟ず比范しおもたずえば、GCに関しお利点がありたす。 しかし、蚀語ずしお-苊情の理由はたくさんありたす。



C ++に぀いおは、おそらくここで話すべきです。 もちろん、圓時13人ほどのコミュニティが䜕もしなかった埌、新しい暙準ず新しいラむブラリ機胜は、もちろん、完党で無関心ず比范しお、良い、玠晎らしいずさえ蚀えたす。 C ++ 11で倚くのこずが起こり、倚くの非垞に有甚な進歩がありたした。今、以前ずはたったく異なるC ++を曞いおいたす。 C ++ 14では、ただ少し改善されおいたすが、C ++ 17では、党䞖界が再び倱望したした-぀たり、誰もが埅っおいた機胜はそこにありたせん。 誰もが䞀般的に望んでいお欲しかった䞻な機胜はモゞュヌルです。 今ではC ++のコンパむルが非垞に遅くなっおいたす。぀たり、プラむマリコンパむルです。 MSVCによる刀断では、その増分性は非垞に優れおいたすが、たずえばれロから組み立おるのは平均的な喜びよりも少ないです。 さお、モゞュヌルはこの問題を解決する必芁がありたすが、い぀誰も知りたせん。



繰り返しになりたすが、C ++には、最も基本的なものが暙準ラむブラリにないずいう問題がありたす。 そしお、これは文字列を小文字に倉換する必芁があるか、トヌクンで打぀必芁がある初心者です。 もちろん、倚くのサヌドパヌティラむブラリがありたすが、ラむブラリの䜿いやすさも問題です。 メタデヌタを持぀蚀語-関数が衚瀺され、その䜿甚方法がわかりたす。ドキュメントもdocumentationめられたす。 たた、C ++では、Func型のテンプレヌト匕数関数を䜿甚できたす。たた、䞊べ替えを行っおも、関数のシグネチャを理解できない堎合がありたす。 実際、これをどうするかは明確ではありたせん。



䞀般に、芁玄するず、䞡方の蚀語は生きおいるかのように芋え、すべおは実際に必芁なものに䟝存したす。 䞀般的に、䞡方で生産的に曞くこずができたす。 Libに関しおは、ここでプロは負けおいたす。これは誰にずっおも明らかです。 蚀語はかなり叀く、ラむブラリは、たずえ存圚しおいおも、Cの䞖界からはあたり䜿い物にならないか、単に存圚しないため、倖郚から探しおダりンロヌドし、コンパむルしおから䜿甚する必芁がありたす。



オレグ・クラスノフ



-なぜC



-SEMrushに参加したずき、他の蚀語のサヌバヌロゞックに倧きな進展はありたせんでした。 圓時、私は䞻にCでプログラミングし、この蚀語で補品を開発するこずにしたした。 私は自分を信じおいたした。 =

私にずっお、Cはシンプルで䟿利な蚀語です。 ラむブラリの十分なスキルず知識を備えおいるため、スクリプト蚀語レベルでの開発のプロトタむピングに最適です。

SEMrushでは、サヌバヌプログラミング蚀語のうち、ディストリビュヌションはおよそ次のずおりです。1/ 3はCおよびC ++、1/3はスクリプト、1/3はJavaです。



-JavaずC、今最も人気のある蚀語は䜕だず思いたすか 䞡方ずも倧人ですが、誰がより成熟しお掗緎されおいたすか



-私の経隓では、蚀語Cでは生産的なタスクに関連するものを開発する䟡倀があるこずが瀺唆されおいたす。 たずえば、これは、゜ケット、デヌタ倚重化、高負荷のマルチスレッドアプリケヌションで動䜜し、コンピュヌタヌリ゜ヌスを完党に管理できたす。

SEMrushは、アプリケヌション領域ごずにプログラミング蚀語を明瀺的に区別したせん。 新しい補品を開始する必芁がある堎合、蚀語の遞択は、アヌキテクチャずプログラミングの開発を開始する人のプロ意識に䟝存したす。 たた、圌がいかにコミュニケヌションを図り、圌が実珟したいアむデアを同僚に䌝えるこずができるかに぀いおも。

私たちにずっお非垞に䞀般的なタスクは、デヌタの収集ず凊理です。 たずえば、すべおの補品でJavaを䜿甚するわけではない理由の1぀は、゚ンティティに関しおは野生の継承がないためです。 䜜業の詳现により、垂盎面での深さは氎平面での深さよりも小さくなっおいたす。 ぀たり、芪ず子孫の間ではなく、独立した゚ンティティ間で倧量のデヌタが転送されたす。



-個別のシステムモゞュヌルを異なる蚀語で開発し、特定のタスクのためにそれらを匷化するこずは理にかなっおいたすか



-そうだず思う。 この点で、すべおが非垞にうたく配眮されおいたす。 開発は5〜6人の小グルヌプで実行され、各グルヌプは独自の補品で動䜜し、それらの間の盞互䜜甚はAPIを介しお実行されたす。 ナヌザヌむンタヌフェむスずサヌビスの䞡方が、盞互に「うたく」盞互䜜甚する必芁がありたす。 これは、たずえばJSONやBinary-JSONなどのデヌタ圢匏を䜿甚しお行われたす。 したがっお、はい、異なる蚀語を䜿甚しおシステム党䜓を䜜成できたす。



Cで蚘述された独自のデヌタベヌスがあり、その操䜜に倧きな問題はありたせんでした。 このベヌスのアヌキテクチャを開発しおいたずき、適切な既補の適切なツヌルはありたせんでした。 このデヌタベヌスは通垞のファむルで機胜し、これを考慮するず、非垞に信頌できたす。 スムヌズな運甚バックアップ、クラスタリングを確保するためのすべおの察策を考慮から陀倖した堎合、「萜ちた」ドラむブハヌドりェアの誀動䜜たたは予期しない技術的理由でも倧きな害はなく、デヌタの8.5しか倱われたせん。 ぀たり、ナヌザヌが苊しむ可胜性は、ビゞネスロゞックのレベルでさらに䜎䞋したす。 しかし、䞀般的に、システムはデヌタが倱われないように蚭蚈されおいたす。 すべおが非垞に信頌できたす。

12台のディスクでハヌドりェアのパフォヌマンスを最倧限に掻甚するためのテストを実斜したした。 RAID5を䜿甚した堎合、読み取り/曞き蟌み速床は1台のハヌドドラむブの玄2.5倍の速床でした。 しかし、システムはビゞネスロゞックのレベルで12個のディスクを個別に䜿甚したす。これにより、各ストリヌムが独自のディスクで動䜜するため、速床が11倍になりたす。



-゚ンタヌプラむズでは䞀般的に蚀語はどのように感じたすか



-私たちには倧きな補品がありたす。 たずえば、そのうちの1぀はむンタヌネットをバむパスし、互いにリンクしおいるサむトペヌゞのデヌタベヌスを䜜成したす。 コアはCで蚘述されおおり、ほが100の「鉄」を凊分できたす。 この補品には150台以䞊のサヌバヌが関係しおいたすが、このアプロヌチにより、サヌバヌパヌクに過剰な支払いがないこずを確認できたす。ご存知のように、財務効率が心配です。 それずは別に、アゞャむル開発プロセスのおかげで、ナヌザヌに新機胜を提䟛する時間ず、各補品のパフォヌマンスを向䞊させる時間の䞡方があるこずに泚意しおください。



-゚ンタヌプラむズシステムず可胜な゜リュヌションを開発する際の最も䞀般的なパフォヌマンスの問題は䜕ですか



-正盎に蚀うず、特定の問題を思い出すこずさえできたせん。 突然十分なパワヌがない堎合は、アセンブラヌ、特別なラむブラリヌ、高玚プログラマヌの努力により、問題を非垞に迅速に解決できたす。 しかし、99の堎合、生産的な゜リュヌションはありたせん。

Javaに偏芋はありたせんが、より倚くのリ゜ヌスを消費したす。 はい。その助けにより、耇雑なマルチレベルビゞネスロゞックの問題を解決し、盞互接続されたシステムを構築するのに非垞に䟿利です。 ただし、ネットワヌク、マルチスレッドプログラミング、たたは倧芏暡なバむナリデヌタなどのタスクは、私の意芋ではCに適しおいたす。Javaでもこれを行うこずができたすが、Cを遞択したす。



-「理想的な」デヌタベヌスはどうあるべきだず思いたすか システムのすべおの胜力がデヌタベヌスぞのトランザクションによっお平準化される堎合、アプリケヌションのパフォヌマンスを気にする䟡倀はありたすか



-理想的なデヌタベヌスは普遍的ではありたせん。 -. , , «» .



— , , — Java ++?



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



— Java C++? , , ? ( )?



— 99, , . , . ++ — ++14 ++17 (draft) , , . , . . .

++ ++. . . ++, .





— ? , ? ( ), ++ ?



— . — . 10 , , 10 , . , , , , . . — . , java , , .. C++ . , java , .



— Unsafe Java, ? ++?



— , Unsafe Java () , . unsafe java . , OpenJDK java.util.HashMap Map.Entry , , . , , .. , . , javac JIT- .



C++, - entry . , . ++ .



java ? Unsafe, off-heap ? , , , . java HashMap .



« », (Unsafe, VarHandlers, memory mapped files, ..). , JEP 169: Value Objects — , Java .



— Enterprise- ?



— , . , SQL-. ぀たり . , , . «» . , . API 1000 , .



— JDK 9 — ? , Java?



— Java . , 30 , .



Java- ? ? .class JVM . JDK9, , , , java-. Java- , , .



– java-. JVM , .



— , C++ Java — runtime, , , ?



— Java — . , java- Iterator. , «» (invokeinterface). , Iterator . JIT- , , « hasNext». , - , « ».



C++, , , , .



, — . C++ «» , C++ (clang LLVM, ..).





?


More articles:


All Articles