160TBのメモリに超高速でアクセスできるというシステムをHPEが構築 67
ストーリー by hylom
デカくて速いデータベース 部門より
デカくて速いデータベース 部門より
Hewlett Packard Enterprise（HPE）が、「メモリ主導型コンピューティング」というアーキテクチャを採用したコンピュータ実証実験に成功したと発表した（ITmedia、ASCII.jp、GIGAZINE）。
HPEは「The Machine」というプロジェクトでメモリ主導型コンピューティングの開発を進めている。実証実験で使われたプロトタイプは40ノードから構成されており、これらが160TBのメモリを共有するというアーキテクチャだそうだ。メモリアクセスにはフォトニクス光通信リンクが使用されており、超高速でアクセスができるという。ちなみにOSはLinuxベース、CPUはARMベースの「ThunderX2 ARM Processors」とのこと。
ネットワークワイドシングルレベルストア (スコア:1)
大昔のApollo Computerからの流れは(DOMAIN/OS)
ネットワークワイドでメモリのアクセスが出来たね。
起動画面が好きだったな
今現在のデータ量 (スコア:1)
リンク先 [itmedia.co.jp]には
> HPEでは、今回の実証実験を受け、最大4096YB（ヨタバイト※）の単一メモリシステムにまで拡張可能と予想。
> この規模は今日の宇宙全体に存在するデジタルデータ総量の2万5000倍にあたり、この規模メモリを活用できれば、
> 例えば地球上の全ての人々の電子カルテ、Facebookの全データ、Googleの自動運転車全ての運転情報、
> 宇宙探索から得られた全データを同時に処理することができ、前例のないスピードで回答を得ることができるとしている。
とあるのだが、「今日の宇宙全体に存在するデジタルデータ総量」は吹きすぎだ。
「地球全体」ならまだ判らなくはないが、宇宙人が持ってるデジタルデータを忘れている。
日本語訳がちょっと意味が違う (スコア:5, 参考になる)
英語で述べられているのは、We’re planning for 4,096 YT of data, more than 250,000x the size of our digital universe today. [hpe.com] です。"our digital universe today" 、つまり「今現在、我々（人類）が扱っている全デジタルデータ」みたいな意味合いでしょう。
ここのところ人類が扱っている全データがゼタバイトとかそのへんなので、その一つ大きな接頭辞の4000ヨタあたりだと25万倍ってのはまあまあ妥当なところだと思います。
Re:今現在のデータ量 (スコア:1)
今日の宇宙全体に存在するデジタルデータ総量なんてヨタバナシ信用するやつがいるか!
Re:今現在のデータ量 (スコア:1)
> 例えば地球上の全ての人々の電子カルテ、Facebookの全データ、Googleの自動運転車全ての運転情報、
> 宇宙探索から得られた全データを同時に処理することができ、前例のないスピードで回答を得ることができるとしている。
42
Re: (スコア:0)
Re: (スコア:0)
再帰〜
Re: (スコア:0)
このシステムは別宇宙に存在、そんなすごいものだったのか！
Re: (スコア:0)
ヨタの上の接頭辞が必要だ。
1000ヨタ = 1ホゲ として、4ホゲバイトまで拡張可能。
Re: (スコア:0)
よくあるITmediaのへんな訳かと思ったが、HPE日本のせいか。
HPEの発表では、the entire digital universe
Re: (スコア:0)
アカシックレコードまで保存できるとはすごいですね。
いや、あれはこの宇宙に存在していないのか？
Re: (スコア:0)
重複排除の力ですよ
でも (スコア:0)
お高いんでしょ？
Re: (スコア:0)
パソコンのメモリも16KB→16MB→16GBって感じに順調に増えてるし、
俺が死ぬ頃には「160TBのメモリがあれば十分だ(ﾄﾞﾔｧ」って言ってるかもしれない。
Re:でも (スコア:2)
16kBのころはさすがに「パソコン」じゃなくて「マイコン」時代かと。
MZ-80Kが標準32kで48kまで増設化と記憶してる。MZ-80B(64k)でもまだ「マイコン」って呼んでた。過渡期だとは思うが。
Re:でも (スコア:2)
マイコンとパソコンの境目な感じですが、素のPC-6001は16KB。+16KBのRAMカートリッジも持ってる友人がうらやましかった。
MSXなんかはもう「パソコン」な時代だと思いますが、規格上は最小8KBで、初期のエントリー機種はだいたい16KBだったかと。
Re:でも (スコア:1)
マイコンとパソコンの境目な感じですが、素のPC-6001は16KB。+16KBのRAMカートリッジも持ってる友人がうらやましかった。
MSXなんかはもう「パソコン」な時代だと思いますが、規格上は最小8KBで、初期のエントリー機種はだいたい16KBだったかと。
ただ、大人気だったPV-7の存在を忘れてはなりませんよ。
8KBだとメモリがC000HではなくE000Hからなのでワークエリア分を除くと残りは雀の涙。
4KBほど？
それでも自分でプログラミングをしないのであれば足りるんですよねぇ
Re:でも (スコア:1)
> マイコンとパソコンの境目
パピコン？
#私はPC-6001mk2でした。
Re: (スコア:0)
Re: (スコア:0)
> 「パソコン」じゃなくて「マイコン」時代かと。
パソコンサンデー：せやろか？
Re:でも (スコア:2)
あれは、もうMZ-2000の時代。
と書いてみて、私はMZ-80Bまでがマイコン世代で、2000以降がパソコンという固定観念があるようです。（80Bを自分が持ってたから）でMZ-80Bが標準で64k使い放題。
でも、良く考えるとMZ-80Bは「当時のハイエンド」だってことも、すっかり忘れてる。
Re: (スコア:0)
> 「パソコン」じゃなくて「マイコン」時代かと。
すがやみつる：せやろか？
Re: (スコア:0)
月刊ASCII 1979年9月号にのってるNEC PC-8001の広告にはパーソナルコンピュータと記載されている。
ちなみに標準メモリは16KBで32KBまで増設可能。
本文の記事でもマイコンとパーソナルコンピュータが混在している。
まあパーソナルコンピュータの略称としてのパソコンは出てきてないみたいですが。
Re:でも (スコア:1)
PC-8001の時代には既に「パソコン」派と「パーコン」派が宗教論争してたような記憶があります。1980年から1981年かな。
Re: (スコア:0)
パソコンだとメモリが大容量になっても使いみちがキャッシュくらいしかないからなー。
時期的に (スコア:0)
Optane連ねたシステムだったりして
# 夢の160TBスワップファイル
ストレージにキャッシュを積む構成との費用対効果 (スコア:0)
従来ストレージに積んでいたデータをオンメモリに置くことでスピードアップを図ろうってことなんだろうけど、
従来型のストレージ＋揮発性メモリという構成でも、キャッシュを増やしていけば、その性能は漸近的に今回の構成のそれに近づくはず。
どこかの段階で費用対効果が最良になるバランスがあると思うんだけど。
それとも、すべてをメモリに置くことで、従来型構成では実現できない質的なブレイクスルーがあるんだろうか？
Re: (スコア:0)
近付くだけで超えられないでしょ。こういうのはコスパではなくパフォーマンスで買う企業が対象。
より多くのデータをストレージではなくメモリにおけるようになればIOPSが上がるからそこがボトルネックになってる用途には嬉しいでしょ。
Re: (スコア:0)
コストが安ければその分を他の能力アップに使えるんだから、コスパが問題にならない用途なんて事実上ない。
例えばコストが半分なら、同じものをもう1台買える。
Re:ストレージにキャッシュを積む構成との費用対効果 (スコア:1)
コスパってコストとパフォーマンスの比で決まるのでこいつ以外で処理できない作業がありなおかつその作業を処理できると今現在以上の大きな利益を挙げられるか強豪に対して大きく優位に立てるなんて場合コストよりパフォーマンスが大きく上回ったりする。
結局装置のコスパなんて企業によって変わる。
Re: (スコア:0)
何を言っているのかわからん。例えばどんな業種のどんな領域よ？
Re:ストレージにキャッシュを積む構成との費用対効果 (スコア:1)
航空宇宙産業や軍需産業、自動車産業あたり？
HPは我々が気付いていない何かに気付いているのかもしれない。HPは単に何かを勘違いしているだけかもしれない。
Re: (スコア:0)
薬もそうかも 山ほどの化合物のタンパク質との相互作用を見れる
仮想記憶も妥協の産物で過去の遺物と化すのか (スコア:0)
死語にはなるだろうが
富豪も一般化してしまえば富豪ではない
# 美人も一般化してしまえば美人ではない? あれ?
Re:仮想記憶も妥協の産物で過去の遺物と化すのか (スコア:1)
現在はCPUがメインメモリに直接結線・管理するのが当たり前だが、その下位にチップセット（ノースブリッジ）を介した外部メモリがまた付くようになるのね。
Re:仮想記憶も妥協の産物で過去の遺物と化すのか (スコア:1)
実に簡単なことだがHPEのホラとあいまって気づきにくい
Re:仮想記憶も妥協の産物で過去の遺物と化すのか (スコア:1)
こういう構成って、結局その単一のストレージへのアクセスがボトルネックになって性能出ないような。
いまどきのスパコンのような分散メモリと高速インターコネクトの組み合わせの方が、おなじくらいのお金を投入するなら性能出るよね、きっと。
まあそういうのは当たり前の解すぎて研究プロジェクトには不向きなんだろうけど。
Re:仮想記憶も妥協の産物で過去の遺物と化すのか (スコア:1)
Re:仮想記憶も妥協の産物で過去の遺物と化すのか (スコア:1)
160TBのメモリを単一ストレージとして載せて The MachineのようなAPIでアクセスするのと、
40ノードに4TBずつ載せてメッセージパッシング型APIでアクセスするのとで、
どちらが性能が出るのかって話。
前者だと単一ストレージへのアクセスがボトルネックになるんじゃないかってこと。
Re: (スコア:0)
当然仮想化して、個々のプロセスからはどのノードの何番地かは気にしなくてすむようにするだろ常識的に考えて
Re: (スコア:0)
セキュリティといった意味でユーザー、アプリ、タスクといった単位でメモリ空間を分離するのには、利用され続けるのではないでしょうか。
# 美人の定義次第で、合格点以上とするのか上位何％とするのかですね。
Re: (スコア:0)
MS リサーチの作ってた Singularity OS がそういう奴だよね。
そろそろファイルやめよう (スコア:0)
もうストレージこんだけ速くてデカい時代になってるんだからさ
全部メモリマップドIOにしてOSやハードウェアが裏でごにょごにょやってくれる方が楽じゃね？
Re: (スコア:0)
読み込みはともかく書き込みはどうすんだよ
Re: (スコア:0)
memory mapped I/O って、普通は uncached にするので目に見えて遅くなります。
framebuffer なんかはさすがに遅すぎるってんで uncached じゃなくて write-combined にしますが、それでもちょっと遅い。
HPE の The Machine の場合、大量のノードから共有されるんで、単純に cached にすると memory consistency を保つための
プロトコルでネットワークが飽和しちゃって実用的性能出せないような。
だからといってアプリ側で明示的に cache flush / invalidate した時だけアクセスするようにすると、それって read/writeと
同じじゃんってことになりそうでメリットが薄れますね。
Re:そろそろファイルやめよう (スコア:1)
そこが新規性なの
Re:そろそろファイルやめよう (スコア:1)
なるほど、ありがとうございます。
ググったら
https://lwn.net/Articles/655437/ [lwn.net]
が出てきました。
こんな感じ
https://github.com/FabricAttachedMemory/libfam-atomic/blob/3362941b36a... [github.com]
でアクセスするんですね。
使いものになる性能出すためにはこれが現実的なアプローチだけど、メモリマップしてアクセスするという言葉で想像するのとはだいぶ違うプログラミングスタイルだなあ。
分散メモリをMPIみたいなメッセージパッシング式のプログラミングスタイルで使うのと比べて性能面でどうなのか気になるところです。
ThunderX2っていうと (スコア:0)
Cavium ThunderX2 [cavium.com]っていうとARM版Windows Server [srad.jp]も対応するCPUか
超高速？？ (スコア:0)
超高速と言われても
テープメディア比ならフロッピーだって超高速だろ？
そのフロッピーだって
Googleドライブの方が高速だし
むしろ160TBにランダムアクセスできることのほうがすごいと思うけど
160TBのテープメディアを光の速度でまわしても太刀打ち出来ないだろ？
もちろんそんなのテープもヘッドも耐えられないし
まあでも (スコア:0)
やることは凄いエロ動画視聴になるだけなんですけどね。