アカウント名:
パスワード:
X3とX4て（ベンチじゃなく）実際の動作速度でいかほど違うんでしょうか。アーキテクチャが複雑になりすぎて「結局どのくらい速いの」ということが把握できなくなってきてます＜自分。
早くするための技術じゃなくて遅くならなくするための技術。
遅くならないのは事実としても、「そのための技術」ってのは今時どうなんですかね。マルチスレッドなアプリってまだそんなに特殊？
「そのための技術」ってのは今時どうなんですかね。
今時だからこそ有効な技術ですよ。バックグラウンドで数十のプロセスが常に動いている今時のOSであればこそ、です。
マルチスレッドなアプリってまだそんなに特殊？
存在が特殊というか、マルチスレッド化して労力に見合った速度になるケースが意外に少ないというのがあるのではないかと。
＞マルチスレッド化して労力に見合った速度になるケースが意外に少ないというのがあるのではないかと。
マルチスレッド化による速度向上に比べ、マルチスレッドアプリを作るための「労力が高く付きすぎる」というのが大きいんではないかと。そもそもマルチスレッドでプログラムを書けないプログラマの方が断然多いし。よってPCだと複数アプリ同時起動（つまりマルチプロセス）がメインになるんでしょう。
やたらでかいアプリをフルビルドしながら、同時に暇潰しにニコ動を見て、ついでにスラドに書き込みするというような贅沢な職場環境なら、CPUコアとディスプレイは多いに越したことはないと思います。
＞「労力が高く付きすぎる」というのが大きいんではないかと。
それもありますが、大きな理由はむしろ「たいして速くならない」からですよ。「1:9の法則」(プログラムコードの1割が処理時間の9割を消費する)という経験則があるように、手を入れることで目に見えて速度が向上する部分はごく一部です。この部分がマルチスレッド化でスピードアップできるような処理でなければほとんど無意味ということです。
スレッド間同期のオーバーヘッドでかえって遅くなることも珍しくないため、マルチスレッド化で体感できるほど速くなるアプリケーションってけっこう限られてます。
非同期処理を並列実行するコードを簡潔に書くためのマルチスレッド化する場合もありますが、この場合は単に待ち時間を減らしたりしているだけなのでマルチコアになってもそんなにスピードは変わりません。
＞マルチスレッドでプログラムを書けないプログラマの方が断然多いし。
これも当然。マルチスレッドの恩恵を受けられない分野ならマルチスレッドでプログラムする需要がありません。マルチスレッド化が有効な処理がそう多くないから、そういうコードを書けるプログラマも限られます。
＞マルチスレッド化が有効な処理がそう多くないから、そういうコードを書けるプログラマも限られます。うーんと、本当にマルチスレッドの並列プログラムをやったことあります？
＞スレッド間同期のオーバーヘッドでかえって遅くなることも珍しくないため、マルチスレッド化で＞体感できるほど速くなるアプリケーションってけっこう限られてます。
は事実だけど、たとえ早くなる処理でさえも並レベルの分かってないプログラマが書くと「スレッド間同期のオーバーヘッドでかえって遅くなる」だけでなく、アルゴリズムや設計が逐次処理とは異なるとか、デバッグが死ぬほど難しいとかにより、マルチスレッドのプログラミングは難易度がもの凄く高いんですよね。
もしプログラミングが簡単だったら実測で２～３割早いだけでもマルチスレッド化するかもしれないけれど、実際には難易度がとてつもなく高いので、最低でも２～３倍速くなって体感速度ではっきり分かるくらいでないと、マルチスレッド化／並列化という選択は採算が合わないのです。
そういう意味ではクワッドコアでもまだまだですね。最大でもたったの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の概念も抽象化され隠蔽されていき、意識せず使うことができる、という方向だと思いますよ。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
一つのことを行い、またそれをうまくやるプログラムを書け -- Malcolm Douglas McIlroy
それ以前に (スコア:1, 興味深い)
X3とX4て（ベンチじゃなく）実際の動作速度でいかほど違うんでしょうか。
アーキテクチャが複雑になりすぎて「結局どのくらい速いの」ということが
把握できなくなってきてます＜自分。
Re: (スコア:3, すばらしい洞察)
よって普通に使っている分にはクロック分の速さしか体感できないですよ。
Re:それ以前に (スコア:0)
早くするための技術じゃなくて遅くならなくするための技術。
遅くならないのは事実としても、「そのための技術」ってのは今時どうなんですかね。
マルチスレッドなアプリってまだそんなに特殊？
Re:それ以前に (スコア:1, 興味深い)
今時だからこそ有効な技術ですよ。バックグラウンドで数十のプロセスが常に動いている今時のOSであればこそ、です。
存在が特殊というか、マルチスレッド化して労力に見合った速度になるケースが意外に少ないというのがあるのではないかと。
Re:それ以前に (スコア:1)
＞マルチスレッド化して労力に見合った速度になるケースが意外に少ないというのがあるのではないかと。
マルチスレッド化による速度向上に比べ、マルチスレッドアプリを作るための
「労力が高く付きすぎる」というのが大きいんではないかと。そもそもマルチ
スレッドでプログラムを書けないプログラマの方が断然多いし。よってPCだと複数
アプリ同時起動（つまりマルチプロセス）がメインになるんでしょう。
やたらでかいアプリをフルビルドしながら、同時に暇潰しにニコ動を見て、
ついでにスラドに書き込みするというような贅沢な職場環境なら、CPUコアと
ディスプレイは多いに越したことはないと思います。
Re:それ以前に (スコア:2, 興味深い)
＞「労力が高く付きすぎる」というのが大きいんではないかと。
それもありますが、大きな理由はむしろ「たいして速くならない」からですよ。
「1:9の法則」(プログラムコードの1割が処理時間の9割を消費する)という経験則があるように、手を入れることで目に見えて速度が向上する部分はごく一部です。この部分がマルチスレッド化でスピードアップできるような処理でなければほとんど無意味ということです。
スレッド間同期のオーバーヘッドでかえって遅くなることも珍しくないため、マルチスレッド化で体感できるほど速くなるアプリケーションってけっこう限られてます。
非同期処理を並列実行するコードを簡潔に書くためのマルチスレッド化する場合もありますが、この場合は単に待ち時間を減らしたりしているだけなのでマルチコアになってもそんなにスピードは変わりません。
＞マルチスレッドでプログラムを書けないプログラマの方が断然多いし。
これも当然。
マルチスレッドの恩恵を受けられない分野ならマルチスレッドでプログラムする需要がありません。
マルチスレッド化が有効な処理がそう多くないから、そういうコードを書けるプログラマも限られます。
うじゃうじゃ
Re:それ以前に (スコア:2)
＞マルチスレッド化が有効な処理がそう多くないから、そういうコードを書けるプログラマも限られます。
うーんと、本当にマルチスレッドの並列プログラムをやったことあります？
＞スレッド間同期のオーバーヘッドでかえって遅くなることも珍しくないため、マルチスレッド化で
＞体感できるほど速くなるアプリケーションってけっこう限られてます。
は事実だけど、たとえ早くなる処理でさえも並レベルの分かってないプログラマが
書くと「スレッド間同期のオーバーヘッドでかえって遅くなる」だけでなく、
アルゴリズムや設計が逐次処理とは異なるとか、デバッグが死ぬほど難しいとかに
より、マルチスレッドのプログラミングは難易度がもの凄く高いんですよね。
もしプログラミングが簡単だったら実測で２～３割早いだけでもマルチスレッド化する
かもしれないけれど、実際には難易度がとてつもなく高いので、最低でも２～３倍速く
なって体感速度ではっきり分かるくらいでないと、マルチスレッド化／並列化という
選択は採算が合わないのです。
そういう意味ではクワッドコアでもまだまだですね。最大でもたったの4倍
（とちょっと）にしかならないのですから。並列処理が大きく意味を持つようになる
には、コア数が16とか32とかくらいにならないと難しいのでは。
あと
＞「1:9の法則」(プログラムコードの1割が処理時間の9割を消費する)という経験則が
＞あるように、手を入れることで目に見えて速度が向上する部分はごく一部です。
この部分の9割とか1割は、この議論にはあんまり関係ないですね。
「その9割を占める1割の部分は、並列化しにくいことが知られている」
などという結論には繋がってないわけですから。
それに実際には1割になってくれてる方が楽です。運が良ければ全体の1割を書き
換えるだけで、全体を2倍～3倍に高速化することも不可能ではないのですから。
「運が良くても悪くても、全部書き換えないと性能が上がらない」よりはずっと
楽です。
Re: (スコア:0)
6コア構成でハイパースレッティング使って12並列処理できますから。
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＋開発ツール位しか使わないので、うれしいアプリはあまり思い
浮かばないですね
＃しいて言えば、エンコくらいかｗ
体感ですが 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の概念も抽象化され隠蔽されていき、意識せず使うことができる、という方向だと思いますよ。