強火で進めやっぱり使えるのね、というのが最初の感想。以前のGCCならツッコミどころ満載のコードを吐いていたのでインラインアセンブラで書く価値は十分にあったけど、今はけっこう賢いコードを吐くようになったみたい。個人的にはアセンブラで書くのは最終手段であって、最適化したけりゃ「コンパイラが吐くアセンブラコードを想定してCでゴリゴリ書いておけ」と思っている。書く時間がかかる割にはあまり高速化されないし、保守性が落ちるからってのがその理由。ある程度プログラミング経験がある人は「アセンブラで書けは必ず高速化される」ようなイメージも持っている人も多そうだけど、今はCPUの特性(パイプライン、キャッシュ、分岐予測等)を熟知して書かないと逆に遅くなってしまう事も十分にありえる、そんな時代なのですよと。それでもアセンブラで書きたい人へとはいえ技術的な好奇心を満たす為にアセンブラで書きたい人も多い気がするので、アセンブラコードを書く以前にすべき事を書いてみた。完璧なデバックアセンブラで高速化した領域が実はバグ有りって事なら目も当てられません。関数の時間計測やみくもにアセンブラで書いても高速化されないし、たまにしか実行されない所をアセンブラで書いても高速化されない。プロファイラというツールを使い、どの関数が一番処理時間がかかっているかを把握するのが一番先。Wikipediaがここでも生きるわけ。あと、勘で「たぶんこの関数が重い」という先入観は捨てる事。間違っている事多いから。命令体系はどんな感じ?などなど、普通は知っていてもムダだけど高速化するには必須の知識。アセンブラで書きたいってだけなら、レジスタと命令体系だけ知っておけばいいんだけどね。CPU特性にあわせたアルゴリズムの変更ここからが腕の見せどころ。アルゴリズムの変更で重要なのはできる限りキャッシュにヒットさせるできる限りキャッシュにヒットさせるできる限りキャッシュにヒットさせる大切な事なので3回言いました。メモリアクセスも最低限に抑える事。そのためには、キャッシュとレジスタで極力やりくりする。アルゴリズム早くてもメモリアクセスやキャッシュにヒットしなかった為にメモリアクセスが発生して遅くなる、という事も十分考えられるわけで。広告スターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。