2013/11/01~

...................................................................................................................................

2013/10/28

デンソー, 車が自動で走行、充電、駐車する「スマートチャージングデモ」, 2013/10/18

先日のITS世界会議でのデンソーのデモ動画が上がっていることを教えてもらった。情報感謝。

-------------------------------------

cnet, アップルの位置情報サービス「iBeacon」-- MLBの試験導入に見る可能性, 2013/10/02

ということで、AppleがiOS7でサポートを開始したiBeacon (記事、記事、記事、記事) なんだけど、Bluetooth 4.0 (LE) 使って最大50 mまで届いて、Beaconと呼ぶ小型送信機はボタン電池で2年間 (!!) 動作するらしい。Beaconの値段は3台で$99 !! iPhoneだけでなく、Androidでも4.3以降なら使えるみたいで、印象としては簡易屋内測位の本命に近い気がする。送信機が安くて設置が簡単なので、今後多数の応用やサービスが出現することが期待される。技術的には完全にIMESと競合するわけだけど、ちょっと考えるとIMESに勝ち目は全くないのではないか。

補足: Bluetooth LE (BLE) 解説。(12:49追記)

再補足: 屋内測位技術の比較項目としては、エリア、精度、価格、消費電力、付加サービス、端末普及度、設置容易性、相互接続性、等々考えられるけど、IMESがBLE/iBeaconに勝っている点て何かあるのかな。WiFiに対しては消費電力、設置容易性等、IMESに少しは優位点があったのだけれど。BLEの圧倒的な低消費電力を知ってしまうとIMES送信機も受信機もいかにも電力食いすぎという感じ。実はBLE、屋外でも周辺障害物の多いところでのGNSSのアシストに使える可能性が高い。例えば駐車場での操車。まあ電波強度では精度が出ない可能性高いけど。超低消費電力GNSS受信機とBLEを組み合わせたシームレス測位デバイスというのも有力。あと重要なのはiPhone標準でSDKがのったということで、今後キラーLBSアプリが出現する可能性が高いこと。送信機が今\3000ということは数が出ればすぐ\100になるし、受信機は\0だし、普及は時間の問題に思える。NFCとはちょっと方向性が違うので住み分けが進むと思うけど。アイデアがある人は今のうちに。(20:36追記)

...................................................................................................................................

2013/10/26

G空間EXPO 2013 地理空間情報科学で未来をつくる, 2013年11月14-16日, 日本科学未来館

あ、蒋君だ。何時の間に。

...................................................................................................................................

2013/10/25

日経, 駐車車両を移動・充電、デンソーが自動走行デモ, 2013年10月16日
MONOist, 自動運転の決め手は準天頂衛星? 測位精度±10cmでEVの無線充電も自動化, 2013年10月25日

多分書いてしまっていいと思うのだけど、このデモでは実はMADOCA-LEX-PPP (それに多分RTKLIB) を使っている。高精度GNSSによる自動走行は、こういう駐車場での操車と高速道路での運転アシストから、徐々に実用化されていくだろうというのが、大ざっぱな技術予測。もちろんマルチセンサ統合は必須で、画像センサ+MEMS-IMU+L1/L5高精度GNSSの組合せが有力。SDRで検討していた様に補強用のLEX/L6受信機はほとんど大した回路いらないので、量産化すれば\1000以下にできるはず。精度いらないのでL1+L6対応の安いパッチアンテナどこかで出さないかなあ。

補足: ということで記事は「嘘ないしとんでも無い誇張」という訳でもない。MADOCA-LEX-PPP、水平RMSで大体10cmは出ているし。もちろん実用化には収束時間の問題や障害物の対応をなんとかしなければいけない訳で、まだ課題は多い。(10/26追記)。

-------------------------------------

計算機が増えて訳が分からなくなってきたので整理のためメモ。

#       HOST,      CPU,  RAM,           HDD/SSD,                 OS,           AP, NOTES
(1) ubuntu11, i7 2600K, 16GB,           2TB+3TB, Ubuntu 11.04 64bit, MADOCA-BATCH,
(2) ubuntu2 , i7 3930K, 16GB,         2TB/240GB, Ubuntu 11.04 64bit,
(3) ubuntu3 , i7 3930K, 32GB, 2TB+2TB+3TB/240GB, Ubuntu 11.04 64bit,    MADOCA-RT,
(4) ubuntu4 , i7 4770K, 32GB,               3TB, Ubuntu 13.04 64bit,             , GTX TITANx2
(5) ubuntu5 , i5 3427U,  4GB,             /64GB, Ubuntu 13.04 64bit,  GNSS-SDRLIB, NUC
(6) windows , i7 2600K, 16GB, 2TB+2TB+2TB/160GB,    Windows 7 64bit,      WINDOWS,
(7)   qnap1 ,        -,    -,     4TBx4(RAID10),      QNAP TS-419II,          NAS,

開発環境はubuntu11のディレクトリを全機でsmbf(cifs)共有。MADOCA-Batchは (2) に移した方が良いかも。MBAが余っているのでこれをMADOCA-RT-PPP-monitor用に設定する予定。

補足: 上のMADOCA-RTは試験評価のため長期連続運用しているもので、QZSSのJAXA-LEX (MADOCA) 用のものとは別。念のため。(10/26追記)

...................................................................................................................................

2013/10/24

Asia Oceania Regional Workshop on GNSS, December 1-3, 2013, Hanoi, Vietnam

一時は存続が危ぶまれたMGA workshopだけど、めでたく5回目。今年はベトナムのハノイ工科大学で。

-------------------------------------

Northrop Grumman, Photo Release -- Northrop Grumman Demonstrates Micro-Gyro Prototype for DARPA Program, October 22, 2013

高精度超小型ジャイロ。NMRG (nuclear magnetic resonance gyro) というタイプらしい。"navigation-grade"とあるが詳細な性能は不明。

-------------------------------------

ついでなので、PPPでのGLONASSの効果を見る。といってもGIPSY-PPPでGLONASSを使うのはgd2p.plの改造が必要でかなり難易度が高い。GIPSY-PPP-AR with GPS + JPL最終暦とRTKLIB-PPP with GPS/GLO + MADOCA速報暦の比較。IGS GRAZ局。何故かこの局のGIPSY解は上に15cmのオフセットが出る　(下記の様にオプションを変更した解に差し替え。GIPSY-PPP-AR解もかなり良いけど、対流圏の分離にはやはり衛星数が効く様。10/25追記)。RTKLIB-PPP with GPS/GLO + MADOCA解はアンビギュイティ解いてなくても概ね十分という感じ。MADOCA暦もGPS/GLO/QZSを入れて正式プロダクトとして運用すれば使う人沢山いそうだなあ。

GIPSY-PPP-AR with GPS and JPL-flinnR (left), RTKLIB-PPP with GPS/GLO and MADOCA Rapid (right)

補足: GIPSY解をRTKPLOTで表示するための簡単なスクリプト (20:18追記)

#!/bin/bash

TDPFILE=tdp_final
if [ "$1" ] ; then TDPFILE=$1; fi

cat $TDPFILE | awk '
BEGIN{printf("%%%14s %15s %15s %15s %3s %3s %8s %8s %8s\n"," GPST","x-ecef(m)",
             "y-ecef(m)","z-ecef(m)","Q","ns","sdx(m)","sdy(m)","sdz(m)");}
/STA Z/{z=$3*1e3; sz=$4*1e3;}
/STA Y/{y=$3*1e3; sy=$4*1e3;}
/STA X/{x=$3*1e3; sx=$4*1e3; t=$1+630763200; w=int(t/604800); t=t-604800*w;
    printf("%4.0f %10.3f %15.4f %15.4f %15.4f %3d %3d %8.4f %8.4f %8.4f\n",
           w,t,x,y,z,6,0,sx,sy,sz);
}'

再補足: GIPSY-PPP-AR解の実行オプション (GRAZ局)。IGS局の場合は大体局情報が登録されているので以下くらいでOK。それ以外の場合は局情報を追加するか追加オプションを指定する必要がある。複数日のデータを結合して解析するのは結構難易度高そう。(21:41追記)

gd2p.pl -d 2013-04-01 -i rinex/graz0910.13o -n GRAZ -r 30 \
    -w_elmin 7 -trop_map GMF -trop_z_rw 1e-7 -amb_res 2 -type k

再々補足: Gradient推定およびOTL補正を入れるには以下オプションを追加。大体のIGS局はOTL係数は既に登録済み。ここまで入れてアンビギュイティを解くと悪くはないけど、やっぱりノイズがすこし大きい。(22:17追記)

gd2pl.pl ... -wetzgrad 2e-9 -add_ocnld -OcnldCpn

再々々補足: 受信機のアンテナモデルは自動では補正してくれないみたい。ということで受信機アンテナモデルの補正にはANTEXからXYZ形式に変換してからオプション指定する必要がある。

sta2antxyz.py -s GRAZ -sinex $GOA_VAR/stainfo/igs.snx -antex $GOA_VAR/etc/antenna_cals_xmit/igs08_1746.atx \
    -o GRAZ.xyz -d 2013-04-01
gd2p.pl ... -AntCal GRAZ.xyz

これで15cmのオフセットが消えて若干精度も向上した。これでRMS E: 0.73 cm, N: 0.95 cm, U: 2.25 cm。しかしオプション増やすとこのケースで83秒もかかる様になった。ちなみにRTKLIB-PPPのGPSのみ解はRMS E: 0.83 cm, N: 1.16 cm, U: 2.03 cmだけど、実行時間が10倍は違うのでGIPSYを常用する気にはならない。(22:49追記)

-------------------------------------

ようやくGIPSYでkinematic PPP解がちゃんと解ける様になった。以下IGS TSKB局のKinematic PPP解。2013/4/1 24H 30s間隔。基準はIGS Final SINEX。ついでなのでRTKLIB-PPP (RTKPOST) とMADOCA-PPP解も。仰角マスク7度。暦はGIPSYはJPL最終暦。RTKLIBとMADOCAはIGS-Finalでアンビギュイティは解いていない。マッピング関数はGIPSYとMADOCAはGMF, RTKLIBはNMF。RTKLIBはOTLと極潮汐補正が入っていない。GIPSYとRTKLIBはフィルタ+スムーザ。MADOCAは最小二乗でZTD+GradientはPW-linearで1H毎推定。実行時間はGIPSYが63秒 (暦ダウンロード除く)、RTKLIBが8秒、MADOCAが12秒 (Core i7 2600K)。

こう見るとARの効果は明らか。GIPSY解のノイズが少し大きいがこれは暦側の問題か? あとGIPSYで大量の解析を流すのは、遅すぎてつらい (まあ複数同時実行すれば少しはマシだが)。

GIPSY-PPP (left: ambiguity-float, right: ambiguity-resolved) with JPL-flinnR

RTKLIB-PPP (left), MADOCA-PPP (right) with IGS-Final

補足: RTKLIB-PPPでこんなに精度出ないんだけど、というお問い合わせを貰った。RTKPOSTの設定とconfファイル。重要な点はキネマティックPPPの場合はクロック補間誤差を避けるため高頻度クロックを使うこと。GPS 1Hzの場合はCODE暦と5Sクロック、GPS+GLONASSの場合はESA暦と30Sクロックを使うと吉。あと軌道とクロックをワイルドカードを使って単一ファイルパスで指定するとクロックがうまく読み込まれない問題があるみたいなので、軌道とクロックは入力ファイルを分けて指定ください。(10/25追記)

再補足: GIPSY解をちゃんとオプション設定した解に差し替え。(10/26追記)

-------------------------------------

ユーザ登録して1週間、ようやくGISPYのdocumentにアクセスできる様になった。ということでdocument全部落として読む。release notes見るとver. 6.0 (Dec 22, 2010) からgd2p.plのオプション-amb_resが使える様になっている。あとGISPY User Group MeetingをAGUに合わせて毎年行っている様。

GISPY用の軌道クロックプロダクト生成システムの構築や運用を始め、ずいぶんと時間と人とお金がかかっている印象。多数の人が開発に関わっている様で、ソフトウェアそのものは複雑で見通し悪いし、ユーザインタフェースもとても使いやすいとは言えないのだけど、実績と伝統のある大規模解析ソフトウェアという感じ。これら開発には米国政府の研究資金が入っているみたいだけど、RTKLIBも、誰か国の予算とって継続的にメンテできる体制作ってくれないかなあ。

...................................................................................................................................

2013/10/22

パソコンGPSショップでNovAtel OEM6の扱いが始まっている。GPS/GLO/GAL/QZS 20Hz (RTK無) で\124万。GPS/GLO版は\40万だけど1周波ではないか (要確認)。

-------------------------------------

GPS/GNSSシンポジウム2013, 2013年10月29-31日, 東京海洋大学 越中島会館

今年から講演会参加は有料 (一般2000円, 学生1000円) になったみたい。ただ、測位航法学会に入会 (年会費 一般5000円, 学生1000円) すれば無料。

2日目午後にPPPの技術動向について少し話をする予定。当日までに新ネタを1つでも仕込みたいなあ。

...................................................................................................................................

2013/10/19

GSA, GNSS Market Report: Issue 3, October, 2013

GSA (European GNSS Agency) によるGNSS市場レポートの最新版。これによるとGNSS市場規模は2016年までは年率9%で延びるけど2017-2022年までは年率5%に鈍化する。ついでなので重要な指標だけ表にしてみる。面白いのは自動車関係の売上があまり伸びないと予測していること。これはPNDの市場がスマホやIVS (in-vehicle systems) に代わられデバイス単価も半分以下に落ちるのが大きい様。あとはまだ市場は小さいけど鉄道が大きく伸びると見ていること。さて実用準天は何を目指すのが正しいのか。

-------------------------------------

W.Bertiger et al., Single receiver phase ambuguity resolution with GPS data, J. Geod, 2010

この論文自体は既に2回くらい貼っているのだが、論文中のPPP-AR手法はGIPSY-OASIS-II 6.1.2では既に利用可能であるとのこと。GIPSYでの解析時に使用するJPLのプロダクトにはAR用バイアス解が含まれている。実は必要あって大学でGIPSYのライセンスを取ってちょっと使い始めたので。ちなみにGIPSYの大学での研究目的の利用は今のところ無償。ただソースプログラムは現在米国外へは公開されないらしく、配布パッケージはバイナリ版しかない。従って、自分で改造しての利用は困難。またライセンス申請から承認まですごく時間がかかるので気長に待つ必要がある。今回は2カ月くらいかかった。ほとんど使ってないけど、これで手元にBernese 5.0, GIPSY-OAISIS-II 6.2, GAMIT 10.4と一通りは揃った。

補足: GIPSYのgd2p.plを実行するとデフォルトではJPLのサーバからPPP用の暦を自動でダウンロードしてくれる。これ結構便利だなあ (まあそれ以外は使いづらい点が多いのだけど)。ということで、RTKPOSTとRNX2RTKPの次期版では暦の自動ダウンロード機能を付けるつもり。(10/20追記)

...................................................................................................................................

2013/10/18

Response, [ITS世界会議13] GPS、グロナス、ガリレオ・・・衛星測位を使った通行料金徴収 各国の現状, 2013年10月18日

おお、小暮さんだ。いつもお世話になってます。ということでGNSSによるロードプライシングなんだけど、ジャミングやスプーフィング対策も必要だし、どれくらい実用的なんだろう。

...................................................................................................................................

2013/10/14

これ見るとMKLでAVX2が有効になるのは11.0かららしい。従って9/28の結果は当然。ということで最新版のC++ Composer XE 2013 SP1 (非商用版) をダウンロードして、Haswellマシンにインストール。再計測。

i7 4770K (MKL 11.1)
matmul()   200 x   200: time=  0.002 s (  7980.0 MFLOPS)
matmul()   500 x   500: time=  0.002 s (124875.0 MFLOPS)
matmul()  1000 x  1000: time=  0.013 s (153769.2 MFLOPS)
matmul()  2000 x  2000: time=  1.076 s ( 14866.2 MFLOPS)
matmul()  5000 x  5000: time=  1.348 s (185441.4 MFLOPS)
matmul() 10000 x 10000: time= 10.540 s (189743.8 MFLOPS)
solve()   200 x   200: time=  0.001 s
solve()   500 x   500: time=  0.004 s
solve()  1000 x  1000: time=  0.024 s
solve()  2000 x  2000: time=  0.170 s
solve()  5000 x  5000: time=  2.187 s
solve() 10000 x 10000: time= 16.488 s

何故か2000 x 2000の乗算だけ異常に遅いが、AVX2の効果はありそうだ。(AVX2でFMA (fused multiply-add) 演算が追加され、DP演算速度が最大16 FLOPS/core/cycle、3.9GHzで249.6GFLOPSになっている)

-------------------------------------

NSLからすぐ回答が来て、新バージョンのβ版を貰ったのは良いのだけど、APIが大幅に変わっている。ということは使うためにはこっちのSDRコードもかなり直す必要がある。なかなか、簡単には行かないなあ。

-------------------------------------

NUCのubuntu 13.04ではまたstereoが正常動作しない。11.04では動いていたのに。ということで、またNSLに問い合わせを送る。ドライバソースを公開して欲しい。

...................................................................................................................................

2013/10/12

IGS ACの中でも最も品質の高いと思われるESA暦 (最終暦) のGPS軌道精度を貼っておく。3D-RMSで1.7cm級。これに追い付くのはかなり大変。

補足: グローバルなcm級測位のため、最終的にはリアルタイムでこれに近い所を狙っている。ただ、アンビギュイティをリアルタイムで解いて、かつ長期安定性を確保するのは技術的にかなりハードルが高い。実用準天が上がる頃にはなんとか。(10/13追記)

-------------------------------------

なんかテンプレでうちの頁が参照されている...。

-------------------------------------

長期評価用に昨年5月から毎日作っているMADOCA速報暦のGPS軌道精度を貼っておく。下と同一期間。障害ノウハウを得るのが目的なので再解析もチューニングも全く行っていない。HDあふれ、N/W障害等で暦の欠落がかなりある。24Hアーク (オーバラップ0H)。データはIGS69局。GLO軌道、局座標、EOPも同時推定して解析時間は1日分概ね5分半 (Core i7 2600K)。

補足: これを見る限り力学モデルや観測モデルはほぼ問題ない。解の乱れの原因はいくつか可能性があるが、(1) パラメータ更新漏れ、(2) QCが甘い、が主。ミスフィックスは残差検定でほぼ100%除去できるはずだが何点か残っている可能性もある。局選定をやり直し、オーバラップを追加して、QCを若干改善すれば、実用暦で3D-RMS 2cm前後はほぼ行けるだろうと思う。もちろん実用暦として運用するためには運用保守要員が必須。なお、リアルタイム暦は品質を上げるのはずっと難しくて、かつ運用経験も不足している。これは今後品質改良のための戦略を考える必要がある。(19:45追記)

再補足: (3) サイクルスリップ検出漏れ、(4) unknownなGLONASSデータの荒れ、を原因に追加しておく。(4) はGLONASS抜いて再解析すると良くなることが多いので。今後、長期評価→オフライン系改良→リアルタイム系改良、の予定。特に入力データスクリーニングは長期の運用経験とノウハウが必要でそのために長期連続で試験運用している訳で。可能なら5年とか10年の運用経験が欲しい。まあRTKLIBでもここまで7年かかっているので、MADOCAも完成までまだまだ時間が必要。(10/14追記)

-------------------------------------

昨年12月に公開された、QZSS最終暦のGPS軌道誤差 (IGS Final基準) を解析したので貼っておく。2012/11/25-2013/9/28 (308日分)。

宇科連での発表によると、7日アーク推定でQZSS MS 9+3局以外にIGS局30-40局のデータを使っているらしい。局の数やアンビギュイティを解いていない点を考慮しても、モデル面で改善要素が相当に有りそうに思える。

...................................................................................................................................

2013/10/11

高橋他, PPP実験用プログラム, GPS/GNSSシンポジウム2013 研究発表会予稿

LEX MT10,11と12って排他でしか送信してないのだけど、どうやってMT10,11取得したのだろう。あとIGS Final使った20時間PPPの平均でN: -5.5cm, U: +3.7cmってあまりに誤差大きすぎる様な。

補足: これ、平成22-24年度の文科省宇宙利用促進調整委託費による研究らしい。税金使った成果ならぜひプログラムを公開して欲しい。(10/12追記)

...................................................................................................................................

2013/10/10

高須他, 複数GNSS対応高精度軌道時刻推定ツールMADOCAの開発, 第57回宇宙科学技術連合講演会, 平成25年10月9日〜11日, 米子コンベンションセンター

宇科連の予稿をアップ。著作権上は少し微妙なのだけど多分許容されるはず。発表資料は春の連合大会と殆ど変りなくて恥ずかしいのでアップせず。自分で書くのもなんだけど、世界的に見ても恥ずかしくない成果だと思っているので、ちゃんとした査読付論文書きたいなあ。

...................................................................................................................................

2013/10/08

Haswell、auto OCで使っていたのだけど、負荷かけて3時間位運転するとリセットがかかる。素の性能だけでなくOC耐性も低い。2600Kも3930Kも、OCして3日位負荷かけ続けても全然問題ないのに。Haswellひ弱過ぎ。ということでOC OFFにして解析最初からやり直し。最近ほとんど耐久試験みたいな解析を、3台パラでずーと流し続けているので。やっぱり3930Kにしておくんだった。

-------------------------------------

秋の測地学会講演会プログラムがupされている。幾つか聞きたい講演があるのだけどGPS/GNSSシンポジウムと重なって参加は無理そう。

...................................................................................................................................

2013/10/07

GeForce GTX Titan単体では1.3TFLOPS, CPU-GPU間メモリコピーを入れても1TFLOPS位は出る様。ホストのマザーがZ87-AでPCIe 3.0 x 16が2本あるので、2枚までならバスネックにならなそう。ということでTitan 2枚目行くか。そのために電源1000W級にしたので。目的は行列計算律速な某APを4倍速くすること。

-------------------------------------

MAGMAを入れてみた (magma-1.4.0)。性能測定用のテストコードが付いているのでdgemm (行列積) とdpotrf (コレスキ分解) の結果。ただ、やはりGPUメモリを超えたサイズの計算はエラーとなる。

> ./testing_dgemm
MAGMA 1.4.0 , capability 3.0
device 0: GeForce GTX TITAN, 875.5 MHz clock, 6143.7 MB memory, capability 3.5
Usage: ./testing_dgemm [options] [-h|--help]

If running lapack (option --lapack), MAGMA and CUBLAS error are both computed
relative to CPU BLAS result. Else, MAGMA error is computed relative to CUBLAS result.

transA = N, transB = N
    M     N     K   MAGMA Gflop/s (ms)  CUBLAS Gflop/s (ms)   CPU Gflop/s (ms)  MAGMA error  CUBLAS error
=========================================================================================================
 1088  1088  1088    686.52 (   3.75)    1130.81 (   2.28)     ---   (  ---  )    1.61e-16     ---
 2112  2112  2112    740.33 (  25.45)    1237.12 (  15.23)     ---   (  ---  )    1.69e-16     ---
 3136  3136  3136    741.15 (  83.23)    1279.18 (  48.22)     ---   (  ---  )    1.16e-16     ---
 4160  4160  4160    737.24 ( 195.30)    1280.01 ( 112.49)     ---   (  ---  )    1.76e-16     ---
 5184  5184  5184    736.00 ( 378.57)    1304.38 ( 213.61)     ---   (  ---  )    1.42e-16     ---
 6208  6208  6208    735.79 ( 650.33)    1292.01 ( 370.36)     ---   (  ---  )    1.19e-16     ---
 7232  7232  7232    726.82 (1040.83)    1282.89 ( 589.68)     ---   (  ---  )    2.05e-16     ---
 8256  8256  8256    732.04 (1537.45)    1273.28 ( 883.92)     ---   (  ---  )    1.80e-16     ---
 9280  9280  9280    723.27 (2209.89)    1267.91 (1260.63)     ---   (  ---  )    1.61e-16     ---
10304 10304 10304    720.77 (3035.63)    1267.06 (1726.83)     ---   (  ---  )    1.45e-16     ---
> ./testing_dpotrf
MAGMA 1.4.0 , capability 3.0
device 0: GeForce GTX TITAN, 875.5 MHz clock, 6143.7 MB memory, capability 3.5
Usage: ./testing_dpotrf [options] [-h|--help]

ngpu 1, uplo L
    N   CPU GFlop/s (sec)   GPU GFlop/s (sec)   ||R_magma - R_lapack||_F / ||R_lapack||_F
========================================================
 1088     ---   (  ---  )     56.64 (   0.01)     ---
 2112     ---   (  ---  )    194.41 (   0.02)     ---
 3136     ---   (  ---  )    299.93 (   0.03)     ---
 4160     ---   (  ---  )    493.23 (   0.05)     ---
 5184     ---   (  ---  )    620.15 (   0.07)     ---
 6208     ---   (  ---  )    700.28 (   0.11)     ---
 7232     ---   (  ---  )    769.77 (   0.16)     ---
 8256     ---   (  ---  )    819.80 (   0.23)     ---
 9280     ---   (  ---  )    861.55 (   0.31)     ---
10304     ---   (  ---  )    900.15 (   0.41)     ---

...................................................................................................................................

2013/10/06

DP速くするためにはGeForce GTX Titanの設定が必要な様。NVIDIA X Server SettingsでCUDA Double Precisionをチェック。

matmul()   200 x   200: time= 0.195 s (     81.8 MFLOPS)
matmul()   500 x   500: time= 0.002 s ( 124875.0 MFLOPS)
matmul()  1000 x  1000: time= 0.008 s ( 249875.0 MFLOPS)
matmul()  2000 x  2000: time= 0.031 s ( 516000.0 MFLOPS)
matmul()  5000 x  5000: time= 0.304 s ( 822286.2 MFLOPS)
matmul() 10000 x 10000: time= 2.025 s ( 987604.9 MFLOPS)
matmul() 15000 x 15000: time= 6.339 s (1064801.2 MFLOPS)

おお、軽く1TFLOPSオーバーである。GPU温度は負荷をかけた状態で75度くらい。小さめのDGEMMだけなら、Xeon E5-2687W × 2 × 3 すなわち\108万相当の価値がある。コストパフォーマンス抜群。あとはn=15000を超える大きな行列を自動分割してくれるライブラリがあると良いのだけど。

...................................................................................................................................

2013/10/01

いつのまにか10月だあ。GPS-702-GGは完全に死亡。代わりにAntcomを屋根の上に上げる。L6だけじゃなくL1, L2も少しレベルが低い感じ。

...................................................................................................................................

〜2013/09/30