アカウント名:
パスワード:
今現在で64bitを有効に使う用途っていうと, どうしても科学技術計算(さすがにDBサーバには怖い)だと思います. とすると現実的にはFORTRANが必須となるわけで, Appleが高効率のコードを吐き出すFORTRANコンパイラを提供できるかが当面のキモになりそうです. もちろんPowerPCアーキテクチャ用としてIBMが提供してくれれば無問題ですが.
MacOSは伝統的に可視化ソフトでは強いですから, 科学技術計算で使えるとなれば, その方面ではかなり使えるプラットホームになると思います.
あと, レンダリング用途でもオブジェクトの配置に大きなメモリ空間が有った方が便利かもしれないのですが, これはあまり例を知らないのでパス.
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
私はプログラマです。1040 formに私の職業としてそう書いています -- Ken Thompson
ってゆーか 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化は切望しています。
Re:ってゆーか 64bit なのですが (スコア:1)
別にAppleが提供する必要はないと思いますよ。というか、提供する能力も
ないでしょうし。
Mac用のFORTRANコンパイラはいくつかのメーカーから商用で販売されて
いますし、評判のよいものも多いようです。
私はFORTRANの人ではないのですぐには挙げられませんが、Absoft [absoft.com]のコンパイラとか。
例えば数学ライブラリを64bitに最適化するだけなら、それほど苦労しないと思います。
> MacOSは伝統的に可視化ソフトでは強いですから
む?そうですか?
最近は顕微鏡についてくるPCもWinNT系になってしまったり、ローエンドでも
Macは見なくなったなあと思っていたのですが。
kaho