24/09/15 15:00:56.64 .net
>>62
商用UNIXおじさん出たーー
確かにlinuxは別
81:
24/09/15 18:20:56.94 .net
今UNIX本筋はLinuxとAndroidとmacOSとiOS
4つもあってどれか持ってる人が多いんだから普及したもんだ
82:名無しさん＠お腹いっぱい。
24/09/15 19:36:06.38 .net
ほぼ死にかけのHP-UXやSolarisはともかく、
今やUnixと言えばAIXだと思うのだが、
パチモンが先に出てくるこの世の中よ...
83:
24/09/16 04:57:23.13 .net
もうAIXだけだもんな
SUS V7適合は
84:名無しさん＠お腹いっぱい。
24/09/18 10:02:47.56 .net
>>41
いやItaniumは命令またいで並列性記述で、後はそれぞれ実装の中でユニットの限り並列に実行するという発想だったんよ
実行ユニットが倍増でもしない限り一度のコンパイルでOKの予定だった
x86の資産が使える方がいいのはその通りだけど
ただ時代も変わってCPUアーキテクチャの種類の重要度落ちたし、ARMがこれだけ発展したなら、x86がなくなってもおかしくはかいかもね
x86にも旧命令を残しつつ、より新しくてスケジュール効率の良い命令も実装してそちらに徐々に入れ替えていこうという構想もあるみたいだけど
85:
24/09/18 10:59:52.07 .net
VLIWってのは凄く原始的なアイデアで
SIMD並列のCPU内部版なわけだけど
古いコンピューター・アーキテクチャが前提になってる
メモリアクセスのコストが一定の前提
現在は計算ユニットとメモリの間には多段のキャッシュがある
だからメモリアクセスコストは実行時にしかわからない
そして一番遅かったのに合わせてしか命令を捌けない
動的スケジューリング以外生き残れないなんて
インテルの技術者はほぼ全員分かっていたと思うが
RISCでさえそうなんだってi960とかの経験で知ってたし
少し前までのマイクロソフトと一緒で社内闘争が激しすぎた
勝ち残ったプロジェクトリーダーは大儲けだから
それを是正出来なかったから会社が凋落するわけだよね
もちろんまだチャンスはある会社だとは思うが
86:名無しさん＠お腹いっぱい。
24/09/22 14:18:59.42 .net
今後のコンピューティング需要はAIが主体だし古いアーキなんてガンガン捨てられる
インテルは相当危機感持ってるよ
87:
24/09/22 15:37:57.87 .net
RISCで負けて
x64で負けて
GPUで負けて
ARM部門は売却済み
全部戦略ミス
88:名無しさん＠お腹いっぱい。
24/09/24 17:27:52.86 .net
>>85
メモリアクセスでキャッシュから外れていたらその時点で例外発生して他のプロセスにスイッチだから、メインメモリへのアクセスが速いか遅いかで全体のパフォーマンスへの影響は無いに等しいよ
(もちろんメモリの速度はトータルのスループットには影響するかもしれないが、スケジューリングが動的か静的かは関係無い)
命令の並列度なんて上限はたかが知れてるし今後もそんなに増えないから、ItaniumのEPIC(VLIW)が順調に進化していたら、デコードコスト低いメリットが活かされていくことになっていただろうねぇ
まあx86の巨大市場の前に技術的な優位性関係なく消えていったが
89:名無しさん＠お腹いっぱい。
24/09/27 21:07:56.24 .net
また0からやり直そう
POSIXから捨てよう
90:
24/09/28 11:48:05.97 .net
>>88
CPU内キャッシュがヒットしないくらいで
プロセス切り替えなんて発生しませんけど
91:名無しさん＠お腹いっぱい。
24/09/28 13:02:58.36 .net
キャッシュミスでコンテキストスイッチみたいな重たい処理動かしてたら
無茶苦茶遅くなりそう...
92:名無しさん＠お腹いっぱい。
24/09/28 14:36:20.31 .net
なるほど、すぐ諦めずちょっと待つという話ですよね
そのへんのタスクスケジューリングのリアルな知見ってどうやって勉強したらよいのやらです。OSを自分で作ってみよう系のムック本とかですかね？
情処エンベデッドにも問題出てくるけど、SES業態でそんなの勉強できる案件ないよトホホ
93:名無しさん＠お腹いっぱい。
24/09/28 14:44:42.95 .net
普通のアプリ作ってるだけでもそういう話に触れると思うけどなあ
例えばWindowsのGUIだって、GUI側で黙って待ってても処理進まないから
sleep(0)でコンテキスト返却するとかバッドノウハウ的な部分だってあるし
そしたらいつコンテキスト取り上げられるんだろう？とか関連APIの説明を読むとか
OSの中身にまで踏み入らなくてもしれる部分はいくらでもある
94:名無しさん＠お腹いっぱい。
24/09/28 15:17:21.36 .net
まあ、そうです…まさに、自分はアプリを作る中で触れてきました
ip通信デーモンを作る仕事を繰り返す中で、
クソ遅かった実装パターンと速く動いた実装パターンとで比較して、自分なりの勝ち筋を見いだした、けど、その知見で次の職場で速いコードを書いても、他人には全く理解してもらえず苦労したんです
自分は実際の職務経験から、select系apiでシングルスレッドでのイベント・ドリブン型、協調型マルチタスクでないと速く動かない！マルチスレッドは全然ダメだ！と結論したけど
そのプログラミングモデルは理解がしやすいと言えないので、他人から「なんでそんな難しく作っちゃうの」的に批判されて、マルチスレッド型で全部作り直したい、とか低評価された
95:名無しさん＠お腹いっぱい。
24/09/28 15:21:10.14 .net
あと私は「アプリ」のプログラミング インタフェース（API）の仕様に、OSのスケジューラがコンテキストスイッチを起こすか起こさないかを、もし書いてたら、書きすぎでメンテ性が低下するバッド仕事だと思います
だから（api 仕には書いてないから）「自分ならOSをこう作るな」と想像したり、試作して比較して多分こう、ていう不確かな知見になって、他人に「それお前の勝手な推測だろ」って言われる訳です
96:
24/09/29 09:50:42.44 .net
>>92
英語だけど
Understanding Linux real-time with PREEMPT_RT training - Bootlin
URLﾘﾝｸ(bootlin.com)
古典的ではない排他プリミティブ
URLﾘﾝｸ(ja.m.wikipedia.org)
CPU内の動的スケジューリング
Lecture 18: Instruction Level Parallelism -- Dynamic Scheduling, Multiple Issue, and Speculation
URLﾘﾝｸ(passlab.github.io)
97:名無しさん＠お腹いっぱい。
24/09/29 10:11:46.31 .net
>>96
ありがとうございます。
CAS命令LLSC命令は前の現場でソース読んでたら出てきて、なんじゃこりゃ？ってなって勉強した記憶があり。少し思い出して来ました
pdfの資料は…時間作って読んでみます。貴重な情報ありがとうございます
98:名無しさん＠お腹いっぱい。
24/10/04 07:02:57.73 .net
Garuda Linux
URLﾘﾝｸ(garudalinux.org)
Garuda Linuxとは？美しいデザインとパフォーマンスに優れた Arch ベースの Linux ディストリビューション
URLﾘﾝｸ(pc-freedom.net)
Garuda Linux プロジェクト日本語トップページ - OSDN
URLﾘﾝｸ(ja.osdn.net)
Garuda Linux をインストールする
URLﾘﾝｸ(zenn.dev)
Garuda Linux は美しいネオンの外観で手間のかからない Arch エクスペリエンスを提供します [ビデオ付きレビュー]
URLﾘﾝｸ(ja.linux-console.net)
【Garuda Linux】おしゃれな外観のLinuxディストリビューション
URLﾘﾝｸ(note.activetk.jp)
99:
24/10/04 12:09:32.29 .net
>>97
ヘネシー・パターソンは読んだんかな
最新まで邦訳されてんのかどうか
preemptinessが必要ないかあまり重要でなければ
自らyiledしてCPUを手放すのは効率がいい
Xorgサーバもそうなっている(使ってるのはselect)
100:名無しさん＠お腹いっぱい。
24/10/04 18:57:41.76 .net
>>99
あざす
ヘネパタって奴ですね、未読です
自分も select 系のAPIを使って、アプリ内の各タスクが細切れのタスクを実行し、自分でcpuを離す方式、で、成功体験が多数あります。まさにXのメインループと同じ方式の認識です
この方式だとどこかがバグって無限ループすると（プリエンプトがないので）他のタスクに制御が行かなくて詰むのだけど、経験上一番速く、cpuがグルングルンに回る