はてなキーワード: コンテキストスイッチとは
買い物は帰りに寄るだけだから大した手間ではない
お前はそうかもしれないが全員がそうなわけじゃない。
個人的には他のこと考えてるのにいちいちコンテキストスイッチが入ると非効率。
それは好みの問題。
見出しはこれ http://anond.hatelabo.jp/20121219191602
http://toro.2ch.net/test/read.cgi/unix/1288765389/232
232 :名無しさん@お腹いっぱい。:2012/03/25(日) 15:05:26.72 今月はじめ、職場に新しいPC(Pentium4の結構ハイエンド構成)が入りました。 多分私が運用保守をまかされそうな雰囲気です。業務的にとある構造分析や シミュレーションなど行う必要がありOSにオープン系を採用するのは 聞いていたのですが、搬入されたPCのダンホール箱に乗っかっていたのは UNIXのインストールパッケージでした。 「うへぇ~、よりによってUNIXかよ」 デバイスドライバがない、コマンドが変・オプションがない、X環境が古い、 今の奴は日本語入力大丈夫なのか(Wnn/Canna/kinput2)、将来の64bit移行はどうなのか、 今時のネットで必須のflashのプラグインは存在するのか不安はつきませんし、 非メジャーなのでネット上の情報も少なく調べるのも大変です。 おそらく導入に際して、大学など教育機関で最初にそれに触れて刷りこまれた人間が 強気の知ったかぶりをして発言権を得て「俺流」をつらぬき紛れ込ませたのでしょう。 昔、当時、唯一CADなどのエンジニアリング環境が充実していたUNIXは大学など 教育機関に浸透していて、日本のUNIX界に多くのバカを輩出しました。 これから私は、おそらくそういうバカが、makeしてもemacsが入らない、 TeXが入らない、コンソールでEUCは使えないのか、Rubyが使えないのかなどと、 サバ管気取りの偏ったどうでもいい我侭を言い出し、(だから鯖にするんじゃねーよ、 鯖の常識で話すなつーのに)それと戦わなければならないのでしょう。 そして時代によって決着している、過去10年のUNIX界隈のくだらないそれらの議論が 再現され、それに巻き込まれるのでしょう。もう今からうんざりです。 だからお願いです。教育現場ではPlamoでもDebianでもRedHatでもKondaraでも Slackwareでもなんでもいいですがメジャーかつ現行のLinuxにしてください。 教育機関で懐古趣味のバカを量産されると現場が非常に苦労するのです。
http://toro.2ch.net/test/read.cgi/unix/1355909018/4
4 :名無しさん@お腹いっぱい。:2012/12/19(水) 18:44:07.79 今月はじめ、職場に新しいPC(Core i7の結構ハイエンド構成)が入りました。 多分私が運用保守をまかされそうな雰囲気です。業務的にとある構造分析や シミュレーションなど行う必要があり、複数マシンでファイルを共有するのは 聞いていたのですが、起動したマシンの/etc/fstabの項目に書かれていたのは nfsという文字でした。 「うへぇ~、よりによってNFSかよ」 ファイルロックすると刺さる、ファイルを消したのに.nfsXXXが残る、 今の奴はACL大丈夫なのか、ファイルのCapabilityに対応してるのか、 今時のLAN上で使ってもセキュリティは大丈夫なのか不安はつきませんし、 ユーザーが減ってるのでネット上の情報も少なく調べるのも大変です。 おそらく導入に際して、大学など教育機関で最初にそれに触れてすりこまれた人間が 強気の知ったかぶりをして発言権を得て「俺流」をつらぬき紛れ込ませたのでしょう。 昔、当時、唯一ローカルディスクかネットワーク上かの区別なく透過的にファイルに アクセスできたNFSは大学など教育機関に浸透していて、日本のストレージ界に 多くのバカが輩出しました。 これから私は、おそらくそういうバカが、ファイルに書き込んだら所有者がnobodyに なっちゃったよとか、タイムスタンプがずれるよとか、NFSv4にしたらマウント できなくなったよとか、TCPよりUDPの方がオーバーヘッドが無い分速いはずだよね などと、鯖管気取りの偏ったどうでもいい我侭を言いだし、 (だからNFS鯖にするんじゃねーよ)それと戦わなければならないのでしょう。 そして時代によって決着している、過去25年のNFS界隈のくだらないそれらの議論が 再現され、それに巻き込まれるのでしょう。もう今からうんざりです。 だからお願いです。教育現場ではSambaでもNetatalkでもFTPでもなんでもいいですが 安定してユーザーが多いファイル共有システムにしてください。 教育機関で懐古趣味のバカを量産されると現場が非常に苦労するのです。
http://toro.2ch.net/test/read.cgi/unix/1351627596/3
3 :名無しさん@お腹いっぱい。:2012/10/31(水) 10:57:28.82 今月はじめ、職場に新しいPC(Core i7の結構ハイエンド構成)が入りました。 多分私が運用保守をまかされそうな雰囲気です。業務的にとある構造分析や シミュレーションなど行う必要がありOSに*BSDを採用するのは聞いていたのですが、 搬入されたPCのダンホール箱に乗っかっていたのはFreeBSDのインストールパッケージ でした。 「うへぇ~、よりによってFreeBSDかよ」 カーネルが変、日本語環境がない、ソフトが変・揃ってない、今の奴は 日本語文字コード大丈夫なのか(utf-8)、x86_64環境は大丈夫なのか、 今時のネットに繋いでもセキュリティは大丈夫なのか不安はつきませんし、 非メジャーなのでネット上の情報も少なく調べるのも大変です。 おそらく導入に際して、大学など教育機関で最初にそれに触れてすりこまれた人間が 強気の知ったかぶりをして発言権を得て「俺流」をつらぬき紛れ込ませたのでしょう。 昔、当時、唯一PC98環境が充実していたFreeBSDは大学など教育機関に浸透していて、 日本のFreeBSD界に多くのバカが輩出しました。 これから私は、おそらくそういうバカが、ポーツ(笑)でemacsが入らない、 TeXが入らない、コンソールでEUCは使えないのか、Rubyが使えないのかとかなどと、 鯖管気取りの偏ったどうでもいい我侭をいいだし、(だから鯖にするんじゃねーよ、 鯖の常識で話すなつーのに)それと戦わなければならないのでしょう。 そして時代によって決着している、過去20年のFreeBSD界隈のくだらないそれらの議論が 再現され、それに巻き込まれるのでしょう。もう今からうんざりです。 だからお願いです。教育現場ではUbuntuでもdebianでもFedoraでもRHELでも OpenSUSEでもなんでもいいですがメジャーかつ現行のLinuxにしてください。 教育機関で懐古趣味のバカを量産されると現場が非常に苦労するのです。
http://toro.2ch.net/test/read.cgi/unix/1209056071/887
887 :名無しさん@お腹いっぱい。:2012/10/21(日) 11:56:55.61 今月はじめ、職場に新しい組み込みマシン(ファン付きだけど結構省スペース構成)が 入りました。多分私が開発全般をまかされそうな雰囲気です。業務的にとある 構造分析やシミュレーションなど行う必要があり、プログラムにアセンブラを 使用するのは聞いていたのですが、添付のサンプルソースコードからチラッと 見えたのはsethi %hi(hoge),%o0という命令でした。 「うへぇ~、よりによってSPARCかよ」 長くなるバイナリーコード、奇数アドレスワードアクセス不可、使いにくい レジスタウィンドウ、今時の素早いコンテキストスイッチに対応できるのか不安は つきませんし、今の若者はこんなCPU使わないので人材も少なくソフト開発も大変です。 おそらく導入に際して、大学など教育機関で最初にSPARCに触れて刷りこまれた人間が 強気の知ったかぶりをして発言権を得て「俺流」をつらぬき紛れ込ませたのでしょう。 昔、当時、32bitCPUでRISCでM68K系よりも高速で動作したSPARCは 大学など教育機関に浸透していて、日本のCPU界に多くのバカが輩出しました。 これから私は、おそらくそういうバカが、16bitイミーディエイト値すら1命令でロード できかないのかよとか、関数呼出しのたびになんで約100バイトもスタックフレームが 要るんだよとか、フラグレジスタの読み出しがなんで特権命令なんだよとか、 %g0ってレジスタ値変わらないし壊れてるよ、初期不良で交換だよとか、 アセンブラ通気取りの偏ったどうでもいい我侭を言い出し(だからSPARC使うんじゃ ねーよ) それと戦わなければならないのでしょう。そして時代によって決着している、 過去25年のCPU界隈のくだらないそれらの議論が再現され、それに巻き込まれるの でしょう。もう今からうんざりです。 だからお願いです。教育現場ではi386でもi568でもi686でも x86_64でもなんでもいいですが現行のCPUにしてください。 教育機関で懐古趣味のバカを量産されると現場が非常に苦労するのです。
わからんけど、グラヒクスと音声は リップシンクがあるから必ずしも別じゃないし
そもそも、音声を鳴らすチップ自体が独立したコアみたいなもんだからなぁ・・・
ネットワークチップだって独立したチップのやつは 別のコアみたいなもんだぜ?
話はずれたけど、まともなマルチコア向けプログラムを書くとなると、いわゆる1スレッド1役割みたいな処理は欠かずに
タスクシステムとか、スレッドの役割分担システムみたいなものを自分で書き下ろして、いわゆるマルチファイバーというか、マルチタスク的なシステムで
組んでいくから、(マルチタスクを自前で組むことが必ずしも高速化ではなくて、いくつもノウハウがあるけど) あまり、セマフォというかミューテックスを意識することは少ないよ?
たとえば、ちょっと違うけど 通信が一万本合ったら、1万スレッド起こすのか?起こさないというのと同じかなぁ。
逆に言うと1つのタスク中に入りと出以外に何箇所もロックしたり、開放したりするシステムはコンテキストスイッチの考え方からあまりよくない。
リソースになるべく触らない、触ったらローカルメモリーに移しておく、なるべく長い時間1つのスレッドを走らせる。リソースに触るときは処理終了して次のタスクにしてしまう。
などなど、そんな感じ。 スレッドに役割を振り分ける というよりは、タスクで回していくという感じ。
もちろん、長々走るものもあるだろうけど。
http://d.hatena.ne.jp/faith_and_brave/20100220/1266673222
まず第一にエンタープライズでの開発が考慮されていない。エンタープライズの開発だと100人200人 マスタークラスから ジュニアーまで様々なレベルの開発者が携わる。
その中で重要になってくるのは可読性。
はっきり言って、歴史的な可読性を犠牲にして効率が上がるならともかく、気持ちの問題程度の効率では意味がない。
第2に
スレッドとファイバーの違いぐらいわかれ、わざわざスレッド起こしたらコンテキストスイッチにどれだけコスト食うんだよ。
関数コールするとレジスタとかが、スタックにPUSHされるんだよってわからん奴が、IF書くなと同じで、スレッドってコンテキストスイッチの塊なんだよってのがわかんないのに下手にスレッド書かせるな。
3にラムダ式・・・いらん・・・必要なのは曲芸じゃない、可読性。可読性を犠牲にして早くなるならともかく・・・
4にforeachではlastを変数に取るな。途中でReallocしたり、eraseしたりしたときに余計なバグを生んで面倒だ。レビューの時も邪魔。速度?速度が必要な背景でSTLのVector使うな。配列使うかポインタ使え。
なんつーか、トータルで見て、次はC++と各種OpenCLとかGLとかのライブラリの集合だな。C++0xはまともに使う人もいなさそう。正規表現とかもライブラリ使えば良いし、そもそもC系列ならBisonとかLRとかだろうと。C系列の使い手ならBNFを使え。正規表現使いたければそれこそ、Perl使え。