ムーアの法則はまだまだ現役? 26
さすがにそろそろ難しいような気も 部門より
capra 曰く、
本家/.記事「45 Years Later, Does Moore's Law Still Hold True?」より。
新しい年が明け、所謂「ムーアの法則」が発表されてから45年が経った。コンピュータ業界では有名なこの法則はことあるごとに引用されるが、今日のこの業界を見渡してもまだ法則が成り立っていると言えるだろうか?
ムーアの法則の初出は1965年、「Electronics Magazine」に投稿された論文の一節であった。
部品あたりのコストが最小になるような複雑さは、毎年およそ2倍の割合で増大してきた。短期的には、この増加率が上昇しないまでも、現状を維持することは確実である。より長期的には、増加率はやや不確実であるとはいえ、少なくとも今後10年間ほぼ一定の率を保てないと信ずべき理由は無い。すなわち、1975年までには、最小コストで得られる集積回路の部品数は65,000に達するであろう。私は、それほどにも大規模な回路が1個のウェハー上に構築できるようになると信じている。
当初は俗に言われているように「半導体の集積密度は18ヶ月ごとに倍になる」法則があると明言した訳ではなく、経験則から短期的な予想を出したに過ぎなかった。しかもムーア氏は1975年に「今後2年毎に2倍のペースにしかならない」との予測を立てていたそうだが、いつからか「18ヶ月」という期間の方が一人歩きしてしまったとのこと。
この法則が現在も成り立っているかは、意見が分かれるところだ。Intelの上級フェローのMark Bohr(マーク・ボーア)氏は「(ムーアの法則は)重要であり、今もわが社はこの法則を追っている」と述べたが、一方でMicroprocessor Reportの著名なチップアナリストは「半導体チップ業界はもう何年もの間この法則を追っていない」と述べているそうだ。
ムーアの法則が努力指標になる (スコア:3, 興味深い)
なんて説明を聞いたことがあります、もう20年くらい前ですが。つまり、ムーアの法則の存在自体がムーアの法則を成立させているわけですな。
の
Re:ムーアの法則が努力指標になる (スコア:2, 興味深い)
確かに、ムーアの法則じゃなくてムーアのノルマと言った方がしっくり来ます。
# 歴史上の著名な暴君に酷使された人数よりも、この法則に酷使される人数の方がヘタしたら多いんじゃ…w
Re:ムーアの法則が努力指標になる (スコア:2, おもしろおかしい)
○ムーアのデスマ
Re:ムーアの法則が努力指標になる (スコア:2, おもしろおかしい)
ムーアのデスマ
「プロジェクトの仕様は18ヶ月ごとに倍になる」
Re:ムーアの法則が努力指標になる (スコア:1)
「プロジェクトの期間は18ヶ月毎に倍になる」
すなわち18ヶ月以上かかるプロジェクトは必ずデスマーチとなる.
# 経験則として, あながち間違っていない気がする
Re:ムーアの法則が努力指標になる (スコア:2, すばらしい洞察)
40年以上にわたってほぼ達成できているノルマだということを考えると、逆にそのノルマが簡単に達成可能なモノだったとかね。
Re:ムーアの法則が努力指標になる (スコア:1, おもしろおかしい)
18ヶ月ではなく12ヶ月で達成できた期間があったとしても
その次の目標が24ヶ月かかるかもしれないので発表しないというのもあるでしょうね。
AMDが発表しないからまだいける、とか。
今回は余裕あるから1ヶ月のバカンスだーっと結局18ヶ月になるというのもありそう。
もちろん間に合いそうにないときはデスマ。
そして18ヶ月に収束する。
Re:ムーアの法則が努力指標になる (スコア:1)
>その次の目標が24ヶ月かかるかもしれないので発表しないというのもあるでしょうね。
>もちろん間に合いそうにないときはデスマ。
余裕でクリアと、デスマでクリアの比率が面白そうですね。
スラドでは話題になるのは、後者が多いみたいなので、
比率としても後者なのかな?とも思う。
スラドに出入りするお方のレベルが低いからデスマなのか?
と思うこともある。だけど、某社でのプロジェクト進捗一覧
みたいなのを見ると、遅延/納期逼迫とかでメンバー工数が
異常(世間ではね、この業界ではよくあること)な値ってのが
結構あった。
エンジニアは死なない程度に働かせるのがよいとか、無茶を
言うPMもいたなぁ...
Re: (スコア:0)
プロジェクトが遅延していないのに残業時間が増加していないのは社員が怠けているからだ
なんて言います。
残業予算の枠内でしか残業を記録してないから、残業時間が増えないんだけどなー。
Re:ムーアの法則が努力指標になる (スコア:1)
>残業予算の枠内でしか残業を記録してないから、残業時間が増えないんだけどなー。
時間単位精算なら、ちゃんと記録しないと契約不履行になるのと違うかな?
やった時間をちゃんとつけるというのも契約の一部なのですけどね。
ちゃんと付けていないから、計測不能に陥るといった弊害もあるわけで、
弊害をよしとしてやっているなら、
>プロジェクトが遅延していないのに残業時間が増加していないのは社員が怠けているからだ
>なんて言います。
数字しか見えない人に、そういう数字を見せちゃっているわけで、何も文句を言うことではないでしょ?
Re: (スコア:0)
そりゃサービス残業は労使双方の違法行為だけどさー。
> 数字しか見えない人に、そういう数字を見せちゃっているわけで、何も文句を言うことではないでしょ?
実際の数字そのまま上げると、生活残業はケシカランとか、社員が怠けている部署には残業代を出さんぞとか、そういう話になる。
色々な経緯の末に現状があるわけで、ねぇ。
有能というかババを引きたくない管理職の人は、従業員の顔を見て判断して、プロジェクトから距離を置くなどの保身に走るよ。
Re:ムーアの法則が努力指標になる (スコア:1)
>実際の数字そのまま上げると、生活残業はケシカランとか、社員が怠けている部署には残業代を出さんぞとか、そういう話になる。
生活残業しているの?
そういった相身互いをやっているなら、相手に間違った数値を示した結果は甘受すべきで、文句は言ってもはじまらない。
>従業員の顔を見て判断して、プロジェクトから距離を置くなどの保身に走るよ。
うん、だから「従業員が誤った数字を出している」という言い逃れを許してしまった結果を招いてもいるわけなんですよね。
お互い、それでよくてやっているわけで、それで何で文句があがるのか、よくわからない。
Re: (スコア:0)
していない。
だが、慢性的というか恒常的というか、ほぼ全員が何年にも渡って残業代によって年収が倍増していると、それを快く思わない人が上層部に出てくるんですよ。
> そういった相身互いをやっているなら、相手に間違った数値を示した結果は甘受すべきで、文句は言ってもはじまらない。
正しい稼働時間を伝えたくても、残業代の予算の範囲内でしか、残業時間は伝えられませんからね。
残業代の予算を越えた残業の記録なんか残そうものなら、間違って記録されているようなので訂正おねがいします、とか言われるだけだし。
Re:ムーアの法則が努力指標になる (スコア:1)
>慢性的というか恒常的というか、ほぼ全員が何年にも渡って残業代によって年収が倍増していると、それを快く思わない人が上層部に出てくるんですよ。
じゃ、ちゃんと仕事して仕事量にみあったモノを貰っていると堂々と言えばいいだけでは?
>正しい稼働時間を伝えたくても、残業代の予算の範囲内でしか、残業時間は伝えられませんからね。
ということは、正しい稼働時間を伝えてないだけでしょ?
>間違って記録されているようなので訂正おねがいします、とか言われるだけだし。
間違っていませんと回答しない理由がわからない。
間違っていないものを間違いだといえということにたいして、認めちゃうってことですよね。
つまりは、間違いをしちゃうわけですよね?
前の方にあった「サービス残業は労使双方の違法行為」ということなのでしょうね。
悪事に加担しているわけなのだから、ワリを食っても文句は言わないのが筋だろうね。
実際、予算はこれだけだが、それでは無理だという話も出したりして、折衝していたけどね。
ない袖はふれないという相手には、ない袖では踊れないという回答しかないわけなんですよ。
Re: (スコア:0)
Re:ムーアの法則が努力指標になる (スコア:1)
>いいね、空想上の理想の会社に勤めてる人は。
労使が共犯になって糞会社にしちゃっているお方程度が愚痴を言ってもはじまりませんよ。
片肺飛行 (スコア:0)
製造プロセスの縮小は続いてるけど、クロックが頭打ちゆえ、シングルスレッド性能の向上が大変難しくなってるわけで、
ムーアの法則は一応生きてるが片肺飛行って感じかなぁ。
クロックに頼らずIntel Core、Sandy Bridgeと大幅な性能向上を果たしたインテルイスラエルチームは凄いっすね。
Re:片肺飛行 (スコア:2)
空冷でも5GHzで動いたなんて話もあります。
http://www.4gamer.net/games/098/G009883/20110103001/ [4gamer.net]
おそらく電圧上げてClock上げてなんてすると、消費電力が
あがりすぎてしまうからやらないのだと思うのですが、
2コアだけど(2コア無効)Clockだけは高いモデルみたいのがあっても面白いですかね?
まあ、Turbo Boostがあるから良いのかもしれないですが
Re: (スコア:0)
Sandy Bridgeが素晴らしいのではなく、32nmプロセスが素晴らしいのです。
Mac専用プロセッサー (スコア:0)
結局このまま突き進んでも
仮想環境で使わないと活きない気がします。
それとも過度にスレッドを増やすコードを書くべきなのでしょうかね?
OSの役目として「交通整理」が必須になるんでは? (スコア:2)
まあ,うまく機能させるためには,仰るとおりスレッドを増やすコードを書かなきゃいけないわけですが,
管理はOSに丸投げすればよいので,さほど面倒なものでもないです。
(パフォーマンスを最大化しようとすると,作業キューの解析が必要ですけど,「そこそこ」でよければ結構手抜きできます)
OS(とゆーよりGDC)でマルチコアをうまく(簡単に)使うには,何よりも大量のメモリを必要とします。
そこらも現在の状況を考えるとあまり問題がないとも言えます。
時勢にあってるといえばあってるので,しばらくはこのまま突き進むのでしょう。
Re: (スコア:0)
Callは原則としてCreate Threadでよいでしょう。そうしたくないときに抑止するコードを書けばいい。
Multi Core化が現状で止まると考える理由はないので、今は過度なThread数でも、明日は適度になる可能性はある。
集積密度?集積度? (スコア:0)
ムーアの法則って、集積密度でしたっけ?集積度だったような気が。
(つまり、密度が一緒でもチップ面積が大きくなると集積度は稼げる)
Re: (スコア:0)
ムーアの法則を超える (スコア:0)
NVIDIAは「GPUのパフォーマンスを、ムーアの法則以上に伸ばすことができる」
と宣伝してますね。
http://pc.watch.impress.co.jp/docs/column/kaigai/20101001_397079.html [impress.co.jp]
http://pc.watch.impress.co.jp/img/pcw/docs/397/079/html/03.jpg.html [impress.co.jp]
まあ宣伝文句ですけど。
セキュリティ要件の基礎数値として (スコア:0)
何かのデータの暗号化を考えるとき、「2039年の真実」みたいなもんで、何年間守る必要があるかを決めて、それに見合った強度になるようにパスワード長とかを決めますが、破る側の計算能力については、ムーアの法則で伸びていくと想定を置いて算出するように思います。
これはまだ見直す必要なさそうなんですね。