アカウント名:
パスワード:
X3とX4て(ベンチじゃなく)実際の動作速度でいかほど違うんでしょうか。アーキテクチャが複雑になりすぎて「結局どのくらい速いの」ということが把握できなくなってきてます<自分。
常時違いを感じることはありません。
単スレッドの性能はコア数が変わっても同じですし、逆に処理時間の比例の仕方が決まっているエンコードなどのフルパワーを使う処理以外のマルチスレッド対応ソフトは、軽過ぎて違いがわからないか、コア数以上のセッションが殺到してCPUよりもネットワークやストレージがボトルネックになったりする、の極端な二択で、何かの処理が早くなったなと実感することは少ないでしょう。
例えば、自分の経験から言えば Firefox はあまり目に見えて早くなりません。タブごとに並行処理してくれるのですが、開くタブの数が多すぎて前述の通りネットワークとメモリの方がヒーヒー言います。
しかし、普段からブラウザにIMにデジタルTVや音楽再生垂れ流しなんてことを同時にやりつつ、、さらにテキストエディターなどのフロントで作業するソフトを起動させたりしようとすると、デュアルコアとクアッドコアぐらいなら如実に差が出ます。
だから無効って訳ではないんですよ。
ちなみにPhenomⅡはコアの数と発熱・消費電力があまり反比例しないので、使えるコアは使っておいた方が損しません。
#Core2との比較はここでは述べませぬ…。
使えるコアは使っておいた方が損しません
一応、選別落ち品の可能性も高いわけで、ベンチマークをとったり、「おお、確かにOSから4CPU見える」と確認するくらいに留めておくのがよさそうな気もするのですが。
試してみて「確実に動かない」のなら単に諦めるだけなので害はないかもしれませんが、場合によって動いたり動かなかったり、(あまり使われない機能の)特定のテストだけパスしなかったコアが殺されているとか…。
マルチコアの恩恵を一番感じるのは
$ make -j
したときですねぇ。
例えば、自分の経験から言えば Firefox はあまり目に見えて早くなりません。 タブごとに並行処理してくれるのですが、開くタブの数が多すぎて前述の通りネットワークとメモリの方がヒーヒー言います。
Fxの処理で一番重いレイアウト、レンダリング処理はGUI用のスレッドで処理されるので、シングルスレッドアプリケーションとあまり違いがありません。ですから、この例には不適切です。
例えば、バックグラウンドのタブででかいページをレイアウトしている最中(読み込んでいる最中)は、GUI上では何もできなくなるということを経験していませんか?
ご指摘ありがとうございます。これは私の間違いでした。レンダリングを並行させていると思い込んでいました。
早くするための技術じゃなくて遅くならなくするための技術
そうですね。以前だったら重複させると動かなくなったような処理を複数走らせても遅くならないってのは非常に強みだと思います。
以前だったら考えられなかった、「エンコードしてる裏側でオンラインゲーム(FPS)をやる」なんて時間の有効活用?も可能になりますし。
早くするための技術じゃなくて遅くならなくするための技術。
遅くならないのは事実としても、「そのための技術」ってのは今時どうなんですかね。マルチスレッドなアプリってまだそんなに特殊?
「そのための技術」ってのは今時どうなんですかね。
今時だからこそ有効な技術ですよ。バックグラウンドで数十のプロセスが常に動いている今時のOSであればこそ、です。
マルチスレッドなアプリってまだそんなに特殊?
存在が特殊というか、マルチスレッド化して労力に見合った速度になるケースが意外に少ないというのがあるのではないかと。
>マルチスレッド化して労力に見合った速度になるケースが意外に少ないというのがあるのではないかと。
マルチスレッド化による速度向上に比べ、マルチスレッドアプリを作るための「労力が高く付きすぎる」というのが大きいんではないかと。そもそもマルチスレッドでプログラムを書けないプログラマの方が断然多いし。よってPCだと複数アプリ同時起動(つまりマルチプロセス)がメインになるんでしょう。
やたらでかいアプリをフルビルドしながら、同時に暇潰しにニコ動を見て、ついでにスラドに書き込みするというような贅沢な職場環境なら、CPUコアとディスプレイは多いに越したことはないと思います。
>「労力が高く付きすぎる」というのが大きいんではないかと。
それもありますが、大きな理由はむしろ「たいして速くならない」からですよ。「1:9の法則」(プログラムコードの1割が処理時間の9割を消費する)という経験則があるように、手を入れることで目に見えて速度が向上する部分はごく一部です。この部分がマルチスレッド化でスピードアップできるような処理でなければほとんど無意味ということです。
スレッド間同期のオーバーヘッドでかえって遅くなることも珍しくないため、マルチスレッド化で体感できるほど速くなるアプリケーションってけっこう限られてます。
非同期処理を並列実行するコードを簡潔に書くためのマルチスレッド化する場合もありますが、この場合は単に待ち時間を減らしたりしているだけなのでマルチコアになってもそんなにスピードは変わりません。
>マルチスレッドでプログラムを書けないプログラマの方が断然多いし。
これも当然。マルチスレッドの恩恵を受けられない分野ならマルチスレッドでプログラムする需要がありません。マルチスレッド化が有効な処理がそう多くないから、そういうコードを書けるプログラマも限られます。
>マルチスレッド化が有効な処理がそう多くないから、そういうコードを書けるプログラマも限られます。うーんと、本当にマルチスレッドの並列プログラムをやったことあります?
>スレッド間同期のオーバーヘッドでかえって遅くなることも珍しくないため、マルチスレッド化で>体感できるほど速くなるアプリケーションってけっこう限られてます。
は事実だけど、たとえ早くなる処理でさえも並レベルの分かってないプログラマが書くと「スレッド間同期のオーバーヘッドでかえって遅くなる」だけでなく、アルゴリズムや設計が逐次処理とは異なるとか、デバッグが死ぬほど難しいとかにより、マルチスレッドのプログラミングは難易度がもの凄く高いんですよね。
もしプログラミングが簡単だったら実測で2~3割早いだけでもマルチスレッド化するかもしれないけれど、実際には難易度がとてつもなく高いので、最低でも2~3倍速くなって体感速度ではっきり分かるくらいでないと、マルチスレッド化/並列化という選択は採算が合わないのです。
そういう意味ではクワッドコアでもまだまだですね。最大でもたったの4倍(とちょっと)にしかならないのですから。並列処理が大きく意味を持つようになるには、コア数が16とか32とかくらいにならないと難しいのでは。
あと>「1:9の法則」(プログラムコードの1割が処理時間の9割を消費する)という経験則が>あるように、手を入れることで目に見えて速度が向上する部分はごく一部です。この部分の9割とか1割は、この議論にはあんまり関係ないですね。「その9割を占める1割の部分は、並列化しにくいことが知られている」などという結論には繋がってないわけですから。
それに実際には1割になってくれてる方が楽です。運が良ければ全体の1割を書き換えるだけで、全体を2倍~3倍に高速化することも不可能ではないのですから。「運が良くても悪くても、全部書き換えないと性能が上がらない」よりはずっと楽です。
>うーんと、本当にマルチスレッドの並列プログラムをやったことあります?
「レスポンス向上などを目的とした非同期処理のためのマルチスレッド」ならけっこうやってますよ。「マルチコアを活用して処理速度を向上するための並列化」はかじった程度ですね。
>この部分の9割とか1割は、この議論にはあんまり関係ないですね。>「その9割を占める1割の部分は、並列化しにくいことが知られている」>などという結論には繋がってないわけですから。
そんなことはないと思いますよ。「処理速度向上のためにコストをかけてマルチスレッド化する価値があるかどうかは、その9割を占める1割の部分が並列化しやすいかどうかにかかっている」(ダメなこともよくある)という表現なら、firewheelさんもそんなに異論はないのでは?
私は別にマルチスレッドプログラミングの難易度が高いことを否定したつもりはありません。それとは別に並列化によって速度向上を期待できるシチュエーションが限られていて、そのため並列化のスキルを身に着けても活かせる場面が限られていることも、並列化のプログラミングコストがなかなか下がらない要因として大きいということが言いたかったのです。もっと幅広く効果が期待できるものであれば、本質的に避けられない複雑さはあるにしてももうちょっとハードルは下がったんじゃないかなと思うわけです。
>やたらでかいアプリをフルビルドしながら、同時に暇潰しにニコ動を見て、>ついでにスラドに書き込みするというような贅沢な職場環境なら、CPUコアと>ディスプレイは多いに越したことはないと思います。
複数台のコンピュータを利用した方が効率的です。HDDやメモリのスループットがボトルネックになりそう。
ん…?じゃあHDDにそこそこのCPUとメモリを組み込んだコンポーネントを大量につなげるようなPCを作ったら、かなり幸せになれるってこと?
せめてキーボードとマウスだけは一台にまとめたいです。机の上に置けないってば。
つ「KVM [kakaku.com]」
つ【SSD】
既製のアルゴリズムを解析して並列化するのは大変だけどアルゴリズムにデータを投入する段階でマスター/ワーカー式粗粒度並列にするのは同期用のキューとかライブラリ・レベルのインフラがそろってればそんなに難しくないです。(前にも書いたような気がするけど)仕事で作ってるコンパイラはJavaの5.0(1.5)以降前提なのでインフラがそろっており、ある最適化をその手口で並列にしたらちゃんとコア数分早くなって結構幸せ。
遅くならないのは事実としても、「そのための技術」ってのは今時どうなんですかね。
OpenMPとかTBB(Threading Building Block)ってキーワードで情報収集すると、幸せになれるかも知れません。
Coreあたりの処理能力が頭打ちになってきているので、今後は如何に処理を並列化するかがパフォーマンスを決めるでしょう。Single threadでQuick Sortするより、Multi ThreadでBubble Sortするほうが早い、ということすらあり得ます。65536coreもあれば、ループ展開が容易なBubble Sortの方が速いかもしれません。まぁ、これは極端すぎますが。
今後は完全にSingle Threadのアプリなんて滅多に見かけない、と言うか作れないようになっていくんじゃないでしょうか。過去がそうであったようにThreadの概念も抽象化され隠蔽されていき、意識せず使うことができる、という方向だと思いますよ。
>早くするための技術じゃなくて遅くならなくするための技術。
なので、ヘビーユーザー以外にとっては現実的にPCを買い換えなければいけない理由がないんですよね、ここ数年。ノートだとPentiumMあたり、デスクトップだとPentium4あたりで、ちょうどXP世代に入った頃でしょうか?メモリも512MB以上が当たり前になった頃でもあります。よく言われる「PCの寿命」的には終わりに差しかかっているこれらの製品ですが、シングルスレッド性能が現行品と変わらない以上は無期限的に使われる可能性も高く、PCの新規需要やOSの世代更新に与える影響が大きいかもしれません。
# もちろん消耗品のHDDだけは交換しなければいけないのですが修理対応の範囲内です・・・。# まぁ、Pentium4は環境に優しくなさすぎるので、長期に渡って使うのもどうかとは思いますが。# そういえばあのNetburstアーキテクチャは64bitでは最速なんでしたっけ?OSの64bitが当たり前になれば見直されるのかな?
32ビットコード→64ビットコードへの切り替えで、速度の上昇率が一番高いことを言いたいんじゃないでしょうか。たぶん。
AMD用語: x86-64(旧称), AMD64(現在の名称)Intel用語: Yamhill(コードネーム), EM64T(旧称), Intel64(現在の名称)MS用語: x64(AMDのとIntelのをひっくるめた名称)
#「「x86-64」という名称は、搭載プロセッサの正式リリースに伴って「AMD64」に変更された」と書いてあるではないですか。
終わんなくなるから下げんのやだ。結局のところストリーミング放送とFPSの両立とかは不可能だし、Windowsでそれやると切り替えに時間取られて全然リニアじゃない速度低下をみますし。今やりたいタスクが複数あるのに「片っぽ優先度下げれば」とか言われても困ります。このmp4ファイルは1時間以内にエンコードしたいし、あのメールは今書かなきゃいけないし、torrentこんなにたまってるんだからキューは早く空けたいし、そろそろ面白Flashサイト巡回を始める時間なんです。そこに多コアというソリューションが降ってきたら、飛びついたっていいでしょう。
# 単コア・メモリ0.7GBのマシンを4コア・メモリ3GBにアップグレードしたら「重いタスク」がほとんどなくなってしまったのでIDで# お前それメモリ足りてなかっただけじゃねとか言わないでー# torrentって何だよって? s...Slackwareと、そうそうUbuntuのライヴDVDですよ。うん。
まあ、あんまり手軽じゃないですが、私は優先度を変えたプログラムについては、起動用ショートカットのリンク先を
C:\WINDOWS\system32\cmd.exe /c "start /HIGH C:\Progra~1…"
といった感じにしてます。
私の使ってるテレビチューナーの録画用のソフトは、IEと同じ優先度だと、IEでスクロールさせるだけで録画がコマ落ちするので、優先度をいじるのは必須…
http://www.vector.co.jp/soft/win95/util/se293319.html [vector.co.jp]オートギアというGUIの自動設定ソフトがあります。チューニングはなかなか大変ですけどね。
内容自体は面白いのですが、
スラド民なら、それくらいのプログラムは朝飯前に書けて当然ですよ。
買いかぶりすぎだと思います。
#当然じゃない人その1。他にもいますよね?ね?
記事を見る限り動作コア数が変わってるだけで、コアの動作速度自体は3.12GHzで変わってないようです。ベンチマークじゃないってことだからこれでいいよね?
結局どのくらいってことなら、マルチスレッド対応のエンコードなら1.3倍くらいにはなるんじゃないかな。
Core2 Extreme X6800 が発表された時には、「これを10個でX68000だ!」なんて思ったものですが
どっかの掲示板で、X68000 を X6800 の typo 扱いされたのを見たことがあります。これも時代か…
X4にするつもりがコアが3つも不良だったぜ!というケースも期待して良いですか?
# 今でも CZ-644C/CZ-880C/CZ-801C ユーザ。X1のことも忘れないでください。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
未知のハックに一心不乱に取り組んだ結果、私は自然の法則を変えてしまった -- あるハッカー
それ以前に (スコア:1, 興味深い)
X3とX4て(ベンチじゃなく)実際の動作速度でいかほど違うんでしょうか。
アーキテクチャが複雑になりすぎて「結局どのくらい速いの」ということが
把握できなくなってきてます<自分。
Re:それ以前に (スコア:5, 参考になる)
常時違いを感じることはありません。
単スレッドの性能はコア数が変わっても同じですし、
逆に処理時間の比例の仕方が決まっているエンコードなどのフルパワーを使う処理以外のマルチスレッド対応ソフトは、
軽過ぎて違いがわからないか、コア数以上のセッションが殺到してCPUよりもネットワークやストレージがボトルネックになったりする、
の極端な二択で、何かの処理が早くなったなと実感することは少ないでしょう。
例えば、自分の経験から言えば Firefox はあまり目に見えて早くなりません。
タブごとに並行処理してくれるのですが、開くタブの数が多すぎて前述の通りネットワークとメモリの方がヒーヒー言います。
しかし、普段からブラウザにIMにデジタルTVや音楽再生垂れ流しなんてことを同時にやりつつ、、
さらにテキストエディターなどのフロントで作業するソフトを起動させたりしようとすると、
デュアルコアとクアッドコアぐらいなら如実に差が出ます。
だから無効って訳ではないんですよ。
ちなみにPhenomⅡはコアの数と発熱・消費電力があまり反比例しないので、使えるコアは使っておいた方が損しません。
#Core2との比較はここでは述べませぬ…。
=-=-= The Inelegance(無粋な人) =-=-=
Re:それ以前に (スコア:3, すばらしい洞察)
一応、選別落ち品の可能性も高いわけで、ベンチマークをとったり、「おお、確かにOSから4CPU見える」と確認するくらいに留めておくのがよさそうな気もするのですが。
試してみて「確実に動かない」のなら単に諦めるだけなので害はないかもしれませんが、場合によって動いたり動かなかったり、(あまり使われない機能の)特定のテストだけパスしなかったコアが殺されているとか…。
Re:それ以前に (スコア:1, 参考になる)
マルチコアの恩恵を一番感じるのは
$ make -j
したときですねぇ。
Re:それ以前に (スコア:1)
Fxの処理で一番重いレイアウト、レンダリング処理はGUI用のスレッドで処理されるので、シングルスレッドアプリケーションとあまり違いがありません。ですから、この例には不適切です。
例えば、バックグラウンドのタブででかいページをレイアウトしている最中(読み込んでいる最中)は、GUI上では何もできなくなるということを経験していませんか?
Re:それ以前に (スコア:2)
ご指摘ありがとうございます。
これは私の間違いでした。レンダリングを並行させていると思い込んでいました。
=-=-= The Inelegance(無粋な人) =-=-=
Re: (スコア:0)
3.1β版では対応しているのかな。
うちのデュアルコアの環境ではfirefoxにCPU負荷50%、片側のCPUが丸々使われてます。
Flashとかのプラグインはさすがに別プログラムとして動いているみたいだけど...
GoogleCromeはタブ毎にプロセスを発行するので多量のタブを開いてページロード中でも
タブ切り替えに応答してくれるからいいですよね。
Re:それ以前に (スコア:3, すばらしい洞察)
よって普通に使っている分にはクロック分の速さしか体感できないですよ。
Re:それ以前に (スコア:1)
早くするための技術じゃなくて遅くならなくするための技術
そうですね。以前だったら重複させると動かなくなったような処理を複数走らせても遅くならない
ってのは非常に強みだと思います。
以前だったら考えられなかった、「エンコードしてる裏側でオンラインゲーム(FPS)をやる」
なんて時間の有効活用?も可能になりますし。
Re: (スコア:0)
Re: (スコア:0)
早くするための技術じゃなくて遅くならなくするための技術。
遅くならないのは事実としても、「そのための技術」ってのは今時どうなんですかね。
マルチスレッドなアプリってまだそんなに特殊?
Re:それ以前に (スコア:1, 興味深い)
今時だからこそ有効な技術ですよ。バックグラウンドで数十のプロセスが常に動いている今時のOSであればこそ、です。
存在が特殊というか、マルチスレッド化して労力に見合った速度になるケースが意外に少ないというのがあるのではないかと。
Re:それ以前に (スコア:1)
>マルチスレッド化して労力に見合った速度になるケースが意外に少ないというのがあるのではないかと。
マルチスレッド化による速度向上に比べ、マルチスレッドアプリを作るための
「労力が高く付きすぎる」というのが大きいんではないかと。そもそもマルチ
スレッドでプログラムを書けないプログラマの方が断然多いし。よってPCだと複数
アプリ同時起動(つまりマルチプロセス)がメインになるんでしょう。
やたらでかいアプリをフルビルドしながら、同時に暇潰しにニコ動を見て、
ついでにスラドに書き込みするというような贅沢な職場環境なら、CPUコアと
ディスプレイは多いに越したことはないと思います。
Re:それ以前に (スコア:2, 興味深い)
>「労力が高く付きすぎる」というのが大きいんではないかと。
それもありますが、大きな理由はむしろ「たいして速くならない」からですよ。
「1:9の法則」(プログラムコードの1割が処理時間の9割を消費する)という経験則があるように、手を入れることで目に見えて速度が向上する部分はごく一部です。この部分がマルチスレッド化でスピードアップできるような処理でなければほとんど無意味ということです。
スレッド間同期のオーバーヘッドでかえって遅くなることも珍しくないため、マルチスレッド化で体感できるほど速くなるアプリケーションってけっこう限られてます。
非同期処理を並列実行するコードを簡潔に書くためのマルチスレッド化する場合もありますが、この場合は単に待ち時間を減らしたりしているだけなのでマルチコアになってもそんなにスピードは変わりません。
>マルチスレッドでプログラムを書けないプログラマの方が断然多いし。
これも当然。
マルチスレッドの恩恵を受けられない分野ならマルチスレッドでプログラムする需要がありません。
マルチスレッド化が有効な処理がそう多くないから、そういうコードを書けるプログラマも限られます。
うじゃうじゃ
Re:それ以前に (スコア:2)
>マルチスレッド化が有効な処理がそう多くないから、そういうコードを書けるプログラマも限られます。
うーんと、本当にマルチスレッドの並列プログラムをやったことあります?
>スレッド間同期のオーバーヘッドでかえって遅くなることも珍しくないため、マルチスレッド化で
>体感できるほど速くなるアプリケーションってけっこう限られてます。
は事実だけど、たとえ早くなる処理でさえも並レベルの分かってないプログラマが
書くと「スレッド間同期のオーバーヘッドでかえって遅くなる」だけでなく、
アルゴリズムや設計が逐次処理とは異なるとか、デバッグが死ぬほど難しいとかに
より、マルチスレッドのプログラミングは難易度がもの凄く高いんですよね。
もしプログラミングが簡単だったら実測で2~3割早いだけでもマルチスレッド化する
かもしれないけれど、実際には難易度がとてつもなく高いので、最低でも2~3倍速く
なって体感速度ではっきり分かるくらいでないと、マルチスレッド化/並列化という
選択は採算が合わないのです。
そういう意味ではクワッドコアでもまだまだですね。最大でもたったの4倍
(とちょっと)にしかならないのですから。並列処理が大きく意味を持つようになる
には、コア数が16とか32とかくらいにならないと難しいのでは。
あと
>「1:9の法則」(プログラムコードの1割が処理時間の9割を消費する)という経験則が
>あるように、手を入れることで目に見えて速度が向上する部分はごく一部です。
この部分の9割とか1割は、この議論にはあんまり関係ないですね。
「その9割を占める1割の部分は、並列化しにくいことが知られている」
などという結論には繋がってないわけですから。
それに実際には1割になってくれてる方が楽です。運が良ければ全体の1割を書き
換えるだけで、全体を2倍~3倍に高速化することも不可能ではないのですから。
「運が良くても悪くても、全部書き換えないと性能が上がらない」よりはずっと
楽です。
Re:それ以前に (スコア:1)
>うーんと、本当にマルチスレッドの並列プログラムをやったことあります?
「レスポンス向上などを目的とした非同期処理のためのマルチスレッド」ならけっこうやってますよ。
「マルチコアを活用して処理速度を向上するための並列化」はかじった程度ですね。
>この部分の9割とか1割は、この議論にはあんまり関係ないですね。
>「その9割を占める1割の部分は、並列化しにくいことが知られている」
>などという結論には繋がってないわけですから。
そんなことはないと思いますよ。
「処理速度向上のためにコストをかけてマルチスレッド化する価値があるかどうかは、その9割を占める1割の部分が並列化しやすいかどうかにかかっている」(ダメなこともよくある)
という表現なら、firewheelさんもそんなに異論はないのでは?
私は別にマルチスレッドプログラミングの難易度が高いことを否定したつもりはありません。
それとは別に並列化によって速度向上を期待できるシチュエーションが限られていて、そのため並列化のスキルを身に着けても活かせる場面が限られていることも、並列化のプログラミングコストがなかなか下がらない要因として大きいということが言いたかったのです。
もっと幅広く効果が期待できるものであれば、本質的に避けられない複雑さはあるにしてももうちょっとハードルは下がったんじゃないかなと思うわけです。
うじゃうじゃ
Re:それ以前に (スコア:1)
>やたらでかいアプリをフルビルドしながら、同時に暇潰しにニコ動を見て、
>ついでにスラドに書き込みするというような贅沢な職場環境なら、CPUコアと
>ディスプレイは多いに越したことはないと思います。
複数台のコンピュータを利用した方が効率的です。
HDDやメモリのスループットがボトルネックになりそう。
Re:それ以前に (スコア:1)
ハードウェア故障率も上がってくるし
Re: (スコア:0)
ん…?
じゃあHDDにそこそこのCPUとメモリを組み込んだコンポーネントを大量につなげるようなPCを作ったら、かなり幸せになれるってこと?
Re:それ以前に (スコア:1)
せめてキーボードとマウスだけは一台にまとめたいです。
机の上に置けないってば。
Re:それ以前に (スコア:1)
つ「KVM [kakaku.com]」
/* Kachou Utumi
I'm Not Rich... */
Re: (スコア:0)
HDDは機械だからトロい。(Re:それ以前に (スコア:1)
つ【SSD】
Re:それ以前に (スコア:1)
既製のアルゴリズムを解析して並列化するのは大変だけどアルゴリズムにデータを投入する段階で
マスター/ワーカー式粗粒度並列にするのは同期用のキューとかライブラリ・レベルのインフラがそろってればそんなに難しくないです。
(前にも書いたような気がするけど)仕事で作ってるコンパイラはJavaの5.0(1.5)以降前提なのでインフラがそろっており、
ある最適化をその手口で並列にしたらちゃんとコア数分早くなって結構幸せ。
Re: (スコア:0)
> 意外に少ないというのがあるのではないかと。
自分的には、Web+開発ツール位しか使わないので、うれしいアプリはあまり思い
浮かばないですね
#しいて言えば、エンコくらいかw
体感ですが 2400+690G+Cnet君x64より9350e+790G+Cent君x32の方が
NetBeansの起動は速い気がする
Re: (スコア:0)
効果が見られますよ。
以前だと、韓国の新聞系サイトなんかがそうです。
シングルコアだと、ページを開いているだけで、かなりのパワーを
持っていかれました。
# 重くて不評だったらしく、すぐにフラッシュは使われなくなりましたが。
Re:それ以前に (スコア:1, 参考になる)
OpenMPとかTBB(Threading Building Block)ってキーワードで情報収集すると、幸せになれるかも知れません。
Coreあたりの処理能力が頭打ちになってきているので、今後は如何に処理を並列化するかがパフォーマンスを決めるでしょう。
Single threadでQuick Sortするより、Multi ThreadでBubble Sortするほうが早い、ということすらあり得ます。
65536coreもあれば、ループ展開が容易なBubble Sortの方が速いかもしれません。
まぁ、これは極端すぎますが。
今後は完全にSingle Threadのアプリなんて滅多に見かけない、と言うか作れないようになっていくんじゃないでしょうか。
過去がそうであったようにThreadの概念も抽象化され隠蔽されていき、意識せず使うことができる、という方向だと思いますよ。
Re: (スコア:0)
>早くするための技術じゃなくて遅くならなくするための技術。
なので、ヘビーユーザー以外にとっては現実的にPCを買い換えなければいけない理由がないんですよね、ここ数年。ノートだとPentiumMあたり、デスクトップだとPentium4あたりで、ちょうどXP世代に入った頃でしょうか?メモリも512MB以上が当たり前になった頃でもあります。よく言われる「PCの寿命」的には終わりに差しかかっているこれらの製品ですが、シングルスレッド性能が現行品と変わらない以上は無期限的に使われる可能性も高く、PCの新規需要やOSの世代更新に与える影響が大きいかもしれません。
# もちろん消耗品のHDDだけは交換しなければいけないのですが修理対応の範囲内です・・・。
# まぁ、Pentium4は環境に優しくなさすぎるので、長期に渡って使うのもどうかとは思いますが。
# そういえばあのNetburstアーキテクチャは64bitでは最速なんでしたっけ?OSの64bitが当たり前になれば見直されるのかな?
Re: (スコア:0)
Re: (スコア:0)
32ビットコード→64ビットコードへの切り替えで、速度の上昇率が一番高いことを言いたいんじゃないでしょうか。たぶん。
Re:それ以前に (スコア:2, 参考になる)
AMD用語: x86-64(旧称), AMD64(現在の名称)
Intel用語: Yamhill(コードネーム), EM64T(旧称), Intel64(現在の名称)
MS用語: x64(AMDのとIntelのをひっくるめた名称)
#「「x86-64」という名称は、搭載プロセッサの正式リリースに伴って「AMD64」に変更された」と書いてあるではないですか。
Re: (スコア:0)
CPUがdualだと遅くならない!なんて10年から指摘されている間違った考え方ですよ。
たとえば、エンコード中でもWebブラウザが重くならない、などという発言をよく見かけましたが、
それは、エンコードのプロセスあるいはスレッドのプライオリティを下げることを知らない故の乱暴な解決策でした。
そういう指摘をすると、
dual使ったことないだろとか、CPUが1つしかない人のやっかみがウザイとか言われたものですが、
むしろdual大好きで、CPUが1つしかないPCは事務用の1台だけで、あとはみなdualでした。
CPUを2個とも使い倒したからこそ、プライオリティを適切に設定することが重要で、CPUを増やす前にやるべきだと説いても、CPUが2個並ぶだけで悦に入ってる、手段が目的になっている人の耳には届きませんでした。
悲しいことに10年経っても、変っていないんですね。
Re:それ以前に (スコア:1)
終わんなくなるから下げんのやだ。結局のところストリーミング放送とFPSの両立とかは不可能だし、Windowsでそれやると切り替えに時間取られて全然リニアじゃない速度低下をみますし。
今やりたいタスクが複数あるのに「片っぽ優先度下げれば」とか言われても困ります。このmp4ファイルは1時間以内にエンコードしたいし、あのメールは今書かなきゃいけないし、torrentこんなにたまってるんだからキューは早く空けたいし、そろそろ面白Flashサイト巡回を始める時間なんです。そこに多コアというソリューションが降ってきたら、飛びついたっていいでしょう。
# 単コア・メモリ0.7GBのマシンを4コア・メモリ3GBにアップグレードしたら「重いタスク」がほとんどなくなってしまったのでIDで
# お前それメモリ足りてなかっただけじゃねとか言わないでー
# torrentって何だよって? s...Slackwareと、そうそうUbuntuのライヴDVDですよ。うん。
Re: (スコア:0)
そのプログラムを一旦終了させたら、優先度情報はリセットされてしまう。
事務所なんかだと、メールに添付されているファイルの内容確認なんかが
かなりの部分を占めるので、EXCELやらWordやらPowerPointやら
Acrobatやらをしょっちゅう起動したり終了したりさせている。
プログラムを立ち上げるたびに優先度を調整するなんて面倒なことを
やるくらいなら、コアの数を大きくした方が簡単。
誰でも間違いなくスピードアップを図れる。
Re:それ以前に (スコア:1)
まあ、あんまり手軽じゃないですが、
私は優先度を変えたプログラムについては、起動用ショートカットのリンク先を
といった感じにしてます。
私の使ってるテレビチューナーの録画用のソフトは、IEと同じ優先度だと、IEでスクロールさせるだけで録画がコマ落ちするので、優先度をいじるのは必須…
Re:それ以前に (スコア:2)
http://www.vector.co.jp/soft/win95/util/se293319.html [vector.co.jp]
オートギアというGUIの自動設定ソフトがあります。
チューニングはなかなか大変ですけどね。
=-=-= The Inelegance(無粋な人) =-=-=
Re: (スコア:0)
みごとなまでに乱暴なソリューション例の披露ありがとうございます。
優先度は上げるものではなく下げるものです。
フォアグラウンドで使うアプリの優先度はデフォルトのままでいいんです。変える必要はありません。
バックグラウンドで走るアプリの優先度を下げるのです。
そして、タスクマネージャでいちいち手作業で設定するような、コンピュータに使われる発想が先に出てはいけません。
どうしたら自動的に設定ができるのか調べて実行しましょうね。
CreateProcess時点で指定する方法もいいですし、
プロセスを列挙して自動的に設定する方法でもいいでしょう。
スラド民なら、それくらいのプログラムは朝飯前に書けて当然ですよ。
ソースのない得体の知れないものでも構わないのであれば、
書かなくてもネットで探せばフリーウェアがいくつも見つかりますが。
Re:それ以前に (スコア:1)
内容自体は面白いのですが、
スラド民なら、それくらいのプログラムは朝飯前に書けて当然ですよ。
買いかぶりすぎだと思います。
#当然じゃない人その1。他にもいますよね?ね?
Re: (スコア:0)
コードを書くのは朝飯の後だから、俺は違う人その1だな。
Re: (スコア:0)
それをみんなに「適切に」やらせることが出来ると思いますか?
自分の設定は適切ですか?
もし、自分の設定が適切だと考えるなら、その根拠はどこにありますか?
多分、何回も調整して経験則から割り出しているのではないですか?
だとすると、他の人も同じレベルの経験を積まないとまともに設定できませんね。
あなたにとっては趣味とか遊びのレベルで会得出来たかもしれないけれど、
会社レベルだと業務としてまじめに取り組まないと会得できない人が
数多く出てくるでしょう。
マルチコアの新しいPCに買い直した方がずっと安上がりですよ。
そもそも、優先度を落とした方は「遅く」なるし。
> CPUがdualだと遅くならない!なんて10年から指摘されている間違った考え方ですよ。
遅くしたくないからのマルチコアですよ。
Re: (スコア:0)
OSやアプリが適切にプライオリティ管理を動的にするべきと言う話なら兎も角
使い倒していないものの現実的に恩恵を受けているユーザーに対して「間違っている」と言うのは言い過ぎだと思われます
10年の間違いが現在の間違いと限らない訳で
私はホームユースとビジネスやエンタープライズあたりのマルチプロセッサ/コアとは分けて考えるべきだと思いますが
Re:それ以前に (スコア:1)
あとは、バックグラウンドで動かしても重たくならないアプリ本数が増えたとかそんなもの。
常駐ソフトを沢山入れている人は目に見えてよくなるでしょうね。
Re:それ以前に (スコア:1)
記事を見る限り動作コア数が変わってるだけで、コアの動作速度自体は3.12GHzで変わってないようです。
ベンチマークじゃないってことだからこれでいいよね?
結局どのくらいってことなら、マルチスレッド対応のエンコードなら1.3倍くらいにはなるんじゃないかな。
Re: (スコア:0)
裏でエンコ中に普通にネットできるのは効果を感じてますけど。
実際のところは半日、一日かかるコーディングでもないと効果は数字でわからないんじゃないですか。
Re: (スコア:0)
Re:それ以前に (スコア:1)
あまりに安直すぎるのでIDで書くことにした。
Re:それ以前に (スコア:1)
頑張って17000個集めましょう。
# や、別に68000コアじゃないから。
Re:それ以前に (スコア:2, おもしろおかしい)
Core2 Extreme X6800 が発表された時には、「これを10個でX68000だ!」なんて思ったものですが
どっかの掲示板で、X68000 を X6800 の typo 扱いされたのを見たことがあります。これも時代か…
Re:それ以前に (スコア:2, 参考になる)
たぶんX68000のTypoだったんだと思います。
Re: (スコア:0)
X4にするつもりがコアが3つも不良だったぜ!
というケースも期待して良いですか?
# 今でも CZ-644C/CZ-880C/CZ-801C ユーザ。X1のことも忘れないでください。