はてなブックマーク

今まで3回にわたって、行列サイズがコンパイル時にわかる場合の正方行列乗算の最適化を取り扱ってきました（行列乗算の最適化入門 - よーる、行列乗算の最適化入門（マルチコア編） - よーる、行列乗算の最適化入門（GPGPU編） - よーる）。 行列サイズがコンパイル時にわかる場合は、コンパイラの自動ベクトル化だけで限界に近い性能が出ました。 今回はちゃんとした行列積プログラム、つまり行列サイズがコンパイル時にわからない場合の正方行列乗算の最適化をやっていきます。 配列のオーバーラップを気にしているのか、どうにもコンパイラの自動ベクトル化ではうまくいかなかったので、ちょっとだけアセンブリ言語に手を出しました。 5×4レジスタブロッキングカーネル 行列乗算の最適化入門（マルチコア編） - よーるで示したように、レジスタブロッキングは5×4が最適でした。 これについて、なぜそうなるかの説明は難しいで

一般に整数除算（ここでは剰余演算も含むこととします）を行う命令は遅いです。 そのため、除算はなるべく回避したいものです。 除数がコンパイル時定数の場合、コンパイラの最適化により、除算が取り除かれることがあります。 これを定数除算最適化と呼びます。 定数除算最適化では、除算はいくつかの軽量な命令に分解されます。 二のべき乗で割る場合、単にシフト命令が使われます。 それ以外の数で割る場合、乗算とシフト命令が使われます。 符号付きの除算の場合、零への丸めの部分の取り扱いが面倒ですが、追加のシフト命令と加算命令だけで（分岐命令を使わずに）なんとかできるようです。 さて、この定数除算最適化は、128bit整数の除算の場合は常には行われないようです。 これを何とかしてみたいと思います。 もちろん、手で最適化されたコードを書けばできますが、コンパイル時計算により除数が決まる場合などに対応するのは困難とい

この記事は自作CPU Advent Calendar 2023の24日目の記事です。 みなさんが使っているパソコンのCPUは、そのほとんどがアウトオブオーダー実行をしているはずです。 しかし、アウトオブオーダーCPUの作り方が書かれた教科書はあまりないような気がします。 トマスロのアルゴリズムというものが紹介されることもありますが、これは現代のアウトオブオーダー実行方式とはかなり違います。 この記事では、より洗練された現代的なアウトオブオーダー実行をするプロセッサを作ってみます。 全体的な構成 今回作るプロセッサは、FPGA上で動き、RV32IZmmul命令セットを動かすことができます。 東大のプロセッサ実験と同じルール（命令メモリ32KiB、データメモリ64KiB）で作ります（プロセッサ設計で一番難しいキャッシュを考えなくていいのですごく楽です）。 パイプラインは、以下のように設計しまし

2023年9月にZicond拡張というのが、ろくに議論もされずに*1承認されたようです。 RISC-Vもその場の思い付きで命令セットを拡張するような、歴史に学ばない命令セットに堕したということですね。 Zicond拡張の機能はRISC命令セットとして素晴らしいものですが、そのエンコーディングは敵であるcmov命令を追い出すために非常に悪意のあるものとなっています。 また、cmov命令を追い出すだけならまだましで、そのエンコーディングの歪みのせいでRISC-V全体を使いづらくしています。 このようなものは、排除アートと呼んで差し支えないでしょう。 命令セットは芸術ですし、英語ではhostile instruction-set architectureとすればよさそうです。 Zicond拡張 Zicond拡張は、czero.eqz命令とczero.nez命令の二つだけからなる拡張です。 cze

この記事は C++ Advent Calendar 2021の5日目の記事です。 2021年ももうすぐ終わりそうですが、みなさんはC++20を使っているでしょうか？ C++20では、符号付き整数型のビット表現が二の補数であると規定されました。 また、ビット表現を保ったまま別の型に変換する関数であるstd::bit_castが標準ライブラリに実装されました。 これら二つの機能追加により、値のビット表現に依存したプログラムを書くことが非常に容易になりました。 この記事では、なぜstd::bit_castを使わなければならないかを説明します。 もちろん、それ以外の時にstd::bit_castを使うべきではないということではありません。 ビット表現を保ったまま別の型に変換したい時にはいつでもstd::bit_castを使う、という方針もありでしょう。 std::bit_castを使わなければなら

IEEE浮動小数点数における演算では、丸め誤差が不可避です。特に、複数回の演算を繰り返すと丸め誤差が積もっていき、正確な値と大きく離れた答えを得てしまうことがあります。しかし、次の演算については、（数学的に）正確な値を求めた後、一回だけの丸めが発生することが、IEEE標準で規定されています。 四則演算 積和演算　Fused multiply add (FMA) 平方根演算（正の平方根を求める*1） 浮動小数点数演算のできるCPUであれば、普通、四則演算や積和演算を行う命令を持っています。 しかし、平方根を正確に計算する命令を持たない命令セットも存在します。 そのような場合、平方根関数はライブラリ実装となるわけですが、どのように実装すれば要求を満たせるのでしょうか？ C++のstd::sqrtは正確に計算しているのか？ 結論 しています。 標準の丸めモード、つまり最近接丸め（ぴったり半分なら

最近何の縁があってか 鬼斬弐 というオープンソースのプロセッサシミュレータの開発を手伝っています。 github.com ここ数日でRISC-VのRV64Gへの対応が急速に進められ、ベンチマークプログラムも動くものが増えてきたようです。 私はちまちま細かいバグを取り除く作業をやっています。 今日は、makeを並列で行うオプション-j付きで実行するとき、その引数（最大何並列にするか）を何にすべきか調査した話をします。 よく見かけるのは、以下のような言説です。 CPUのスレッド数を指定するべき これはもっとも単純で、CPUの動かせるスレッド数より並列度を高くしても、本当に並列に実行できるわけではないので、これが最大の効率になるはず、といった考えから来るものでしょう。 CPUのコア数を指定するべき 同時マルチスレッディングで複数のスレッドが動かせるといっても、あくまで1つのCPUで行っているため

概要 クイックソートは一般に高速なソートアルゴリズムとして知られています。 アルゴリズム中にはピボットを選択する部分がありますが、ここでなるべく中央値に近い値を選択すると、総比較回数を少なくすることができます。 しかし、最近の高性能プロセッサは投機実行するため、比較回数ではなく分岐予測ミスの回数が性能に大きく影響します。 ピボットとして中央値ではなく四分位数を選択する場合、比較回数が23%増加するものの、分岐予測ミス回数を38%削減し、ソートにかかる時間を20%削減できることが分かりました。 はじめに 去年の末、kimiyukiさん（kimiyuki@うさぎ🐇 (@kimiyuki_u) | Twitter）に「クイックソートのピボットとして中央値ではない値を選んだほうが、分岐予測ミス率が減って高速なのでは」という話をいただきました。 その時私は、「分岐予測ミス率を減らせても、トータルの

C++にはinline指定子があります。しかし、このinline指定子は、その名前から誤解されがちです。 (誤解)inline指定子を付けると、その関数はインライン展開される これは誤解であり、正しくありません。正しくは、以下のような意味になります。 inline指定子を付けた場合、複数回の定義が許される。また、複数の翻訳単位*1で定義されたとしても実体は一つになることが保証される*2。 (C++14まで)inline指定子を付けた場合、コンパイラはその関数をインライン展開するヒントとすることができる。 「inline指定子を付けた場合、コンパイラはその関数をインライン展開するヒントとすることができる。」という記述はC++17以降で無くなりました。 ただし、コンパイラの最適化は見える結果が変わらない範囲で自由に行えるため、inline指定子をヒントにすることは問題ありません。（2020/0

C++のテンプレートメタプログラミングによるコンパイル時C言語コンパイラ、「ltmpc」を作っています。 やっとコードが生成できるようになったので、今日はそのはなしを書こうと思います。 動くものが見たい！ GitHub - lpha-z/ltmpc: C++11TMP compile time C compiler はじめに 世の中には、プログラムを書くこと自体が難しいような、難解言語と呼ばれるものがあります。難解言語は何かを効率化するためにはあまり役に立ちませんが、その魅力から意外と愛好者がいるようです。 難解言語は手で書くのが難しいため、自動生成しようとの試みがよく起きます。それを推し進めたものとして、去年、ELVMというコンパイラ基盤が出現しました。 ELVM Compiler Infrastructure について - 兼雑記 これは、いきなりC言語ソースから難解言語ソースを生成す