AMD 9950Xで驚異のCSVパース速度21GB/sを達成 SIMD活用
引用元：https://news.ycombinator.com/item?id=43936592
IntelがAVX-512をコンシューマー向けに入れるのに何年もダイスペースを割いてたのに、やっとライブラリが対応してきたら、目標達成したのにやめちゃうとかマジでクレイジーだよね。AMDがAVX-512サポートでIntelを出し抜いたわけじゃなくて、Intelが自社の投資から手を引いたせいでAMDだけにAVX-512があるってのがね。
それこそIntelがよくやる手だよね。市場を育てて（Optaneとか）、いきなり撤退する（Depth Camerasとか）。新しい技術にドカンと力を入れて、普及しないとすぐに見捨てるのを繰り返してる。ゆっくり育ててタイミング見て一気に推せばいいのにね。OptaneなんてLinuxカーネルでサポートが成熟してきた頃にやめたし。半アイドルVM向けの代替RAMみたいな変なコストカット目的で売り出したのも意味不明だった。このパターン、iAPX 432の頃からずっと変わってないよ。
HP PA-Risc、SGI MIPS、DEC Alphaを潰して、SparcやPOWERの普及を大きく妨げた（他にもあったっけ？）という点ではね。でもさ、彼らは1998年までに何も出さずに終わらせることもできたんだよ。そしたら競合アーキテクチャも潰せただろうに。それなのに2020年までサポートを続けたんだから。ItaniumのVLIWに必要だったのに全然手に入らなかったのは、まともなコンパイラサポートだよ。NVIDIAはCUDAでこれがばっちりできてる。NVIDIAにポートするのは簡単だし、そこでかなりの高速化が得られる。AVX-512は、ICC（と適切にコンパイルされたnumpy/scipy）ではしっかりサポートされてたみたいだけど、そこまで劇的なスピードアップはなかった印象だな。
Optaneの撤退は信じられないくらいイライラしたな。Intelはレガシーにしがみつく遅い導入者だらけの業界（RDBMSとか）で、ワークロードをマジで大きく改善する技術を開発したんだ。彼らは投資を続けて、自分たちの主張が誰の目にも明らかになって、遅い導入者たちがやっと理解し始めたまさにそのタイミングで…終わらせたんだ！
あんなに下手な手があるかってくらいだよ。数年経った今でも、Optaneドライブがなくて困ってる。代替になるものが今だにないからね。あと少しだけ持ちこたえてたら、2040年になっても買ってくれる企業顧客層を作り出せてたはずなのに。
＞What the VLIW of Itanium needed and never really got was proper compiler support.
これはちょっと控えめな言い方かな。Itaniumみたいな静的スケジューリングのVLIWマシンの根本的な問題は、全ての複雑さをコンパイラに押し付けちゃうことなんだ。残念ながら、良い静的スケジューラを作るのは本当に難しいってことが判明したわけ。
対照的に、動的スケジューリングのアウト・オブ・オーダーのスーパースカラーマシンは上手くいくけど、全ての複雑さをシリコン側に入れ込むんだ。昔はトランジスタのオーバーヘッドが高かったから、静的スケジューリングのVLIWが良いアイデアに見えた。でも、静的スケジューリングはずっと難しいままだったのに、動的スケジューリングのトランジスタのオーバーヘッドは取るに足らないくらい安くなったんだ。「ハードウェアをぶっ込め」が、「より良いソフトウェアを作れ」に圧勝したってことだね。
おっしゃる通り。IntelはAVX 512を意図的に将来の世代ではXeonとかエンタープライズ向けプロセッサ専用の機能にしちゃったんだよ。この後退したせいで使える人が人工的に制限されて、企業はもっと高いハードウェアに投資せざるを得なくなる。
Arc GPUでも似たようなことしてるんじゃないかと思うね。GPU仮想化（SR-IOV）をサポートしてないんだから。まあ、第12～14世代の内蔵チップ全部でi915ドライバー経由でvGPUサポートをいくらか追加したけどね。同じGPUで複数のVMで同時にグラフィックアクセラレーションできるのは嬉しいけど。
確かに。Octane/3dxpointはぶっ飛んだ未来技術って感じだったのに、市場に出てたった5年で消えたとか？短絡的すぎでしょ。
この記事では、こういう速度が出てたんだよね：
オリジナル：18 GB/s
AVX2：20 GB/s
AVX512：21 GB/s
これはAMDのCPUだけど、AVX512のメリットがAVX2に比べてわずかっていうのは明らかだね。Intelのコンシューマー向けチップは、EコアでもAVX2はサポートしてるってことに注意ね。
でも話はそれだけじゃないんだ：これはシングルスレッドのベンチマークなんだよ。IntelはAVX512を諦めて、その分のダイスペースをより多くのコアのために空けたんだ。結果として、Intelの最高級コンシューマー向けパーツは24コアになってるのに対して、AMDの最高級は16コアなんだ。実際のIntelのベンチマークを見ないと分からないけど、AVX2からAVX512への改善がわずかなら、より多くのコアを使ったマルチスレッドのAVX2バージョンの方が、少ないコアのマルチスレッドAVX512バージョンを上回る可能性が高い。IntelのEコアはPコアよりAVX2命令の実行は遅いけど、それでもこのベンチマークではAVXの恩恵自体がわずかだしね。
Intelが機能を奪ったって怒る人がいるのは分かるけど、AVX2だけでなくAVX512があるっていう現実世界のメリットはすごく小さいんだ。ほとんどの場合、余分なコアが問題を処理することによるメリットの方が上回るはずだよ。AVX-512から恩恵を受けるすごく特定のワークロード、しばしばシングルスレッドのものもあるけど、アプリやベンチマークを混ぜて見ると、Intelは彼らがやったことを情報に基づいて決定したんじゃないかと俺は疑ってるね。
いやさ、VLIWはこれよりさらにヤバいって。コンパイラの問題って言うだけじゃ全然足りてないんだわ。VLIWってマルチタスクとかマルチテナントのシステムには全然向いてないんだよ。キャッシュの問題があってさ。コンパイラはキャッシュに何があるか分からないと効率的に命令をスケジューリングできないんだけど、隣のタスクが時間帯をどう使うか分からないと、キャッシュに何が入るかも分からないじゃん。仮想化とか入れたらもうメチャクチャだよ。
この記事で驚いたのは、9950XのAVX2パーサーが約20GB/sで、AVX-512より10%速かったってとこ。これはもう直したみたいだけど、正直AVX-512って一般ユーザーにはそこまでメリットない気がするんだよね。CSV解析速度が20GB/sでも十分だし。ベクトルアセンブリ好きのマニア向けじゃないかな。
動的な共有がない、アクセラレーターみたいな固定されたワークロードでしか動かないんだよ。
あいつら（Intel）、市場をセグメント分けするのに必死なんだよな。ECCとかAVXとかOptaneのサポートとか（特定のサーバー向けSKUだけ）。マジ嫌い。家でPC使うユーザーとしても嫌いだし、エンタープライズの客としても嫌いだし、株主としても嫌い。
Optaneの失敗は予想できたこと。Intelだけが維持してたけど、これはすごい技術なのに「使い道を探してるソリューション」だったのが問題。電源断に強い領域ならNVDIMM、高速ストレージならFlashの方が速くて安い。Optaneは両方から挟まれてた。Intelは今ピンチで、赤字脱却と競合対策に集中が必要。儲からない脇道プロジェクトはやめるしかない、イノベーションも潰れるけどね。
Optaneが中止になったのは、メーカーが工場（fab）売っちゃったからだよ。
へー？それって、ECDLのロイヤリティ払ってないのがバレたのと全然関係ない偶然？
＞実際のIntelのベンチマーク見ないとだけど、AVX2からAVX512の改善が marginal なら、コア数多いAVX2の方が少ないAVX512より速いかも。Blenderとか見ると、E-coresはAMDコア1個分の性能出すのに2個くらい必要でマジ遅い。AVX512だけが違いなら24 AVX2コアが16 AVX-512コアに勝つけど、違いはそれだけじゃない。E-coresが中途半端な数で性能もイマイチなんだよ。
何がバレたの？もう少し詳しい情報とか、調べられるリンクとかない？
＞静的スケジューリングは難しいままで，動的スケジューリングのトランジスタのオーバーヘッドはマジで安くなったって話，後者ホント？俺が知る限り，今のCPUのダイ面積とか電力は，実際の計算じゃなくてオーバーヘッドにほとんど食われてると思うけどな．
AVX-10がもう来るんでしょ？AVX-512の良いとこはほとんど持ってるんじゃない？（マジで何が違うかよく分かんないけど）
うん，VLIWは今もDSPとかGPUとかに使われてるけど，普通のコンピューターには合わないんだよな．
NVMe SSDってOptaneと大体同じ価値でしょ？Optaneマジすごかったってコメ見たけど，NVMeもほぼ同じくらい良いし他のメーカーもあるなら，意味分かんないんだけど．
どの会社もそうだよ．おばあちゃんがネットとかWord，Excelしか使わないのに，使わない機能のために50ドル余分に払いたいと思う？NPUも同じ．お客さんごとに欲しい機能と値段は違うんだってば．
＞Eコアは弱すぎて，AMDコア1個分出すのに2個くらい必要って？それは「弱い」んじゃなくてさ．ダイショット分析見れば分かるけど，EコアはPコアと比べてマジ小さくて，面積は半分以下だし電力ももっと少ないんだよ．Pコアは稀なシングルスレッド作業でしか役に立たないけど，それ以外ならEコアが勝つって．
Energy Conversion Devicesが潰れた時，Intelがその技術パクって，OptaneのPCMメモリのロイヤリティ払わなかったみたい．Case No． 12-43166がOptaneを終わらせたんだよ．つまり，IntelがIntelだったからOptaneは消えたってわけ．
AVX-10には前，AVX-10/256っていうのがあったんだけど，それはAVX-512から512ビットレジスタ無くしたやつね．でも最近無くなったんだ．だから今AVX-10は，AVX-512の拡張機能のほとんどのセットになってて，これからの目標は，次のバージョンが出るたびに前のより機能が増えるのを保証すること（AVX-512みたいにバラバラな拡張機能がいっぱいあるのとは違う）．
それ多分，単にメモリの帯域幅がボトルネックになってる問題ってことだと思うよ．もっと計算必要なタスクなら話は別だろうけどさ．
Optane懐かしいなー。金融系時系列DBの会社で働いてんだけど、NVMeより速くてRAMより遅い層のユースケース、マジでいっぱいあるんだよね。しかもこういう会社ってお金めっちゃ持ってるのに。なんで誰もこの隙間埋めないんだろ？技術的に特許が強いのかな？
<br>とか\rとか;とか”の文字に対して4回比較して3回orする代わりに、よくあるテクニックとしてshuffle 1回、比較 1回、or 0回で済ませる方法があるよ。このトリックについてブログに書いたんだけど、https://stoppels.ch/2022/11/30/io-is-no-longer-the-bottlenec… （Trick 2）
追記：彼らはternary logicを使ってorを1回減らしてるね、これは良いね。具体的には(a | b | c) | dをvpternlogdとvporで計算してるっぽい。
文字セットが限定されてるならこれ当てはまるけど、shuffleにはレジスタが余分に必要になるから、必ずしも速いわけじゃないんだよね。試してみたけど、ここでは速くならなかったよ。
Intelめ、消費向けCPUからAVX-512全部消しやがって、代わりに全部にslow coreぶっ込んでくるわマルチポンプも考えねえわ、って感じだろ。
もっとコメントを表示（1）
これの多くは、Intelが抜け出す必要があった10nmの穴に根ざしてるんだよな。歩留まりが悪いからコストが高いし、だからダイを可能な限り小さくしてAtom由来のコアを出して、エネルギー効率対策として売り出したんだ。高いパーツはもっと大きくできるし、サーバー/クラウド分野を維持するためにそっちの利益を削るぞ、と。あと、俺たちの収益はゴミみたいになって市場シェアも失うけど、少なくとも頑張ってみたぞ、って感じ。
Intelの問題はFab失敗より、アーキテクチャ更新をFab待ちで止めたこと。Pコアはデカすぎ、Eコアは古すぎになり、Alder Lakeで混ぜただけ。プロセス・Fab間で設計を移植できない影響は今も出てて、今年のノートPC向けCPUのHyperThreadingはIntel Fab製の一番安い部品だけで、TSMC製は違うみたい。（要約）
え、これってSepが2023年6月に導入されてからたった2年足らずで、約3倍の驚異的な改善ってこと？
ハードウェアがめっちゃアップグレードしてるのにそれは主張できないでしょ。
彼らは新しいハードウェアで0.9.0と0.10.0を比較してるんだ。（21385 vs 18203）だからソフトウェアによる向上は17％。
それなら旧ハードウェアの0.9.0（13088）に17％を足すと15375になる。
バージョン0.1.0は7335だった。
だから…15375/7335で→たった2年足らずで約2.1倍の驚異的な向上ってことだよ。
彼らは同じハードウェアでの以前のバージョンのsepに対して3GB/sの向上を主張してるんだ—そして”マーケティング”ベンチマークとは違って、実際に達成した速度と使ったハードウェアを含んでる。
ちょっと気をつけたいのが、3GB/s速くなる前でさえ、ほとんどのディスクの帯域幅を超えてるってことね。だからボトルネックはメモリにデータを読み込むとこだよ。CSVがメモリで作られたり消費されたりするアプリってそんな知らないから、どんな使い道があるんだろって思うな。
”We can parse at x GB/s”ってのは、だいたい”we need y％ of your CPU capacity to saturate I/O”の逆みたいなもんかな。Higher x -＞ lower y -＞ more CPU for my actual workload。
Slower than network！ In-memory processing of OLAP tables、streaming splitters、large data set division…でもパースが速いほど、パースに費やす時間は減って、実際の作業にもっと時間をかけられるよね。
正直、ちょっと予想外だったかな。良い内部ネットワークとメモリ上のデータがあるDBなら、ディスクから読むよりネットワークで取る方が速いこともあるんだよね。もちろん、もっと速いディスクとメモリでアプリサーバー作って、キャッシュも実装できるけど、それって高度なリソース使ってDBを自作してるようなもん。高頻度取引みたいなのは別として、普通のウェブバックエンドなら、そこそこのDBとクエリを最適化できる人がいる方が、多くの開発者にとってずっと楽になるんだ。
これ、Infinibandでも似たようなことできるんだけど、そっちはまあ予想通りって感じかな。一度、ネットワーク帯域幅がメモリ帯域幅と同じくらいっていうシステムを使ったことあって、本物のHPCな人たちには驚かないかもしれないけど、俺はビックリしたね！
Decompression is your friend。たいていCSVってめちゃくちゃ圧縮効くんだ。Multiple cores decompressing LZ4 compressed data can achieve crazy bandwidth。コアあたり5 GB/s以上とか。
まあそうかもだけど、ハードウェアだけで3倍速くなるのが当たり前だったmoore’s law時代はもう過ぎたと思うな。それでも、現代においてはかなりすごいことだよ。
> You can’t claim this when you also do a huge hardware jump
うーん、彼らはそうしたけどね。個人的には、これは面白い見方だと思うな。このソフトを年々使った場合に得られる”real performance”を見るレンズになる。（まあ、それがmisleading or fallacious claimじゃないとは言わないけどね。）
マジかよあのchart、”massive performance gain”って見せるためにCPU4世代分もすっ飛ばしてんじゃん。この投稿はゴミ行きだわ。
でも、新しいハードウェアで0.9.0のテストも繰り返してるんだよ。だから最初の大きなジャンプはハードウェア変更で、二番目のジャンプはソフトウェアの変更なんだ。
これ、全CPUでの結果みたいだね。シングルスレッドだと1.3 GB/sじゃ全然すごくないよ。
ほんとそれ。ベンチマークってさ、ハード固定してデータをメモリに入れてシングルコアでやるのそんな難しい？ああいうグラフ見ると、”他に何隠してるんだ？”って思っちゃうんだよね。
マジで速いCSVパーサー探してるなら、https://github.com/dathere/qsv 見てみてよ。
うーん、だってさ… 9950xのシングルコアだと、メモリコピー帯域幅で16 GB/s出すのも大変だろうし。それより一桁落ちるくらいなら妥当に見えるけどね。
4世代？
5950xはZen 3
9950xはZen 5
Zen 2 (3000番台)以降、モバイルCPUはデスクトップ版より番号が千番上がってるんだよね。追記：Zen世代をNとすると、Nx2000ってことかな。
それに、たとえ2世代だとしてもさ、CPUの世代進化って昔の、お菓子が1ドル以下だった頃みたいじゃなくなっちゃったよね。
運が良ければ、Arthur Whitneyがこれに触発されて、これを打ち負かすワンライナーか、shakti engineのアップデートと一緒にワンライナーを投稿してくれるかもね。進歩だ！
うわー、誰がそんなに速く何百万行ものCSVを処理する必要があるのか想像するのも恐ろしい…
CSVって社内でもめちゃくちゃ普通のデータ交換形式になったし、圧縮も簡単だしね。NICカードの速度でCSVがどんどん吐き出されるコードベース（Netflow由来のデータとか）で作業したことあるよ。集計されてCSVでマスターに送られてた。
でもさ、なんでみんな代わりにprotocol buffers使わないんだろうね？protobufってそんなに難しい？
金融業界にはいっぱいいるよ。どこのFinance会社ともCSVでデータ共有できるし、向こうで処理できるからね。テキストだからさ。
人間が作る情報なんてせいぜい秒間数バイトだよ。
金融取引の意思決定だけしてたって、21GB/sなんて無理。アルゴリズム同士の話だよね。
そんなに投資したアルゴ同士が、わざわざCSVをやり取りする必要あるのかな？
Protobufはなんか面倒だし、読み書き遅いんだよね。
CSVの方がprintfで作るのも読むのも簡単で、エスケープもそこまで難しくない。
Protobufはライブラリとかスキーマとか色々準備いってAPIも使いにくい。
可変長とかあるからライブラリも結局遅いみたい。
俺の経験だとprotobufは遅くてメモリ食うし、コードも無駄に大きい気がする。
Protobuf作った人のcapnproto.orgも見てみてよ（https://capnproto.org/）。
CSVがprotobufより速いか試してないけど、速くても驚かないかな。
「CSVはprintfで作るのも読むのも簡単」って言ってるけど、
俺が見た中で、壊れたCSV作っちゃうソフトや、まあまあ正しいCSVなのにパースできないソフトがいっぱいあるのを見ると、それは違うと思うよ。
printfでサクッと書けるから簡単そうに見えるけど、ほとんどのプログラマーが考えもしないようなエッジケースがいっぱいあるんだ。
やり取りする両方（送り手と受け手）を自分でコントロールできるなら問題ないよ。
CSVは表形式のデータ交換にすごくいいフォーマットだよ。
特に数値データが多い場合はね。
内部サービス同士でデータを渡すなら最高だし、すごく速いんだ。
欠点はいっぱいあるけど、CSVは今でも一番よく使われてるデータ交換フォーマットだと思うよ。
もっとコメントを表示（2）
うーん、ファイルベースで一番ってことかな？
世界中のデータ交換全体で見たら、JSONがキングじゃない？
たぶん2番目はform-dataかな、あれって基本メールのmultipartだし。
もちろんメールそのものもデータフォーマットとしてすごく一般的だよね。
JSONがキングなのか、正直疑問なんだよね。
フィンテックで働くまではそう思ってたんだけど。
XMLが残念ながらどこにでもあるんだ。
うーん、もし単に内部ツールなら、structの配列で良くない？
パースもいらないし、Optionalも持てる。
何もせず渡すより速いものはないでしょ。
人事の人とかに「WorkdayとかのUIで右クリックしてProtobufをエクスポートして」なんて絶対言えないって。
ビジネスの世界のほとんどの人はExcelとかSpreadsheetで生きてるから、CSVがすごく自然に感じるんだよ。
データ転送としてはCSVがエッジケースだらけだって一日中議論できるけど、結局お客さんが使ってるのはこれなんだ。
あのデータサイズでCSV選ぶのは疑問だな。
サイズの効率も悪いし（実数はバイナリよりテキストの方がバイト食う）、
パースも最速じゃない（エスケープがあるからね）。
あと、区切り文字とかエスケープが一つでもズレると、それ以降全部ダメになるんだ。
エンコーディングとかデリミタの違いとか、他の問題もいっぱいあるしね。
一番の理由は、依存関係がめんどくさいからだよ。特に別の言語を使ってるチームが同じフォーマットに対応する必要があるときは、さらにね。
parquetデータとかSQLite DBとか、他のものでデータをやり取りできたらいいなとは思うんだけど、それには上流・下流の他のチームに専用のサポートをお願いする必要がある。
CSVなら、誰でも、何でも対応してるんだ。もし対応してなくても、簡単なパーサーならサクッと作れる。CSVのパーサーを全てのエッジケースまでちゃんと作るのはすごく難しいのは知ってるけど、別にそこまで完璧じゃなくていいんだ。自分たちが使う機能だけサポートできればいい。それならシンプルで早いし、みんなすぐにデータを処理する本来の作業に移れるからね。
JSONって表形式のデータには向いてないんだよね。で、結構な量のデータが表形式なんだ。
正直、21Gb/sの速度が役立つほどデカいスプレッドシートを読み込む必要なんて、まずないと思うけどね。
人間が意思決定やテキスト情報を生成するレートはせいぜいバイト/秒くらいだ、って？
うん、それはそうだけど、その意思決定の結果が持つ価値はもっと大きいんだよ。ユーザーにIDをつけたり、取引にIDをつけたり。どこで、いつ行われたかを保存したりね。そういうのを積み重ねるとデータ量は増えるんだ。
うん、社内向けによく使ってるよ。パースや使う上で困った記憶はないな。表形式データのファイル交換形式として、うちではちゃんと機能してる。もちろん、うちは文字セットが基本的にASCII文字と数字だけだから、カンマも引用符もいらないくらいだけどね。
あるある。特定のスタートアップが陥りやすい状況だと思うよ。
– 最初はデータが少ないからCSVでいいや、と誰かが決める。非エンジニアの人も読みやすいから、Excelくれって言われなくなるし。ここでいう非エンジニアってのは、データを見る必要があってExcel得意な人なら誰でもね。ビジネスサイドから研究者まで色々いる。
– CSVで作ってるから、社内のプロセスもCSVを使うようになる。CSVを消費する重要なパイプラインをいくつも作る。
– 突然データが10倍、100倍、それ以上になる。何かうまくいき始めたからだ：顧客が増えた、センサーのスループットが上がった、研究が進んだ、とかね。
– すると、数百万、数十億行のCSVを取り込むのを最適化する意味が出てくる。これは、よりこの種のデータに向いたフォーマットに社内プロセス（と他のチームのやつも）を移行し始めるまでの時間稼ぎになるんだ。
それ（IDとかの追加）は、少しの情報しか追加しないと思うけどな（DBならJOINでモデル化されるだろうし）。すごく非効率にやらない限り、そんなに大量のデータを増やすことにはならないよ。
21 GB/sのCSVを処理した”結果”を保存することを考えるだけで、ゾッとするな。願わくば、何か役に立つ集計であってほしいけど、これが構造化データに対する検索の裏側で動いてるなら、どっかに保存しなきゃいけないわけだし…。
何十年分ものデータがそのフォーマット（CSV）で溜まってて、それをデータベースに入れたい、って場合があるかもしれないね。
唯一リアルな例として思いつくのは、USのオプション市場のフィードかな。今は50 GiB/sくらいまでいってて、1日6．5時間オープンしてる。データ分析のために一部だけ抜き出したとしても、膨大になりうる。こういうとこにはCSV使うべきじゃないって同意だけど、きっと使われてるんだろうな。
うん、そういうサポートできるフォーマットはないね。
俺は数値データ（センサーの値とか）に偏ってるから、ライブラリとか依存関係を気にしなくても
data = (uint32_t *)read(f);
とか
data = struct.unpack…
みたいにできるんだよね。
君はもっと複雑な、構造が必要な可変フォーマットデータを扱ってるみたいだね．
標準ってのは（単体だと）最高じゃないことが多いけど、現実では広く使われてるから最高なんだよ。
この目的でCSVを置き換えたいって想像してみてよ。
技術的には超理にかなってる。だから調査して、もっと良い標準考えて、今あるやつの必要な機能全部網羅してるか確認して、リファレンス実装書いて、さあ採用してもらおうって行くわけだ。
最初に行ったところで二つ質問されるんだ。「ウチの提携機関でこれ受け入れてるとこどこ？」と「これに切り替える実際的なメリット何？」ってね。
一つ目の答えは「誰もいない」だし、二つ目は保守性とかプログラマーがハッピーになるとか、クライアントの名前がアクセント付きでもちゃんと処理できるとか、なんか曖昧で適当な感じになる。
次に行ったとこも同じ質問してきて、最初んとこ興味示さなかったから、答えはまた同じ。
「Good Enough」な既存の標準を置き換えるのって、マジで超大変なんだよね．
実数はバイナリよりテキストの方が保存容量食うって言うけど、データセットの数値の分布によるかな．
小さい数値が結構あるなら、特に64ビットとかの大きいバイナリエンコーディングと比べると、テキストの方が効率的な表現になることもあるよ．
JSONはさ、XMLが難しすぎるからって出てきたのにさ．
デベロッパー達は「そうだ、XMLにあったもん全部JSONにハックして戻そうぜ！ただしもっと悪く、非標準でな！」って感じだよね．だって結局そういうのたまに必要になるって分かったからさ！
うん、XMLパースするの嫌いだけど、複雑なJSON表現が引き起こすラヴクラフト的世界観みたいなAPI設計と付き合うよりはマシかな．
JSONのtabular data形式は、CSVと比べて行ごとにブラケットが数個、ファイル最初と最後に付くだけだよ．圧縮すればこのわずかなビットなんてほぼ消えるし、その代わりに標準フォーマットが保証されるんだ．
俺的には良いトレードオフだと思うけどね．
上の皆さん、素晴らしい回答どうもです．
Cap’n Protoってやつがまさに君が説明してること（インメモリ表現とワイヤーフォーマットが同じで、それを見てgetter/setterメソッドが生成される）をやってるみたいだよ．
アセンブリ言語を見るのかと思ったら、C#が出てきてマジで驚いた．
超すごいね！
ナイスワーク！
モダンな.NETは、多くの人が「高レベル言語」と考えるものの中で、SIMDとvector intrinsicsとの連携が一番深いよ．
https://learn.microsoft.com/en-us/dotnet/standard/simd
MicrosoftのTanner Gooding氏がこの分野の開発の多くを担当していて、彼のブログ記事もいくつか参考になるよ．例えばこれとかね．
https://devblogs.microsoft.com/dotnet/dotnet-8-hardware-intr…
