【初心者歓迎】C/C++室 Ver.37【環境依存OK】

>>949
sseだと、floatなら４要素まとめて計算できるのに対して、
doubleだと２要素までが限界。
そういう意味ではfloatの方が圧倒的に速いね。

藤原の翁の時代は、圧倒的にdoubleの方が速かった。
何故なら、当時のCはfloat同士の演算でもdoubleへの格上げが起こっていたから。
今のCは超越関数にも全てfloat版が用意されているしx86系などのCPUについては
ベクタ演算やキャッシュを考えてもfloatが不利の状況は随分と減った。
しかし、精度が高々10進に換算して7桁程度しかないのは痛い。

気になって、IA32アーキテクチャってやつを読んでググったりもした結果
さっぱりわかんね。ま、わかんなくて当たり前なんだけど。（頭悪りいから）
結局コンパイラ次第なのかな。
まぁ、いいや。

近似でおおざっぱに計算するときは、浮動小数点が速い(CPUに専用ハードが搭載されているからな)
厳密な計算をするには、整数でやるしかない


例えば、エンコーディングなどは、浮動小数点計算を多用するだろ?同じオプションで2度やっても
同じファイルは生成されない(これは途中の計算が近似になってしまっているという事だ)
例えば、円周率計算などは、何度やっても正確に数億桁求まる(整数演算は正確だという事だ)

>>955
>>955
>>955

つまり、doubleで実数演算を繰り返して円周率を数億桁正確に求めるプログラムを作った漏れは神と言うことですな。

>>956
どうした?ホントだぞ

触っちゃだめだよ。きっと変なのがうつる。

実数計算は、桁落ちとかあるんだぞ　しらんのか
10億と、10のマイナス20乗くらいを足してみると、10億になってしまうんだ　しらんのか

よくわからんが、それは実行ごとに違った結果を返すの？

Athlon 64 X2が浮動小数点演算は35%早いものの、
逆に円周率演算のベンチマークではCore 2 Duoが20%早いという結果に。
AMDはこのデータをもとにして「ひたすら円周率の計算をしたい人なら
Core 2 Duoを買ってください」と皮肉った。

http://www.watch.impress.co.jp/akiba/hotline/20060812/etc_amdevent.html

float/double使わない奴ってmath.hインクルードしたことないんだろうな
ま、実際使わん方面では全然使わんからUnix方面では通常
libmがlibcから分離されてるんだろうけどな

ま、>>955の持ってるPCでは中の人がサイコロ振ってて、
sin()だのlog()だのが呼ぶたんびに違う結果を返すんだろｗ

>>961
よく知らんが、FFTとかで計算順序(CPUへ命令が送られる順序)が変わったりするため
浮動小数点を使うエンコーディングなどは同一データが生成され無いと思われ

>>963
誰のPCでもMP3のエンコーディングすると、違うファイルが生成されるはずだ
同一オプションでMP3を生成して、ファイル比較ソフトundupで比較してみ

class CObjectがあるとき、配置newを使ってCObjectの為のリソースchar* pool
を使いまわしにしているとする。

あるCObjectのインスタンスAが既にある時に同じリソースを使って別のインスタンスBを
作る際に、どうやらAのデストラクタが呼ばれないようなんで、"仮想"デストラクタを設計したい。
こういうときに使える常套的な方法をどなたかご存知ないでしょうか？

自分で思いついた方法は、同じCObjcetのインスタンスをファクトリから作らせるようにして
新たにインスタンスを作る際に既に存在しているインスタンスの"仮想"デストラクタを
呼ぶような設計にするぐらいです。

>>965
Lameで10Kほどのファイルを4回エンコしてみたが、結果かわらんみたいだよ。

>>967
使ったソフトの入手先教えて　再現するか試してみるから

午後のこ〜だでも変化なし。

>>968
cdex v1.51付属のlameエンコーダ。
普通にcdexからエンコした。
入手先は忘れたよ。CDEX_151.EXEって名前のインストーラだけど。

4分のapeをそれぞれ5つ変換してmd5sumで比較してみたけど、
lameなら全部同じで、oggencは全部違った。

確認するけど違いは、音質や、ファイルサイズのことでは無いよ
厳密に1ビットもズレが無いって事だよ

>>972
んなの分かりきっとる。俺はUnix環境じゃないからcompコマンド使ったよ

エンコーダとマルチコアとかで結果は変わってくるようだな
一般的に、並列処理する部分があれば、浮動小数点計算は、桁落ちや、情報落ちが
起こって最終的な結果がかわる

ぁあ…キムチ食べるっ、キムチ食べますうっ！！
ビッ、ブリュッ、ブリュブリュブリュゥゥゥーーーーーッッッ！！！
いやああああっっっ！！おかわりしないで、お願いぃぃぃっっっ！！！
ブジュッ！ジャアアアアーーーーーーッッッ…ブシャッ！
ブババババババアアアアアアッッッッ！！！！
んはああーーーーっっっ！！！キッ、キムッ、キムチィィィッッ！！！
ムリムリイッッ！！ブチュブチュッッ、ミチミチミチィィッッ！！！
おおっ！メイド　イン　チャイナッ！！チッ、チッ、チャイナッッ！！！
原産国見てぇっ ああっ、もう ダメッ！！はうあああーーーーっっっ！！！
ブリイッ！ブボッ！ブリブリブリィィィィッッッッ！！！！
いやぁぁっ！あたし、こんなにいっぱいキムチ食べてるゥゥッ！

>>966
配置 new やメモリ領域の使い回しをやめればいいと思うよ。

TUBAMEや地球シミュレータやその他諸々の並列演算処理系を否定する勢いだな。

ファイルヘッダにエンコード日時欄があるとかいうオチは勘弁だぜ？

まー何だ、浮動小数点数では結合法則や交換法則が厳密にはなりたたんことが
あるのは事実だわな。
A=すんごいでっかい数
のとき、
数学的には
A-A+1 == 1
でなければならないが、加算の順序を変えたりするとそうはならなかったり。
だから、逐次的でないやり方で計算をすれば確かに結果は変わり得るだろう。

とはいえ「逐次的に計算すれば」問題は無いわけだから、浮動小数点数の
演算は再現性が無いから糞、というように読み取れる>>955は
暴論としかいいようがない（実際lameの結果はビットパーフェクトで
再現してるよな）し、逐次的でない並列計算を行うにしろ、誤差が
許容範囲に入ってて、ビットパーフェクトの再現性が必要でないのなら
別に問題ではないわけだよな。

全く同じ計算を同じCPUの同じ命令で行えば、
誤差も全く同じになるから、結果も同じにならないわけがない。
違ったらそれこそPentium以上の大事件だ。

>>980
だから、「計算順序を変えたら結果が変わる」ってだけだべ
要は「同じ計算」をやってないってことなんだが

マルチコアでも、コアによって計算結果が違うことは無いだろう。
一つ一つのデータを見た場合、
それに対する計算は常に同じ順序で行われるわけだから、
並列計算時でも結果が違うことは無いだろ。

>>978
oggencが入れているかどうかは知らないけれど、日付けのフィールドは確かにあるね。

命令スケジューリングで並び替えられたらマズそうな気が
結果が変わるような浮動小数点演算を並び替えたりはしないんだろか

>>984
例えば、'r = a + b + c'をコンパイルして

mov r, a // r = a
add r, b // r += b (1)
add r, c // r += c (2)

となった場合に、(1)と(2)の順番が入れ替わることがありえるのかって話だよね？
↑のコードだと、依存性があるからアウトオブオーダーで入れ替わることは無いんだけど、
他のコンパイル結果ならそういうことが起こるかもしれない。
ちょっと分からない。

まぁ、しないね。
寧ろ、x86系の場合FPUとSSEで精度が変わる方が厄介。
#まぁ、それもコンパイルオプションで強制できるけど。

CPUのキャッシュに送られてからでも計算順序は変わる可能性あるだろ
OSとか他の命令動かしているんだし
OSの命令が入り込むかどうかで変わるだろ

>>985,986
thx。やっぱそうだよなあ。
>>987
おいおい……

>OSの命令が入り込むかどうかで
なんと危なっかしいアーキテクチャだろうか。

>>987の脳内ではマルチタスクOSではプログラムの逐次実行という
ノイマン型計算機の基本すら保障されないらしいｗ

おまいらはここ読んでべんきようしろよな

投機的実行
http://ja.wikipedia.org/wiki/%E6%8A%95%E6%A9%9F%E7%9A%84%E5%AE%9F%E8%A1%8C

アウト・オブ・オーダー実行
http://ja.wikipedia.org/wiki/%E3%82%A2%E3%82%A6%E3%83%88%E3%83%BB%E3%82%AA%E3%83%96%E3%83%BB%E3%82%AA%E3%83%BC%E3%83%80%E3%83%BC%E5%AE%9F%E8%A1%8C

スーパースケーラ
http://ja.wikipedia.org/wiki/%E3%82%B9%E3%83%BC%E3%83%91%E3%83%BC%E3%82%B9%E3%82%B1%E3%83%BC%E3%83%A9

>>987
燃料投下乙。埋めネタとしてはまぁまぁ上出来だったよ。

CPUの最適化ってのは丸め誤差や情報落ちその他、
浮動小数点計算について回る存在しないことを前提に
行われるものだったのか

また面白くもないものを引っ張ってきたようだな（＠ｗぷ

計算機アーキテクチャに関する書籍でも買ったらどうかね（＠ｗぷ

＞＞９９１

>>994
ちょ、懐かしいなオイ(w

（＠ｗぷ

埋めるなら先に次スレ立てろ
【初心者歓迎】C/C++室 Ver.38【環境依存OK】
http://pc11.2ch.net/test/read.cgi/tech/1180877635/l50

>>997
乙

梅

1000なら幸せになれる

このスレッドは１０００を超えました。
もう書けないので、新しいスレッドを立ててくださいです。。。