CPUのハードウェアスレッド数が増大する実装を妄想してみる

CPUはマルチコアに進むといいながらも、まだCore i7みたいなハイエンドでも8コア16スレッドとかで止まっていて、もうちょっと何とかならないかって感じ。例えばUnix like osで「ps aux」かけたときに出るプロセス数は3桁行っていて(で、いいんだよな？)、ほんとならばこれそれぞれにスレッドが割り当てられていた方が少なくともコンテキストスイッチにかかるコストは少なくなるはずです。ちなみに、ハードウェア側でスレッドを実装する(コアそのものが増えてもいいし、HTみたいな方法でもいいんですが)際にスレッドのプライオリティに意味が出てくるかどうかは実は謎だったりして。ハードウェアが均等に割り当てるのならプライオリティ無くても困らないような気が。少なくともマルチコアCPUのそれぞれのコアはnice値のような方法でプライオリティ管理はしてないはずなので、スレッド側がきちんと割り込み受付から応答までの時間を保証できれば別にそれ以上のことは求めなくてもいいような気も。
本当に何百もコアを用意するのは意味がなさそうなので、やるとしたらレジスタセットをスレッド数分用意して、演算装置自体は10程度で、これらを自動的に切り替えながら進めるHTみたいな方法論が現実的なんだろうな。レジスタ(SRAMだろうなぁ)を数百用意すること自体は今の一次キャッシュの延長線上でさほど難しくなさげなので、今のCore iシリーズやPowerPCみたいに「コア1つに付きハードウェアスレッド2つ」とかいう実装じゃなくてもいい気が。
だと、OSの実装は大変シンプルになりますね。少なくともTSSの機構自体はOSが持つ必要はないですし、プライオリティの考え方も少し違ったものになります。スレッドの生成を動的にできるようにしないと意味がないので、今の命令セットそのままでは動かせられませんが。
あと、ボトルネックの位置が微妙に今のシステムとは変わってくるかも。結局記憶装置のレイヤーによって速度が変わってくるという所は変わらないので、だったら単一レベル記憶にしちゃってキャッシュの存在やディスクの存在をCPUの命令セット的に意識しない方がいいのかな。UnixやWindowsという既存システムというよりは、Java/CLRがそのまま動く何かみたいな感じになる気がします。