Wikipediaの嘘と人身攻撃と、それでも炎上しなかったわけ
すこし煽るようなタイトルになってしまいましたね。
直近で私も似たような経験があり、思うことがあったので書いてみたいと思います。
（あ、断っておきますが、人身攻撃ではないです。影響力がある人の発言と事実関係の調べのことです）
普段は結論から書きますが、ここは順に説明したいと思います。
・wikipediaの間違い
発端はいま話題のgtx 1080絡みですが、
公開さいれいるgtx 1000 seriesのスペックでどうやらsingle precision(GFLOPS)が正しくないのでは？という疑問からですね。
いまは修正されているのでヒストリーから抜粋するとこちらを参考すればと思います。
https://en.wikipedia.org/w/index.php?title=GeForce_10_series&diff=720847585&oldid=720783968
ここでwikipedia側のミスに関して説明すると
・Single precision performance is calculated as 2 times the number of shaders multiplied by the boost core clock speed.
という記述があり、boost coreをベースで計算したということですね。
それによりwikipedia側にはGFLOPSの数字が以下の記載になっていました。
GTX 1070 : 6500
GTX 1080 : 8228
ところが、実際にboost coreをベースで計算した場合
gtx 1070 : 1.600 * 2 * 1920 = 6144
gtx 1080 : 1.733 * 2 * 2560 = 8872.96
になり、wikipedia上との数字とは異なっていた！
・正解は？
gtx 1070はbase core が書かれてなかったので当時はわからなかったですが、
gtx 1080のbase core 数字を参考に計算すると
1.607 * 2 * 2560 = 8227.84
であり、この8228はどうやらbase coreで計算したのでは？という結論が出ますね。
しかし、wikipedia側にはっきりと"by the boost core clock"という文言があるのでwikipediaの記載に問題はあります。
なお、gtx 1080のページはいろいろ変更された痕跡があるけど、一覧ページ
https://en.wikipedia.org/wiki/List_of_Nvidia_graphics_processing_units
は最初から確定的な言い方をしていました。
どちらもnvidiaの発表があった2016/5/7から2016/5/18まで十日以上間違った情報を配信していたことですね。
・戦いが起きた！
https://en.wikipedia.org/wiki/Talk:GeForce_10_series#Single-precision_performance_of_1070
上記のgtx 1070に関する疑問を誰かが提起したところでいきなり人身攻撃が行われてしまった。
いい言葉ではないので翻訳はしませんが、意味が伝えると思います。
あえて原文を引用します。
Are you stupid or really unable to use your brain to find info?
もはや人身攻撃以外になにものでもないですね。。
・それでもwikipediaは冷静だった。
ただ、こんなことがあったとしでも個人への攻撃は禁止するとのポリシーをもって冷静に対処しています。
なので喧嘩になれず、ルール違反として終わってました。
あと、間違った内容が記述されているページへもちゃんと修正が入り訂正されています。
さすがという感じがしました。
・感想
よく「wikipediaに書いているから」という理由で根拠にしたり、いかにも事実であるかのように振舞うが、
wikipediaだって間違ったり、嘘を書いていたりします。
もちろんそれを修正する仕組みもちゃんとありますが、人間である以上は失敗もしますね。
特に今回みたいにGFLOPSの数字は１年に１回みるか見ないかするほどの頻度の情報であるので、
間違ったから再度確認とか、いや、そもそも参照する人は間違いに気付くのだろうか？
というレベルで考えるとむしろ恐ろしいですね。
デマの発祥とはこういうことか〜と思ったりします。
しかも、4chやredditとは違ってwikipediaはイメージですが、
学問的で大人が集まりそうな場所だと思っていましたが、
そういうところでも露骨な表現が出たことにはすこし驚きですね。
・結論
１）どんな情報であれ、まず根拠があるかを確認する。必ず疑いをもって事実確認することは大事。、(wikipediaすら間違うのだから！)
２）常に紛争はお超えることなので（性悪説に基づいてもいい）論争が起こった時に冷静に解決できるポリシーを作るのは大事。人間の感性に任せるだけではよろしくない。
まあ、わかっていたとしても時間が経つにずれ忘れてしまい、もしくは油断してしまうことですので、
まず私自身への心かまえにしたいのと、
あと、説明する時に具体的な事例として記録したいと思って残っておきます。
では〜
hava a nice day^^
GTX 1080 とか、pascalアーキテクチャーとか
gtx 1080の発表からすこし時間も立ちいろいろ情報も出たのですこしまとめてみた。
gtx 1080とは
2016年5月7日に発表したnvidiaの新しいレファレンスグラフィックカード
初のpascalアーキテクチャーを使ったGP104採用
メモリーはGDDR5のマイナーチェンジのGDDR5X
（HBMの採用が見送られたのは残念だが、いまの歩留まりを考えると、まあ妥当かと）
詳細なスペックは以下を参考
http://www.geforce.com/hardware/10series/geforce-gtx-1080
gtx 1080の性能
以下の仕様表を参考
https://en.wikipedia.org/wiki/List_of_Nvidia_graphics_processing_units#GeForce_10_Series
http://wccftech.com/nvidia-pascal-gp104-gpu-pictured-leaked/
2 FLOPs per clock cycleらしいので厳密に計算すると理論値は
1.733 * 2 * 2560 = 8872.96
まあ、弱9 TFLOPS
base coreとboost coreの違いはbaseは最低値、boostは稼働して平均値のことをいう。
最大値はまたmaxと言って別に表記される。
FLOPSは浮動小数点数演算を１秒に何回できるかを示す指標であり、数字が大きければ大量に演算ができる。
参考までにPS3が 0.2 TFLOPS, PS4が 1.8 TFLOPSなのでPS3の45倍、PS4の5倍の性能になる。
もちろんGPUだけで動くわけではないので数字だけで全てを比較することはできない。
このへんは4gamerで実際にベンチマークしたのでご参考までに
http://www.4gamer.net/games/251/G025177/20160517060/
pascal アーキテクチャー
2016年から採用されるnvidiaのアーキテクチャー。
初めて商品化されるのはgtx 1080から。
一言でpascalになってどう変わったのかをいうのは難しいか、
1) 既存の28nm工程から16nmに変わり、80億トランジスタから153億トランジスタに２倍くらいの搭載になった。
2）finfetトランジスタ採用によりより少ない電力で性能が出せる
3) レジスター数が上がった（既存6.1MBから14.3MB)ので並行で実行できるスレッド数が上がった
感想
nvidiaとintelの水面下で戦いがだんだん現れるかなと思われる。
pascalでアーキテクチャーは最終的にGPCPUへの狙いかと、
まあ、ユーザにとっては性能がいいGPUを安く手に入れて嬉しんだけどねｗ
javascriptで便利そうなのを整理（関数型）
最近はJavascriptも便利になったもので関数型のコーディングもできるようになった。
ただJavascriptのsyntaxにはどうもなれなくて、、なんでこういう書き方をする？と言われると「jsの特性」としか言えないので、いくつか整理
ほぼ自分が忘れた時に参考する自分用メモに近い
jQueryだろうが、AngularJSだろうが、関係なく使えるはず
// 基本オブジェクトというか連想配列で扱う // 処理前後で引数のステータスを変えたくない // リストのソート // hogeが数字 function sort(array) { return array.concat().sort(function(x,y) { return x.hoge - y.hoge; }); } // リストのソート // hogeが文字 function sort(array) { return array.concat().sort(function(x,y) { return x.hoge.localeCompare(y.hoge); }); } // リストの検索 // indexOfのオブジェクト対応版 function indexOf(array, key) { return array.map(function (e) { return e[key]; }).indexOf(key); } // フィルター // 例は100円以上のものを抽出 function filter(array) { return array.filter(function(x) { return x.cost > 100;}); } // 繰り返し処理 // 例えば消費税計算(tex = 0.08) function loopexec(array, tex) { return array.concat().forEach(function(x) { x.price = x.cost * (1 + tax);}); } // 要素同士の計算 // 例えば総額の計算 function total(array) { return array.reduce(function(x,y) { return x.price + y.price;} ); }
大概のことが１行でできるのですっきりする。
prototypeとうまく調合すれば普通のオブジェクトみたいにもなりそうだけど、今回の目的ではないので割愛
いまときのブラウザーだと大概は支援しているはず。
chromeでは問題なく動作しました。
windows 7上にbash + gvm 環境構築
まあ、chocolateyネタです。
某事情によりwindowsに入れる必要が生じたので、2015年4月24日現時点で動く手順
bash環境を整える
1) chocolateyインストール
https://chocolatey.org/
こちらに従いインストール
2) 以下cmdから作業
choco install mingw choco install mingw-get -version 1.0.3 choco install conemu
3) cmd再起動（%PATH%認識のため）
mingw-get install msys-bash
4) conemuに以下を設定して起動
C:\tools\mingw64\msys\1.0\bin\bash --login -i
これでbash起動はできる。
gvm環境設定
前提：上記の作業完了後
1) 以下インストール
mingw-get install msys-base mingw-get install msys-wget mingw-get install msys-unzip mingw-get install mingw32-libz mingw-get install msys-libopenssl mingw-get install msys-openssl mingw-get install msys-grep mingw-get install msys-diffutils mingw-get install msys-less mingw-get install msys-awk mingw-get install msys-sed
choco install curl wget http://curl.haxx.se/ca/cacert.pem mv cacert.pem /c/ProgramData/chocolatey/bin/curl-ca-bundle.crt
3) gvm設定
curl -s get.gvmtool.net | bash source ~/.gvm/bin/gvm-init.sh
4) 確認
gvm install gradle gradle -v
もしmingw-getがうまくインストールできなかったら、http://www.mingw.org/から手動インストールする。
google chromeブックマークマネージャが遅すぎる場合の対処 （旧ブックマークに戻す方法）
最近google chromeがアップデートしてからブックマークデザインが変わった。
いい、悪いはあとにして、ブックマークマネージャがいつまで待っても立ち上がらない
起動すらできないと話しにならないので前のブックマークに戻すことにする。
やり方はURL入力に以下を入力する
chrome://flags/#enhanced-bookmarks-experiment
既定になっているのを無効にして再起動する。
これで前のブックマークに戻る。
いくらいいUI/UXといっても性能を犠牲にして、動きがもっさりする、いつまでの待たされるものはいらない。
android 64bit対応とか、abiとか、java.lang.UnsatisfiedLinkErrorとか、などなど
今回は解決策はなしでとりあえず状況のみ整理
2015年4月17日の現時点で手に入るandroidの64bitデバイスはタブレットのnexus 9のみである。
nexus 9が採用してるアーキテクチャはnvidia k1であるが、
k1も２種類あって、32bitのCortex-A15 r3と64bitのDenverがある。
nexus 9が採用してるのがこのDenverのため初の64bitである。
(android自体は5.xから64bit版があるか、iPhoneとは違いHWはベンダー任せになるので、
nexus 9以外は32bit版のandroid 5.xになるわけですよ）
adb shellでgetpropsの中からabiだけ抜き取ると
ro.product.cpu.abi=arm64-v8a ro.product.cpu.abilist=arm64-v8a,armeabi-v7a,armeabi ro.product.cpu.abilist32=armeabi-v7a,armeabi ro.product.cpu.abilist64=arm64-v8a
このarm64-v8aが64bitであるが、すこしやっかいなことはある。
たしかに64bitでも32bitへの互換性はあるので、
（abiは存在する）32bit版アプリが動かないことはないが、、
基本的にライブラリロードパスが
/system/lib64
/system/app/${appname}/lib64
などになってしまい、
（特にライブラリが32bitと64bitが混じってる場合で64bitが用意されてない場合に）
java.lang.UnsatisfiedLinkError地獄が始まるわけですよ
いまのところは32bit互換性モードで動作させる方法をとるか
（Android.mkに"LOCAL_MULTILIB := 32"を設定するのがセオリ
まあ、System.load("/system/lib/somelib.so");という論外な方法もあるちゃある。）
もしくは64bitのライブラリをそろうかの２択がだが、、
外部FWなどはまだ32bitしかなかったりもするので、まだまだ時間かかりそうだ、、
Ubuntu 12.04 LTS上のruby 1.9.3へのバージョン上げ
わりと面倒くさい手順を踏まないといけなかったのでコマンドのまま記入
redmineの最新trunkがruby 1.9.3なので上げざるを得ないが、、
sudo apt-get update sudo apt-get install ruby1.9.3 sudo update-alternatives --install /usr/bin/ruby ruby /usr/bin/ruby1.9.3 400 \ --slave /usr/share/man/man1/ruby.1.gz ruby.1.gz \ /usr/share/man/man1/ruby1.9.3.1.gz \ --slave /usr/bin/ri ri /usr/bin/ri1.9.3 \ --slave /usr/bin/irb irb /usr/bin/irb1.9.3 \ --slave /usr/bin/rdoc rdoc /usr/bin/rdoc1.9.3 # ruby1.9.3を選択 sudo update-alternatives --config ruby # ruby 1.9.1を選択 sudo update-alternatives --config gem # バージョン確認 ruby --version
Ubuntu 12.04のruby 1.9.3がABIバージョンなのが、原因らしい。。
参考
https://leonard.io/blog/2012/05/installing-ruby-1-9-3-on-ubuntu-12-04-precise-pengolin/
