Intel、次期CPU「Penryn」の詳細公開 63
ストーリー by yoosee
どこがどのくらい速くなるんだろう 部門より
どこがどのくらい速くなるんだろう 部門より
Intelが、Core 2シリーズの後継となる次期CPU「Penryn」の詳細を公開したとのこと。Coreマイクロアーキテクチャをベースにキャッシュ容量を6MBに増やし、新命令セット「SSE4」を実装する。
製造プロセスはx86 CPUとして初の45nmプロセス。SSE4命令の実装によってデジタルメディアおよび3Dグラフィックスでの処理速度の向上を図る。また 128bit長の命令を1クロックで実行可能とし、SSE2/3/4命令を従来の約2倍の速度で実行できるとのこと。コアクロック、内部PLL、L1キャッシュ、L2キャッシュをすべてOFFにするDeep Power Down や、片方のコアをOFFにしてもう片方のコアをTDP範囲内でオーバークロックさせることでシングルスレッドの実行性能を向上させるEnhanced Dynamic Accelerationも実装されている。
Intel入ってます (スコア:1)
RはRevolution・Return・Rememberの意味です
Re:Intel入ってます (スコア:1)
Prestoniaの最高峰を、という具合に
既存のマシンの延長でしかとらえられなくなって久しいです、ハイ
# その頃のメモリがまた安くなってないんですな
次はマックス16スレッド (スコア:1)
Linuxではペンギン大行進になるなぁ。
# Xeon系なら2ソケットで32コア?
## アプリ実行コアは卵の絵とかに変更になるかしらん。
Penrynでも4コアをどう生かすか、難しいかも。
むしろゲームとかのハードロードより、それぞれ勝手にリソースを使うオフィス系ソフトでの快適さや、即応性の向上がいいところかもしれません。
# 最近事務作業ばかりなコーダーなのでID
M-FalconSky (暑いか寒い)
Re:次はマックス16スレッド (スコア:3, おもしろおかしい)
> の快適さや、即応性の向上がいいところかもしれません。
-Windowsの基本部分で1コア
-Aeroの描画で1コア
-Google Desktopのインデックス作成で1コア
-サウンドで1コア
-BitTorrentで1コア
-冴子先生で1コア
と富豪的に使えばますます快適になるでしょう。
Re:次はマックス16スレッド (スコア:1)
ところでどうでもいい話ですが、LinuxのBoot時にペンギンが、Coreの数だけ並ぶとカッコイイと思ったのですが・・・。自分だけでしょうか。
#壮大なストーリ。空転するアイディア。
Re:次はマックス16スレッド (スコア:0)
CPUはAeroの描画をしないでしょ。Intelはやらせたいのかもしれないけど
Re:次はマックス16スレッド (スコア:0)
CPU側から描画コマンド送ってやらないといけない。
Re:次はマックス16スレッド(もちろん余計なもの:-2003XP) (スコア:1)
現実的に考えると、Outlook とかなんかは (受信処理等で) バックグラウンドでの処理がそこそこあるし、Word なんかでも構文のリアルタイムパースなどがあるので 1 スレッド動作前提で考えるのは微妙。
Windows で 1 コアってのも、動いているサービスごとに数コアは欲しいでしょう。とか考えると、普段使ってる環境でも 100 コアくらいは欲しくなることに。
# タスクマネージャ見たらシステム全体で 1,000 スレッド程度あったりしますし。
HyperThreading (スコア:1)
Re:HyperThreading (スコア:1)
なんかしらのスレッドが投入されていればコア内のリソース使用率があがる(=無駄がない)ので、結果として高パフォーマンスということですし。
やっぱりOSが割り振るしかないんでは。
# 実現したら、単一コアの仮想16スレッドCPUでしかないような...
M-FalconSky (暑いか寒い)
Re:HyperThreading (スコア:0)
Re:次はマックス16スレッド (スコア:0)
仕事でデュアル・コアのマシンを使った感想は
バックグラウンドで動くウイルス・チェック,バックアップ・ツール等が業務用アプリケーションの実行を妨げることが
無くなったのが嬉しい. 結局,いくらプロセッサ屋さんが頑張っても,ハウスキーピング・ジョブが効率化されるだけの
効果しかない.
どんどん増えるSSE命令だが (スコア:0)
ソフトウェア会社はAMDのCPUや下位互換性を考慮するので、
積極的に使われる場面は少ないであろう。
すると、命令を増やし回路面積を増やすよりか、
既存の命令の組み合わせでそのSSEをエミュレートすればゲフンゲフン
Re:どんどん増えるSSE命令だが (スコア:2, すばらしい洞察)
ハードウエアサブルーチンってかんじですかね。
ビット演算がショボ (スコア:1)
やっぱり動画のエンコードなどマルチメディア系の処理じゃないと活用しづらいのかな。SIMD命令のために使われている回路面積ってどの程度のものなんでしょうね。
屍体メモ [windy.cx]
Re:ビット演算がショボ (スコア:1, 興味深い)
古のbitの連載でMMXを使いこなしてるのも見てショックを受けました。
マジですか! (スコア:1)
うむむ、そのbitの記事、激しく見てみたいぞ。
巻号調べてみよう。図書館にあるかも知れん。
屍体メモ [windy.cx]
Re:ビット演算がショボ (スコア:0)
これからのソフトウェアを書く人 (スコア:1)
多分ソフトウェア科学的にはこちらが正しい道。とはい
えゴリゴリに使い回すには相応のコンパイラ側の技術が
必要。
# 実はその辺 gcc はあまり強くないイメージが…。
2)人間が頑張る
自分は mplayer/mencoder、それに gmp(GNU-mp) 位でし
か使っていないと思うんですが、これらは一部アセンブ
ラ表記ですね。
基本命令セットなら自分もアセンブラゴリゴリの時代も
ありましたが、パイプラインやアウトオブオーダ、レジ
スタリネーミング、キャッシュなどを考え始めると人間
には辛い。
もっというと CPU の細かいバージョン毎に最適な方法
が違ったりしてノウハウが長生きしないイメージがあり
ます。
icc? 興味はあるけど評価も時間かかるしなぁ…。
「FreeBSD のカーネルを icc でコンパイル出来るように
しようプロジェクト」ってどうなったんでしょうか。
Re:これからのソフトウェアを書く人 (スコア:2, 興味深い)
0)頑張ったBLASをベンダーに提供させる
>多分ソフトウェア科学的にはこちらが正しい道。
Intel、iccみたいなコンパイラじゃなくて、実行時に書き換えるソリューションの方が (スコア:1)
---
TaddyHatty - always @( posedge ↑ or negedge ↓ )
Re:Intel、iccみたいなコンパイラじゃなくて、実行時に書き換えるソリューションの方が (スコア:1)
たしか、JavaVMなんかはSSE命令とかを必要に応じて使ってくれたはず。どの程度最適化がされるかは知らんけど。
Re:Intel、iccみたいなコンパイラじゃなくて、実行時に書き換えるソリューションの方が (スコア:1)
> たしか、JavaVMなんかはSSE命令とかを必要に応じて使ってくれたはず。どの程度最適化が
> されるかは知らんけど。
あ、Intel純正コンパイラのiccのことを考えてたから、Javaのことは思いつかなかった。
codecのコードとかを実行時にCPUごとに最適化出来るようなのって無いのかなーって思ったので。
COFFやELFが実行時に解析されて、SSE命令に変換されて実行されて、で、プログラム終了時に書き換えた後のコードがシステム上の何処かに保存されるようなIntel(半導体ベンダ)純正ミドルウェアって無いのかなーと思って。
複雑な命令セットを持つプロセッサやマルチコアプロセッサ向け、とか。
---
TaddyHatty - always @( posedge ↑ or negedge ↓ )
Re:Intel、iccみたいなコンパイラじゃなくて、実行時に書き換えるソリューションの方が (スコア:0)
Re:Intel、iccみたいなコンパイラじゃなくて、実行時に書き換えるソリューションの方が (スコア:0)
べたに実装するならサポート命令を確認してから分岐、だけど、
その分岐コードで自己書き換えやって、確認命令をダイレクトに
処理分にジャンプするようにすればOK。
ただ、これまでは一般的だったと思うけど、今後セキュリティ強化の
流れで自己反映演算ができなくなってきそうな気もする。
Re:これからのソフトウェアを書く人 (スコア:0)
Re:どんどん増えるSSE命令だが (スコア:0)
SSE4 (スコア:0)
SSE4は従来からあった?
Re:SSE4 (スコア:0)
Re:ぺんりん…(おふとぴ: -9999) (スコア:3, すばらしい洞察)
みたいなの見るたびに思うんですけど、オフトピだと自分で分かってるなら何でわざわざ投稿するんでしょうね。荒らしなんでしょうか。実はオフトピじゃないと思ってるなら堂々としてりゃいいのに。
日記はチラシの裏 [srad.jp]にどうぞ
Re:ぺんりん…(おふとぴ: -9999) (スコア:1)
駄洒落や親父ギャグもダダ漏れになるものなんですよ。
明日はわが身。温かい目で見守ってあげてください。
Re:ぺんりん…(おふとぴ: -9999) (スコア:1, すばらしい洞察)
Re:ぺんりん…(おふとぴ: -9999) (スコア:1, すばらしい洞察)
余計にS/N比悪くなるだろうに。
# 自分はほとんどノイズでも気にならないけど。
Re:ぺんりん…(おふとぴ: -9999) (スコア:0)
オフトピだけどとんでもなく面白い(と自分では思っている)ので書いてみたとか。
#まあ得てして面白くはないんですが。
Re:ぺんりん…(おふとぴ: -9999) (スコア:1)
----- 傷の治療は傷より痛い -----
Re:ぺんりん…(おふとぴ: -9999) (スコア:0)
# CPU にもついに「萌え」?
Re:ぺんりん…(おふとぴ: -9999) (スコア:2, おもしろおかしい)
つまりペンティアム系で番号を決めかねているってことだよ。(嘘)
Re:ぺんりん…(おふとぴ: -9999) (スコア:1, おもしろおかしい)
「燃え」だと思っていたが?
#Athlonなら毛糸洗いに自信がもてます~
Re:ぺんりん…(おふとぴ: -9999) (スコア:0)
同一性保持権違反です :-p
Re:Mac専用、Windows終焉 (スコア:1)
まるでホストコンピュータ時代への回帰ですね。
あるいはthinclientの最終形か。
thinclient懐疑派としてはそんな未来が来ないように
力いっぱい否定したいところです。
Re:Mac専用、Windows終焉 (スコア:1)
必要十分なスペックのマシンを数台揃えるより、その人数が仮想環境として同時使用したときに耐えれるだけの高スペックマシンの価格の方が圧倒的に高価ですからねぇ。クライアント用の端末も加えて必要ですし。
仮想化はサンドボックスとか、セキュリティ面での利用の方が一般向けには普及するんじゃないですかね?
Re:Mac専用、Windows終焉 (スコア:1)
まぁ、それが売れるかは別ですが…
天琉陳(Teruching)
Re:Mac専用、Windows終焉 (スコア:1)
# Window 2003 server を購入しようと調べてみたけど,
# ライセンス関連で意味が理解できずに断念したのですが
全く分かってない人多数とちょっとは分かる人一人って組織(例えば家族)
のような場合は, 非常に管理が楽になりそう.
しかし, ノート PC とか, 出先で使う場合は通信速度とセキュリティ
がネックで難しいかもですね.
VNC を ssh でとばすと結構重いですから.
Re:Mac専用、Windows終焉 (スコア:0)
複数プロセスが同時に動いてるところを見てれば、1人でWindowsを使ってるだけだと
しても複数のCPUを持つことに意味はあるんじゃないかと。
# マルチコア=仮想化用だけじゃないのでAC
Re:Mac専用、Windows終焉 (スコア:0)
「Macはマルチユーザに対応しており、独立したGUIを複数ユーザに対して同時に
割り当てられる。Windowsはこの点不利だ」
って内容かと思ったんだけど、Parallelsってエミュレータじゃねえの?
Re:Mac専用、Windows終焉 (スコア:0)
ハードがやってくれるので不要、あたかも0番地から動いているように出来る所がポイント
処理する部分は現存するハードウェアにデータを横流しする部分だけがエミュレートになる。
仮にバグっても全体に影響しない点など有利な点は多い。
どうせワープロしか使ってない人が多いのですから現実的な選択だと思います。
Re:Mac専用、Windows終焉 (スコア:0)
じゃあ最初からWindowsマシンとparallels以外の仮想化の組み合わせでいいじゃん。
parallelsにこだわる必要性は?
Re:Mac専用、Windows終焉 (スコア:0)
make -j 16
で16並列コンパイル。これで使いきれるじゃん。
Re:Mac専用、Windows終焉 (スコア:0)
弱結合な数値計算ならば、苦労せずともMPIを使ってハッピーになれるかもしれない。
メモリが十二分にあれば、時間のかかるプログラムを16個 (或はパラメーターを変えて16通り)といった、
手動並列処理が楽しみ。
Re:Mac専用、Windows終焉 (スコア:1)
伝統的なCプロジェクトだと、IO律速ってのは結構前から言われてるけど、
たとえば、g++でstlとかboostとか使うと、CPUがものすごく考えるよね。