This domain is registered at Dynadot.com. Website coming soon.
巷ではIntel, AMD, ARMを巻き込んだCPUのバグ "Meltdown", "Spectre" が話題です。 これらの問題、内容を読み進めていくと、コンピュータアーキテクチャにおける重要な要素を多く含んでいることが分かって来ました。 つまり、このCPUのセキュリティ問題を読み解いていくと現代のマイクロプロセッサが持つ、性能向上のためのあくなき機能追加の一端が見えてくるのではないかと思い、Google, Intelの文献を読み解いてみることにしました。 が、私はセキュリティの専門家ではありませんし、過去にデスクトップPC向けのような大規模なCPU設計に参加したこともありません。 あくまでコンピュータアーキテクチャに比較的近い場所にいる人間として、この問題の本質はどこにあるのか、可能な限り読み解いていき、現代のマイクロプロセッサが持つ高性能かつ高機能な内部実装について解き明かしていき
あけましておめでとうございます! 去年は AWS 認定試験を制覇したので、今年は実践スキルを今以上に磨いていこうと思います。 さて、最近の EC2 インスタンスは Intel CPU のプロセッサー・ナンバーが公開されています。ですが M1, M2, C1 といった旧世代インスタンスでは CPU にばらつきがあり、当たり外れの差が激しかったのは記憶に新しいところ。 当たりの CPU が出るまで stop → start を繰り返すインスタンスガチャも流行りました (笑) 今回は AWS の CPU について歴史を振り返りつつ、その戦略を考えてみます。物理レイヤーを意識することがほとんどない AWS ですが、物理の知識なしでは最高のパフォーマンスは得られません。知っておいて損はないでしょう。 インスタンスタイプのリリース時期は公式ブログ「EC2 の歴史」に載っていますので参考にしてください。
Hot Chips 29では、Intelは「Xeon Scalable Processor」と呼ぶ新プロセサを発表した。これは、これまで「Skylake-SP」と呼ばれていたプロセサである。Xeon Scalable Processorは、AMDのEPYCのような大変更はないが、バランスの取れた各種の改良が盛り込まれたデータセンター向けの新プロセサである。 従来、Intelのデータセンター向けCPUは「Xeon E5」とか「E7」とかいう名称であったが、今回の製品から、「Platinum」、「Gold」などという呼び方になった。 Xeon Scalable Processorは2016年Q2から出荷されているXeon E5、E7の後継となるサーバ用プロセサである。E5/E7が最大24コア、48スレッドであったのを最大28コア、56スレッドまで集積度を上げている。これまで複数のCPUチップの
CPU実験が終わって半年ですが、忘れる前にやったことを書き残しておこうと思います。 並列化ーー CPU実験 全体 4人程のチームで、自作CPU、コンパイラ、アセンブラ、シュミレータ等を作り、最終的には高級言語(mincamlというOcamlのサブセット)で書かれたプログラム(レイトレーシング)を実行速度を競います。CPU実験の詳細は検索すると結構出てくるかと思います。 レイトレプログラムの出力結果 自班の最終成果 『レイトレプログラムをマルチコアで並列実行する』ということをやりました。結論から言うとこれがかなり上手いこといって、歴代最速記録を大幅に(1/2位?)更新することができました。 具体的には記録は以下の通りです。詳しくは*1 4.666948 s(7コア、逐次実行と比べ演算順序が変わり得る) 5.193502 s(6コア、演算順序が変わらない) *実験の条件も年々良くなっているので
自分の「シンプルでシステマチックな〇〇性能分析」のルーツな面々のうちの2人*1 Brendan Gregg@Netflix と Tanel Poder@Gluent が素敵な絡みをしていたのでメモ。 @brendangregg Could be useful: I once documented my understanding of the typical CPU counters that perf exposes all in one place: https://t.co/pqaDdbDyi1— Tanel Poder (@TanelPoder) 2017年5月10日 Brendan Gregg はざっくり、以下のようなことを言っている。 CPUの1サイクルと比較してメモリアクセスは遅い*2ので、ON CPU でもメモリI/O*3待ちでストールしてることが多い。 IPC(Instr
はじめに Linux で採取できるCPU使用量(率)の情報として、%user や %sys 等に加えて %steal という量がある。これが追加されたのは、仮想化が広く使われはじめた10年くらい前だろうか。筆者は Xen を調べていて気づいたのだが、もっと前にs390のために追加されたのかもしれない。当時、ESXの場合も含めて調べていたのだが、最近、KVMの場合にどういう実装になっているのか、ふと気になって軽く調べてみたのでメモ。 CPU使用率の計算 まず最初に、sar や vmstat や mpstat 等、さまざまなツールでCPU使用率を取得することができるわけだが、どのような情報を元に、どのような計算を行って算出しているのか? まず、kernel内ではboot以後の各種実行モードのCPU時間を分類して積算値として保持している。user モード、特権モード、割り込み処理に使った時間..
Intel と AMD の CPU には AES-NI という CPU 命令拡張が搭載されています。詳細は Wikipedia を読んでください。ちなみに ARM にも AES 拡張が搭載されているものがあります。 ちなみに 私自身はハードがわからないので AES-NI の知識はまったくありません。AES がハードウェアによって高速化される程度の知識です。 ただ、AES といっても暗号の種類は CBC 以外にも、最近良く使われている AES-GCM (TLS 1.2 で利用) や、 WebRTC の SRTP で利用されている AES-CTR があり、実は CPU ごとに AES-GCM や AES-CTR はかなりの差があるというのを最近調べていて気づきました。 ということでインターネッツのちからを使って募集してみることにしました。この記事を読んだ人も是非お時間あれば、気軽にコメントして
Netflixのパフォーマンスエンジニアである筆者からの、topコマンドなどで表示されるCPU使用率(%CPU)は、いまや本当の使用率を表しておらず、チューニングなどのための指標として使えないという指摘。なぜそうなってしまったのか、何を見れば本当のCPU使用率がわかるのかをわかりやすく解説した記事。 私たちみんながCPU使用率として使っている指標は非常に誤解を招くもので、この状況は毎年悪化しています。CPU使用率とは何でしょうか?プロセッサーがどのくらい忙しいか?違います。CPU使用率が表しているのはそれではありません。私が話しているのは、あちこちで、あらゆる人たちに、あらゆる監視製品で、あるいはtop(1)でも使われている、"%CPU"という指標のことです。 あなたの考えているであろうCPU使用率90% : 実際 : "stalled"(訳注 : 以下ストールと言う)とは、プロセッサーが
ALF - Amdahl's Law is Forever (France) 88245Centre Inria de l'Université de Rennes (Campus de beaulieu 35042 Rennes cedex - France) 419153Inria - Institut National de Recherche en Informatique et en Automatique (Domaine de Voluceau Rocquencourt - BP 105 78153 Le Chesnay Cedex - France) 300009IRISA-D3 - ARCHITECTURE (France) 419364IRISA - Institut de Recherche en Informatique et Systèmes Aléatoires
先日の日記で最近のIntel CPUでは間接分岐の分岐予測がほとんどミスしなくなっているという話を紹介しましたが、Branch Prediction and the Performance of Interpreters - Don't Trust Folkloreという論文にまさに同じことが書かれているのを見つけました。ていうか、この論文わたし見た形跡がある……。 去年にこの論文を見かけたときは「Direct threaded codeとかオワコン」って話までしか見てなかったんですが、今改めて見ると分岐予測が世代ごとに進化していてすごいって話に加えて、ITTAGEという分岐予測手法を使うと同じくらい当たるって書いてありますね。 ITTAGEはTAGE (TAgged GEometric length predictor)の間接分岐版で、TAGEは原論文がA case for (parti
Recent posts: 04 Aug 2025 » When to Hire a Computer Performance Engineering Team (2025) part 1 of 2 22 May 2025 » 3 Years of Extremely Remote Work 01 May 2025 » Doom GPU Flame Graphs 29 Oct 2024 » AI Flame Graphs 22 Jul 2024 » No More Blue Fridays 24 Mar 2024 » Linux Crisis Tools 17 Mar 2024 » The Return of the Frame Pointers 10 Mar 2024 » eBPF Documentary 28 Apr 2023 » eBPF Observability Tools Ar
仮想アドレスと物理アドレスを変換する Address Translationの基本 前回はメモリーの階層構造と同様に、複数段階のキャッシュ構成があることを説明した。今回はちょっと見方を変えた話をしたい。まず、キャッシュという形でCPU内部に搭載されている、別のメモリーについて触れよう。 ご存知の通り、1次キャッシュは通常「ハーバード・アーキテクチャー」と呼ばれる構造に基づき、命令用とデータ用がそれぞれ別に用意される。詳細は後述するが、2次キャッシュや最近では3次キャッシュを搭載するプロセッサーも多くなった。ただ、これらはいずれも「プログラムそのもの、およびプログラムの実行時に利用されるデータ」である。 「ではそれ以外に何かあるのか?」と言われると、これが結構ある。一番多く利用されるのが「TLB」(Translation Lookaside Buffer)と言われるものだ。これは「仮想記憶」
Linux OSからFPGAを透過的に利用する構想。文字列処理をCPUからFPGAへオフロードで10倍速になった研究結果をミラクル・リナックスが発表 プロセッサ内部のロジックをソフトウェアで動的に書き換えることができるFPGAは、アプリケーションごとにロジックを最適化できるため、x86などの汎用プロセッサよりも高速かつ効率的なアプリケーションの実行が可能になると注目されています。 特に、今年の1月にインテルがFPGA大手のアルテラを買収し、XeonにFPGAを統合するという将来計画を発表してから、FPGAへの注目度はさらに高まっています。 しかしいまのところ、FPGAをアプリケーションから利用するには、ロジックを開発ツールなどを用いてFPGAに書き込み、それをデバイスドライバを経由してフレームワークなどを通じて利用するというものになります。 これをもっと簡単にしようという構想を明らかにした
今日はすごいアクセス数が来ると思ったら、ソフトバンクのARM買収により代替手法としてのRISC-Vについていくつかのツイートで言及されたためか、RISC-V関連のアクセスが急上昇したため、コメントも含めて"RISC-Vについて"のページを更新しておいた。 msyksphinz.hatenablog.com 現在の僕の考え方としては、RISC-VはARMの代替手段としては、まだ成熟していないのでは無いかと考えている。基本的な算術演算が出来ればアーキテクチャに大した違いはない、というのは大間違いで(あくまで僕の意見)、それぞれの時代に即した命令を追加していくことでアーキテクチャは進化している。 「この命令セットでは、計算は出来るけど性能は全然出ないよ」というのでは、アーキテクチャとしては使いものになっても最終製品としては全然使いものにならない、ってことだってある。 Extensionという形で
Multi-core processors are capable of running multiple software streams/tasks concurrently. Multi-core allows a physical processor to simultaneously execute instructions from multiple processes or threads. Core of a processor is the part that executes application instructions. Core is shared by hardware threads (called Hyper-Threads). When two hyper-threads are active in the same core, it results i
今どきCPUだけで大丈夫?ビッグデータや人工知能でGPU/FPGAを使う前に知っておきたい“ハード屋”と“ソフト屋”の違い:特集:インフラエンジニアのためのハードウェア活用の道標(3)(2/2 ページ) CPU、GPU、FPGA――適材適所での使い分けを 結論としてはごく当たり前だが、「特性を押さえて適材適所で使うことになるでしょう。GPUやFPGAでOSを走らせるのは難しいです。CPUにハウスキーパー的なことをやらせ、GPUやFPGAには重たいデータ処理をオフロードする形で、使い分ける必要があります」(泉田氏)というところに落ち着く。 ちなみにGPUとFPGAで比べたら、「GPUの方がプログラムを書くのは楽でしょう。CPUのソフトウェアパラダイムのちょっと先にある世界なので、ハードルは低いと思います。一方FPGAとなると、ハードウェアに落とし込む必要があるので、これまでソフトウェアしかや
後置インクリメントにはひと目で遅くなりそうな処理が見て取れますね。 前置インクリメントがインクリメント処理後、単純に自身の参照を返すのに対し、後置インクリメントではインクリメント前に一時オブジェクトの生成、そしてインクリメント後にはその前に生成した一時オブジェクトを値で返しています。 前置と後置では、単純にオブジェクトをコピーして返す分、普通に考えたら後置の方が遅いよね。というのが従来の認識でした。 「C++ Coding Standards -101のルール、ガイドライン、ベストプラクティス」の中でも、特に後置インクリメントの必然性が無い時は迷わず前置インクリメントを使うことが推奨されてきました。 元の値を必要としないときは前置形式の演算子を使おう __C++ Coding Standards (p50) 新たな主張 「ゲームエンジン・アーキテクチャ第二版」の中の一節を紹介します。 しか
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く