アカウント名:
パスワード:
今現在で64bitを有効に使う用途っていうと, どうしても科学技術計算(さすがにDBサーバには怖い)だと思います. とすると現実的にはFORTRANが必須となるわけで, Appleが高効率のコードを吐き出すFORTRANコンパイラを提供できるかが当面のキモになりそうです. もちろんPowerPCアーキテクチャ用としてIBMが提供してくれれば無問題ですが.
MacOSは伝統的に可視化
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
海軍に入るくらいなら海賊になった方がいい -- Steven Paul Jobs
ってゆーか 64bit なのですが (スコア:0)
教えて、エロ^H らい人。
Re:ってゆーか 64bit なのですが (スコア:1)
今現在で64bitを有効に使う用途っていうと, どうしても科学技術計算(さすがにDBサーバには怖い)だと思います. とすると現実的にはFORTRANが必須となるわけで, Appleが高効率のコードを吐き出すFORTRANコンパイラを提供できるかが当面のキモになりそうです. もちろんPowerPCアーキテクチャ用としてIBMが提供してくれれば無問題ですが.
MacOSは伝統的に可視化
Re:ってゆーか 64bit なのですが (スコア:3, 参考になる)
グローバルイルミネーションを実現するためのフォトンマップや、パストレーシング+イラディアンスキャッシュの構築は、簡単なシーンでも数ギガバイト消費することがあります。
フォトンマップの場合、XYZ座標、入射光方向のベクトル、RGB各32bitに加えて、光源のIDなどのデータを持ったフォトンが、一つの光源から数万個~のオーダーで発生します。
ちょっと古くさいけどメッシュ分割するラジオシティでもシーンが充分に複雑であれば同様に足りなくなります。
いままではそれだけのデータを喰うレンダリング(やプリプロセッシング)を時間的な問題から待てなかったので、問題が表面化することは少なかったのですが、最近はプロセッサの速度が向上しているためこの限界に突き当たることが出てきました。
高い精度のデータを扱えるのも重要なポイントです。
視点からの距離データも重要ですね。数km先まで見えるシーンで目の前の2mmの段差を判定しなければならないようなシチュエーションがあります。
ネイティブにdouble floatが扱えるなら、このような処理も高い信頼性と処理速度でこなせるようになり、応用範囲が広がるでしょう。
どれも「そんなシーン作る方が悪い」ということになっていますし、それぞれのレンダラーもメモリを食わないように工夫はしています。
それでもネイティブに64bit処理ができるなら、制作側では32bitの量的、精度的な壁のことを考える必要も少なくなり、開発側も楽になるのではないでしょうか。
レンダラーとプラットホームとなるOS、プロセッサの64bit化は切望しています。