Re: Re: OpenCLやる前にSIMD使い切れっていう幻想

d.hatena.ne.jp

なんだか知らない間にぜんっぜん関係ないtweetを拾われて勝手に憤られてた上に、全然まともに計算していないもの*1を出されてたので、ちゃんと動くようにして測りなおしました。

計算機は前回と同じものを使いますが、手元からVS2013がなくなってVS2015になってしまったので、Visual Studioのバージョンだけ違います（System.Numerics.Vectorsが必要ですが、4.1.0を使ってます）。
結果は以下の通り。

• C#（なにもしない）
  • 5.5秒ぐらい
• C#（System.Numerics.Vector<double>）
  • 4.5秒ぐらい

ということで、1秒ぐらい縮まりました。

FX-8350だとSIMD幅が128bitと判定されてSystem.Numerics.Vector<double>.Countが2になっていました（※先の記事の通りAVX2を使えば256bitできます）。
なので、2倍弱ぐらいは期待したのですが、結果は1.2倍で、ちょっと微妙な感じです。
関数呼び出しのコストがこんなに取られてるのか・・・よく分かりません。

私は最近まともなC#を書けてないので、まともなC#erさんに解明を期待します。

追記 (09/21 11:30)

すいません、昨日眠い状態でコード書いてたので、最後にコミットせずにpushして安心して寝てしまってました・・・。多分昨日の時点ではSystem.Numerics.Vector<double>を使っても全然速くないどころか遅かったと思います。
正しいのはさっきコミットしました。これで、4.5秒ぐらい（x1.2ぐらい）です。

追記 (09/21 12:30)

構造体もちゃんとサイズを切り分けたら、速くなりました。

• C#（なにもしない）
  • 5.5秒ぐらい
• C#（System.Numerics.Vector<double>）
  • 2.5秒ぐらい

なぜか2倍以上出ている・・・？まぁとりあえず速くなったので良しとします。
多分これが一番早いと思います（フラグ）。

追記 (09/21 23:00)

@aokomoriuta @matarillo ちょっと動かしてみました。私の環境ではSIMD長=4に処理が飛んできたので、structでラップしないでナマのVector<double>の配列で試してみました。が、100msほど縮んだだけですね。

— てらだ (@u_1roh) 2015年9月21日

という話を聞いて、確かに手元のSurface Pro 3（OS：Win10、CPU：i3 4020Y）で試したところ、256bit SIMDになってくれました。

• C#（なにもしない）
  • 5.5秒ぐらい
• C#（System.Numerics.Vector<double>）
  • 2.2秒ぐらい

CPUが違うので単純比較できませんが・・・。
実行可能ファイルも置いておくので、もしお時間のある方は、OSとCPUの情報を添えて、実行時間とSIMD長を教えてくれると嬉しいです。

追記 (10/17 15:00)

↓のコメントにある通りAkio Takahashiさんからpull requestもらってました。
全部は取り込みませんでしたが、一部を取り込んだところ、以下のようになりました。

• C#（なにもしない）
  • 5.5秒ぐらい
• C#（System.Numerics.Vector<double>）
  • 2.5秒ぐらい
• C#（今回）
  • 1.3秒ぐらい

以前の記事でC++のSIMD(AVX2)が1.3秒ぐらいだったので、同等ぐらいには速くなったようです。
ちょっと使い方に工夫が要るのかもしれませんが、C++と同じぐらいの性能がでるのであれば、C#には

• アライン考えなくていい
• CPUに合わせて勝手にSIMD長変えてくれる（逆にこれは欠点でもある？）
• 最初から演算子がオーバーロードされてるのでintrinsic書かなくていい

という長所が3点あります。

積極的に使えるタイミングでは使っていきたいところですね。

*1:4倍近く加速されたとのことでしたが、System.Numerics.Vector<T>が何かをちゃんと理解できておらず、System.Numerics.Vector.Countを一切考慮できていない、結果的に半分しか計算できていない粗末なものだった（例えばxSimd[0][2]とかアクセスしたら、SIMD長が足りなくて例外吐いて死ぬ）

Radeon Fury Xを使ってみた

@Tommy6がAMD Radeon R9 Fury Xを貸してくれたので、例のまたaokomoriuta.hateblo.jp
を使って測ってみました。

ソースコードも前と同じ場所にあります。普通にmakeすれば動くはずです。

結果、

Fury X (Fiji)

Normal: 44979[ms]
Simd  : 38869[ms]
OpenMP: 8threads
Normal: 12062[ms]
Simd  : 10243[ms]
OpenCL: 730[ms]

• OS: Ubuntu 3.19.0
• CPU: Core i7 3770K
• AMD APP SDK: 3.0
• gcc: 4.9.2
• memory: DDR3-1600 4GBx2

290X (Hawaii)

Normal: 70199[ms]
Simd  : 61474[ms]
OpenMP: 8threads
Normal: 19010[ms]
Simd  : 16672[ms]
OpenCL: 743[ms]

• OS: Ubuntu 3.13.0
• CPU: Core i7 2600K
• AMD APP SDK: 3.0
• gcc: 4.8.4
• memory: DDR3-1600 8GBx2

FuryXの方が10[ms]ですが速いですね！！
・・・誤差な気がする。
まぁ最適化もなにもしてないからなぁという気はしますが。

どっちかというと、Sandy-Bridge(2600K)よりIvy-Biridge(3770K)が1.5倍ぐらい速いのが気になるんですが・・・ほんとにこんなもんですかね？

AMD APP SDKのOpenCLをCPUで動かしたらOpenMPより倍速い？

以前のaokomoriuta.hateblo.jp

をちょっと修正して
CPUで動かすようにしたので、手元にあった環境で動かしてみました。

• OS: Ubuntu 4.8.2-19ubuntu1
• CPU: Core i7 2600K
• AMD APP SDK: 3.0 Beta
• gcc: 1.8.2

$cd opencl_etc/cpu
$make
$./cpu
= OpenCL on CPU =
Normal: 7785[ms]
OpenMP: 8threads
Normal: 2124[ms]
OpenCL: 1413[ms]
== Platform : 0x7fde975d4670 ==
Name    : AMD Accelerated Parallel Processing
Vendor  : Advanced Micro Devices, Inc.
Version : OpenCL 2.0 AMD-APP (1598.5)
== Device : 0x1642b10 ==
Name                                             : Intel(R) Core(TM) i7-2600K CPU @ 3.40GHz
Vendor                                           : GenuineIntel (ID:4098)
Version                                          : OpenCL 1.2 AMD-APP (1598.5)
Driver version                                   : 1598.5 (sse2,avx)
OpenCL C version                                 : OpenCL C 1.2

OpenMPより倍速いだって・・・！？
なんか信じられないのでもうちょっと調べてみるけどあり得るのか・・・。

6/7追記

「gccのOpenMPが裏でpthreadを使っていて、OpenCLはTBBを使っていて、つまりpthreadよりTBBが速いのでは？」と言われたので、純AMD環境でVisualStudioでやってみました。

• OS: Windows7 Professional
• CPU: AMD FX 8350
• AMD APP SDK: 3.0 Beta
• VisualStudio: 2013

= OpenCL on CPU =
Normal: 13274[ms]
OpenMP: 8threads
Normal: 2372[ms]
OpenCL: 859[ms]
== Platform : 000007FED1817B60 ==
Name    : AMD Accelerated Parallel Processing
Vendor  : Advanced Micro Devices, Inc.
Version : OpenCL 2.0 AMD-APP (1642.5)
== Device : 0000000002EB1220 ==
Name                                             : AMD FX(tm)-8350 Eight-Core Processor
Vendor                                           : AuthenticAMD (ID:4098)
Version                                          : OpenCL 1.2 AMD-APP (1642.5)
Driver version                                   : 1642.5 (sse2,avx,fma4)
OpenCL C version                                 : OpenCL C 1.2

1スレッド版が激遅なのはなんなのかって感じですがOpenCL版は更に速かったです。
うーん・・・なんなんでしょう。

白か黒か、認識に性差は本当にあるのか？

この話。

男性は左が白で右が黒、女性は左が黒で右が白と認識するらしい pic.twitter.com/FydDcHZVH8

— 青子守歌 (@aokomoriuta) 2015, 5月 8

本当か？

そもそもとしてそんな性差があると私は聞いたことがないです（自分で言っておきながら）。完全なる創作です（創作目的は後述）。

それはそれとして、いっぱいreplyやらmentionやらRTやら受けて、このまま「あー面白かった」で終わらせてももったいないので、せっかくなので統計とってみました。

結果は

• (A)男性は「黒-白」、女性は「白-黒だった！」と、つまり逆だったと言う人のほうが多かった
• (B)ただし、全体としては、左が白で右が黒と言っている人が多かった

でした。

もう少し詳しく言うと

• こういう話はなんでも大体「逆だった！」と言う発言の方が多く、逆に「その通りだった」と言う人はあまり発言しないものです*1。感覚的にも違うほうが面白いしネタになりやすいですからね。これが結果(A)の理由だろうと思います。
• (B)については、単純に取得したデータ全体でと、性別不明だった人で、白-黒だと言っている人の方が多いかったです。
• また、Twitterユーザー全体の男性の方が多いという結果があるにも関わらず、今回取得したデータは女性からの発言に偏っていました。
• 男女比と(A)の理由と合わせると、男だろうと女だろうと白-黒と認識しているという結果(B)の事実があり、その結果、逆だった女性のほうが多く発言しており（ユーザー比率は小さいにもかかわらず）、tweetの通りだった男性の方はあまり発言しなかった（ユーザー比率は大きいのに）、ということになったんじゃないでしょうか。

ということでここでは白か黒かの認識に性差は関係ない（左が白で右が黒だという人のほうが多い）と結論づけます。

データは
google spreadsheetで見れます。
odsも置いておくので、データを追加したかったり色々したい人はここからダウンロードして下さい。

以下解説です。

*1:[要出典]な感じなので誰かよさ気な文献知ってたら教えてください

OpenCLやる前にSIMD使い切れっていう幻想

お詫び

アライン忘れてましたごめんなさい、でも時間あんまり変わってないから許して・・・ https://t.co/JNtq2U2kMq

— 青子守歌 (@aokomoriuta) April 29, 2015

では本編どうぞ↓

本編

若干話題に乗り遅れた感ありますが。

d.hatena.ne.jp

けど、SSEも知らねー、SIMDも知らねー、なんか俺が書いたアルゴリズム遅いけどとりあえずOpenCLとかで高速化しよっかなーとかね、甘ったれてんじゃねえよ。CPUをもっと使いきれよ。お前のアオいコードのせいでCPUが泣いてるよ。っていう話ですよ。

GPGPUなんてのはSIMDを使い切った後の話でしょ。

GPGPUするのにGPUのパワーとメモリが足りませんとか言う前にまずSIMDからだろ。

とか言われてたので、検証することにした（やっつけ）。

株式会社はてなに入社しました

株式会社はてなに入社しました

株式会社はてなに入社しました - hitode909の日記

QiitaでのHaskellポエムについて何故か作者に敵視されている非Haskellerが思うこと

Twitter界隈でQiitaでkenokabeさんの書いたHaskell記事を発端に色々と話題になっています。

個人的にこの騒動について思うのは、別にQiitaにあぁいう記事があってもいいんじゃないかなと。
私自身はあの記事を良いとは思わないし、kenokabeさん自身についても、少なくとも私自身の価値観とは合わないので極力なら関わらずに生きていきたいと願ってます。
ただ一方で、彼の思想や書き方についてはすごいところも多いと思いますし、優れている部分もあるなと思っています。必要悪とかそういう意味では全くなく、単に、価値観の相違があって学ぶべきことはあるがまじわるとお互いつらい、という存在だと私は認識しています*1。だから私からすると一連の記事に対して（良いでも悪いでもなく）「アレ」という感想しかもてないわけです。

なので、みんながあぁやってポエムだポエムだと言っているスタイルについては、それはそれで確かに旧来のQiitaユーザーとは違う書き方ではあるけど、彼自身が「プログラマに共有したい知識」と思って書いたことなのだから、そういう記事があっても良いとは思います。そうやって違うものを受け入れて多様化することの重要性はみんな理解しているはずです。

ただ、それをQiitaユーザーが「良い」「悪い」と評価したことをフィードバック（つまり検索した時のランキングなどに反映）する仕組みがあまり良くなかったです。
この辺り私がQiitaを使わなくなった理由でも述べられてますが、kenokabeさんが書いた一連の記事に対して結構な問題が指摘されたのにそれが上位にあって良記事のように見えてしまったのが問題だったんでしょう。
特に関数型プログラミング界隈の方々、Haskellerの方々にとってはタグが「汚染」されてしまうという深刻な問題だったようです（私は非Haskellerなので実害なかったですが）

そして最終的に、問題はエスカレートしてしまって、Qiita公式の独断で記事を消したりしてさらに問題は悪化してすごい人たちは使いたがらなくなったし、kenokabeさんもユーザー資格停止処分にまでなって、最悪の結末だと思います。

じゃあどうしたらいいかという話は、思う所ありますが、後出しジャンケンになるので、タイトル通り以上のただの「思うこと」だけで終わらせておきます。

*1:なぜか先方は私のことを一方的に敵視してるようですが、どちらかというと私個人というよりは私が属しているコミュニティそのものに対する敵視のように感じます。