アカウント名:
パスワード:
この主な原因は、priorityを引き上げたprocessがすぐにscheduleされないことにあります。となると、対策としてはcpuよりもむしろkernelの改良になります。具体的には、preemptive kernelやpriority inversionの防止などになります。
が、これがマトモにできているのはSolarisぐらいしか思いつきません。追い付かなければならないのはわかっていますが...
それも一因とは思いますけど、根本的な原因はむしろGUI設計者のポリシだと 思います。結局、レスポンスというのはCPU性能とUIの機能とのトレードオフ で決まるものですから、一番効いてくるのはGUI設計者がバランス点をどこに 見出すかでしょう。
それでどうも、世のGUI設計者は、常に快適なレスポンスから二三歩後退し た位置にバランス点を見出す気がするのです。まあ、CPUが速くなったら いろんな機能を付けてみたくなる、という気持ちは分かりますけどね。 GUI設計者にはぜひロースペックなマシンで開発してもらいたいものです。
> これがマトモにできているのはSolarisぐらいしか思いつきません。 > 追い付かなければならないのはわかっていますが...
Solarisって、負荷や並列度が高かったりするときにはいいOSですね。 (というか、他のOSはハイエンドユースでの経験値が少ないというか…) ところで、オフトピ気味ですが、ここで追いつかなければならないのは誰(ど のOS)でしょう?
ところで、オフトピ気味ですが、ここで追いつかなければならないのは誰(どのOS)でしょう?
書きわすれてました。Solaris以外のUnix-likeなOS全てです。大抵はkernelに入ると出てくるまでcpuを使いっぱなしになってしまいます。一部realtime向けUnixもあったりしますが、applicationは限定されてしまいます。TSSとrealtimeを同居させるのはSolarisの得意技。
個人的には自分で手を加えられるFreeBSDですが、それに限った話ではないということで。
そう言えば, SolarisではありませんがSVR4.2ベースのマシンで32MBしかメモリが無かったころに, Xのレスポンスを少しでも上げるためにリアルタイムプロセス(実際には固定プライオリティなだけだけど)にして動かしていました. MIPS R4000という貧弱な環境でしたが, 少しは効果が有ったように思います.
常に快適なレスポンスから二三歩後退した位置にバランス点を見出す気がする
理由はいくつかあると思います。
理由はいくつかあると思います。 開発者が速いマシンを使いすぎ。
さすがに遅いマシンだと開発作業のロスが大変なので(ほら、「プログラマとか [srad.jp] デザイナとか入出力をもっぱらにする者にとっては、UIに求めるもの としてはやはりレスポンスです。
こいつって、priority inversion対策はやっているんでしょうか? だいぶ前の記憶(2.4.1ぐらい)ですが、調べたらownerをtrackするようなlock primitiveがありませんでした(といってもshared-exclusiveやsemaphoreになるともはや近似的にしか扱えないが)。dispatch delayの分散はどんなもんなんでしょう?
あと、lock breakingというのはSVR4/MPと似たような問題を抱えていないでしょうか?
ちなみにFreeBSD-currentの方でも、preemptionはすでに有効になっています(i386とalphaで確認、他は不明)。なおかつ、system call共通部の全てと一部のsemanticsについてGiantがとれています。lock primitiveはSolarisとほぼ等価(adaptive lockは現在実装中)。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
開いた括弧は必ず閉じる -- あるプログラマー
レスポンス (スコア:3, すばらしい洞察)
るものとしてはやはりレスポンスです。人間が感じられないギリギリまでは遅
くても全然構わないのですが、さすがにコンマ何秒や数秒も待たされると思考
が中断されてイラつきます。
CPUの性能はどんどん上がっているのに、常に微妙にイラつくぐらいのCP
Re:レスポンス (スコア:1)
この主な原因は、priorityを引き上げたprocessがすぐにscheduleされないことにあります。となると、対策としてはcpuよりもむしろkernelの改良になります。具体的には、preemptive kernelやpriority inversionの防止などになります。
が、これがマトモにできているのはSolarisぐらいしか思いつきません。追い付かなければならないのはわかっていますが...
Re:レスポンス (スコア:2, すばらしい洞察)
それも一因とは思いますけど、根本的な原因はむしろGUI設計者のポリシだと 思います。結局、レスポンスというのはCPU性能とUIの機能とのトレードオフ で決まるものですから、一番効いてくるのはGUI設計者がバランス点をどこに 見出すかでしょう。
それでどうも、世のGUI設計者は、常に快適なレスポンスから二三歩後退し た位置にバランス点を見出す気がするのです。まあ、CPUが速くなったら いろんな機能を付けてみたくなる、という気持ちは分かりますけどね。 GUI設計者にはぜひロースペックなマシンで開発してもらいたいものです。
> これがマトモにできているのはSolarisぐらいしか思いつきません。
> 追い付かなければならないのはわかっていますが...
Solarisって、負荷や並列度が高かったりするときにはいいOSですね。 (というか、他のOSはハイエンドユースでの経験値が少ないというか…)
ところで、オフトピ気味ですが、ここで追いつかなければならないのは誰(ど のOS)でしょう?
Re:レスポンス (スコア:2, 参考になる)
書きわすれてました。Solaris以外のUnix-likeなOS全てです。大抵はkernelに入ると出てくるまでcpuを使いっぱなしになってしまいます。一部realtime向けUnixもあったりしますが、applicationは限定されてしまいます。TSSとrealtimeを同居させるのはSolarisの得意技。
個人的には自分で手を加えられるFreeBSDですが、それに限った話ではないということで。
Re:レスポンス (スコア:1)
そう言えば, SolarisではありませんがSVR4.2ベースのマシンで32MBしかメモリが無かったころに, Xのレスポンスを少しでも上げるためにリアルタイムプロセス(実際には固定プライオリティなだけだけど)にして動かしていました. MIPS R4000という貧弱な環境でしたが, 少しは効果が有ったように思います.
Re:レスポンス (スコア:2, 興味深い)
理由はいくつかあると思います。
なるほど。 (スコア:1)
------
世界は狭いし唯1つだよ 仲良くしようぜ基地外どもゆ?
個人情報の秘匿WA破滅eNO第一歩也。
Re:レスポンス (スコア:0)
さすがに遅いマシンだと開発作業のロスが大変なので(ほら、「プログラマとか [srad.jp]
デザイナとか入出力をもっぱらにする者にとっては、UIに求めるもの
としてはやはりレスポンスです。
Re:レスポンス (スコア:2, 参考になる)
http://www.tech9.net/rml/linux/ [tech9.net]
完全にまともと言えるかどうかはともかく、まぁ動くしアプリケーションによっては目に見えるレベルの改善がはかれます。
Re:レスポンス (スコア:1)
こいつって、priority inversion対策はやっているんでしょうか? だいぶ前の記憶(2.4.1ぐらい)ですが、調べたらownerをtrackするようなlock primitiveがありませんでした(といってもshared-exclusiveやsemaphoreになるともはや近似的にしか扱えないが)。dispatch delayの分散はどんなもんなんでしょう?
あと、lock breakingというのはSVR4/MPと似たような問題を抱えていないでしょうか?
ちなみにFreeBSD-currentの方でも、preemptionはすでに有効になっています(i386とalphaで確認、他は不明)。なおかつ、system call共通部の全てと一部のsemanticsについてGiantがとれています。lock primitiveはSolarisとほぼ等価(adaptive lockは現在実装中)。