初めに 今月初め (2024/11/9) のKernel/VM探検隊@北陸 Part 7で、satoru_takeuchiさんによる「利きプロセススケジューラ」という発表がありました。そこで二番煎じではありますが「利きx64アセンブラ」というネタを紹介します（ネタ自体は前から構想はあったけど形にはしてなかった - 言い訳）。 アセンブラ アセンブラとはアセンブリ言語で書かれたプログラムを機械語のバイト列に変換するツールで、ここではx86-64アーキテクチャ用アセンブラを対象とします。 アセンブラなんてCPUの仕様書にしたがってバイト列を生成するだけなのでアセンブラごとの違いなんてあるの?と思われるかもしれませんが、よく探してみると意外と個性が出ることがあります。 筆者は長年JITアセンブラXbyakというものを開発していたので、アセンブラが生成したバイト列を眺めることが多く、その違いにはま
Contemporary high-level programming languages and advanced compilers greatly simplify software development and lower its costs. However, this way of programming can hide the performance capabilities of modern hardware, partly due to inefficiencies of application programming interfaces (APIs). Apparently, a good old assembly code path can improve performance by between three and 94 times, depending
浮動小数点数の演算結果は環境によって変わる場合があります。どういう場合に変わることがあり、それはどういう原因によるのでしょうか。この記事では、演算結果が変わる原因として考えられるものをいくつか紹介します。 対象とする言語はC言語とします。基本的にC17の前提で書きますが、一部にC23への言及を含みます。 C言語では浮動小数点演算の精度は処理系定義です（C17 5.2.4.2.2.7）。C言語的に浮動小数点演算についてまともなことが言えるのは処理系がAnnex Fに準拠している場合です。C17のAnnex FはIEEE 754-1985を参照し、C23のAnnex FではIEEE 754-2019を参照します。 ただ、この記事では「どういう場合に変わるか」を考え、「どういう場合に結果が変わらないことが保証されるか」はあまり考えないので、Annex F準拠であるかはあまり重要ではないかもしれま
浮動小数点数にはIEEE 754という標準規格がありますが、規格の範囲内であっても僅かに実装による差異が認められています。その一つがNaNのビットパターンです。 WebAssemblyはNaNのビットパターンに関しては実装依存の結果を許容しており、Wasmランタイムは特に深い理由がなければホストCPUの浮動小数点命令をそのまま用いると考えられるため、結果として「WasmからNaNのビットパターンを観測することでホストのCPUの命令セットを推測する」ことができます。 ここでは、「x86(_64)」「RISC-V」「その他（Armなど）」の3択で判定することを目指します。 判定コード 判定するコードは以下です： #include <inttypes.h> #include <stdio.h> #include <string.h> float u32_to_f32(uint32_t x) {
サイバーセキュリティ企業のIOActiveは2024年8月10日に、AMDの数多くのCPUに影響を及ぼす重大なセキュリティ脆弱(ぜいじゃく)性「Sinkclose」の存在を公表しました。これを受け、AMDは比較的新しいCPUに対して脆弱性を軽減するパッチを提供しています。一方で2017年に生産されたRyzen 1000シリーズなど、比較的古いモデルについてはアップデートの予定はないとのことです。 DEF CON Official Talk | AMD Sinkclose: Universal Ring-2 Privilege Escalation | Las Vegas, NV – IOActive https://ioactive.com/event/def-con-talk-amd-sinkclose-universal-ring-2-privilege-escalation/ SMM
Tuesday, May 21, 2019 A few months ago it dawned on me that I didn’t really understand how computers work under the hood. I still don’t understand how modern computers work. However, after making my way through But How Do It Know? by J. Clark Scott, a book which describes the bits of a simple 8-bit computer from the NAND gates, through to the registers, RAM, bits of the CPU, ALU and I/O, I got a h
シリーズ： CPUの機能を実行時に検出する：x86編（この記事） CPUの機能を実行時に検出する：Arm編 CPUの機能を実行時に検出する：実践編 その辺で売っているCPUは世代を経るにつれて性能が向上するだけではなく、使える命令が増えていきます。x86系であればSSEが実装され、AVXが実装され、AVX-512が実装され（そして削除され）、という感じです。Armもアーキテクチャーのマイナーバージョンが上がると命令が増えたりします。 新しく追加された命令をプログラムから利用したいとき、直接呼び出してしまうとそのプログラムは古いCPUでは動かなくなってしまいます。コンパイルオプションで切り替えるというのも一つの方法ですが、同じバイナリーを複数のCPUで動かし、最適な性能を得たいという場合に困ります。そこで、実行時にCPUの機能を検出して、プログラム内で分岐するという方法が考えられます。擬似コ
最近、プロセッサに「NPU」と呼ばれる人工知能（AI）処理に特化したユニットが搭載されるのがちょっとしたブーム（？）になっている。このNPUって、GPUなどと何が違うのか、なぜプロセッサに搭載されるようになってきたのか解説しよう。 プロセッサに搭載されている「NPU」って何？ Intelの最新プロセッサ「Core Ultra」には、人工知能（AI）処理に特化した「NPU」が搭載されている。NPUは、スマートフォン向けのプロセッサにも搭載が進んでいる。ところで、このNPUはCPUやGPUと何が違うのだろうか？ 写真は、Intelのプレスリリース「AI PCの新時代の到来を告げるインテル Core Ultra プロセッサー」のCore Ultraプロセッサーの写真を使って、「CPU」「GPU」「NPU」の文字を載せたもの。 今回のお題は「NPU」である。出だしから注釈になってしまうが、NPUと
従来から、「ARMはx86より（電力的に）効率的だ」という言説があります。これは単純に「ARMは省電力なスマホ向けで、x86は電力を食うPC向け」程度のアバウトなイメージのこともありますし、前世紀のRISC vs CISC論争のころからある「ARMはx86 (x64を含む)に比べ命令セットがシンプルなので、命令デコードにかかる電力が少なくて済んで効率的」という議論の形をとることもあります。 この議論については、半導体エンジニアの多くは「ARMがx86 より効率が良いというのは、もはや過去の神話」(in today’s age it is a very dead argument)という認識を共有していると言っていいでしょう。有名なところではApple CPU (ARM)とZen (x86)の両方を開発したジム・ケラー氏のインタビューでも言われていますし、Chips and Cheeseとい
この記事はUTF-8のバリデーションとオートマトンの続きです。 前回はUTF-8のバリデーションが8状態のオートマトン (DFA) で表現できることを見ました。状態と遷移を擬似コードで書けば次のようになるでしょう： -- 8つの状態 data State = START | TAILx1 | TAILx2 | TAILx3 | A | B | C | D -- 入力バイトに応じて次の状態を返す。次の状態が該当しなかったら Nothing を返す next :: Word8 -> State -> Maybe State +----+----+-----+----+ | a0 | a1 | ... | aN | 8ビット整数列 +----+----+-----+----+ | | | v v v +----+----+-----+----+ | m0 | m1 | ... | mN | モノ
長年CPU製品を市場に送り出してきたIntelとAMD。良きライバルでありながらも、技術の標準化において協力関係にある両社。製品の性能を比較することはあっても、これまで互いを罵り合うような関係ではなかった。 だが、IntelがAMDを公式に非難したとして話題になっている。しかも、その中で過激な言葉も使われたとか……。一体、両社の間に何があったのか？ IntelがAMDに対して「Snake oil」と罵ったことが始まりだった。これは、19世紀終盤から20世紀の初頭にかけて米国で使われていた言葉なのだそうだ。Snake oilとは効果がなかったり、効果を大げさにうたったりしている薬品や治療法のことを指し、そこから転じて「インチキ」「詐欺」といった意味を表す言葉として使われている。 Intelは2023年12月4日に「Core Truths」と題したスライドを自社のWebサイトに公開した。Sna
関連キーワード Intel（インテル） | Google | 脆弱性 Intel製CPU（中央処理装置）に、機密情報の漏えいにつながる恐れのある脆弱（ぜいじゃく）性が見つかった。2018年にGoogleが公開した「Spectre」「Meltdown」に続いて、Intel製CPUの新たな脆弱性が明らかになった形だ。 2023年8月、GoogleはIntel製CPUに脆弱性「Downfall」（CVE-2022-40982）を発見したと発表した。攻撃者がDownfallを悪用すると、レジスタ（CPU内蔵メモリ）のデータにアクセスできる可能性があるという。第6世代（開発コードネーム：Skylake）から第11世代（開発コードネーム：Tiger Lake）までのIntel製CPUが、Downfallの影響を受ける。 「Downfall」は何が危険なのか？ 併せて読みたいお薦め記事 脆弱性によるリス
この記事は検証可能な参考文献や出典が全く示されていないか、不十分です。 出典を追加して記事の信頼性向上にご協力ください。（このテンプレートの使い方） 出典検索?: "メモリバリア" – ニュース · 書籍 · スカラー · CiNii · J-STAGE · NDL · dlib.jp · ジャパンサーチ · TWL (2023年7月) メモリバリア（英: memory barrier）またはメモリフェンス（英: memory fence）とは、その前後のメモリ操作の順序性を制限するCPUの命令の一種である。 CPUには、性能最適化策としてアウト・オブ・オーダー実行を行うものがあり、メモリのロード命令やストア命令を含めて順序を入れ替えて実行することがある。この命令の並べ替えは、ひとつのスレッドの中で一般に暗黙のうちに行われるが、マルチスレッドプログラムやデバイスドライバでは慎重に制御しない
現在、最先端の半導体チップを開発・製造・販売するバリューチェーンに大変革が起こりつつあることをご存じだろうか。これまでは異なるメーカーから個別供給されていた半導体チップが、1つのパッケージの中に統合されて供給される時代が到来しようとしているのだ。その背景にあるのが「チップレット」と呼ばれる技術であり、半導体業界の関連企業がこぞって注目している。チップレット技術の概要とその技術的なインパクト、それによってもたらされる近未来を解説する。 米Intel（インテル）のCPU（中央演算処理装置）と米NVIDIA（エヌビディア）のGPU（画像処理半導体）、場合によっては米Qualcomm（クアルコム）の移動通信用ベースバンドチップや韓国Samsung Electronics（サムスン電子）のDRAM（一時記憶向けメモリー）まで――。これまで個別供給されていた別メーカー製の半導体チップが、1つのパッケー
本書の構成 第1章。「ふむふむ、このレベルから説明してくれるのか」 第２章の途中からギアアップしてきて、「スーパースカラ+スーパーパイプライン化」で現代のCPUの規模感のようなものを思い知ることになります。順調にCPUの中を流れる命令列はまるでナイアガラの滝のよう。 でもちょっとしたことでその流れは止まってしまい、そのペナルティの大きさを実感することになります。 第3章から第8章で、CPUの処理の流れを止めるさまざまな要因が語られていきます。 第9章は「マルチプロセッサ」。一段と複雑になる要因ですが、現代のCPUでは外せないもの。 第10章から第12章で、共有メモリ型マルチプロセッサでのマルチスレッドをするときの注意点が語られていきます。 第13章がまとめ。それ以降は付録です。 私としては第9章の「マルチプロセッサ」以降が非常に勉強になりました。ぼんやりとしかわかってなかったことがこれでク
Kernel/VM探検隊online part6 で Rui Ueyama 氏による『リンカー moldをいろんなターゲットに移植した話』のセッションを視聴し、普段は接点のないCPUやpsABIといった低レイヤーの世界を覗き見したので、メモを残しておきます。 動画 発表スライド Ruiさんは、LLVMのリンカlldの作者でもあり、過去には同勉強会のPart 2でもリンカについて発表されています。 超高速リンカmold 1/2 - ログミーTech 超高速リンカmold 2/2 - ログミーTech 今回も、前日に発表が決まったとはとても思えない、非常に濃い発表でした。 本テーマは筆者の普段の業務と大きく異なります。間違いなどがあればコメントで指摘していただけると助かります。 以下の様なキーワードが頻出します。 リンカ psABI ELF QEMU ISA RISC/CISC エンディアン
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
