Intelの業績が冴えない。2024年8月1日に発表された2024年第2四半期（Q2）の決算は、売上高が128.2億米ドルで、営業損失が19.8億米ドル、最終損益が16.1億米ドルといずれも赤字を計上した。加えて、従業員15000人を削減し、配当を停止することも発表された。 Intelの不調は今に始まったことではない。2019年以降の四半期の売上高と営業利益を見てみると、コロナ特需によって2021年に営業利益が増大したが、2022年に入って特需が終焉すると、売上高も営業利益も急降下した。特に営業利益は、2022年Q2以降、ほとんど赤字で推移するようになった（図1）。 その後、2022年11月30日に、Open AIがChatGPTを公開すると、米NVIDIA、米AMD、SK hynixなどが売上高を大きく伸ばす一方、Intelの売上高は横ばいで、営業利益はまたしても赤字に陥った。要するに、
アウト・オブ・オーダー実行について補足 前回の記事で「アウト・オブ・オーダー実行」について特に説明せずに話を進めてしまったことに気づいたので、まずはそれについて簡単に補足しておこう。 コンピューターの性能向上の歴史はレイテンシーとの戦いの歴史でもある。 colin-scott.github.io 上のサイトは年代毎にコンピューターシステムでの各種レイテンシーがどのように変化していったかを紹介している。1990年代前半はキャッシュメモリとメインメモリとの間のレイテンシー差はそれほど大きくなかったが、その後の技術革新によって現在はL1キャッシュとメインメモリとの間に100倍くらいのレイテンシー差があるようになってしまった。これはつまり、プログラム実行中にメインメモリへのアクセスが発生してしまうと、それだけ長いレイテンシーの間CPUの処理を進めることができなくなってしまうことを意味する。そのため
OS のメモリ管理の仕組みについて調べたことをまとめました。 読んでいただくと、以下のようなことについて少し詳しくわかるかもしれません。 あるユーザー空間プロセスが他のユーザー空間プロセスのメモリにアクセスできない理由 ユーザー空間プロセスがカーネル空間のメモリにアクセスできない理由 ユーザー空間のプロセスとスレッドの違いはどのように実装できるか 共有メモリはどのように実装できるか メモリマップトファイルはどのように実装できるか malloc は何故必要か あるコンテナが別のコンテナのメモリにアクセスできない理由 コンテナと仮想マシンのメモリ領域の分離についての違い 上記の全ての点について、仮想メモリという一つの機構で概ね説明可能である、というのが今回のポイントです。 また、そもそものユーザー空間プロセスとメモリの関係についても、少しわかるかもしれません。 当記事は、x86-64 CPU
PC向けCPUの主流な命令セットアーキテクチャであるx86は、Intel 8086プロセッサに起源を持ち、46年の長きにわたって使われてきました。そんなx86は近い未来に滅んでしまうだろうと、技術系ブログのHackadayが主張しています。 Why X86 Needs To Die | Hackaday https://hackaday.com/2024/03/21/why-x86-needs-to-die/ x86を採用する現代のCPUは、複雑な命令セットコンピューターであるCISC、1クロックサイクルあたり複数の命令を実行可能な「スーパースカラー」、命令を高速化するため順序を変更して実行する「アウト・オブ・オーダー実行」、分岐先の命令を条件が満たされるか不明な状態で実行する「投機的実行」を特徴とする、フォン・ノイマン型アーキテクチャの一部分です。x86はもともとは16bitプロセッサで
Hackaday recently published an article titled “Why x86 Needs to Die” – the latest addition in a long-running RISC vs CISC debate. Rather than x86 needing to die, I believe the RISC vs CISC debate needs to die. It should’ve died a long time ago. And by long, I mean really long. About a decade ago, a college professor asked if I knew about the RISC vs CISC debate. I did not. When I asked further, he
簡単に書くよ メモリインターリーブ（英：memory interleaving）とは メモリを何となく分身させて同時にやり取りすることで、CPU（コンピュータの脳みそに相当する部品）とメモリの間のやり取りを速くする技術 です。 順番に見ていきましょう。 まずは予備知識として「CPU」と「メモリ」について簡単に説明します。 「そんなの説明されなくても知ってるよ！」な人は適当に読み飛ばしてください。 CPUは「パソコンさんの脳みそ」です。 実際に計算したり、あれやこれやの処理を実行する部品です。 今回、登場するメモリは「パソコンさんが作業するときに使う机」です。 仕事中の内容を記憶させておく部品であり、CPUさんが直接読み書きできる記憶装置です。 「メインメモリ」とも呼ばれます。 以上を踏まえて、本題に入ります。 CPUとメモリの関係は CPU：データを使うやつ メモリ：データを持っておくやつ
Alder Lake以降のIntel CPUでは、P-coreとE-coreの2種類のコアが搭載されている。 P-coreは性能重視、E-coreは省電力重視という位置づけで、OSがうまくこれらのコアを使い分けることで、消費電力と性能の両立が図られている。 ここまでの話は広く知られているが、実際にどのようにしてOSに対してコアの使い分けをさせているのかの実装レベルでの解説は (少なくとも日本語では) ほぼ存在しないようなので調べてみた。 OSから見たP-coreとE-core OSの役割の一つとしてプロセススケジューリングがあり、どのプロセスをいつどれぐらいの期間どのCPUコアで実行するかを決める。OSができるだけ効率よくプロセスをスケジューリングするためには、CPUコアの性能や消費電力の違いを考慮したスケジューリングが必要になる。そこで、Intel CPUではOSに対して次の2つの情報を
『Zenbleed』に対するUbuntuの対応 Zen2シリーズ（＝Ryzenプロセッサーの一部）に影響する、『Zenbleed』と呼ばれる脆弱性（CVE-2023-20593）が公開されました。AMDからも脆弱性情報が提供されています。 影響があるのはZen 2アーキテクチャを採用したCPUファミリーです[1]。 今回見つかったものは、Spectreのときのようなサイドチャネル攻撃（つまり「新しいタイプの攻撃手法によって見つかった新しい脆弱性」）ではなく、純粋なCPUのバグです。サイドチャネル攻撃の場合は「このような操作をすると、CPU上で扱っているデータを推定することができました。たとえば処理にかかる時間の差とか」というものだったのですが、今回のものは「こういう操作をすると、なんだかCPUがおかしな挙動をしていることがわかりました、直前まで扱っていたデータを復元可能です」というもの
CPUのx86/x64/x86_64/AMD64/i386/i686とはなんなのか？についてわかりやすくまとめます まとめ 実際の定義はこちら 一般的な理解はこちら ビット数の違い（32bit、64bit）とは CPUのざっくり歴史（32bit〜） x86とは なんでx32じゃなくてx86っていう名前なの？ x64とは そのほか i386とは i686とは IA-32とは IA-64、Intel 64の違い まとめ 出てきた単語をざっくり分類 bit数 アーキテクチャ 32bit x86、i386、i686、IA-32 64bit x64、x86_64、x86-64、AMD64、IA-64、Intel 64 実際の定義はこちら 一般的な理解はこちら ※厳密にはPentiumやCeleronも型番によって違うなどありますが、大雑把にはこんな感じです。 ※一般的な理解としてはx86=32bit
(最新SSD IOはPCIe x4でした。ご指摘ありがとうございます。） はじめに どの処理で律速しているか調べる 各処理の速度改善方法 データ読み込み速度の改善 データ前処理速度の改善 GPU処理速度の改善 コンピューティングについての他記事 はじめに Kaggle Advent Calendar 2022 8日目です。 突然ですが、あなたはDNN学習時にどの処理で学習速度が律速しているか把握してますか？ DNN学習には図に示すように大きく3つの要素があります： （SSDからの）データ読み込み （CPUによる）データ前処理 （GPUによる）DNN計算 学習時のデータの流れとしては SSDからデータが読み込まれ、CPUに送られる(SATA or PCIe) CPUにてaugmentationや正規化などの前処理が行われ、GPUにデータが送られる(PCIe x16) GPUにてDNNの計算・
Apple M1についての面白い記事を見かけて、久しぶりにメモリモデル屋(?)の血が騒いだのでブログを書く。 note.com 強いメモリモデル 現代のCPUアーキテクチャでは、x86(64bit, 32bitどちらも)が「強いメモリモデル」を採用しており、それ以外のメジャーなCPUが「弱いメモリモデル」を採用している。この「強いメモリモデル」「弱いメモリモデル」について、まずおさらいしておこう。 以下のように、2つの変数a, bに対して異なるCPUコアが同時にアクセスしたとする。 int a = 0; int b = 0; CPU1: a = 1; b = 1; CPU2: int r1 = b; int r2 = a; (上記はC言語に似た疑似コードを用いているが、実際は機械語命令になっていると考えてほしい。つまり、CPU1は変数a, bの示すメモリアドレスに対するストア命令を実行して
Apple SiliconのM1が速いと話題だ。単に速いというだけでなくRosetta 2を用いてx86_64バイナリをARMに変換して実行した時にIntel CPUで直接実行した時より速くなる場合があるというのだから驚きだ。その要因を考察するにつれ一つの仮説に思い至ったのでここに記しておく。 その要因とはRISCとCISCの違いだ。殴り書きなので詳細は省くが、CISCのほうがやってることが複雑で単純な実行速度という意味ではRISCに敵わない。特にRISCの固定長命令という特徴がカギを握る。 CISCの代表がIntelのx86である。しかし2000年ごろにはCISCはもう駄目だ的なことが声高に叫ばれていたが、気が付けばx86はそのまま栄華を極め2020年にまで至ってしまった。そこまで持ちこたえた理由の1つがRISCとCISCの境目がなくなる Pentium Proの逆襲に書かれているのだが
macOSのM1とx86-64におけるベンチマーク比較の考察
世間ではAppleの新しい製品に使われるARM64 CPUであるM1の話題でもちきりだ。ただし、日本語を話す記者というのは極めて非科学的かつ無能であり、M1の現物を手にしても、末端のソフトウェアを動かして、体感で早いだの遅いだのと語るだけだ。そういう感想は居酒屋で酒を片手に漏らすべきであって、報道と呼ぶべきシロモノではない。 と思っていたら、Phoronixがやってくれた。M1とi7で動くmacOSでベンチマークをしている。 これを考察すると、M1のMac Miniは、一世代前のi7のMac Miniに比べて、メモリ性能とI/O性能が高く、演算性能は低いようだ。このことを考えると、M1の性能特性としては、動画のエンコードやソフトウェアレイトレーシングをするには不向きだが、その他の作業は遜色ないだろう。 問題は、仮想化とRosettaを組み合わせることができないという点だ。x86-64のユー
IT分野の問題に鈍感な日本のメディア 新年早々、イギリスのテクノロジー専門メディアによる「CPU（中央演算処理装置）の脆弱性」スクープのおかげで、米インテル固有の欠陥という誤解がすっかり拡散してしまった。 日本の大手メディアはほとんど見過ごしたが、脆弱性を発見した米グーグルの”ハッカー集団”が震撼したのは、今後に深刻な影響を及ぼしかねないIT社会特有の構造的な「闇」だった。 コトの発端は、多くの日本人が今年の初夢を見ていたころのことだ。1月2日（現地時間）の夜に、英レジスターが報じた「半導体大手インテルのCPUの構造的な欠陥（脆弱性）が原因で、OSのカーネル（中核）部分に保管されている重要情報が盗まれるリスクがあり、リナックスやウィンドウズで再設計が必要になっている」という記事である。 目的不明のウィンドウズOSアップデートがくり返されていることに着目した同メディアが取材した結果、インテル
NOTE1: 2017/8/12に2つ目の問題について更新しました。ついに両方の問題が解決しました。 NOTE2: 2つ目の問題についてはすべての経緯をまとめた書籍があります。 4月にRyzenを積んだデスクトップマシンを買いました。その上で日課であるカーネルビルド&テストをした*1ことをきっかけに、2つの問題が発生しました。先代のCore i5を積んだマシンでは起きなかった現象です。 このエントリは自分用のメモがてら、新しいことがわかれば随時更新していきます。後者については9月に開催されたkernelvm北陸にて、本ブログには書かれていない解析の詳細などについて発表してきました。 Ryzen segv battle from Satoru Takeuchi www.slideshare.net 環境 ハードウェア CPU: Ryzen 1800X Motherboard: ASUS PR
ここ一ヶ月ほどQEMUのコードとお戯れしていたのですが、 qemuのソースコードもうすぐ読みきりそうなのでどこかにまとめたいんだけど、qemu internalみたいな記事ってどれぐらい需要あるの— 前代未聞 (@RKX1209) 2015, 11月 9 と言ってみた所なんとなく需要がありそうだったので書きました。 本記事ではQEMUの内部実装を追い、具体的な仕組みを見ていきます。もし研究や仕事などでqemuを読む必要がある方や、これから趣味で読んでみようという方はぜひ参考にしてください。 (QEMU internalsというよりはQEMUコードリーディングの方が適切かもしれませんね....) さてここで扱うQEMUはqemu2.4.0でゲストはx86,ホストはx64であると仮定します。 両方共x86系となるとDBTの意味はあまり無く、KVM使ってどうぞという話になるのですが、あくまでコー
iOSアプリケーション開発会社の経営者であるDrew Crawford氏は、現在のモバイルWebアプリケーションが遅く、また、近い将来にその遅さが大幅に改善されると思えない理由を、ブログ記事（内容が充実しており、良く調査して書かれている）の中で明らかにした。 このブログ記事は、これより前に書かれた記事への追加記事である。前の記事で氏は、モバイルにおけるJavaScriptのパフォーマンスがデスクトップの10倍遅いことを指摘した。その記事は激しい批判を浴びたため、Drew氏はそれに答える形で、さらに詳細な内容の記事を記した。モバイルの貧弱なパフォーマンスと、それについての改善が見られない理由は、次の3つに分類される。 モバイルのARMプロセッサのスピードと、デスクトップのx86プロセッサのスピードとの違い JavaScriptエンジンのパフォーマンスの傾向 ガベージコレクションに関連する特定
作成日：2006.03.30 修正日：2016.10.17 更新記録 (2006.03.30) 2006/3/10 と2006/3/11 の日記の内容を元に作成。 (2006.04.07) SPARC 32 ビットプロセッサのページテーブル構成を修正。 (2006.05.25) 3.2節ページテーブルエントリを追加。 (2012.05.29) PowerPC のセグメントサイズの誤りの修正と図の追加。 (2016.10.17) Intel64 の Process-Context Identifiers(PCIDs) と Protection Keys の説明を追加。また TLB エントリの無効化と ARM の情報も追加。タイポの修正。 1. はじめに 2. 仮想メモリの全体像とページング以外の機構 事前処理 事後処理 3. ページング 3.1 ページウォーク 3.2 ページテーブルエントリ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
