BLASの高速化の編集

*BLASの高速化 [#lb854bcb]
//by なかま 2004-08-10

COLOR(red){SIZE(25){祝！ libgoto-1.0.0 リリース！}}

[[TACC:http://www.tacc.utexas.edu/resources/software/]]より(要登録)ダウンロード
- 05/10/04現在Linux版のみ(更に早くなってる...XEONで体験)

**なんでも掲示板で話題の後藤ライブラリ(libgoto) [#x15b1612]

***なんでも掲示板より [#da4da1d3]

更なる幸せを求めて.~
 私「マシン欲しい...奥様買ってぇ〜(爆)」
 妻「昨日速くなったって喜んでたじゃない。」
 私「...」

***Windowsの人 [#i8b902e4]

から自分のCPUにあった
 libgoto_CPU_L2-Rel.zip をダウンロード
 libgoto_CPU_L2-Rel.zip を解凍
 # Rblasと置き換える
 move R_HOME?bin?Rblas.dll R_HOME?bin?Rblas.dll.org
 copy  libgoto_CPU_L2-Rel.dll R_HOME?bin?Rblas.dll

R-1.9.1のソース(win32)の中にはlibgotoが複素数を扱えない
ものとしてblasGoto.cがコーディングされている.
その結果,R標準のBLASのcmpblas.fが利用される.
なんとなく、その労力を消すのはもったいない気がする.(謎)~
ソースからビルドする方は注意されたい.

***Unixの人 [#x999cf2e]
http://www.cs.utexas.edu/users/kgoto/ から自分のCPUにあった
 libgoto と xerbla.c をダウンロード.
 gzip -d  libgoto_p4_128-r0.94.so.gz
 gcc -c xerbla.c
 gcc -shared -o libgoto.so ~/libgoto_p4_128-r0.94.so xerbla.o 
 # xerbla(BLASやLAPACKで表示に必要)ルーチンはRのsrc/main/print.cにも
 # 含まれているので,Rでしかlibgotoを使わないならば,直接libgoto_xx_xxx-r0.xx.so
 # を使えば良い.

Rgoto と言うシェルスクリプト作成

#!/bin/bash
 export LD_PRELOAD=~/libgoto.so:/lib/libpthread.so:/lib/libm.so
 ${RPROG:-R} -q $*

起動

$ ./Rgoto

無論、ちゃんとビルドしなおした方が良いのは言うまでも無い.

***スレッド使いな人 [#p82354ce]

マルチスレッド版のGogo's BLASをダウンロード~
環境変数 OMP_NUM_THREADS 又は GOTO_NUM_THREADS(0.99以降) に並列数を定義~
 export OMP_NUM_THREADS=2
A%*%B等の演算が高速に行われます~

***野良ビルド派 [#ye8bad3f]
libgotoを/usr/local/libに入れたなら.~
 ./configure --with-blas='-L/usr/local/lib -lgoto_xxx -lpthread'

***rpmの人向け [#qec1bce3]
SPECファイル&ref(libgoto.spec); をダウンロード.~
ターゲットのlibgotoとxerbla.c をダウンロード.~
 mv libgoto.spec ~/rpm/SPECS/
 mv libgoto*so.gz xerbla.c ~/rpm/SOURCES/
 
 # define で cpu と rel をあたえる.
 rpm -ba --define 'cpu p4_128' --define 'rel r0.95' ~/rpm/SPECS/libgoto.spec
 
 # インストール
 rpm -ivh ~/rpm/RPMS/i386/libgoto*.rpm

R 本体は SPECファイル内の configure の所に --with-blas=goto を加えて再ビルド
を行えばよい.

**なんでも掲示板で話題が薄くなったATLAS [#p4f8bc7b]

***Windowsの人 [#b6a42d70]
[[http://cran.md.tsukuba.ac.jp/bin/windows/contrib/ATLAS/:http://cran.md.tsukuba.ac.jp/bin/windows/contrib/ATLAS/]]
から適当なRblas.dllをダウンロードしてR_HOME/bin にコピーすればよい.

***Debian [#j7d06501]
Debianの中の人はアレゲ(?)なので既にRはATLAS化されています.
でもキャッシュのサイズはマシン毎に異なるので自前でビルドしなおすと
もうすこし早くなると思われる.

***Unix [#m5299b7b]
ATLASを持ってきて
 make xconfig
 ./xconfig -c gcc -f g77 -m gcc -F c $CFLAGS -F f $FFLAGS -F m $CFLAGS
等好き勝手にするなり、言われたとおりにするなり好奇心の続く限り挑戦する.
さらにLAPACK(ATLAS化)も可能だが,労力には見合わない.

----
-CPU が違うということですが、お持ちのCPUは何ですか？ -- [[後藤]] &new{2004-08-11 (水) 20:43:17};
-あはは。元発言者とは違うのですが，私はMacintoshG5なんです。 -- [[青木繁伸]] &new{2004-08-11 (水) 20:54:40};
-ちなみに私はAthlon-XP(BartonコアL2 512KB)です。Windows上でですがPentium3用でもそこそこ速くなりました。と言っても http://toucan.stats.ox.ac.uk/R/RWin/ATLAS/ の方が20%くらい速かったですが。Opteron用は動きませんでした。 -- [[aki]] &new{2004-08-11 (水) 21:12:29};
-G5 用なら私のページにあります。Athlon-XP は裏でこそこそと作っていますが、じゃ、お試しということで公開します。しばしお待ちを。 -- [[後藤]] &new{2004-08-11 (水) 21:29:38};
-http://www.cs.utexas.edu/users/kgoto/R/libgoto_athlon-r0.05.zip として置いておきました。ただ、行列積の性能はまだ ATLAS の方が速いです。 -- [[後藤]] &new{2004-08-11 (水) 21:44:34};
-ウワーイv(^O^) -- [[aki]] &new{2004-08-11 (水) 21:45:12};
-http://www.cs.utexas.edu/users/kgoto/R/libgoto_athlon-r0.95.zip URL違うようです。 -- [[aki]] &new{2004-08-11 (水) 21:46:50};
-なかまさんのtest2ではATLASと同程度のようです。 -- [[aki]] &new{2004-08-11 (水) 21:51:17};
-バージョン番号間違えました。0.05 ではなくて 0.95 が正しいです。 -- [[後藤]] &new{2004-08-11 (水) 22:06:55};
-うっ,いつのまにか推敲されている...この推敲機能はMac製のようですね.(^-^; -- [[なかま]] &new{2004-08-12 (木) 20:03:40};
-P4 の 128kB L2 版を http://www.cs.utexas.edu/users/kgoto/R/ に置いておきました。 -- [[後藤]] &new{2004-08-12 (木) 20:57:52};
-テキサスに引っ越しました。上記のURLはあと数週間でなくなる予定です。新しいアドレスは追って連絡します。 -- [[後藤]] &new{2004-12-04 (土) 09:55:58};
-心よりお待ちしてます。m(_|_)m -- [[なかま]] &new{2004-12-07 (火) 10:15:25};
-[[FreeBSD Expert 2005:http://www.gihyo.co.jp/magazines/fbe]]にFreeBSDへのATLASによる最適化BLASの導入について触れられています。libgotoも紹介だけされています。 -- [[aki]] &new{2004-12-11 (土) 23:22:29};
-バージョンを 0.96 に上げました。 -- [[後藤]] &new{2004-12-21 (火) 13:26:46};
-さっそく(p4-128ですが...)試したんですが,~
  # reg-tests-1 より
  > data(esoph)
  > options(digits=22) # <- 一応入れてみた
  > ## PR 796 (aic in binomial models is often wrong)
  > ##
  > a1 <- glm(cbind(ncases, ncontrols) ~ agegp + tobgp * alcgp,
  +         data = esoph, family = binomial())$aic
  > a1
  [1] 236.9644704031314006443
  > a2 <- glm(ncases/(ncases+ncontrols) ~ agegp + tobgp * alcgp,
  +         data = esoph, family = binomial(), weights=ncases+ncontrols)$aic
  > a2
  [1] 236.9644704031314290660
  > stopifnot(a1 == a2)
  Error: a1 == a2 is not TRUE
  Execution halted
などとtests/{lm-tests.R,reg-test-1.R}等で精度によるエラーとなってしまいました-- [[なかま]] &new{2004-12-22 (水) 10:55:37};
-うむむ。調べてみたのですが、Lapack のエラーチェックでは引っかからないのですが。以前のバージョンでは正しく動作しますか？ -- [[後藤]] &new{2004-12-22 (水) 11:59:48};
-0.95では問題ありませんでした. -- [[なかま]] &new{2004-12-22 (水) 14:28:14};
-バグの原因は ddot でした。ただいま修理中です。ご迷惑をおかけします。 -- [[後藤]] &new{2004-12-23 (木) 01:26:48};
-バグと書いたのですが、どうもバグではないかもしれません。今回から dot は SSE2 を使うようにしたのですが、その影響として計算順序が異なること、80bit 精度であったのが 64bit に落ちたことで計算誤差が発生しています。これは避けられないんじゃないですか？(BLAS の精度は信用しないほうがいいです。はい)。 -- [[後藤]] &new{2004-12-23 (木) 07:37:01};
-非常に詳しい解説をどうもありがとうございました.現状のRでは過度?の最適化は確かに誤差の応酬になってしまいます.やはり浮動小数点統計の限界でしょうか.==やuniqueなんかを見直すとよいのかもしれませんが,大規模な問題なんかではとんでもない結果になるでしょうし...ああっ,難しすぎ...(笑) -- [[なかま]] &new{2004-12-23 (木) 16:51:31};
-R のチェックルーチンでは"正しい解"と比較しているのではなくて、切り口を変えて比較しているので、相対的な精度が重要みたいです。複数のアーキテクチャで試してみましたが、他のすべてのアーキテクチャでは、236.96447040313143 となりました（よくみると桁数が合わない）。というわけで、x86 の fp スタックと SSE2 の演算を混ぜたことに問題がありそうです。ちなみに x86_64 では同一の ddot を使用しているにもかかわらずテストはパスしました。 -- [[後藤]] &new{2004-12-24 (金) 03:10:46};
-いろんなアーキテクチャ(コンパイラが違うとかも)ということで,236.9644704031314,236.96447040313140,236.96447040313143,と総計3種類(x86以外ですが)導き出されました.ですので相対精度が重要(それで比較しているわけですので)となるのは間違いありません.値的にもとんでもなく違ってる訳でもないのですが,もしかして期待してもよろしいのでしょうか(Rユーザ向け?改善の余地はあるのでしょうか).(^_^; -- [[なかま]] &new{2004-12-24 (金) 07:03:01};
-とりあえず他にバグが潜んでいるかもしれないので、いろいろ確認してみます（x86_64 でパスした点が引っかかっているので）。浮動小数点誤差の蓄積は避けられないので、あとは使う人が気をつけるしかないです（金利計算に使われたらどうなるんだろう．．） -- [[後藤]] &new{2004-12-24 (金) 07:55:11};
-よろしくお願い致しますm(_|_)m.追記ですが,同じ演算を繰り返しても値が異なるようです(それは是非避けたい事象なのですが...). -- [[なかま]] &new{2004-12-24 (金) 10:34:18};
-結果が異なるんですか〜．．．．。バグかも。 -- [[後藤]] &new{2004-12-24 (金) 11:16:38};
-誤差の原因がわかりました。内積計算の途中段階で値が非常に小さくなるときがあるんです。具体的には n=10 の時に 7.7546476184853219e-15 となる時があります。計算順序を変更すると、この加算が結果的に考慮されなくなります。修正前のライブラリは順番に加算していたのですが、そのときには偶然にも中間の内積値が小さいらしいのです。SSE2 に変更して計算順序を変えたら問題が発生したというわけです。というわけで、ごのバグは R のチェックルーチンに問題があるという結論になりました。 -- [[後藤]] &new{2004-12-24 (金) 14:06:03};
-ちなみに x86_64 でパスした理由は、すべての浮動小数点演算のディフォルトが SSE/SSE2 だからです。x87 fp は使っていません。 -- [[後藤]] &new{2004-12-24 (金) 14:08:39};
-再現するプログラムを添付しておきました。なお、値を正確に保持するためにプログラムがきたないですが、ご容赦ください。ほぼ絶対値が同じで、符号が違う加算を最後に行っています。これって、Ｒの意図した計算なのでしょうか？そうだとしたら私の出る幕ではないですが。 -- [[後藤]] &new{2004-12-24 (金) 15:43:31};
-「ディフォルトが SSE/SSE2 」との事なので,-mfpmath=sse -msse2 -O2 -pipe -march=i386 -mcpu=i686 でビルドを行った所,チェックは通過するようになりました.しかし,値の末尾は4,40,43,46等と不定期ですので出にくくなっただけなんだと思います.AICの結果については精度までは不毛だと思います(たぶん).誤差なんかを考えればほぼ近似値であればいいもの(そういう関数があったかは?ですが)なんだと思います.でも同じ演算のはずが毎回結果が違うのだけはなんとかならないものでしょうか.(^^; -- [[なかま]] &new{2004-12-24 (金) 17:07:15};
-- -march=i386 -mcpu=i686ではsse2は使用されないのでは。-march=pentium4にする必要があったような。 -- [[aki]] &new{2004-12-24 (金) 19:47:32};
-- gccのバージョンによるのかもしれませんが,ごみプロでアセンブラを吐かせると,大丈夫のようでした.表示もSSEっぽい(桁数が少ない)ですし。
- たんなる私のボケが入っているとなんですので
 options(digits=22)
 data(esoph)
 aic<-array()
 for (i in 1:100)
 aic[i]<- glm(ncases/(ncases+ncontrols) ~ agegp + tobgp * alcgp,
              data = esoph, family = binomial(), weights=ncases+ncontrols)$aic
 fivenum(aic)
 [1] 236.96447040313137 236.96447040313140 236.96447040313143
 [4] 236.96447040313143 236.96447040313149
-私のところでは再現できないのですが。。。この手の問題の場合にはＣＰＵが熱くなっていて誤動作しているとか（他にクロックアップとか）、そんなことはないですか？ -- [[後藤]] &new{2004-12-24 (金) 23:10:02};
-chroot環境のR,ビルド環境の野良R,いちおうインストールしたR,LD_PRELOADした場合と,やはり0.96のみそうなります.(^^; クロックアップはしてませんし,この時期の冷却には自信?があります...セレロンだから? まあ,なんにしても私だけの問題なのでしたらなんなのですが... -- [[なかま]] &new{2004-12-25 (土) 03:02:51};
-ddotをlibblasから持ってきてgcc -shared -o libhoge.so ddot.o -lm してLD_PRELOADすると,値が異なる問題は発生しませんでした. -- [[なかま]] &new{2004-12-25 (土) 04:45:56};
-今回の直接の犯人は確かに ddot なのですが、たまたま ddot が問題になっただけで、他の内積系ルーチン(GEMV,GEMM)でも同じ様な問題が発生するはずです。これが私のプログラムに問題があるのか、それともハードウェアの問題なのかの切り分けをしたいのですが。最近の MKL(7.2) でも SSE2 を使っていますので、こちらで動作させたらどうなりますか？同じ様な挙動を示すと思うのですが。 -- [[後藤]] &new{2004-12-25 (土) 08:34:39};
-おなじ挙動とあいなりました。さしずめ,そんなCPU使っちゃいやん〜。と解釈すればよろしいでしょうか。(滝汗) -- [[なかま]] &new{2004-12-25 (土) 11:36:25};
-ならばＣＰＵの誤動作と考えられますので、周波数を下げる、供給電圧を上げる、もしくは交換しかないです。このままだと夏場になったら大きな誤差がでますよ。 -- [[後藤]] &new{2004-12-25 (土) 11:51:09};
-こちらこそ大変お手数をおかけしました.(壊れないPCが欲しい今日このごろ...)m(_|_)m -- [[なかま]] &new{2004-12-25 (土) 20:10:05};
-この問題を回避するパッチを作っておきました。これでいいのかなぁと思うところもあるのですが、とりあえずテストは通ります。 -- [[後藤]] &new{2004-12-28 (火) 09:03:00};
-ありがとうございますm(_|_)m.正月休みにはCPU他は交換予定です.して,そのパッチはどちらに... -- [[なかま]] &new{2004-12-28 (火) 10:31:16};
-このページに添付してあるfpu.patchなのでは? -- [[aki]] &new{2004-12-28 (火) 11:21:19};
-思いっきり,見落としました.(爆)御指摘ありがとうございまする. -- [[なかま]] &new{2004-12-28 (火) 11:29:19};
-src/unix/system.c:Rf_initialize_R -> src/unix/sys-unix.c:fpu_setup の所でいままで_FPU_IEEE(0x037f)してましたんでこれを0x027f(FreeBSDはどうするんだろ)にしたとして,あとようるすにどれだけ影響が出るか?が問題となって来る訳ですね.(^^; -- [[なかま]] &new{2004-12-28 (火) 11:53:10};
-最近のライブラリは SSE/SSE2 を多用していることが多いので、精度を揃えるという点では必要なパッチです。あとは、どこで精度を設定するかは開発者のポリシー依存です。 -- [[後藤]] &new{2004-12-28 (火) 12:08:31};
-そうすると,configureに--with-sse(オプションとfpu_controlの制御目的)とかを追加するのが一番妥当でしょうか.採用されるかはわかりませんが作ってみます. -- [[なかま]] &new{2004-12-28 (火) 12:49:00};
-どちらかというと、ディフォルトで組み込んでしまってもいいんじゃないですか？ -- [[後藤]] &new{2004-12-28 (火) 12:54:09};
-ぜんぜん関係のない話ですが、上記の "Unix の人" のところで xerbla.o をリンクする話が書いてありますが、私が試した限りではこのステップは不要でした。単純に名前を書き換えるか、--with-blas= でライブラリ名を正確に指定すれば大丈夫です。 -- [[後藤]] &new{2004-12-28 (火) 13:12:15};
-XERBLAは,src/main/print.cに含まれていますが,BLAS自体はR以外でも使うかなぁーと思いましたもので. -- [[なかま]] &new{2004-12-28 (火) 13:53:47};
-新たに, CeleronDの2.8G(L2=256) + Mother + Memory を購入したんですが, p4_128 p4_256 とも やはり毎度値が異なってしまいました。(^^;; バッタモノでも掴まされているのでしょうか? 他にCeleron,P4をお持ちの方は如何でしょうか. もしかしてうちのlibmが腐っている?  -- [[なかま]] &new{2005-01-08 (土) 19:15:45};
-中間様、R のバイナリをメールで送っていただけませんか？こちらで確認してみます。まさかですが、100V の電圧が実は低くて、高負荷をかけると誤動作するなんてことはないですよね？ -- [[後藤]] &new{2005-01-13 (木) 15:22:59};
-FreeBSD(NetBSD)用のライブラリの需要ってどの程度ありますか？x86 版をとりあえず作ってみようかな、と思ったので。 -- [[後藤]] &new{2005-01-13 (木) 15:29:21};
-自宅ではなく,会社にてDebian(sarge)pentiumM(L2,1M)の環境でlibgoto_p4_512-r0.96を試しました.Rはdebianの物(LD_PRELOADで実行)ですが同じ(結果がばらつく)結果でした.libmもlibimfに変えてみましたが同じでした. -- [[なかま]] &new{2005-01-13 (木) 18:25:26};
-野良ビルドで R-2,0,1 and R-2.0.1+patch はみょーな事になりますが,R-develでは正常に機能しました.(いったいこの違いは...)と言うことでR側を再度調べてみます.ざっと見,それらしい修正は無いような... -- [[なかま]] &new{2005-01-13 (木) 22:22:39};
-私は欲しいです＞FreeBSD用。でも私ぐらいなんでしょうか・・・。FreeBSDユーザがそんなに少ないとも思えないんですが・・・。 -- [[aki]] &new{2005-01-13 (木) 23:18:02};
-私も PentiumM を持っているので試してみます。可能性としては低いのですが、マルチスレッド経由で呼び出されている場合にはこの現象が起こるかもしれません。 -- [[後藤]] &new{2005-01-14 (金) 03:11:46};
-とりあえず [[FreeBSD:http://www.cs.utexas.edu/users/kgoto/FreeBSD/]] 版を作ってみました。ただし、現時点では Pentium4 Northwood 版のみです。ちゃんと動くかどうかわからないので、動作報告をお願いします。 -- [[後藤]] &new{2005-01-17 (月) 07:18:51};
-すみませんPentium4機持ってません・・・(泣。 -- [[aki]] &new{2005-01-17 (月) 14:27:56};
-もしかして Athlon ですか？ -- [[後藤]] &new{2005-01-17 (月) 14:51:55};
-そうです。AthlonXP 2500+が3台あります(笑)。 -- [[aki]] &new{2005-01-18 (火) 04:39:36};
-あと、私は現在修論の追い込みでいっぱいいっぱいなのでRのリビルドなどができるようになるのは修論発表が終わる2月中頃以降になります。すみません。他にもどなたかFreeBSDでRをご利用の方がいらっしゃればよいのですが。 -- [[aki]] &new{2005-01-18 (火) 22:18:23};
-今のところ FreeBSD 用は誰も取っていかないですね〜(ダウンロード数ゼロ)。 -- [[後藤]] &new{2005-01-19 (水) 05:31:18};
-ガーーーン。FreeBSDユーザーってそんなに少ないのか・・・。 -- [[aki]] &new{2005-01-22 (土) 02:57:48};
-バージョン0.97が出たようです. --  &new{2005-03-21 (月) 20:35:04};
-性能の悪い部分の見直しを始めました。作業量が多くて、まだ途中の段階です。 -- [[後藤]] &new{2005-03-22 (火) 12:20:39};
-it2p-r0.97ですが,BLAS : Bad memory allocation! Program is Terminated.と言われてしまいました. -- [[なかま]] &new{2005-04-12 (火) 15:03:55};
 a<-array(runif(2^2),dim=c(2,2))
 b<-array(runif(2^2),dim=c(2,2))
 a%*%b
OMP_NUM_THREADS(デフォルトは未設定で8設定してみたのは2)を変更しても再現しました.
意味はないかもしれませんが,スレッドライブラリは標準では/lib/tls/libpthread-0.60.soで,/lib/libpthread-0.10.so(他libc,libm)をプリロードしましたが,同様な結果と
なりました.
PentiumMはp3_512-r0.97で元気に動いてくれました.Xeon3.2,Opteron(246),
も元気に動いてくれました.CeleronD2.8は今だ謎ですが,p3とすることにしました.(^^;
-OMP_NUM_THREADS=2 で動作しませんか？メモリ管理の問題でスレッド数を抑えてあります。P4 用に関しては、キャッシュサイズを自動検出して内部のパラメータを動的に変更するようにプログラムを修正中しているところです。 -- [[後藤]] &new{2005-04-13 (水) 13:14:21};
-失礼しました.スクリプトを確認したところ,OMP_NUM_THREADSのSが抜けておりました.m(_o_)m とても快適に動作致しております.ありがとうございます. -- [[なかま]] &new{2005-04-13 (水) 13:42:05};
-ライブラリを更新しました。L2 のサイズ/CPU 数は自動検出ですが、コア別になっているので、ちょっとわかりづらいかも。ちなみに Celeron D は Prescott コアです。 -- [[後藤]] &new{2005-05-11 (水) 09:01:24};
-Celeron D で動きました. m(_|_)m -- [[なかま]] &new{2005-05-11 (水) 14:24:06};
-0.99が出たようです. --  &new{2005-05-26 (木) 22:03:14};
-libgoto 0.99 を中間処方箋に従い試してみました。R で set.seed(123); system.time(sort(runif(1e6))) を実行すると、使わないと 2.54 秒、使うと 1.33 秒でした。早い！ただし、A <- matrix(1:100,10,10); A%*%A を実行すると以下のメッセージが出て、R が死にます。P4 32 ビット版のどちらでも同じ症状でした。他の方いかがですか？なお、つっこまれても計算機音痴の私にはおそらく満足のいく使用環境の説明は不可能です。 -- [[間瀬]] &new{2005-05-26 (木) 22:50:47};
 /usr/lib/R/bin/exec/R: relocation error: 
 /home/mase/libgoto_prescott-32-r0.99.so: undefined symbol: pthread_create
-リンクオプションに -lpthread を加えてください。 -- [[後藤]] &new{2005-05-26 (木) 23:48:32};
-libpthreadも一緒にプリロードする必要があります. -- [[なかま]] &new{2005-05-27 (金) 00:01:45};
 #!/bin/bash
 # libgotoの位置,名前は便宜書き換えてみてください.
 
 LIBPTHREAD=`/sbin/ldconfig -p|grep libpthread.so|head -1|perl -p -e 's#.*\s([/\.0-z]+)#$1#'`
 LIBM=`/sbin/ldconfig -p|grep libm.so|head -1|perl -p -e 's#.*\s([/\.0-z]+)#$1#'`
 export  LD_PRELOAD=~/lib/libgoto_katmai-32-r0.99.so:${LIBPTHREAD}:${LIBM}
 echo $LD_PRELOAD
 /usr/bin/R $*
-set.seed(123); system.time(sort(runif(1e6))) はリブ後藤とは無関係なような... -- [[なかま]] &new{2005-05-27 (金) 00:18:14};
-後藤さん、中間さん、コメントありがとうございました。A%*%B のエラーはなくなりました。ついでに便乗質問、P4 32 ビット版の二つのライブラリのどちらが私のシステム向きなのか確認する簡便な方法がありますか。見たところどちらも問題なく使え、簡単な検査ではほぼ同等の速度向上をしているように見えますが。もう一つ、中間さんのコメントで、libgoto は線形代数用(?)ライブラリだということを思い出しましたが、それでもやはり単に /usr/bin/R で実行する場合に比べ格段に sort(runif(1e6)) の実行速度が早い（二倍程度）のはなぜ？ また A <- matrix(runif(1e6),1000,1000); system.time(A%*%A) では両者の速度が実に１０倍程度違うのですが、これは libgoto の霊験と考えていいのでしょうか（少し極端過ぎるような？）.普段使うPCを最近代えてから、ソフト（例えばKDE）の反応速度が異様に遅くなり、困っていますが、何かこれと関係する問題かなとも勝手に憶測したりもしているのですが（こんなこと聞かれても答えようがないですね、すみません）。 -- [[間瀬]] &new{2005-05-27 (金) 15:36:27};
-Debian Sargeですよね。たぶん。するとデフォルトでインストールすると,2.4系カーネルで,linux26[Enter]でインストールすると,2.6系がインストールされます.たぶんlibc6-i686もインストールされているので,ldconfig -pでは2.6用のlibmが選ばれるのではないかと.普通に起動して2.4カーネルだとlibc6の方のlibmを読みます.libc6-i686はオプティマイズされてますから,その差ではないかと(物凄いいい加減な推論).なので2.6系カーネルをインストールしてgrub-install+再起動を行えば,幸せになれるのかも.コアの確認は最近変えられたのであれば下の段でほぼ間違い無いのではないかと思います.10倍の性能差はatlas3-{base,sse}が入ってなければありうるかも. -- [[なかま]] &new{2005-05-27 (金) 22:49:37};
-質問が複数ありますので項目別にします。 -- [[後藤]] &new{2005-05-27 (金) 23:50:05};
-- 最近購入されたマシンならばPrescott コアです。Prescott版のライブラリでA*Aを実行して動作すればPrescott、落ちた場合にはNorthwood版を使えばいいです。
-- sort(runif(1e6))ではほとんどの実行時間はsort内で消費されていると思いますが、これは私のライブラリは関係ないでしょう。考えられる理由はライブラリの実行アドレスが変化して、命令の実行効率が上がったためかもしれません。
-- 速度差が10倍くらいなら正常ではないでしょうか。少し大きな行列で計算時間を測定して、理論性能に対する効率が80%以上となるならば正常です。
-- 体感的に遅く感じられるということでしたら、カーネルを再構築したほうがいいです。割り込みの処理で不具合が出ている場合があります。不必要なドライバは全部取り除くといいです。微妙に遅いということなら、2.6系のカーネルはタイムスライスの関係だと思うのですが、若干ユーザ時間に割り当てられる時間が短くなっています。結果的に性能が少し落ちます。
-かなり個人的なことがらに丁寧にお答えいただき恐縮です。検討してみます。 -- [[間瀬]] &new{2005-05-28 (土) 08:05:54};
-本当に初歩的な質問で恐縮なのですが、blasのサポートがなくてもRは動きますよね？blasのサポートがあった方がRが高速に動くのでしょうか？ --  &new{2005-05-28 (土) 10:20:25};
-Rは幾つかのBLASルーチン(最適化されてない)を持っています.外部BLAS(ATLAS,GOTO等)を使えば行列*ベクトル,行列*行列等が高速に行われます.Rは更にLAPACKルーチンも持っていますが,これもBLASを呼びますからこれらの演算も恩恵にあずかります.(でもRはBLASルーチンのほんの一部の機能しか使いませんが). -- [[なかま]] &new{2005-05-28 (土) 12:34:12};
-レスありがとうございました。早速BLASを含めてＲのコンパイルをしようと思います。 --  &new{2005-05-28 (土) 12:55:39};
-確認してみましたが、sort(runif(1e6))では R_rsort2 という関数でほとんどの実行時間(80%以上)を消費しているようです。というわけで BLAS は関係ないようです。 -- [[後藤]] &new{2005-05-30 (月) 15:52:51};
-有難うございます。新パソコンと Linux の相性が悪い（こんなことは初めて）らしく、実行速度については何を信じて良いのかわからない状態です。 -- [[間瀬]] &new{2005-05-30 (月) 17:39:02};
-そのマシンの構成ハードウェアがちゃんとLinuxに対応しているか確認して買わないと、特に新しいマシンでは問題が出ることがありますよ。メジャーなハードならいずれ問題は解決するとは思いますが。私が使っているFreeBSDはLinuxよりハードの対応が少なくて遅いので気を付けてパーツを揃える癖が付きました。Debian(sarge)ならカーネルもできるだけ新しいものにしてみてはどうでしょうか。 -- [[aki]] &new{2005-05-30 (月) 19:22:01};
-泣く人が増えないように、報告しておきます。機械は EPSON Endeavour AT951 です。一年前の同機種は何の問題も無く快適だったとのですが。ちなみに Linux は Knoppix 3.8 ですから、カーネルも 2.6.11 です。ネットで調べたら、やはり同じ機械で数値計算が異様に遅いという記事がありましたが、解決策は示されていませんでした。 -- [[間瀬]] &new{2005-05-30 (月) 20:13:40};
-どうもAT951には動作はしても速度が一定しない不安定な個体があるようですね。[[BIOSの更新プログラム:http://support.epsondirect.co.jp/edcfaq/edsnsys_expub.nsf/ContentsID/DL100000162]]が出ていますのでもし古いBIOSでしたら更新してみられてはいかがですか。ダメならメーカーにクレームを入れた方が良いのでは。私の場合、購入時には後のことも考えてメジャーマザーボードベンダの、メジャーなデバイスばかり搭載したマザーボードを採用しているPCを購入するようにしています。メジャーなデバイスなら問題の発生率も低くソフト側の対処も期待できますし、ベンダ側のBIOSの修正も期待できますので、それで直る問題もありますし。残念ながらAT951はEPSON独自マザーボードのようですね。以前はBIOS更新の頻繁なASUS製を採用していたのですが(今も採用機はあるかもしれません)。あと、直接関係無いですけどグラフィック機能統合チップセット採用機はCPUとグラフィック機能でメモリ帯域を食い合ってパフォーマンス上不利なので独立したグラフィックチップ搭載機を買われた方がよろしいかと。できればメモリもデュアルチャネルで。 -- [[aki]] &new{2005-05-31 (火) 00:57:59};
-そういえば、Windows 版の BLAS はきちんど動作しているのだろうか？どなたか試されました？ダウンロードしていく方は多いのですが（ちなみに本日のダウンロード数４６２）、動作報告はほとんどないので。バグ報告がないということは動作していると思うのですが。 -- [[後藤]] &new{2005-06-01 (水) 11:55:34};
-Northwoodは動きましたが,Katmaiの方はなにやら申します. -- [[なかま]]
 #0  0x6c989ad7 in ztrsm () from c:\Program Files\R\rw2010\bin\Rblas.dll
 #1  0x6c989066 in ztrsm () from c:\Program Files\R\rw2010\bin\Rblas.dll
 #2  0x6c94dd0b in libgoto_p3_512-r0!STRMV ()
    from c:\Program Files\R\rw2010\bin\Rblas.dll
 #3  0x1002eafc in do_matprod () from c:\Program Files\R\rw2010\bin\R.dll
&new{2005-06-01 (水) 16:07:45};
-バグを見つけてしまいました。ただいま修正中。 -- [[後藤]] &new{2005-06-04 (土) 07:52:31};
-修正しました。 -- [[後藤]] &new{2005-06-07 (火) 13:22:09};
-Window2000/XPのリンク先が Windowsのパスになってますです.(^-^; -- [[なかま]] &new{2005-06-07 (火) 14:22:24};
-修正しました。リンク先をチェックするのを忘れていました。 -- [[後藤]] &new{2005-06-07 (火) 14:33:26};
-別のリンクミス発見。とほほ。 -- [[後藤]] &new{2005-06-08 (水) 04:50:57};
-Win32でcoppermine,northwoodは動作したんですが,katmaiは上記と同じままでした. -- [[なかま]] &new{2005-06-08 (水) 11:25:21};
-すみません。まだやっていません。これから調べてみます。 -- [[後藤]] &new{2005-06-08 (水) 11:29:35};
-あっいえ、一応報告と言うことですので.(^-^;滝汗; -- [[なかま]] &new{2005-06-08 (水) 13:42:55};
-調べてみましたが、こちらでは問題を見つけることができませんでした。中間さんの動作チェックは同一マシン上で行ったものでしょうか（すべてのチェックを P4 上で行ったということ）？そうだとしたら、やっぱり私のライブラリの方に問題があるのでしょう。 -- [[後藤]] &new{2005-06-10 (金) 02:45:45};
-PentiumMで行いました. P3マシンは今手元に無いので明日調べてみます. -- [[なかま]] &new{2005-06-10 (金) 15:07:40};
-ではやはり私のライブラリの方に問題があると思いますので、もうすこし丁寧に調べてみます。 -- [[後藤]] &new{2005-06-10 (金) 20:48:12};
-このページにあるｗｉｎｄｏｗｓ用のlibgotoのリンクがないのですが、もうなくなってしまったのでしょうか。NorthwoodのwinxpでＲを使用しているのですが・・・・。 -- [[やま]] &new{2005-11-16 (水) 18:32:14};
-現在Linux版のみのようです. ATLASを使いましょう. -- [[なかま]] &new{2005-11-16 (水) 20:20:39};

#comment

タイムスタンプを変更しない