QT for Windows もデュアルライセンスに, CELL、発表
QT for Windows もデュアルライセンスに
KDE、Opera でも使われているクロスプラットフォームな GUI ツールキット、QT はこれまで、Linux 版と Mac OS X 版が GPL と商用のデュアルライセンスで、なぜか Windows 版だけ商用版しかなかったのですが、次期 QT であるところの QT4 からは Windows 版もデュアルライセンスとなることが決まったようです。登場予定は今年の第2四半期とか。
これまでフリーのクロスプラットホームアプリを作るにあたっては wxWidgets1 などを使っていたのですけれども、よりメジャーな QT が使えるようになるのはうれしい限りです。
CELL、発表
も、萌え〜。ただいまいそいそと情報収集中…。
コメント
- SAK (Tue, 08 Feb 2005 18:54:37)
-
CELLは「スーパーコンピュータ・オン・チップ」とか言われているようだが、
スパコンTop500リスト最下位のマシンと比べても1/3の処理能力しかないじゃん。
どこがスパコン??? またクソニーのハッタリかよwwwww
ってのが今のところ一番的確な煽りかね?
- Digitune (Tue, 08 Feb 2005 18:57:57)
-
「選手兼監督一人の野球チーム」というのも捨てがたいが、これは煽りではないな。
「すぱこんおんちっぷ」がハッタリなのは始めからわかってたことでしょー。つーか理論値で議論してる時点でダメダメじゃん(笑。
- shudo (Tue, 08 Feb 2005 20:13:56)
-
倍精度浮動小数点演算が前提のスパコンと、CELLの単精度演算性能 (256 GFlops @ 4 GHz) を比較すること自体がおかしかったりします。
今回の CELL プロセッサが倍精度演算をサポートしてるか否かは、PC Watch記事に貼ってあるスライドを読んでもわかりませんでした。
サポートしているとしたら、128 GFlops ?
スパコンオンチップ、っていう表現は、僕にはあんまり違和感ないです。
例えば、3.8 GHz Pentium 4 ですら理論ピーク性能 7.6 GFlops (倍精度)、15.2 GFlops (単精度) だから、128, 256 GFlops はデュアルプロセッサ x 8台の小さな PCクラスタのピーク性能にあたります。
一応、スパコンの端くれと言っても違和感ないです。
- かぴのすけ (Tue, 08 Feb 2005 20:49:48)
-
今回のセル記事でちと気になったのは、「仮想化技術で従来OSも動作可能に」とかいうところ。よーするにトラメタやVMなことをやるのかと。リコンフィギュラブルなプロセッサをうまく使えば相当高速なのが作れるのかも。
- うさうさ (Tue, 08 Feb 2005 22:35:29)
-
みんな次元が違いすぎ。
おいら486SXで十分だよ・・・
そんなCPU使いこなしてコード書く自信ない。
- Digitune (Wed, 09 Feb 2005 14:00:58)
-
毎度的確なコメントありがとうございます>shudoさん。
理論値で比較しても Pentium4 とはそれだけの差があるのですね。ただ CELL の場合あの特殊な SPE をどれだけ効率的に使うか、という点で大きく実効性能に差が出てきそうですから、意外に PC クラスタよりも使いにくかったりするのかもしれません (その代わりに「当分 CELL でしか出来ない計算」なんてものが生まれたりするのかも。そんなことになったら SCE 的には願ったりかなったりだろうなぁ)。
仮想化技術といっても、transmeta のような話ではないんじゃない?>かぴどん。
どちらかというと Intel の Vanderpool とか IBM の LPAR に近いもの、と言われているようだ。それに「従来 OS」というのは別に x86 向けのものじゃなくて、単純に Linux/PowerPC のような気もするし。
俺は SPE をゴリゴリドライブする専用の OS と、一般的な Linux 等が同じチップ上で同居できる、という話なんじゃないかと想像してる。
さすがに 486SX は辛いんでないかい?>うさどん。
我が家の Linux router は AMD の 5x86-133MHz で、これも 486SX と比較すると相当高速なはずだけど、最近のごく当たり前の処理をさせるだけでも正直我慢できないくらい時間がかかります。想像以上に遅いですよ>昔の 486。
- KenG (Wed, 09 Feb 2005 15:48:21)
-
先生! CELLがMac miniに載るのはいつですか!?
っつーか、これでいいじゃん>ジョブやん
- かぴのすけ (Wed, 09 Feb 2005 19:51:49)
-
> 仮想化技術といっても、transmeta のような話ではないんじゃない?
うむ。斜め読みしすぎてた。
仮想化するのはマルチコアアーキテクチャの方だな。
Cell PCが出るとしたら、OS周りはたぶんリナクス(PPC)+プログラミングフレームワーク(SPE)となることだろー。
- ねおん (Thu, 10 Feb 2005 03:06:30)
-
みなのしゅう、ワシはしろーとなので、おしえてけろ〜
マルチコアのCPUを使うまわりのユニットは、どーいう風に使われるのかの?
グラフィックスとかのデバイスの制御じゃな。
- Digitune (Thu, 10 Feb 2005 09:16:40)
-
Mac に載せてもクロックほどは速くないかもしれません>KenG さん。
というのも、下記記事にもあるように CELL の高クロックは「シンプルさ」とのトレードオフの結果で、例えば最近の CPU では当たり前になっている out-of-order 実行などの実行効率を高めるための機能が存在しないようです。このことにより、CELL 向けに書かれたのではない、旧来の PowerPC 用のコードでは良い性能が出ない可能性があるといえます。ゲーム機の場合アーキテクチャが一つなので、全てのバイナリコードがそのアーキテクチャに対して最大限に最適化出来ます。つまりわざわざ out-of-order 実行する局面がないはずである (in-order でもパイプラインストールしないよう最適に命令配置されてるはず)…という仮定が置けることから、こういった割り切った設計になっているものと思われます。
http://pc.watch.impress.co.jp/docs/2005/0209/kaigai154.htm
今のところみんなの予想としては、計 76.8Gbytes/s の帯域を持つ FlexIO の先に nVIDIA の石がぶら下がる、ということのようですね>ねおんさん。
つなぐとすればそこしかないのでこれは順当な予想でしょう。PS2 のアーキテクチャから考えると、メインメモリやら LocalStore やらにセットアップされたコマンド&データを DMAC (データ転送を行うための専用のユニット) がそれぞれのコア・周辺機器へガンガン送りあうような形になるのだと思います。こんな感じでたぶん合ってるよね?>SAK
- SAK (Thu, 10 Feb 2005 13:48:57)
-
答えなんか知らんわい。何故オレに聞く?
まぁ、SPEバケツリレーに特化した設計なのは間違いないと思うが。
- うさうさ (Thu, 10 Feb 2005 23:18:08)
-
>さすがに 486SX は辛いんでないかい?>うさどん。
クソ重いOSなんか積んでるからじゃ、DOS+エクステンダで十分。
つーか、486のインストラクションですらフルに使い切ってないのに
SSEだのMMXだの、わけわからんわい。
それを覆い隠すOSのAPIもわけわからんわい。
と、引退したプログラマがゆってみる。
- Digitune (Fri, 11 Feb 2005 12:50:52)
-
> クソ重いOSなんか積んでるからじゃ、DOS+エクステンダで十分。
確かに MS-DOS よりは重いけど(^^;、Linux+コンソールという環境は比較的軽い方だと思うよ。それでも SSH のハンドシェイクとかに何秒もかかる。本質的に暗号系の処理は重いからなぁ。gcc でコンパイル、とかもプログラムが大きくなってくると無理目な部類 (kernel make は一日がかり…)。
> つーか、486のインストラクションですらフルに使い切ってないのに
といううさどんはゲームプログラマー向きかもしれんね。ゲームコンソールのプログラムってのはそれはもーハードの極限まで使い切らんとめちゃくちゃがんばってるので…。
基本的に OS 以上、というか普段は何らかの TOOLKIT 以上しか使わないアプリケーションプログラマーから見ればスゲー世界ですよ。感謝感謝。
- うさ (Mon, 14 Feb 2005 22:58:20)
-
ゲームプログラマねえ。10年前なら喜んで身の程知らずに
「なる!なる!」いってたかもしれんなあ。
やっぱ自分の限界を知るって大事だよって誰かゆってた。
というか、ゲーム業界はやっぱりまだ35歳定年説が有力?
- Digitune (Tue, 15 Feb 2005 11:35:01)
-
そんなことないと思うけど>35歳定年説
ただ、何らかの技術を持ってないと辛いというのはあるかも。デジドカなら若い方がいいに決まってるから。
- かぴえもん (Wed, 16 Feb 2005 20:41:32)
-
Cellアーキそのままでレンダラ作るよりは、専用レンダラ並べた方が効率いーみたいだね。やはり。そこまでプログラマブルである必要はないと。バスの仕様だけCellにあわせて、SPEとかと同レベルでプログラマブルレンダラを並べるアーキだと見た。各レンダラはキャッシュを持ち、メイン空間上に配置されたVRAMにアクセスする。nVidiaのレンダリングプロセッサとCellアーキを組み合わせた感じになるんじゃなかろーか。
- Digitune (Thu, 17 Feb 2005 12:43:57)
-
うむ。なかなか合理的な設計だと思うよ>かぴえもん。
GPU 側にも専用レンダラ (というかシェーダというかプロセッサというか) があって、メモリはキャッシュ・一時バッファ用に小さい (が早い) ものが混載 or 外付けされてて、基本的には UMA 構成、ということだよね。nVIDIA の TurboCache 技術のこともあって、各所の予想でもおおむねそのような感じな模様。
-
それなりに使いやすくはあるのですが、バイナリサイズが肥大化するのが玉に瑕で。その他の選択肢としては当然 Java などですね。 ↩︎