  |
はてなキーワード: CPUとは
C++は、現在でも世界で最も高速な部類に入るプログラミング言語です。2025年時点でも、高いパフォーマンス、低レイテンシ、細かいハードウェア制御が要求される分野（ゲーム開発、高頻度取引、組み込みシステムなど）において、依然として最高レベルのパフォーマンスを提供し続けています。
1. なぜC++が「最も速い」と言われるのか
機械語への近い変換: C++はコンパイラ言語であり、ソースコードが非常に効率的なネイティブ機械語に直接変換されるため、中間ランタイムが存在せず高速に動作します。
手動メモリ管理: ガベージコレクション（GC）がないため、自動メモリ解放による突発的な遅延が発生せず、決定論的なレイテンシ（安定した速度）を実現します。
ゼロコスト抽象化: 高度な抽象化（オブジェクト指向など）を用いても、パフォーマンスのオーバーヘッドがほぼかからないように設計されています。
ハードウェアへの直接アクセス: ポインタやSIMD（Single Instruction, Multiple Data）命令など、CPUの能力を最大限に引き出す低レベルな操作が可能です。
C言語: C++の基盤であり、同等の速度を持っています。C++は抽象化能力が高いため、同等のパフォーマンスを保ったまま複雑なアプリケーションを記述しやすいです。
Rust: 近年C++の最大のライバルです。多くのベンチマークでC++と同等の速度を示し、安全性を保証しながらC++を凌駕するケースもあります。
Go/Java/C#: GC（ガベージコレクション）を持つため、メモリ負荷が高いタスクではC++やRustに遅れを取る傾向がありますが、開発速度や並行処理には強みがあります。
Python/JS: インタプリタ言語であり、C++に比べて実行速度は非常に遅いです。
必ず速いわけではない: C++は速い「言語」ですが、非効率なコードを書けば遅くなります。高速化にはコンパイラの最適化設定や、高度な最適化テクニック（メモリアクセス最適化など）の知識が必要です。
安全性のトレードオフ: 手動メモリ管理は高速ですが、バグ（メモリーリークなど）が起きやすく、パフォーマンスを高めるために安全性を犠牲にする場合があります。
C++は極限のパフォーマンス（最高速度）を求めるなら依然として最強の選択肢の一つです。しかし、Rustのようなモダンで安全な言語も台頭しており、用途に合わせて選ぶのが現代的なアプローチです。
https://b.hatena.ne.jp/entry/s/xenospectrum.com/toyota-fluorite-flutter-game-engine-digital-cockpit/
一人でもいたら要注意。IT業界の面接官はユキビタス脳波盗聴装置を使って、不特定多数が相手のことを好いているか嫌っているかをリアルタイムでスキャンしてきます。
内容に関わらず、できる限り恨みは買わないのが得策です。また恨まれていることが発覚した場合、たとえそれが逆恨みであっても「相手の気持ちが正しかった可能性」を最大限尊重し、即座に寄り添い無念を晴らすべきです。
面接直後までの間に、過去に関係した全員（小学校のクラスメイト、通学路の犬、インターネット上の匿名アイコン含む）と和解しておけばセーフです。
・父親であっても殴られたことはあるか？（または殴ったことはあるか）
IT業界の面接官は殴打検出装置を使います。物理的暴力だけでなく、声を荒げた、舌打ちをした、空気を重くした、などの準暴力行為も検出対象です。
誰の怒りも買わないように生きてきた人間だけが通過します。感情の発生自体がリスクなので、できる限り人を怒らせず、また自分も怒らないようにしましょう。怒りを感じた場合は、即座にOSを再起動してください。
要注意です。IT業界では正しさは仕様変更の一形態とみなされます。
面接官は「正義感共鳴センサ」を用いて、内心で自分を正当化していないかを検査します。
常に「私が間違っている可能性は99.9%ある」という姿勢を維持し、残り0.1%も即時破棄できる柔軟性が求められます。
優越感はレイテンシとして蓄積され、最終面接で一気にスパイクします。
IT業界では「全員が天才で、かつ全員が無能」という重ね合わせ状態のみが許容されます。
自分の成果はすべて環境・運・偶然・CPUクロックの揺らぎのおかげだと説明できるようにしておきましょう。
危険です。
IT業界の評価関数は非連続・非凸・非公開です。努力と結果の相関を信じていると、想定外の分岐で精神が例外終了します。
「評価は気分で揺れるノイズ」と理解している人材が好まれます。
昨日と言っていることが今日と違っても、それは成長ではなく「仕様が変わっただけ」と説明できる能力が重要です。
3年前の発言を掘り返されても、「当時は旧バージョンでした」で通してください。
理想的なのは「社会にデプロイされる途中の未完成なモジュール」だと自己認識していることです。
感情・尊厳・人生観はオプション機能なので、必要に応じて無効化できるようにしておきましょう。
なお、実際に通るかどうかとは一切関係ありません。
画像編集や写真編集、ブックデザインを生業としてるけどパソコン知識がゴミクソに乏しい
CPUにこだわりは無いけど、2019年製の携行用PC(メモリ 8GB、SSD256GB、COREi5)でガックガクだけどギリAdobe動くレベルだからスペック落としてもいいのかもしれんね
開発とか動画編集とかSteamとかしない限りそんなハイスペいらねーよ
CPUも5年前のi5とか5シリーズ程度と比べるなら現行世代のi3でも同程度になるからCPUグレード横滑りするだけで今までどおりの環境が整う
日経平均株価が半導体指数になってニュースで話題になるが、製造装置や材料は盛り上がっているが、日本に半導体チップ設計の仕事がない。
一方、中国はというと沢山あって羨ましい。
続き
そのうち、世の中はウィンドウズ時代に突入し、パソコンも１６ビットパソコンから３２ビットパソコンへと移行していったのである。…といっても、ウィンドウズ３．１は、とっくに発売されていたが、ゲームの世界が未だにＤＯＳベースだったので、それまでは何とかなっていたのであった。が、こう周りがウィンドウズだらけになってくると、流石に不安になって、ＤＯＳからの移行を考えざるを得なくなってしまったのであった。
上述のＰＣ－２８６ＶＥでも、ウィンドウズを試してみたことがあった。そのころは、ウィンドウズは３．０で、フロッピー５枚組という、今から考えればささやかな構成であった。当時は、ウィンドウズ３．０対応のソフトもほとんどなく、これは試してみるだけで終わったが。
実は、３２ビットパソコンへの移行の際に、一つの考えがあったのである。つまり、Ｍａｃへの移行である。当時、Ｍａｃの世界も変革の時期を迎えていたらしく、小さい筐体が却って可愛らしいマック・クラシックやカラーマック（多分これでいいんだよな…）が発売されると共に、通常のサイズのマックも、そこそこの（ウィンドウズマシンと変わらない）価格で発売されるようになっていたのである。
しかしながら、相変わらずゲームユーザーであった私は、ゲームソフトのコーナーを一瞥して、やっぱりゲームはＤＯＳベースが多い、とばかりに、ウィンドウズマシンを選んだのであった。思えば、ここが運命の分かれ道であった。
まぁ、ウィンドウズがいいか、マックがいいかは、今でも議論が分かれるところではあるが、このときマックを選択していれば、今の私のパソコンライフは、かなり違ったものになっていただろうことは、疑いのないところではある。
で、購入したマシンは、１６ビットに引き続き、ＥＰＳＯＮの、いわゆる「ジャケットサイズ」（…といっても、今はもうＬＰレコードそのものがマイナーな存在であるが…）の小さな筐体がウリのマシンであった。ＣＰＵは、４８６ＤＸの廉価版の４８６ＳＸで、クロックは２０ＭＨｚだった、確か。この辺は記憶が曖昧。１２０ＭＢのハードディスクと８ＭＢのメモリが付いていた。一応、ウィンドウズ３．１は動くというスペック。
このＰＣ－４８６ＳＥは、当然のことながら、後にいろいろと手を加えた。
こんな具合に。
グラフィックアクセレータ追加（メルコ製、サウンドボードに装着するタイプ）
メモリ８ＭＢ追加して１６ＭＢに。
ＣＤ－ＲＯＭドライブ追加（メルコ製のサウンドボードに直結のタイプ、２倍速）
オーバードライブプロセッサ（確かＩＯデータ製）追加して、ＣＰＵをPentium 75MHz相当に。
ディスク圧縮ツールを購入し、３４０ＭＢのハードディスクの容量を５４０ＭＢ相当に。
これだけの改造（とはいわないか…）を施し、やっとウィンドウズ３．１が快適に動作するようになったのだ。しかし何ですな、よくこれだけ発展性のない改造をやったものだと、我ながら思う。ＣＤ－ＲＯＭは、インターフェイスが専用なので使い回しができないし。
因みに、ＣＲＴは、グラフィックアクセレータを追加するまでは、８８０１の頃から使っていたＮＥＣのＰＣ－８５４Ｎを使っていた。アクセレータ購入後に、ＣＲＴがマルチスキャン対応ではないことに気づき、ＣＲＴを買い換える。ソフマップブランドの、Susteenのものでした。安い割には結構画質が良かった。
ウィンドウズ３．１にしてから、インターネット接続も始めた。最初は何がなんだか分からなかったので、接続ソフトは、取り敢えずインターネット・オフィスという、パック品を使用。接続は、スムーズであった。付属のブラウザは、今や懐かしい「モザイク」である。モデムは友人から譲り受けた14,400bpsのものだったが、このころはこれで十分なのであった。
ホームページもこのころから作り始めた。かねてから懸案のFrank Zappaのページ作りを始めるに当たり、ジャケット取り込みのためのスキャナを購入。このころは、真裸婦ラットベッドの製品は非常に高価であったので、ハンディタイプのものを購入。ＬＰジャケットを８回に分けてスキャンし、付属の合成ソフトで合成するという、涙ぐましいものであった。
このＰＣ－４８６ＳＥでも、ゲームはずいぶんとやった。でも、以前ほどたくさんはやっていないのだな。
上述したＥＬＦの「同級生」の続編。こちらの作品は、「兄と妹」という設定で大ヒットしたという記憶がある。前作のシステムやノリをそのまま引き継ぎ、内容をさらに充実させた、名作。
ホムンクルス（妖精）を育てて人間にするという、育てものゲーム。キャラデザが、イラストレーターの中村博文（どじ）氏だということで購入。そこそこやったが、何故か私が育てるとみんな悪魔になってしまい、そのうち断念。
…印象に残っているのは、このくらい。この時期は、ゲームはスパーファミコンを中心にプレイしていたような気がする。パソゲーが少ないのはそのせいかな。
さて、ここでウィンドウズ９５の発売となるのだが、ＥＰＳＯＮがＥＰＳＯＮパソコン対応のウィンドウズ９５の店頭販売を断念し、注文販売だけにしてしまったので、これは先が無いことが判明してしまった。新規にパソコンを買う予算も、早々には調達できない私は、しばし呆然とし、どうしようかと思いあぐねたのだった。
そのとき、天の導きかはたまた悪魔の誘いか、職場の先輩から、１枚のマザーボードが私の下へ転がり込んだのである。この１枚のマザーボードを発端として、今に至るまでの私のパソコン自作時代、パソコン大散財時代へと突入するのであった。
この譲り受けたマザーボードで製作した最初のシステムは、以下の通り。
MB(Mother Board):メーカー不詳、P54C対応マザー
SB(Sound Board):Sound Blaster互換のバルク品
Graphic Card:Canorpus PW-3DV
以下は、ＰＣ－４８６ＳＥのころのものを継続して使用している。というか、このころは、ＰＣ－４８６ＳＥも併用して使っていた。
Modem:Microcore 28.2kbps
CRT:Susteen 15inch
とにかく安く上げようとして組んだ結果がこれである。ま、最初にしては上出来だったのかもしれない。
で、そろそろこのシステムでは物足りなくなり、もう少し上のシステムに組み替えようと思い立ったわけである。
さらに、ホームページ作りに役立てようと、スキャナを購入したのも、このころかな。
CPU:Cyrix PR166+ (Clock=133MHz)
SB(Sound Board):Sound Blaster互換のバルク品
Graphic Card:Canorpus PW-3DV /VRAMを4MBに増設、ビデオキャプチャ機能を増設
Modem:Microcore 28.2kbps
CRT:Susteen 15inch
ＭＢにＧＩＧＡ－ＢＹＴＥを選んだのは、メーカー名が気に入ったのと、当時大攻勢だったASUSのものは使わないというコンセプト（？）からである。それと、SIMMのスロットが６本あるというのも、魅力であった。結局、SIMMは４本しか使わなかったが。これは、RAMをマッピングするTAG RAMの増設を億劫がったためである。TAG RAMを増設しないと、64MB以上のメモリ空間に対してアクセスが遅くなり、全体的にパフォーマンスが悪くなるらしいのだ。
さらに、このシステムに対して、ＣＤ－Ｒドライブを増設。ヤマハのCDR-400t-VKである。I/Fは、SCSIである。このころから、音楽製作関連にも大散財時代が訪れたのであった。
ＣＤ－Ｒを使って、現在も続いているＰＳＹ－ＤＯＬＬというバンドのＣＤを焼きまくったのであった。当時は、ＣＤ－Ｒの原盤の質もそれほど良くはなく、結構エラーが発生して板を無駄にすることが多かった。
この後、システムは急速に変遷を続け、私は、大散財を続けるのであった。
RAM:DIMM PC-100/CL2 192MB(64MB+128MB)
Audio Card:emagic Audiowerk8
Graphic Card:Creative Labs Graphics BLASTER/RIVA TN
DISPLAY:MITSUBISHI RDT141X(LCD)
フォルダを漁っていたら、1999年5月に書かれた、自分のPC履歴が発掘されたので、貼り付けてみる。
なんだかんだ言って、私がパソコンを使うようになってから、１０年近く経ってしまったのである。プログラムを組んで実行できる最初のマシンは、高校のときに購入したＣＡＳＩＯのプログラム電卓ＦＸ－５０２Ｐであるが、これはあくまで電卓であり、パソコンとは多少趣を異にするものであった。
パソコンとして最初に購入したのは、ＮＥＣの８ビットマシンＰＣ－８８０１ＭＡ２であり、完全なるゲームマシンであった。以下、１６ビット時代に突入してＥＰＳＯＮ ＰＣ－２８６ＶＥ、３２ビットマシンのＥＰＳＯＮ ＰＣ－４８６ＳＥと続き、とうとう自作ＤＯＳ／Ｖマシンをメインのマシンにするようになってしまうのであった。
これから、私のこのしょ～もない足跡を辿ってみたいと思う。ＰＣ－８８０１ＭＡ２～ＰＣ－４８６ＳＥの項には、そのときハマったゲームの感想なども記してある。暇な方はこちらもどうぞ!?
小さい頃から、電気・電子関係が好きで、親にマイキット（パネル上にトランジスタとか抵抗、コンデンサなどが並べられており、スプリングになった端子にコードを挟んでそれらを繋いで回路を作る）や電子ブロック（透明なブロックにトランジスタや抵抗などが入っており、ブロックをボード上に配置して回路を作る）などを買ってもらい、それでラジオなどを作って遊んでいたのである。マイキットでラジオを作り、夜中にこっそりと深夜放送を聞いていました。(^^;
因みに、私がアマチュア無線の免許を取得したのは、小学生のときである。これは、ちょっと自慢してもいいと思う。
当時、「初歩のラジオ」とか「ラジオの製作」、「電波科学」などの雑誌をよく読んでいたのだが、流石に、中学生の私にはディジタル回路は難しく（というよりも、何をするためのものなのか、イマイチ理解できなかった）、ボードマイコンＴＫ－８０などに手を出すには至らなかった。
まぁ、何しろ当時は、マイコンといっても論理回路の動作から入る必要があったので、当然といえば当然であろう。
そして、関数電卓などをいじくり、「このキーとこのキーを同時に押すと変な表示になる!?」などと遊んでいた私が、最初に手にしたコンピュータらしきものは、カシオのプログラム電卓「ＦＸ－５０２Ｐ」である。
これは、５１２ステップまでのプログラムが組めるというもので、ちゃんと「ＧＯＴＯ」キーや「ＧＯＳＵＢ」キー、「ＬＡＢＥＬ」キー、条件判定を設定するキーなどが用意されていて、結構本格的なものでした。レジスタも１０個使えた。ランダムに数値を出力するキーも付いていたな。
プログラムライブラリ（本ですが）なども付いてきていて、掲載されている通りに打ち込むと、科学計算をやったりゲームなどを楽しむことができた。もちろん、プログラムを外部に記録しておくこともできたのだ。オプションが必要だが（買った）、普通のラジカセなどを使ってカセットテープにプログラムを記録するのである。
あと、ＦＸ－５０２Ｐでは、キーに４分音符や１６分音符などが割り当てられていて、短音だが楽曲を打ち込むこともできた。上述のオプションを利用して、ラジカセなどで鳴らすのである。
学生時代は、ビンボーだったせいもあって、パソコンには縁がなかった。友人宅でシャープのＴｕｒｂｏIIIなどでゲームをさせてもらうのが関の山なのであった。
で、就職して最初に購入したパソコンが、ＮＥＣの８ビットパソコンの最終形態ともいうべきＰＣ－８８０１ＭＡ２である。
当時は、既に１６ビットパソコンのＰＣ－９８０１Ｖｍ２なども発売されていたのだが、私の選択したのは８ビットマシンの「ハチハチ」なのであった。何故か？
それは、パソコンでゲームがしたかったからである。当時は、違法行為に限りなく近いレンタルソフト屋が横行していて、ゲームソフトなどが比較的安い価格で入手できた（ソフト毎のパラメータファイルでコピーを行うＦｉｌｅ Ｍａｓｔｅｒは必需品）。また、ゲーム市場も８８０１主体であって、９８０１用のものはごく少なかったのである。
とにかく、とても全部やりきれないくらい、ゲームを借りまくった。
何を隠そう、私が８８０１を購入して、最初に買ったゲームがこれである。何で、最初からこんなに難易度の高いゲームを、と疑問を持つ向きもあろうが、要するに、当時はパソゲーなるものが全く分かっていなかったのである。しかも、あろうことか、購入時には、アクションＲＰＧの先駆け的存在である「ソーサリアン」とこの「マイト・アンド・マジック」を天秤に掛けていたのである。
世間では、「クソゲー」との評価が一般的であるが、私は、このゲームは名作であると信じている。とにかく、世界が存在していて、プレイヤーはその世界に住むところから始まるのである。ストーリーは、最初は与えられず、発見したものだけがストーリーに参加できる。しかし、ストーリーに参加しなくても、とにかく世界が広大・深淵なので、アイテム探しやダンジョン探検だけでも、十分堪能できる。私は、後述する１６ビットパソコンの時代まで、約３年以上もこのゲームにお世話になったのである。
「ドラクエ」シリーズで有名なエニックスのアドベンチャーゲーム（ＡＶＧ）。
不気味な感じが大変心地よい秀作。本作では謎を残したまま終結し、後に「アンジェラス２」が発売されるが、時期を完全にはずしていたし、余り面白くなさそうだったので私はやっていない。
今はＨゲーのメーカーになってしまった、しゃんばらのＲＰＧ。私の大好き（だった）漫画家、松田紘佳がキャラデザ他を手がけている。音楽もこの人だったな。もしかすると、「２」は後述のＰＣ－２８６ＶＥでプレイしたのかもしれない。海が舞台の、異色のＲＰＧ。とにかく海なので、３次元的に自在に移動できるのがミソ。階段を使って他の階へ移動する一般的なダンジョンとはひと味違うのである。
ただ、惜しむらくは、これは私がコピー品でプレイしていたから良くないのであろうが、２作ともエンディングを見れなかったことだ。
１作目では、「ピー」とビープ音がしてゲームがハングアップ。２作目では、たぶん最終場面であろう画面から１歩も進めず、アウト。
今あったら、正式に購入して再度挑戦してみたいゲームではある。
かのアスキーが発売していた、Ｈゲー。ダンジョンを歩き回るＲＰＧである。
このゲームは、とにかくノリが非常によく、テンポが軽快で楽しいゲームであった。ゲーム自体は、６階＋αの「ウロボロスの塔」を探検して、秘密を探るというもので、出てくるモンスターが女の子で、ダメージを与える度に女の子が１枚ずつ服を脱いでいくという、他愛もないものである。
このゲームをして最初に驚かされたのは、グラフィックの描画の早さである。何だかんだ言っても、８ビットパソコンであるので、当時のゲーム、特に、グラフィックを強調したゲームでは、描画に恐ろしく時間がかかった。一枚の画像を出すのに数秒、ひどいものでは、数十秒、なんていうのもあった。
そんな中で、この「カオス・エンジェルス」は、とにかく、一瞬で画像が描き換わった。これは、当時ではとても新鮮なことであった。
また、そのＢＧＭもとても斬新で、簡単なＦＭ音源を使いながら、とてもハイセンスな雰囲気を醸し出していたのだ。音楽の秀逸さでは、水龍士といい勝負かもしれない。
しかし、このゲームの最大のポイントは、「洒落っけ」にあると思う。ダンジョンの壁に、前に探検した人の落書きがあって、これがまた奥が深く面白い。この落書きがゲームのヒントにもなっているのだが、関係のない落書きもあって、これを探すだけでも、結構楽しめた。
当時、特にスタジオピエロ系のキャラクターもののゲームを数多く出していた、マイクロキャビンのＡＶＧ。マイクロキャビンでは、この後も、「めぞん一刻」や「気まぐれオレンジロード」などのキャラ系ゲームを続々と発売していた。
このゲームは、少年サンデーに連載されて、アニメ化もされ一世を風靡した、高橋留美子の同名の漫画「うる星やつら」をゲーム化したものである。
ゲーム内容は、確か、面堂家の誰か（終太郎か、了子か、どっちか忘れた、たぶん了子だ）の誕生日に招待されたお馴染みのメンバーが「迷路」を探索しながらゴールにたどり着くというものである。何かのイベントを経る毎に、時間が経過していき、それにより結果が変化するというのと、途中の行動で結果が変化するということで、数種類のエンディングが用意されていたように思う。
マルチエンディングや時間の概念は今でこそ珍しくもないが、当時では結構画期的なことであったのだ。
フェアリーテール（ＥＬＦ）の伝説的名作ＡＶＧである。確か「２」もあった。フェアリーテール（ＥＬＦ）のＡＶＧは、何かこう、独特の雰囲気があって、それが私は非常に気に入っていた。なんていうか、どことなく寂しげな感触というか、ちょっと空虚な感じとでもいおうか。キャラクターや展開、秀逸なＢＧＭなどが、この雰囲気を醸し出しているのだ。
フェアリーテール（ＥＬＦ）のＡＶＧは、この他にも相当やった。「ＥＬＬＥ」なんかは、最後のどんでん返しが強烈でした。
そのほかにも、いろいろゲームはやったが、とんでもねーゲームを一つだけ…
これは、要するに当時大流行の「北斗の拳」のパロディーＨゲーである。
ゲーム内容がくだらないのもさることながら（あまりにくだらなすぎて、ケンシロウのようなキャラが出てくること以外、忘れた）、その作りがとにかく凄い。
これは想像だが、このゲームは、おそらくＮ８８－ＢＡＳＩＣで組まれている。なぜなら、まず、ストップキーでゲームが止まってしまう。そして、そのとき、画面の左上隅に「>C^」が出る（分かる人には分かるね!?）。
そして、ＮＥＣの８８０１，９８０１シリーズのパソコンには必ず付いていた、画面のハードコピーを取るキー「COPY」を押すと、押したときに表示されている画面をプリンタに印刷することができる。
なんか、「流行だから適当に作って一発当てよう」という意図の見え見えなゲームでありました。
…そうこうしているうちに、８ビットパソコンは衰退し、ゲームソフトも発売されなくなって、世の中は１６ビットパソコンの時代へと、大幅に突入したのだった。
そこで購入したのが、ＮＥＣではなくて、ＥＰＳＯＮのパソコンなのである。ここいらへんに、私の偏屈さがにじみ出ていますね～。(^^;
パソコンに金をかけだしたのも、このころからである。…まぁ、８８０１じゃあ、金をかけようにもかけるところがないですが。(^^)
今ではもう信じられないが、当時は、１ＭＢ／１万円がメモリの相場であった。しかも、メモリをパソコンに組み込むには面倒な設定がいくつも必要で、さらに、汎用のスロットを一つ占有してしまうのだった。また、今でこそ、ＳＩＭＭとかＤＩＭＭとかいって、大容量がコンパクトに収納されているが、当時は、たとえ１ＭＢでも、１２ｃｍ角くらいの基板にチップがびっしり載っていたのだった。
それでも、１ＭＢあると無いとでは、雲泥の差があった。
これも、今ではもう信じられないが、当時は、例えば４０ＭＢで８万円位した。しかも専用のインターフェイスが要る。これでまたスロットが一つ埋まったのであった。
でも、当時のソフトは、４０ＭＢでもお釣りが来るくらいの容量だったんだよね～。
あと、このマシンから、パソコン通信を始めた。当然NIFTY Serveから。
当時は、WTERMを使い、通信速度も2400bpsであった。50kBの画像をダウンロードするのに何分もかかり、さらにその画像を表示するのに何分もかかった。大変な時代であった。
このＰＣ－２８６ＶＥは、後に友人の手に渡り、そこでＶＲＡＭ異常が発生してお亡くなりになってしまいましたとさ。合掌。
このマシンでも、ゲームはずいぶんとやった。中で、印象深いものをいくつか紹介しようと思う。
上述したものと同じである。当然、続きではなくて、新規に始めた。やはり８ビットのものと比べて速い。何しろ、８ビット版は２ＤＤのディスク４枚組で、地上、ダンジョン、城、と場所を変える度にディスクの入れ替えが必要だった上、そのたび毎に、システムディスクに書き込み（１分くらいかかった、マジで…）をしていたのだ。それがなくなっただけでも、快適である。ただ、８ビット版の頃はあったＢＧＭがなくなってしまったのは、ちょっと寂しかったが。
なかなかハマった。各エンディングも味わい深いもので、３０数種類あるといわれているエンディングを２０数種類まで見て、飽きてやめた。プリンセスと謎のエンディングは見ていない。けど、いいや。
「１」と「２」は、３Ｄダンジョンもの。当時は３Ｄダンジョンでさえ珍しかったのに、Ｈゲーで３Ｄダンジョンというのは、相当なインパクトがあった。ゲーム的にもよく練れており、ダンジョンの仕掛けも良くできていた。Ｈゲーという観点を排除して、単にゲームとしてみた場合に、非常に完成度の高いゲームであった。
「３」は、確かドラクエタイプの２ＤのＲＰＧ。「４」は、ダンジョンに戻ったのだっけかな？この辺はあんまり印象にないのだな。「５」は、私の大嫌いなシミュレーションで、遂にエンディングを見ることができなかった。…と言うよりは、途中でつまんなくって止めた。「４」と「５」は、多分、後述のＰＣ－４８６ＳＥでやっている。
これは、今更説明するまでもない、ＥＬＦが世に放つ名作中の名作。このゲームが今までのゲームの流れを一気に変えたといってもいいでしょう。味のあるキャラクタ（しかも大勢！）に、深みのあるストーリー。それぞれが練りに練られたマルチエンディング。とってもシビアな時間の概念。所持金の存在も内容に深みを与えています。
さらに、複雑なフラグ制御がすばらしい。よくあれだけの条件設定をして、ゲームが破綻しないものだ。
そして、何より高校生最後の夏休みという、絶妙のセッティング。
とにかく、この「同級生」は、何遍やっても違った展開になるし、違った楽しみ方ができるゲームという、画期的なゲームでした。
後に「２」も出て、共通するキャラクタも出演している。私は、「２」は後述する３２ビット版でやったのだけれど、その面白さは全く失われてはいませんでした。恐るべし、ＥＬＦ。
そのうち、世の中はウィンドウズ時代に突入し、パソコンも１６ビットパソコンから３２ビットパソコンへと移行していったのである。…といっても、ウィンドウズ３．１は、とっくに発売されていたが、ゲームの世界が未だにＤＯＳベースだったので、それまでは何とかなっていたのであった。が、こう周りがウィンドウズだらけになってくると、流石に不安になって、ＤＯＳからの移行を考えざるを得なくなってしまったのであった。
上述のＰＣ－２８６ＶＥでも、ウィンドウズを試してみたことがあった。そのころは、ウィンドウズは３．０で、フロッピー５枚組という、今から考えればささやかな構成であった。当時は、ウィンドウズ３．０対応のソフトもほとんどなく、これは試してみるだけで終わったが。
実は、３２ビットパソコンへの移行の際に、一つの考えがあったのである。つまり、Ｍａｃへの移行である。当時、Ｍａｃの世界も変革の時期を迎えていたらしく、小さい筐体が却って可愛らしい Permalink | 記事への反応(1) | 12:53
生成AIが直接機械語やバイナリを出力するようになるのではないか、という問いは本質的に間違っている。
自分は、まだ素朴なニューラルネットワークで光学文字認識(OCR)の精度を出していた頃から似たようなことを考えていたので、少し他人よりも蓄積がある。
これは、Large Language Model(LLM)を開発する企業が資金を集めるために多少誇張した未来を語るという文脈では大目に見た方が良いが、正確性に欠ける。
本質的な問いは、なぜ我々は、ノイマン型コンピュータを用いて、主記憶に置かれたプログラムをCPUを用いて実行する形式をとるのか、というものである。
まず、筋の悪い反論から説明し、妥当な反論にも触れたうえで、本質的に問うべき課題を説明する。
これは明確に、いいえ、と答えることが出来る。
最初こそ人間による補助は必要だが、LLMを含むAIは明確な目標があれば人間のデータなしでも十分に学習することが出来る。
これは身近なところでは将棋、有名なものだと囲碁で実証された研究が存在する。
そのため、単純に「機械語は人間による学習データが少ないので扱いが難しいだろう」という反論は成立しない。
そういったものはLLMではないだろうという指摘は可能だが、LLMでそういったAIを出力することは限定的とはいえ現在でもできる。将来できないと言うだけの論拠にはならない。
英語に限った話ではなく、人間が意思疎通に用いる言語である自然言語(natural language)は、曖昧さやばらつきがある。
これを形式言語(formal language)という、曖昧さを無くして語彙や文法を限定した言語に記述しなおすことで、厳密にする手法がある。
この形式言語での表現が、アルゴリズムやデータ構造になり、現代のノイマン型コンピュータにおけるプログラムそのものと言うことが出来る。
なぜ限定的かと言えば、形式言語の一種であるプログラミング言語には曖昧さが許容されているからである。
ほとんどのプログラミング言語では、同じ目的を達成する為に複数の記述が許容されている。
主に、人間が書きやすいから、とか、複数の人間で書きやすいように、といった理由で、曖昧さが許容されている。
そのため、機械へ命令するためには厳密さが必要だからプログラミング言語が必要だ、と言う反論は妥当ではあるが、弱い。
なぜ大統一プログラミング言語のように、自然言語の意図を機械に伝えるための形式言語が一種類になっていないかと言えば、人間の認知能力には限界があるからだ。
そのため、簡易で曖昧さを含むために最適化はできないが十分な性能を持つプログラミング言語や、非常に複雑で記述量も多くなるが大人数で作業するには最適なプログラミング言語などが複数存在する。
これらはいずれも、人間が楽に記述できる形式言語であったり、人間同士が齟齬なくコミュニケーションを取るために必要な形式言語である。
ありていに言って、人間や人間たちが理解可能な形式言語でないと機械にその意図を伝えることが出来ないから、と言える。
ただし、コンパイラから出力されたニーモニックやLLVM-IRを監査できる人間は現代では非常に少なく、現状ほぼ監査なく受け入れていると言って良い。
何故非常に少なくなったかと言えば、機械に伝える意図が大規模になり、単純にマンパワーが足りなくなったので監査しきれなくなっただけに過ぎない。
（もちろん、途方もない努力の末に最適化が進み、ほぼどの様な書き方をしても最適な機械語が出力されるようになったから、とも言える）
同様の理屈で、単純に大規模になり監査が間に合わなくなったので、受け入れるようになる未来が来ないとは言い切れない。
本質的な問いは、なぜ我々はノイマン型コンピュータを用いて機械に意図を伝えるのか、である。
ASIC(Application Specific Integrated Circuit)と呼ばれる、特定の用途向けの集積回路がある。
蟹チップとして、Realtek社のNIC(Network Interface Card)をご存じの方も多いと思う。
必要十分な処理があらかじめ定まっているのであれば集積回路を組んだ方が高効率省電力にできる。
暗号化や復号もASICで行われることが多く、ブロック暗号はその性質上集積回路での実装が容易であり、それに向けた研究も行われている。
一般的にも、ハードウェアエンコーダーなどでお世話になっている人も多いと思う。
ではなぜ、我々は身近な全てをASICにしないのか。
それは、書き換えできず、単純な処理しかできず、大量生産しないとコストに見合わないからである。
FPGAのように、ハードウェア記述言語を用いて集積回路を書き換えるものも、ほぼ同様の理由で研究開発用途や産業用途に留まっている。
（一部のPLD (Programmable Logic Device)は根強く産業利用されているし、大規模に展開され高効率を要求されかつ書き換えを求められるネットワーク機器では一部採用が進んでいる）
汎用的で書き換えが可能、伝える意図を変更できる様々な処理が可能な機械に価値があるから、である。
ここ半年から1年で急激にLLMの性能が上がったと感じている人と、コーディングツールとしてLLMの利用が洗練されたと感じている人の間には溝がある。
自分は、LLM自体は順調に進歩し続けているが、それほど劇的な変化はない、という立場をとっている。
これはモデルそのものが質的に大きく変化したと感じないから、である。
しかし、プログラミングの世界に限って観ると、コーディングエージェントや実利用では大きな変化があったと思う。
この、"コーディングを取り巻く環境としてのLLM利用"という文脈は、"LLMの進化"という文脈とは異なる、という点は頭の隅にでも覚えて帰ってほしい。
これは、LLMから直接と言う意味であれば、個人的にはNOだと思う。
ただし、LLMに指示すればバイナリが出力されるという意味であれば、個人的にはYESと答える。
この二つは明確に異なるので、今後自分の意見を述べる際には区別すると良いと思う。
コーディング周りの環境が劇的に整備されつつある、という話題に軽く触れたのはこのためで、LLMが直接バイナリを出力しなくても、結果が同じであれば人々はそれほど気にしない。
例えば、現時点でもローカルのLLMに指示するとGO言語で書かれたコードが生成され、ローカル環境に合わせたシングルバイナリが出力される一連のパイプラインを組むことはできる。
自分の想定する、未来のAIがバイナリを直接出力するというのは、この延長にあると思う。AIがイコールLLMである必要はどこにもない。
少しでもクラウド上でのサーバー処理について触れると、廃棄容易性(Disposability)は俎上に上がる。いつでも落とせていつでも捨てられる、という性質のことである。
こうした、単機能バイナリをコンテナ等に載せて処理し、日に数度デプロイするような環境だと、LLMがバイナリを出力するというのもそれほど遠い未来の話には思えなくなる。
LLMが機械語を出力する未来は個人的には来ないと思う。それは難易度が高いからではなく単純にメリットが少ないからである。
ただし、パイプラインが組まれた一環として、LLMがバイナリを出力する未来は、それほど不思議には思わない。現時点でも可能である。
単純なLinterから進んで静的解析や、動的な結合試験が組み込まれているCICDパイプラインが珍しいとまでは言えない現代において、来るべき近未来像としては妥当性がある。
（その場合、ソースコードはログとして機能し、テキストで保管が容易な、次回以降変更可能なコンテキストの一部になるだろうと思う。今後変更不要ならHDLでFPGAを弄った方が早い）
現代人のすべてがJavaで同一の書き方をしているのではない現状において、自然言語では揺らぎが強すぎて形式言語ほど意図を機械に伝えきれないという反論は、弱い。
それよりは、現代のLLMはコンテキストウィンドウが人間の数倍～数十倍程度で、適切に分割して処理しなければならず、大規模なソフトウェアを丸ごと扱えるほどではない、という反論の方が適切である。
ただ、LLMに適したプログラミング言語が生まれるのではないかと言う予測には懐疑的である。既存のプログラミング言語を使う方が人間が読みやすい。
AIが、人間が欲しいバイナリに適したプログラミング言語をLLMを用いて書き、LLMを用いてレビューし、テストツールでテストし、コンパイラでビルドし、ツールでデプロイし、実稼働するという未来予想図が、荒唐無稽とは思えない。
LLMに適したプログラミング言語が生まれる未来よりも、(冗長であっても)人間可読性の高いコードやSelf-documenting codeが生成される未来の方が、来そうに思う。
また、おそらくこの文章のもつくであろう「どんなプロンプトで書いたのか」という、一定以上の長さの文章はLLMが出力しただろうと仮定する人間が増えている(そしてある程度の妥当性がある)現状において、プロンプトで指示してデプロイまでされる未来はそこまで遠いとも思えない。
ただ、購入できるハードウェアの性能とコストが律速になるので、よほど特殊な(CPUやGPUの設計をLLMが劇的に改善する)状況にならない限り、5～10年はプログラマーが消えることは無いと思う。
金に糸目をつけないのであれば、再来年当たりからはLLMレビューのみで仕様バグ以外のほぼ無いプロダクトが世に出てもおかしくは無いと思う。
人類の言語そのものを目的関数としてそれに対して最適化するのがLLMなのだから、人類の認知で到底不可能なことはやりようがないだろう。
一文で本質を突いている。AIの能力限界を構造的に説明している。
今よりもAIが進歩した未来では「自然言語で与えられた仕様から機械語を出力するように訓練されたAI」が出てくるかもしれないけど、そいつの内部をよく観察したら結局今日の高級言語みたいなもので思考していた、みたいなオチになるんじゃないんですかね
結論と完全に一致。内部に抽象化レイヤーが生まれるという洞察。
マシン語でエラーを吐き出されても、元となるプログラミング言語での設計がすっ飛ばされていたら、どこの何が問題なのかが照合困難で修正が困難なのが根幹な気がします。
検証・修正サイクルに意味の単位が必要という話を、実務的な観点から der 表現。
計算機科学について何一つ知らなかったとしても、ニーモニックを無作為に並べるよりソースからコンパイルした結果の方が解空間が圧倒的に小さいのだから、機械語の生成は AI 以前に単なる探索として悪手だ、というのが自然な発想だと思うんだけど。
探索空間という観点からの指摘。高級言語は制約を与えて解空間を狭める役割がある。
抽象化した方が簡潔に記述できるのはAIにとっても同じことで、そっちの方がAIも理解しやすいし、生成しやすい。現在の機械語、アセンブリ、高級言語の階層構造が崩れるとは思えない。
「AIにとっても同じ」という視点が正しい。人間向けとAI向けが乖離しないことを理解している。
「AIが直接機械語書けばプログラミング言語は要らないのでは？」的な話はみんな最初に頭を過るだろうけど、コードを出力するのがLarge "Language" Modelである以上は意味論から組み立てる高級言語の方がそりゃ相性いいでしょうね。
AIを何かgodlikeな超知性だと思っている人間が多いけど、人間にとって「機械語よりも高級言語の方が当然書きやすい」のと同様、AIにとっても「機械語よりも高級言語の方が当然書きやすい」よなぁという話
「AI向け言語は人間にも使いやすいはず」という結論と同じ方向。
CPUへの命令にまで細かく分解された機械語なんて、それが何をするための処理なのかはAI（LLM）でも大変だと思いますよ。そのCPUへの命令群で何をやろうとしているのかなんていう情報はほぼ捨て去っているわけなので。
機械語には意味がエンコードされていない、という議論の核心部分。
機械語派は抽象化の力を舐めすぎ。型なし言語はトークン削減量に対して失われる確定情報量が多すぎ。LLMが内部で型を推論したら本当にトークンが削減できるか怪しい。全能AIを仮定するなら、「人が作ったハード上で機械語を直接書く」なんて中途半端で「ハードごと最適化」くらいの夢を語ってほしい。
AIが機械語を直接書くようになるとか言っている人は、機械語にこそ真の価値があると思ってるんですかね？いかなる音声も元にせず、指示に従ってレコードに直接溝を刻んで音を鳴らす技術が広まれば、音楽がさらに発展するとでも思っているんでしょうか？
AI専用言語にせよ機械語を直接出力にせよ、人の持つ高レベルの意図や仕様、アルゴリズムを正しく反映したデータセット、意味構造が保存された対応データが存在しないから難しいというか現実的に無理よなぁ
学習データの観点から。意味構造が保存されたデータがないと学習できない。
「AI がマシン語を吐いたらプログラミング言語はいらない」系の話が出てくるのは「AIは人間の言葉より、機械の言葉の方が本当は理解しやすいはずだ」という思い込みから来ているのじゃないかと思っていて
誤解の根源を正確に特定している。
まず機械語を直接記述するメリットがない。現代コンパイラ、インタープリタは超優秀(OSや組み込みの一部だけ)。人類のプログラム資産は高級言語がほとんど。AIの学習先もそれ、よってAIは高級言語で出力するほうが成績が良い
AIが直接機械語を出力すべきか？という話題が流行っている。直感的には、動作中のAIの中身を調べると、結局はコンパイラやプログラミング言語に相当する構造が即席で構成されてそう。つまり同じことを高いコストでやる感じになり
内部に抽象化レイヤーが生まれるという洞察。mod_poppoさんと同じ結論。
意味推論がLLMの得意技なので、意味を削ぎ落とした本質の塊である機械語は理解できず、意味の羅列である高級言語こそがむしろ生成AIに最適化されている。
コンパイラって優秀だから、AIといえども生で機械語を読み書きするよりもコンパイラ介した方がいいと思うんだよな。そのくらいLLMって機械寄りじゃなくて人間寄りなんだと思う。元がニューロンの模倣だし。
高レベルになるとコンパイラの出力を疑って生成されたコードを読まないといけない状況は普通にあるので、高水準なAI生成のコードが何をやってるか理解するスキルは当面は必須だと思う
もし仮にAIが機械語を吐き出せるとしても、高速に、決定論的に、段階的に、最適に動作するコンパイラを使わず、低速で、確率論的で、逐次的で、最適な動作ができないAIを利用する意義はほぼないと思う
コンパイラとの比較で、AIに機械語を吐かせるメリットのなさを指摘。
機械語は冗長で複雑かつ非常に正確な出力が必要なので、高級言語を使って既存のコンパイラやビルドパイプラインに乗せる方がAIにとっても効率が圧倒的に良いと聞いて確かになぁと思いました。
自然言語を処理するのがLLMなので、不自然な機械語は難しいだろうね。1命令ごとに「それは何を目的とした操作か」とか文脈でわかりにくいしねぇ。
AI時代の人間の仕事は、信頼性確約（＝こういう理屈で大丈夫、と説明できること）が大きな領分を占めるだろうと推測されるので、機械語だけで良いとか言ってるやつは責任を取る気皆無なゴミ野郎です。
LLMに機械語を出力させようとするやつは「AIは機械なんだから機械語は簡単に扱える」という意味不明な思考をしてるだけなのでまともに取り扱うような相手ではない。名字が山口な人は長州方言が話せるんですよねとか言ってるくらい支離滅裂
人間がソフトウェアに「こう動いてほしい」という意図と「ソースコードがどのように変更されたか」の対応はGitHubとかに大量のデータがあるのでそれを学習すればコーディングするAIは作れる気がするけど、人間の意図と機械語の対応は学習データが全然ないからAI作れないように思う
「よく使うロジックを共通部品化する」とか「とはいえ局所最適な命令も欲しい」とかを考えると、中間言語を用意して最終的な機械語へコンパイルする、という流れは必要と思う。つまり、「AI用に最適化されたプログラミング言語」があるべき。
AIは人とのコミュニケーションをいかにスマートにするかにとんでもなく時間を掛けてきたわけで、人が直接読み書きできない機械語を出力しても意味がないよね。
AI機械語コーディング、やろうと思えばできるが普通はやらないような可読性の低いコーディング方法が多すぎて、AIﾁｬﾝに本気出されるとバグったときに修復不能になりそうな気がする
これだけAIが発展したならAIに直接機械語作らせればいいじゃんみたいな言説をたまに見るけど、それどうやって今のLLMと同じ水準まで学習するの？といつも思ってる
ロジックに従っているわけだから、ソースで想定外の挙動をした被疑箇所前後にロガーやらブレークポイントを仕込むという原始的だが確実なデバッグが、いきなり機械語を吐かれると出来ないんよ。
デバッグ実務の観点から。意味の単位がないとデバッグできない。
AIにしか読めない言語より、人類が発見的に設計したんじゃない人類にもAIにも優しいプログラミング言語・中間表現・機械語をデータドリブンに統計的に正しくAIが作るって方向に行かないですかね
AIが直接機械語吐くのは遠回りしてるだけだから無いとして、完全に人間がプログラムを読まなくなったらプログラミング言語はどう進化するのかは気になる
「無い」と断じた上で、次の問いを立てている。建設的。
プログラミング言語は人間の認知負荷、記憶量の限界、ミステイク、スパゲティコード理解できないためにあるので、AIだったら直接機械語吐くだろ。常考。
反論： 完全に逆。プログラミング言語は「人間の限界を補うため」ではなく「意味を構造として保持するため」にある。AIも意味を扱う以上、意味を表現する層が必要。「常考」と言いながら何も考えてない。
シンギュラリティ前夜 アダム（AI）が、人間には理解できないどころか、読むことすらできないコードを出力し始めた。後に判明することだが、それは機械語だった。
反論： SFポエム。「人間に読めない＝機械語」という発想が、まさに今回の議論で否定されてる誤解そのもの。AIが人間を超えるとしたら、ローレベルに降りるんじゃなくてハイレベルに登る方向。
なんかLLM界隈？では「AIがやがて機械語をだす（ので実用的にはコンピュータ言語は不要になる）」と言うと、無知だとか実情知らないとかブロックしてやるとか言われる見たいだけど。数年は無理だけど、いずれそうなると予想してる。
反論： 「数年は無理だけど、いずれそうなる」の根拠がゼロ。なぜそうなるのか、意味と機械語のギャップをどう埋めるのか、何も説明してない。批判されてる理由を理解してない。
プログラム言語って人間が扱うために自由度を削り取った結果の産物やから、AIに機械語で作ってもらって最適解であれば、現代の言語の宗教感ってほぼほぼ否定されるのです
反論： 「人間が扱うために」という前提が間違い。自由度を削ってるのは「意味を保持するため」。AIも意味を扱う以上、同じ制約を受ける。「宗教感」とか言って茶化してるけど、構造を理解してない。
「まだ」人間が安心する為では無いのですか？コンパイル後の機械語を読む人が殆ど居ない事は受け入れてるのに、将来的にAIが機械語出力する事に忌避感を感じるのは論理的とは言えません
反論： コンパイラの出力を読まないのは「コンパイラが検証済みだから」。AIの出力は検証が必要。この二つを同列に扱うのがおかしい。「論理的とは言えません」と言いながら、論理が破綻してる。
AIが機械語はけば、は数ヶ月前にメンバーと話になった。結論は、いまはあかんやろけど数年後に、もう人間が見る必要全然ないわ、となったらありうるな、となった。
反論： 「人間が見る必要がなくなったら」という仮定自体が検討されてない。人間が見なくていいとして、AIはどうやって検証・修正するの？意味の単位がない機械語で？その議論が抜けてる。
機械語って逆にトークン消費するの？お〜…じゃあLIFE3.0時代のAIは機械語ではなくAI用に最適化された人間には読めない言語で思考する、という方向性なのかな。
反論： 「人間には読めない言語」がなぜ生まれると思うのか。AIは人間の認知を模倣してるので、AIにとって扱いやすい言語は人間にも扱いやすい方向に収束する。逆方向には行かない。
中間言語不要派の言い分：AIが直接機械語を出力可能で、効率最適化が進む。人間の都合で言語が存在するが、AIなら移植性や抽象化不要で中間層をスキップできる。
反論： Grok自身が「中間言語不要派の言い分」として紹介してるけど、これ全部間違い。「人間の都合で言語が存在する」が誤り。意味を扱うために言語が存在する。AIも意味を扱う。
反論： 「うまくやってくれるかもしれん」で済む話じゃない。なぜうまくいくのか、検証・修正はどうするのか、何も考えてない。
反論： これは自虐なので反論というより…正直でよろしい。専門外だと自覚してるなら、なぜそう思ったのか掘り下げて、専門家の意見を聞く姿勢があれば良いと思う。
筋の悪い言説に共通するのは：
1. 「高級言語＝人間のため」という誤解 - 意味を扱うための構造だと理解してない
2. 「AIは機械だから機械語が得意」という誤解 - AIは人間の認知を模倣してると理解してない
3. 検証・修正の問題を無視 - 一発で完璧に動く前提になってる
ソフトウェアって、結局「意味」を扱うものなんです。銀行口座の残高、予約の空き状況、SNSのタイムライン。全部、人間世界の概念を処理している。
一方で、CPUが実際に実行するのは「このアドレスに値を書け」みたいなビット操作の羅列。そこには「ログイン機能」という単位が存在しません。
この二つを繋ぐには、「何を作るべきか」「できたものが正しいか」を判定する基準が要ります。「ログインできること」「不正なパスワードを弾くこと」といった仕様は、意味の単位がないと記述できない。だから「意味→手続き」の変換には、意味を表現できる抽象化レイヤーが必須になる。これが高級言語の本質的な役割です。
じゃあ「AIが直接機械語を吐けばいい」はなぜ成り立たないのか。
AIは意味のレベルで動作します。「ログイン機能を作れ」を受け取って処理する。最終的にCPUが実行するのはビット操作。この間に「意味→手続き」の変換が必ず発生します。
AIが何を出力するにせよ、内部でこの変換が起きる。つまり、AI内部に意味を表現する抽象化レイヤーが必ず生まれます。これは人間が読み書きする形式でなくても、機能的には高級言語そのものです。
だから「高級言語をスキップしてAIが直接機械語を吐く」は原理的に不可能なんです。スキップしたように見えても、内部で同等の抽象化が起きている。中間層が消えたんじゃなくて、見えなくなっただけです。
「じゃあ人間が読める形式は要らないよね、AI内部にあればいいのでは」という疑問が出るかもしれません。
ソフトウェアは一発で完成しない。動かない、どこがおかしい、直す、また動かす。この検証・修正のサイクルを回すには、「ここがバグ」と意味の単位で指し示せる表現が要ります。
「人間が読めなくても、AIが検証・修正すればいい」という場合でも同じです。AIが「何について検証するか」を表現する層が必要になる。「ログイン機能が正しく動いているか」を確かめるには、「ログイン機能」という意味の単位を指し示せないといけない。機械語にはそれがない。だからAIが検証する場合でも、意味を表現する層を経由します。それは高級言語と機能的に同じものです。
現実のアーキテクチャで確認してみると、自然言語でのプログラミングは既に成立しつつあります。
AIに「去年御歳暮もらった人に、いい感じのお返し送っといて」と言えば、AIが解釈して実行する。これはプログラミングしてるんです。AI自体が実行環境になっていて、ユーザーからは高級言語が見えない。
現時点では、背後でAIがAPIを叩き、そのAPIは高級言語で書かれたソフトウェアが動かしています。では将来、AIがAPIを叩かずに直接システムを構成する可能性はあるか。
仮にそうなったとしても、AIが「何を作るか」を把握し、「作ったものが正しいか」を判定するには、意味のレベルで表現する層が要ります。最終出力が機械語だとしても、その生成過程で抽象化レイヤーを経由する。これは現在のアーキテクチャに依存した話ではなく、「意味を扱って手続きを生成する」という行為の構造的な制約です。
「AIが直接機械語を吐く」と主張する人は、意味と機械語の間にあるギャップを何がどう埋めるかを説明していません。このギャップを埋めるものが高級言語（またはそれと機能的に同等の抽象化レイヤー）であり、それは形を変えても消えないんです。
今１８万ぐらいで買えるパソコンでCPUもGPUも１０年戦えるレベルだと思うが？
これ以上のスペックが要求されるのって「最新のVRコンテンツをその時の最高画質でプレイしたい！」ぐらいだと思うんだけど、それはもうPCの買い替えについての需要とは切り離して考えるべきじゃないのか。
なんで「このままだと３年後にミドルエンドに買い替えるときには４０万円になっちまうぜ」みたいな話をしてるんだ？
もうここまで来たらローエンドぐらいでいいじゃん。
それで全然戦える。
もうPCのスペックをいくら上げてもゲームの画質を滅茶苦茶アップさせるぐらいしか差が出なくなってると思うんだよな。
むしろ聞きたいんだけどさ、なんでこれ以上のPCスペックを求めようとしてるの？
一つ言っておくが、「仕事で使ってる」なら会社の経費で買ってもらえばいいかだけなんだから今回はその回答を飲み込んでね。目に入れるだけ時間の無駄。
AMD A8（例えば2014年頃のA8-7600など）から最新のCPU（Ryzen 9000シリーズやCore i14/15世代）に換装した場合、AV1エンコードのスピードは「測定不能」あるいは「数十倍〜百倍以上」という次元の差になります。
これには、単なる計算速度の向上だけでなく、「ハードウェア支援」の有無が決定的に関わっているからです。
1. ソフトウェアエンコード（CPUパワーのみ）の場合
AMD A8はAV1という新しい規格が登場する前の設計であるため、最新の効率的な命令セット（AVX-512など）を持っていません。
AMD A8: 1fps（1秒間に1フレーム）すら出ない、あるいは処理が重すぎて途中でエラーになるレベルです。
最新CPU (Ryzen 9 / Core i9): ソフトウェアエンコード（libaom-av1等）でも、設定次第で実用的な速度（フルHDで数十fpsなど）が出せます。
倍率の目安: 純粋な計算能力の差だけで10〜20倍以上の差がつきます。
2. ハードウェアエンコード（内蔵GPU）の場合
ここが最大のポイントです。最新のCPUには、AV1を高速に処理するための専用回路「AV1エンコーダー」が搭載されています。
AMD A8: AV1のハードウェアエンコード機能は非搭載です。
最新CPU: Ryzen 7000/9000シリーズや、Intel Core 第12世代以降（内蔵GPU）には、専用のハードウェア回路が組み込まれています。
倍率の目安: ソフトウェア処理に頼るA8に対し、最新CPUのハードウェアエンコードは「瞬きする間に終わる」レベルの差になります。比較自体が酷なほどで、体感では100倍以上のスピード感になります。
