ソフトウェアもムーアの法則に従え 141
ストーリー by mhatta
従えと言われてもねえ 部門より
従えと言われてもねえ 部門より
Anonymous Coward 曰く、
18ヵ月から24ヵ月年ごとに2倍のフレーズでお馴染みのムーアの法則であるが、CNET Japanに ソフトウェアもムーアの法則に従えという記事が掲載されている。 マルチコア化によってムーアの法則を続けているIntel側が、 ソフトウェア業界に対して演算能力を使い切るための並列処理への取り組みを 増やすよう求めているような内容であるが、 マルチコア化の速度に、ソフトウェア開発者の能力と過去のサポートも必要な ソフトウェア業界が対応できるような気はしない。ちょっと無茶言うなという 感じだろうか。
従いましょう (スコア:5, おもしろおかしい)
Re:従いましょう (スコア:3, すばらしい洞察)
Re:従いましょう (スコア:2, おもしろおかしい)
#転職して半年で激変した友人がいるのでAC
Re:従いましょう (スコア:3, おもしろおかしい)
皆喜んで書いてくれるのでは?
現状は、残業時間がムーアの法則に... orz
Re:従いましょう (スコア:1, すばらしい洞察)
それは給料(価格)は同じで2倍働くと。俺には無理だなあ。
Re:従いましょう (スコア:1)
#しかし/.er諸氏は実労働時間を2倍にしようとしても1日30時間労働という矛盾 [wikipedia.org]を生んでしまう人が多そうだ。
#俺は実労働時間半分で給料0.7倍なら喜んで受け入れちゃうなぁ。
言い分としては (スコア:4, すばらしい洞察)
ってとこでしょうか。
#サボってたのは俺を含む一部の人たちですが。
妖精哲学の三信
「だらしねぇ」という戒めの心、「歪みねぇ」という賛美の心、「仕方ない」という許容の心
言い分の解釈 (スコア:3, すばらしい洞察)
ユーザーは古い(安い)プロセッサで満足するので、Core 2が売れない。
○「マルチコアのプロセッサだと性能がぐんと上がるプログラムを書いて下さいよ」
新型プロセッサに強気の値付けができるので、インテルは嬉しい。
Re:言い分としては (スコア:1)
2つ付けただけでそれは昔からあるDualCPUとなんら変わりませんし。
3Dゲームをやってるけど、GPUよりCPU性能が足りない部分が
結構あるんで、1CPUで演算能力上げてください。
Re:言い分としては (スコア:1)
#ってはなしでしょ?
参考資料 (スコア:3, 参考になる)
動作周波数をひたすら向上する→物理的な限界に突き当たる。
平均IPCをひたすら向上する→手は尽くしているが、これからの劇的な向上は困難。
といったところで、各社とも正攻法は手詰まりの感がある、といったあたりでしょうか。
命令の並列性をハードウェアにて抽出するSuperScalar型アーキテクチャでは、IPC向上にも
限度がある、といわれています。
並列性抽出をコンパイラに移したVLIW型アーキテクチャは高IPCを実現できますが、その方向
であればIntelもItaniumでやってはいますね。
Re:参考資料 (スコア:1)
バスが64Bitの60/66MHz動作になって一般に普及していた486の32bit/33MHzバスに比べ
足まわりは速くなったが、大きな特徴である2命令同時実行を活かすには、
それなりの最適化コンパイラが必要になった。
両方のパイプラインを動かすため、同時実行できる単純命令をペアにして命令デコーダに
投入できるようコーディングする必要があったわけで。今度はマルチコアで性能を引き出す
最適化コンパイラが要求されているだけなのでは。
ベクトル型スーパーコンピュータだと、ハードウェアの特徴を活かすために専用の
ベクトル化コンパイラなんてものが付属してました。今回もスレッド分割を自動でやってくれる
賢いコンパイラが出てきたらそれでOKのような気がしないでもないです。
Re:参考資料 (スコア:1)
スレッド化する場合、処理の相関関係、データの相関関係を意識する必要があるので
コンパイラというので有れば不可能です
プログラムソースだけでは情報が足りなすぎます。
自動化と言うのであれば、仕様からプログラム自体を自動生成する必要が出てくるでしょう
法則? (スコア:2, すばらしい洞察)
#ムーア本人の責任じゃないとは思うけれど・・・・・・
Deepsea the Evoker St:10 Dx:13 Co:14 In:18 Wi:9 Ch:9 Neutral
Dlvl:1 $:0 HP:12(12) Pw:8(8) AC:9 Xp:1
Re:法則? (スコア:2, 参考になる)
古来より法則 (Law)なんて“経験則あるいは目安・目標に過ぎないもの”なんですよ。グレシャムの法則、ケプラーの法則、パスカルの法則、メンデルの法則しかり。
それらにはきちんとした理論・理屈があるじゃないか、だって?
それは後年その法則を裏付ける理論が発見されただけで、その裏付けがなされる前であっても法則であったのはたしかです。
一つ取ってみて、ケプラーの法則だと、「過去の天体運行のデータからこう言える」ってだけで、何でそうなるかはニュートンを待たねばならなかったんです。「過去の天体運行のデータからこう言える」はいいけど、「過去の半導体技術のデータからこう言える」はダメってことはないでしょ。
しかしこう言ったところで「抵抗感がある」という個人の主観はいかんともしがたいんだよなぁ。
Re:法則? (スコア:1)
現象から導かれた理論であるべき法則に現象の方が合わせるのはなんとも・・・
#浮いてないで落ちろ
#バターを塗った面を下にしろ
#言い出しっぺは負けろ
Re:法則? (スコア:1)
証明可能なものは、定理(theorem)と呼ぶ方がしっくりきますけど。
ソフトウェアって一括りにするのは間違いで (スコア:2, 興味深い)
と、なると、マルチコアが有用な利用法を考えて、かつユーザに受け入れられる必要があります。ただ、デスクトップ用途のほとんどは「人間とのインタラクション」だと考えると、人間のI/Oは並列化しづらい性質のものなので(少なくとも言語的思考の流れや注視点は2つ以上にすることは困難)、CPUにはI/Oに関係しない仕事をやらせるか、「壁紙を動画にする」などの無駄な仕事をやらせるかのどちらかになるのだと思います。
そもそも、今のPCに求められてる機能って
- Internet Explorer(+flash再生機能)と、
- Outlook (Express?)と、
- (optionally) Word/Excel/Powerpoint
ぐらいなんじゃないでしょうか(サンプル: 親とか非アレゲなきょうだいとか)。おもしろいもの(コンテンツ)がどんどんネットの向う側に行ってしまう昨今、CPUの高速化への要求は3年前ぐらいに止まってしまったのかもしれません。
# ぶっちゃけ、「なぜか」OSが重くなる分を補償するためなんじゃねーの?
Re:ソフトウェアって一括りにするのは間違いで (スコア:2, 興味深い)
それこそが古く凝り固まった考え方なのではないか?と思うのです。
人間が同時に操作できない点に縛られて後ろ向きになったり、
別々の複数のソフトウェアやバックグラウンドのI/Oを走らせる用途しかアイデアがないとか、
そういう古典的な並列コアの使い方を何とかしろよと問われているのだと思うのですが。
ほとんど効果が見えないSIMD命令の類も同じ。本当に動画のエンコードぐらいしか活用方法がないの?
マルチメディア処理用命令と業界全体が思い込んでるだけじゃないの?
=-=-= The Inelegance(無粋な人) =-=-=
Re:ソフトウェアって一括りにするのは間違いで (スコア:5, 興味深い)
10人の妊婦が協力しても子供は1ヶ月で産まれてこない。
Brooksが「人月の神話」でソフトウェアの開発期間についてそんなことを書いていたと記憶しています。
本質的に並列化が向いている処理と向いていない処理がある、という点でソフトウェアの並列化にも同じ事が言えます。
並列化が向いている処理というのは「他の処理と独立して行える比較的時間のかかる処理」です。
「他の処理と独立して行えない処理」を並列化するなんてのは論理的に不可能だし、
「他の処理と独立して行えるが時間のかからない処理」は並列化しても同期処理に時間がかかって
作業効率はほとんど上がらない(場合によってはかえって遅くなる)、しかも並列化プログラムは
バグ取りに非常な困難が伴うので割に合わない、というのは並列プログラムを書いたことがある人に
とっては常識ですね。
で、「他の処理と独立して行える比較的時間のかかる処理」ってのはデスクトップ用途の場合だと既に挙がっているようなものしかないわけで。
Re:ソフトウェアって一括りにするのは間違いで (スコア:1)
いや、まだ「無駄にCPUを食っていいから」という「投機的実行」パターンが残っていると思うぞ。
あとは、「従来できなかったような総当たり戦」というものも…
fjの教祖様
Re:ソフトウェアって一括りにするのは間違いで (スコア:1)
「今のデスクトップコンピューティングじゃない何かを考えろよ」
と言ってるのに等しい気がしますね。
# もちろんみんな考えてるさ。答はまだないが。
Re:ソフトウェアって一括りにするのは間違いで (スコア:1)
バックグラウンドではゲームという物が常に動いているわけです
マルチプロセス/スレッドで組んでくれよってだけの話なので
旧CPUを蹴落とす必要はありません
シングルCPUだとしてもその辺はOSが調整してくれます
ただし、プロセス/スレッド間通信の分処理は遅くなるでしょうが...
Re:ソフトウェアって一括りにするのは間違いで (スコア:1)
単一CPUでも動作しますよ
ただし、スレッドを使う/使わないはプログラム固有の事なのでさすがにCPUが単一だから
スレッドを別けずに自動的に動作するみたいな事はOSはしてくれません
(そんなこと勝手にしたらバグが出る可能性もあるし(笑))
別けておいてもらえれば、後は選択できるので問題はないでしょう
>マルチコアの処理能力を存分に発揮なんてしなくても現状で十分
と言うかデスクトップの場合、ゲーム等後ろで何か処理し続けるって物で無いと
現状で十分って状況になり始めてるかと
画像/動画処理等処理が重い物をマルチ化して高速化するって話以上は
デスクトップ環境では不要でしょう
後は人に余ってるCPUパワー貸し出すとか?
Re:ソフトウェアって一括りにするのは間違いで (スコア:1)
見落としてたけど、これ、とても大事な指摘だと思う。
ある処理をスレッドに分割するとして、「いくつ」に分割すれば良いのでしょうか。
スレッドが少なすぎると活かされないコアが出ます。スレッドが多すぎるとタスクスイッチングのコストがもったいなくなります。
現状では、1コア~2コア、ハイパースレッディングのP4で4コアぐらいですね。現状ではこの程度なので、4スレッドに分割! と決め打っても問題なさそうですが、4コアとか8コアとか、さらにハイパースレッディングを復活!なんて出てくれば、この辺の問題を無視できなくなりそうです。
ちょっと解決法を考えてみます。
一つの方法としては、CPUからコア数を直接聞きに行く方法が思いつきます。しかし、重い処理をするときは、処理内容をN個のスレッドに分割する処理を入れるだなんて、プログラマはたいへんだと思います。
また、「スレッド数 = コア数」と決め打って良いかどうかという問題もあります。IO処理が伴うならば、コア数より多めが良いだろうし、バックで(重めの)別プロセスが走ってる場合は、コア数より少なめが良いだろうし。
どうも OS が「仲介役」をしてくれないと、この問題の解決は難しそうです。
おっ、この「仲介役」の仕組みで特許を取れば、MSから金をがっぽりとれそうな予感!!
Re:ソフトウェアって一括りにするのは間違いで (スコア:1)
1つのコードで対応するのは困難だし、コードを分けるといろいろな問題が噴出する訳ですね。
しかし、複数の環境が同時に絡むネトゲはともかく、
他のことはそう考えなくていい単体のアプリケーションなら、
それはそれで並列化が進んでもいい様な気がします。
低級な部分(OSとか)のより進んだ対応の方が求められているんでしょうか。
そうなるとプログラマやSEの時間的余裕も必要になるので、マネージャーや営業の意識改革も必要か。
購買求心力にさほど影響しない部分だから難しそうだな…。
でもそれで本当はどうでもいい見た目の為に無駄にマルチコアのリソース食うなんて、アホくさい哀しい未来だな。
技術的に夢のある未来が見たい…。
=-=-= The Inelegance(無粋な人) =-=-=
Re:ソフトウェアって一括りにするのは間違いで (スコア:1)
>他のことはそう考えなくていい単体のアプリケーションなら、
>それはそれで並列化が進んでもいい様な気がします。
逆ですよー、複数の環境/処理が同時に進む物はマルチ化の恩恵を受けやすいんです
人の入力とは関係なしに動作可能ですから
すでにマルチスレッド対応なゲームは出ています
MMOならSWGがマルチ対応です(日本語版ぽしゃったけど)他にも有るんじゃないかな?
逆に単一アプリはどうしても入力待ち/処理待ちと言う物が存在するので
処理自体を高速化するためにマルチにする事は可能でも
入力待ちを高速化することはできません
また処理中のデータをロックする必要が出た場合、
処理が終わる前に処理中断以外の入力を受け付ける事ができません
単一アプリで効率的にマルチ処理を実施するには入力装置の革命も必要かもしれませんね
Re:ソフトウェアって一括りにするのは間違いで (スコア:1)
そういうのを要求される環境もあるのかも知れないが、跡2者はたいていはスレッドが使えない時に仕方なくそうするものな気がするんだがなぁ...。
Re:ソフトウェアって一括りにするのは間違いで (スコア:1)
あぁ、「ン」が消えてるんですよ。「ビーフン・カレー」ね。
Re:ソフトウェアって一括りにするのは間違いで (スコア:1)
本人の好みに合わせ勝手にWebページを収集してリストアップしまくってくれるとか
Outlookだと..
メールが来たら定型処理は例文を作っておいてくれるとか
まぁエディタ関連はちょっと無理っぽいですが
入力されたデータに合わせて例文を作成し続けるとか?
個人向け端末だと、裏で秘書プログラムが動くのが一番役に立ちそうですね
まぁただ同じ処理でもマルチスレッド/タスク化出来る物は有るでしょうから
順次やってってくれよって事なのでしょうが...
マルチスレッド/プロセスなプログラムって作る際に処理だけではなく
データの流れとかも意識しなきゃいけなくなるので
単にいきなり言われても作れる人が少ないって話しのような気がします
Re:ソフトウェアって一括りにするのは間違いで (スコア:1)
音出してる時も、ビデオ見てるときも、そんなにCPUいらないなぁ。
所詮等倍速だし。
iTunesに入れる時のエンコ時はCPU食うけど、それよりドライブ速度が足枷な気がする。
で、iTunes使ってて足りないと思うのはメモリ。
# 30Gくらい音データがあると、ライブラリだけで300Mbyteくらい持っていってるような
Re:性能上げるだけじゃなくて (スコア:1)
単に「消費電力とクロックの関係」を一般論で語るなら、「消費電力はクロックに比例」ですね。
もっとも「クロックを落とすと電源電圧を下げられる」し「消費電力は電源電圧の二乗に比例」しますので、
クロックの比例以上に発熱量を減らすことができる場合が多いです。
従わないからIntelが儲かる (スコア:2, 興味深い)
↓
早いマシンが必要になる
↓
ハード業界が儲かる
Re:従わないからIntelが儲かる (スコア:1)
古典的な勘違い (スコア:2, おもしろおかしい)
顧客 「ふんふん、それで?」
イ*テル「普通の会社は1人しか派遣できないので、4個の井戸を掘るのに4日です。」
顧客 「ふんふん、それで?」
イ*テル「うちでは4人も派遣しますので、4個の井戸を掘るのは1日ですみます。」
顧客 「あー、でも、うちは1個の井戸だけ掘れれば、それで十分なのよね。」
イ*テル「…。」
顧客 「ていうか4人で1個の井戸を掘るのに6時間ですむかって話だよ。」
clausemitz
Re:古典的な勘違い (スコア:2, おもしろおかしい)
そうすればうちは4人派遣します。それが今回の提言の趣旨です」
Re:古典的な勘違い (スコア:1)
なので、4人使って期間が3/4くらいなら……
ムーアの法則といえば (スコア:1, おもしろおかしい)
新たなバズワードの前振りでは? (スコア:1)
最近のIT業界をみてると,「関数型プログラミング言語」を新しい流行にしようというながれが目に付きます(例 [atmarkit.co.jp])。処理を並列化しやすいというその特性が,とくにH/Wよりのメーカーにとって魅力的だからです。
いままで「構造化」「オブジェクト指向」と進んできたプログラミングパラダイスが,次は「関数型プログラミング」へと進みますよ,というメッセージの一環なのでは?
Re:新たなバズワードの前振りでは? (スコア:1)
Re:無茶言うなというか (スコア:2, すばらしい洞察)
そういうことをちゃんとやれと言ってるだけですよ。
CPU が一つしかないことを前提にしたようなプログラムを書かずに、CPU がいくつだろうとパフォーマンスを発揮できるような構造にすべきだと。
フレームワークやコンパイラがいくら頑張っても、逐次処理しか考えてないような古い設計のアプリでは複数の CPU を活用するのは難しいでしょう。
Re:24ヵ月年ごとに2倍了解 (スコア:2, おもしろおかしい)
* AC1>コードの長さを倍にします。性能は据え置きで。
* AC2>では膨らまし粉ということで、ここに連絡事項書く事にしましょう。
* AC3>その考えはなかったな。
* AC4>でもさ、24ヶ月2倍って無茶言ってない?この開発マシン10年近く前のPCなんだけど。
* AC2>あははは。それじゃーソース1/32にすればいいんじゃないの?
* AC3>なにその1/32スケール超合金プログラム。
* AC2>スゲー強そう。でも原作だと最終回で壊れちゃうんだよね。お約束だよね。
* AC4>腕とか一部だけ動けば良い仕様なら楽だな。
* AC1>おまえら・・・仕事しろ。
*/
Re:24ヵ月年ごとに2倍了解 (スコア:1)
Re:ムーアの法則って... (スコア:2, すばらしい洞察)
SMTだの(マルチコアな)SMPだのってのは「一つのタスクでは命令間の依存関係の関係でパイプラインを埋められないから依存関係がないことが明白である別のタスクから命令を持って来てパイプラインを埋める」という方策なわけで、命令セットやレジスタセットの大幅な変更なし、かつみかけのコア数を増やさずにパイプラインを埋めて性能を引き出すことはできないんじゃないか? だからIA32だのEMT64だのやってる間はそれは無理な話。
# ところで、マルチコアってSMT的に(Linuxでcloneしたときみたいにプロセスなんだけどいろいろ共有みたいな)運用ってできるんだっけ?
Re:ムーアの法則って... (スコア:2, 参考になる)
それ(正しくはIPC*クロックの向上ですけど)が行き詰ったから(x86に限らず)マルチコアに
向かってるわけですよね?
出来ないからあきらめたことをやれって言われても……って感じじゃないでしょうか。
Re:ムーアの法則って... (スコア:1)
ソフトが対応しきれてないのに、
「コア数(お値段も)増やすから、ソフトもそれに追いつけ」
なんて勝手もいいとこでしょ
将来的に「インテルのCPUは値段の割に性能が出ない」と言われたとき、
インテルは「それを活かさないソフトが悪い」って
責任転嫁するのがみえみえだから。
要するに余計なことをするなです。
Re:ムーアの法則って... (スコア:2, おもしろおかしい)
> どうやって?
やっぱ「スーパースカラ」じゃないですかね。
パイプラインが32本ぐらいあって、「最大32命令同時実行可能」とかなんとか。
で、「そんなに同時実行できるようなケースなんて実際にはありえねーよ」ってツッコミ入れたら、
「パイプラインを全て使い切るように、ソフトウェアもムーアの法則に従え」と返されるんです。
Re:ムーアの法則って... (スコア:1)
Re:もしそうなるなら、 (スコア:1)
なるとして,まあもっともゆるい24カ月で2倍とすると6年で8倍.
582MBの8倍だと4.5GBぐらい.
お,わりといいペースか?
Re:みんなで幸せになるには (スコア:2, 興味深い)
いや,だから元記事自体,
・ハードウェアの改良によるIPC*クロックの引き上げが限界に来たからマルチコアに向かう
・だけれどもマルチコア化により性能を向上させるためにはソフトウェア側の並列化推進が必要
としか言っていないわけですよね?
誰も「実行性能が頭打ちなのはソフトウェアが悪いから何とかしろ」なんて言っていないわけで.
キャッシュの中でぐるぐる回るスレッドをいっぱい作れということでは.
TLPが上がれば(よほど各スレッドがメモリを読みに行かない限り)レイテンシの効果は隠蔽されて
効かなくなってくるはずでしょうし.