#performance

GPUの matrix multiplication（matmul）は、普通は「入力の値に関係なく同じ速さ」で動くと思いがち ところが実際には、ゼロや同じ値のような“予測しやすいデータ”のほうが速くなることがある 理由は、GPU内部の dynamic/switching power（トランジスタが切り替わるたびに消費される電力） 電力制限に当たると GPU は throttling（性能を落として消費電力を抑える）するので、速さが変わる これは「GPUは計算性能だけでなく、電力との綱引きで速さが決まる」ことをよく示していて、かなり面白い Nvidiaのカタログ上の FLOPS と、実際の持続性能に差が出る理由もここにある この記事の出発点は、かなりシンプルです。 著者の Horace He さんは、GPU向けの高速matmul実装である CUTLASS を試していました。 8192×8192×8192 の大きな行列積をベンチマークすると、最初は CUTLASS が CuBLAS より速いように見えたそうです。これは「お、すごい」と思いますよね。私もここで

REST APIが遅くなる最大の原因は、だいたいdatabaseアクセス Redisのような in-memory cache を使うと、読み込みをかなり速くできる Spring Bootでは `@EnableCaching` や `@CachePut`、`@CacheEvict` が実用的 更新時は「DBとcacheを同時に整える」設計が大事 人気データが一斉に失効すると cache stampede が起きるので、distributed lock で守る 最後は JMeter で load test して、ちゃんと速くなったか確認するのが重要 元記事の主張はかなりシンプルです。 高トラフィックなREST APIは、databaseアクセスがボトルネックになりやすい、という話です。 これは現場感としてもすごく納得感があります。 どんなにSQLを改善して、indexを貼って、ちょっと頑張っても、DBに毎回取りに行く構成だと限界が見えやすいんですよね。記事では、DBの応答が数百ミリ秒かかる一方で、Redisを使えばずっと速くなると説明しています。しかも、Redisはメモリ上で動くの

深層学習の高速化は、Compute / Memory / Overhead の3つに分けて考えると整理しやすい GPUを速く使うには、まずどこで時間を食っているかを見極めるのが大事 多くの小さな演算は、計算そのものよりメモリ往復で遅くなる そこで効いてくるのが operator fusion（演算のまとめ実行） 速さは「理論上のFLOPS」だけでは決まらず、データ移動の少なさがかなり効く PyTorchやGPU最適化の話に見えるが、考え方はかなり汎用的 元記事の主張はかなりシンプルです。 深層学習を速くしたいとき、闇雲に「このテクニックが効くらしい」「とりあえず in-place にしよう」みたいな小技を積むのではなく、何に時間を使っているかを第一原理で分解して考えよう、という話です。 ここは個人的にすごく好きなポイントです。 性能チューニングって、経験則が強すぎて魔術っぽく見えがちなんですよね。でも著者はそこに対して、「いや、まずは大きく3分類しようよ」と言ってくる。こういう整理の仕方は、地味だけど本当に強いと思います。 --- 記事で

Redditのr/singularityで、AI coding agent と index performance に関する投稿が話題になった ただし、今回こちらで確認できた元記事本文は 「Reddit - Please wait for verification」 とだけ表示されており、詳細な内容までは読めない そのため、この記事では 見えている範囲の事実 と、そこからわかる 文脈・背景 をやさしく整理する AIによるコーディング支援は、今や「コードを書く道具」から「作業を肩代わりするエージェント」へ進化しつつある 一方で、index performance のような地味だけど重要な性能問題は、AI時代でも無視できない 今回の元記事は、Redditのコミュニティ r/singularity に投稿されたものです。 タイトルは 「AA introduces coding agent index performance」 となっていましたが、本文は取得時点で **「Reddit - Please wait for verif