aokomoriuta's blog

青子守歌のブログ

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]

290X (Hawaii)

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


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

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

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

以前のaokomoriuta.hateblo.jp

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

$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版は更に速かったです。
うーん・・・なんなんでしょう。

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

この話。


本当か？

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

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

結果は

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

でした。

もう少し詳しく言うと

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


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

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

以下解説です。

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

続きを読む

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

お詫び

では本編どうぞ↓

本編

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

d.hatena.ne.jp

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

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

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

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

続きを読む

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

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

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

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

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

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

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

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

BitbucketでGithubみたいなコミット通知をTwitterにhookする

OpenMPSをGithubからBitucketに引っ越したんですが、その時Githubみたいなコミット通知をTwitterにhookする必要がありました。

簡単なヘルプは
Twitter hook management - Bitbucket - Atlassian Documentation
にあるんですが、最後のFormatがくせもので、そのままだと

レポジトリ名 コミッター名 メッセージ

とだけの質素なものになっていて、少なくともコミットURLがほしいので色々悩んだ結果、どうもうまくいかず、妥協してそのヘルプページにあるTinyURLを使う方法しかできませんでした。

${repository.name}: commit by ${commit.author} ${commit.tinyurl} ${commit.message}

誰かもっといいFormatテンプレート持ってたら教えてください・・・。