アカウント名:
パスワード:
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さんもそんなに異論はないのでは？
私は別にマルチスレッドプログラミングの難易度が高いことを否定したつもりはありません。それとは別に並列化によって速度向上を期待できるシチュエーションが限られていて、そのため並列化のスキルを身に着けても活かせる場面が限られていることも、並列化のプログラミングコストがなかなか下がらない要因として大きいということが言いたかったのです。もっと幅広く効果が期待できるものであれば、本質的に避けられない複雑さはあるにしてももうちょっとハードルは下がったんじゃないかなと思うわけです。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
最初のバージョンは常に打ち捨てられる。
それ以前に (スコア: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さんもそんなに異論はないのでは？
私は別にマルチスレッドプログラミングの難易度が高いことを否定したつもりはありません。
それとは別に並列化によって速度向上を期待できるシチュエーションが限られていて、そのため並列化のスキルを身に着けても活かせる場面が限られていることも、並列化のプログラミングコストがなかなか下がらない要因として大きいということが言いたかったのです。
もっと幅広く効果が期待できるものであれば、本質的に避けられない複雑さはあるにしてももうちょっとハードルは下がったんじゃないかなと思うわけです。
うじゃうじゃ