アカウント名:
パスワード:
数値演算の精度を端折って高速化したと。
浮動小数点演算で、64ビットのdouble型演算の代わりに、可能な限り32ビットのfloat型の演算を使用することで、大幅にその演算速度が向上したという。
数値演算の精度が問題になる場面で、不具合が起きなければいいが・・・Officeスウィート系のWebアプリは怖くて使えんなあ。
明らかに処理の内容を変えて「高速化」というのは疑問を感じますね。それで、C++に迫ったといわれてもなんか違う。
世の中の最適化を全否定だな。答えが一緒なら処理なんて関係ないでしょ。
型が単精度から倍精度に変わるんだよ？常に答えが一緒になるとは限らないでしょ。
んで、最適化によって値が変わる可能性があるから、Cとかにはvolatileが用意されてるわけで。JavaScriptにvolatileに相当するものは私の知る限りは無いはず。そういう言語で値が変わるかも知れない最適化ってのはちょっと問題ある気がする。
JavaScriptの仕様的にはオーバーフローしたら倍精度に勝手に変換するみたいだけど、そこら辺どうなんだろ。仕様に合わせて内部処理を最適化しただけって話ならいいんだけど。
んで、最適化によって値が変わる可能性があるから、Cとかにはvolatileが用意されてるわけで。
違うけど?
ん？冗長性の排除も最適化の一種だよね？それによってはき出す値が一定しないなら「最適化によって値が変わる」って言えると思ってたんだけど、違うかな。特にポインタの排除なんか、Cだと値が不定になるわけでしょ？
実際にvolatileが必要になるケースに出会った事がなくて資料上で把握していた知識なので、認識が間違ってたらその部分を指摘してもらえるととても嬉しい。
それはむしろ例えばgccの-ffloat-storeとか-fexcess-precisionとか-ffast-math-funsafe-math-optimizationsとかのオプションで変えるような動作なんじゃないか？丸めるとか丸めないとか、そんな類の動作の違いで結果として動かす環境によって下の方のビットが違ったり違わなかったりとかするわけだけど。
volatileのは最適化じゃなくて何かのバグだろう。volatileはその有無で計算内容が変わるわけじゃない。
ちょっと自信ないけど、
volatile double hoge;
ってあったとすると、hogeへのアクセスは必ずメモリを読み書きするんだよね？doubleはメモリ上では64ビットだけど、x86のFPUレジスタは80ビットだから、誤差が出るかもしれないし出ないかもしれない。私もよくわかりませんが、どなたか検証してくれないかな。
ウチの環境(core2duo Cygwin gcc 4.7.3)で試してみた結果が↓
#include <stdio.h>#include <limits.h>
int main(){ const int x = INT_MAX; { double e = 1.0; const double m = 1.0 + 1.0 / x; int i; for (i = 0; i < x; i++) { e *= m; } printf("(1.0 + 1.0 / %d) ** %d = %1.20lf\n", x, x, e); } { volatile double e = 1.0; const double m = 1.0 + 1.0 / x; int i; for (i = 0; i < x; i++) { e *= m; } printf("(1.0 + 1.0 / %d) ** %d = %1.20lf\n", x, x, e); } return 0;}
$ gcc -O2 e.c && ./a.exe(1.0 + 1.0 / 2147483647) ** 2147483647 = 2.71828182656034833542(1.0 + 1.0 / 2147483647) ** 2147483647 = 2.71828182653240091327
お、誤差出ましたか。
http://homepage1.nifty.com/herumi/prog/prog90.html [nifty.com]
↑によると、fnstcwという命令で、演算精度を変更できるらしいです。同じマシンでも、コンパイラによって、設定が異なるとか。
ほうほう。一致してるのが10進で10桁(+一の位が2なので1bit)だから(10/log2)+1でだいたい33bitsとちょっと(？)ってとこか。「オプションを何も付けてなきゃ計算精度も格納精度も一緒だから誤差は出ない」かと思ってた。オプションつけるとまた違うんだろうなー。
バイナリが 32bit だからだろう。32bit版では、浮動小数点計算には x87 を使う。最適化すれば途中結果はx87 のレジスタ上に残っているが、最適化しなければ x87 (80bit)とメモリ(64bit)との間を行ったり来たりする。
対して、64bit 版では SSE などの SIMD レジスタ(64bit)を使う。従って、実行結果は一致する(実際一致した)。
これは、-mfpmath=sse オプションが設定されているかどうかに依存するらしい。32bit版では設定されておらず(明示的に指定する必要があり)、64bit版ではデフォルトで設定されている。
info gcc より：'-mfpmath=UNIT'
$ gcc -O2 -mfpmath=387 e.c && ./a.exe(1.0 + 1.0 / 2147483647) ** 2147483647 = 2.71828182656034833542(1.0 + 1.0 / 2147483647) ** 2147483647 = 2.71828182653240091327
$ gcc -O2 -mfpmath=sse e.c && ./a.exe(1.0 + 1.0 / 2147483647) ** 2147483647 = 2.71828182656008765505(1.0 + 1.0 / 2147483647) ** 2147483647 = 2.71828182656008765505
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
目玉の数さえ十分あれば、どんなバグも深刻ではない -- Eric Raymond
数値演算の精度が問題になることないの？ (スコア:0)
数値演算の精度を端折って高速化したと。
浮動小数点演算で、64ビットのdouble型演算の代わりに、可能な限り32ビットのfloat型の演算を使用することで、大幅にその演算速度が向上したという。
数値演算の精度が問題になる場面で、不具合が起きなければいいが・・・Officeスウィート系のWebアプリは怖くて使えんなあ。
Re: (スコア:0)
明らかに処理の内容を変えて「高速化」というのは疑問を感じますね。
それで、C++に迫ったといわれてもなんか違う。
Re: (スコア:0)
世の中の最適化を全否定だな。答えが一緒なら処理なんて関係ないでしょ。
Re: (スコア:0)
型が単精度から倍精度に変わるんだよ？
常に答えが一緒になるとは限らないでしょ。
んで、最適化によって値が変わる可能性があるから、Cとかにはvolatileが用意されてるわけで。
JavaScriptにvolatileに相当するものは私の知る限りは無いはず。
そういう言語で値が変わるかも知れない最適化ってのはちょっと問題ある気がする。
JavaScriptの仕様的にはオーバーフローしたら倍精度に勝手に変換するみたいだけど、そこら辺どうなんだろ。
仕様に合わせて内部処理を最適化しただけって話ならいいんだけど。
Re: (スコア:0)
んで、最適化によって値が変わる可能性があるから、Cとかにはvolatileが用意されてるわけで。
違うけど?
Re: (スコア:0)
ん？
冗長性の排除も最適化の一種だよね？
それによってはき出す値が一定しないなら「最適化によって値が変わる」って言えると思ってたんだけど、違うかな。
特にポインタの排除なんか、Cだと値が不定になるわけでしょ？
実際にvolatileが必要になるケースに出会った事がなくて資料上で把握していた知識なので、認識が間違ってたらその部分を指摘してもらえるととても嬉しい。
Re: (スコア:1)
それはむしろ例えばgccの-ffloat-storeとか-fexcess-precisionとか-ffast-math-funsafe-math-optimizationsとかのオプションで変えるような動作なんじゃないか？丸めるとか丸めないとか、そんな類の動作の違いで結果として動かす環境によって下の方のビットが違ったり違わなかったりとかするわけだけど。
volatileのは最適化じゃなくて何かのバグだろう。volatileはその有無で計算内容が変わるわけじゃない。
Re:数値演算の精度が問題になることないの？ (スコア:1)
ちょっと自信ないけど、
volatile double hoge;
ってあったとすると、hogeへのアクセスは必ずメモリを読み書きするんだよね？
doubleはメモリ上では64ビットだけど、x86のFPUレジスタは80ビットだから、
誤差が出るかもしれないし出ないかもしれない。
私もよくわかりませんが、どなたか検証してくれないかな。
Re:数値演算の精度が問題になることないの？ (スコア:2, 参考になる)
ウチの環境(core2duo Cygwin gcc 4.7.3)で試してみた結果が↓
#include <stdio.h>
#include <limits.h>
int main()
{
const int x = INT_MAX;
{
double e = 1.0;
const double m = 1.0 + 1.0 / x;
int i;
for (i = 0; i < x; i++) {
e *= m;
}
printf("(1.0 + 1.0 / %d) ** %d = %1.20lf\n", x, x, e);
}
{
volatile double e = 1.0;
const double m = 1.0 + 1.0 / x;
int i;
for (i = 0; i < x; i++) {
e *= m;
}
printf("(1.0 + 1.0 / %d) ** %d = %1.20lf\n", x, x, e);
}
return 0;
}
$ gcc -O2 e.c && ./a.exe
(1.0 + 1.0 / 2147483647) ** 2147483647 = 2.71828182656034833542
(1.0 + 1.0 / 2147483647) ** 2147483647 = 2.71828182653240091327
Re:数値演算の精度が問題になることないの？ (スコア:1)
お、誤差出ましたか。
http://homepage1.nifty.com/herumi/prog/prog90.html [nifty.com]
↑によると、fnstcwという命令で、演算精度を変更できるらしいです。
同じマシンでも、コンパイラによって、設定が異なるとか。
Re:数値演算の精度が問題になることないの？ (スコア:1)
ほうほう。
一致してるのが10進で10桁(+一の位が2なので1bit)だから(10/log2)+1でだいたい33bitsとちょっと(？)ってとこか。
「オプションを何も付けてなきゃ計算精度も格納精度も一緒だから誤差は出ない」かと思ってた。
オプションつけるとまた違うんだろうなー。
Re: (スコア:0)
バイナリが 32bit だからだろう。32bit版では、浮動小数点計算には x87 を使う。最適化すれば途中結果はx87 のレジスタ上に残っているが、最適化しなければ x87 (80bit)とメモリ(64bit)との間を行ったり来たりする。
対して、64bit 版では SSE などの SIMD レジスタ(64bit)を使う。従って、実行結果は一致する(実際一致した)。
これは、-mfpmath=sse オプションが設定されているかどうかに依存するらしい。32bit版では設定されておらず(明示的に指定する必要があり)、64bit版ではデフォルトで設定されている。
info gcc より：
'-mfpmath=UNIT'
Re: (スコア:0)
$ gcc -O2 -mfpmath=387 e.c && ./a.exe
(1.0 + 1.0 / 2147483647) ** 2147483647 = 2.71828182656034833542
(1.0 + 1.0 / 2147483647) ** 2147483647 = 2.71828182653240091327
$ gcc -O2 -mfpmath=sse e.c && ./a.exe
(1.0 + 1.0 / 2147483647) ** 2147483647 = 2.71828182656008765505
(1.0 + 1.0 / 2147483647) ** 2147483647 = 2.71828182656008765505