はてなブックマーク

概要 経緯 : http://d.hatena.ne.jp/w_o/20150602#1433229756 なんか社内チャットで https://github.com/WL-Amigo/waifu2x-converter-cpp をはやくしろというメッセージを受信したのでやった。 まあそれなりに頑張ったのでまとめておく 今の waifu2x のパラメータ(カーネル3x3、平面数32の倍数)に依存したチューニングをしている部分もあるが、 カーネルサイズが小さいCNNなら同じような考えかたを適用できるのではないかと思う 今の実装の効率はhttp://d.hatena.ne.jp/w_o/20150616#1434392833にあるとおり。 自分では確認できていないが、CUDA版はKeplerが効率悪くて、Fermi、Maxwellなら30〜40%程度の効率らしい。 前提知識 OpenCV が少

ふたつのコアで1モジュールを構成する それぞれのコアは、4本の整数パイプと、L1D を持つ 整数は、基本的な演算+メモリアクセスを実行するAGLUx2 と、パイプごとに対応する命令を実行するEXx2の4本 L1I、Fetch、Decode、L2、FPUはふたつのコアで共有されている L1I->Fetchは32Byte、4命令デコード/clk FPUは、4本が色々と命令できて、うち2本が128bit FMAを実行できる 思想としては、 FPUはリソース多く使うので無駄遣いしないように実行効率を上げたい → FPUをヘヴィに使うプログラムでは HT みたいになる 整数は軽いのでたくさん入れたい → サーバー等ではHTよりも絶対性能高い ということなんだと思われる。 命令単位ベンチマーク 実際どうなっているか命令単位でベンチマークしてみる ソース(Win32 cl.exeが必要) 手元(A8-4

ふたつのコアで1モジュールを構成する それぞれのコアは、4本の整数パイプと、L1D を持つ 整数は、基本的な演算+メモリアクセスを実行するAGLUx2 と、パイプごとに対応する命令を実行するEXx2の4本 L1I、Fetch、Decode、L2、FPUはふたつのコアで共有されている L1I->Fetchは32Byte、4命令デコード/clk FPUは、4本が色々と命令できて、うち2本が128bit FMAを実行できる 思想としては、 FPUはリソース多く使うので無駄遣いしないように実行効率を上げたい → FPUをヘヴィに使うプログラムでは HT みたいになる 整数は軽いのでたくさん入れたい → サーバー等ではHTよりも絶対性能高い ということなんだと思われる。 命令単位ベンチマーク 実際どうなっているか命令単位でベンチマークしてみる ソース(Win32 cl.exeが必要) 手元(A8-4

概要 gcc -mtune=hoge ってあんまよくわからず付けてるけど意味あんの？ 効果 前のk10 vs coremaみたいな感じでparsecをひととおり動かした -O2 の時間を1.0とした時の処理時間の比 app |-O2 -mtune-native streamcluster | 1.016 canneal | 1.016 vips | 0.954 bodytrack | 0.966 x264 | 1.049 blackscholes | 0.986 swaptions | 0.981 ferret | 0.997 なんらかの効果がある…ように見える…？ (ネタバレ: -march=avxが付いてて、それの効果が出ている) 超簡単にGCCのコード解説 gcc/*.c アーキ非依存のコード gcc/config/i386/* i386のコード gcc/config/i386/i3

いまどきの☆あせんぶりーらんげーじ 概要 今のCPUは複雑すぎるのでコンパイラのほうが人間より賢いとか嘘である。 基本を抑えればそんなことないので、皆さんコンパイラに打ち勝ちましょう。 以下では、パイプライン化されてて、スーパースカラなマシンをいまどきの☆アーキテクチャとしている。(つってももう20年前くらいの話なんじゃないか…) 今でもスーパースカラじゃないRISCとかあるよ！！とかの意見は、自分のブログに書いておいてください。 あと、x86をいまどきのアーキテクチャと呼ぶのは抵抗あるけど、深追いするならx86が一番面白いと思うので、x86限定の話題も遠慮しないで書く。あと、アセンブリの記法はAT&Tです。 前提知識 x86アセンブリ 参考文献 これを読めばこの文書を読む必要は無い。 The microarchitecture of Intel and AMD CPU’s: An opt

概要 pthreadはクソだというのをひしひしと実感している…わけではないけど、 Win32のスレッドと比べると微妙な感じが拭えないので、Linuxのスレッドを使えばもっとハッピーになれるよ、というような話。 pthreadがクソな理由 pthreadは Win32 のスレッドに比べていくつか微妙だと思われる点がある。まずはその点について書こう、と思ったのだけど、大体[ここ]に書いてあったので、列挙だけしておく。詳細はリンク先を読んでね！ Win32スレッドがWaitFor(Single/Multiple)Object(s)で全部待てるのに対して、pthreadは mutex、cond、sem、join のどれか、しかも一つだけしか待てない Win32のオブジェクトはシグナル状態を保持し続けるのに対して、pthreadの条件変数は、シグナル待ちになっていない状態でcond_signalを受

概要 Linuxのパフォーマンス解析ツールであるperfの使いかたの紹介 背景 個人的にperfよくできてると思うので紹介したいというのと、 パフォーマンスカウンタの読み方ってあんまり知られてないみたいなので、 それの解説を書きたい。 構成 perf について説明したあと、パフォーマンスカウンタの読みかた、見かた、を説明する。 perfとは何か Linuxに付いてくるプロファイラ。 man perf によると、 NAME ---- perf - Performance analysis tools for Linux と、書いてある。名前がひどいのでなんとかしてほしい。 perf の特徴 個人的には、手軽に使えるのが素晴らしいと思う。 2.6.31以降カーネルに標準で付いてる。(Ubuntuだとlinux-tools-common(TODO:あとで確認)で入るはず) 特殊な設定が必要無く、

という感じで、「k10 < Nehalem << Sandy」ぽい雰囲気を感じられるかと。(あと-mtune=nativeはあまり変わらんというか、若干悪くなってるというのも) メモリの影響少なそうなblackshcoles、raytraceでもSandy、NehalemのほうがIPCよい。 なので、たまに見かける「コアは互角だが、キャッシュ良いからIntel勝ってる説」は、あまり信憑性無いのではないかと思う。 fluidanimate 一番差の大きいfluidanimateから見ていく。粒子法の流体シミュレーション。 perf annotate -l した結果が、 === a8 === Sorted summary for file /home/w0/src/parsec-2.1/pkgs/apps/fluidanimate/inst/amd64-linux.gcc/bin/fluid

概要 Linuxのパフォーマンス解析ツールであるperfの使いかたの紹介 前提知識 Linux系 perfについて カーネル内のイベントや、ハードウェアイベントの発生回数を計測できるツール。 インストール 2.6.31 からはカーネルに標準搭載されてるので、特に必要なものは無い。 やることは、 カーネルのCONFIG_PERF_COUNTERSを有効にする カーネルをビルド なんらかの手段でelfutilsのlibelfを入れる(libelf-0.8.12ではない) カーネルソース内にある tools/perf/ で make する できた'perf'コマンドをパスの通るところに置く debugfsを/sys/kernel/debugにマウントする で、$ perf list などとやって、イベントリストが表示されれば使える 使いかた マニュアルは tools/perf/Documenta