CPUアーキテクチャについて語れ 43
■ このスレッドは過去ログ倉庫に格納されています
教えてください！
x86系CPUのコア数なんですが、将来的な見通しとして最大何コアまで行きそうでしょうか？
パラレル動作するインタプリタを作っておりまして、スレッド用のスロットをいくつ確保するかを仕様として決め打ちしたいのです x86といえばWindowsだが
Windowsの論理プロセッサ数はクライアント版（Pro）が256とかだっけか
サーバだとそれ以上。 >>4
ありがとうございます！
このページによるとWindows Server 2016では512論理プロセッサとあります
http://www.atmarkit.co.jp/ait/spv/1612/21/news047.html
このくらいを考えておいた方がいいってことですね >>5
要求がよくわからんから大くくりの回答しかできんかったわ
市場の顧客の条件にも依るんじゃないか。
デスクトップPC向けが256論理コア行く事なんて向こう10年はなさそうだし。 >>6
いや、充分です
考えてみればマイクロソフトが一番情報を持っているだろうし
ありがとう！ >>1000
HBM1はむしろ高いよ
1層2Gbの非効率なメモリダイとロジックダイとTSVを使う高級規格
コスト的な理想はロジックダイなし単層で小型の最新プロセス版WideI/Oメモリを作ることだと思う
HBM3の規格と製造プロセスと共通化するのがええ ハイエンドサーバとかの場合、MSに聞くよりハードウェアベンダーに聞いたほうがいい
ハードウェアベンダがサポートするOSを使うのが基本だからな >>8
LC-HBMの暫定が確かそんな仕様だった
が、実装都合上メリットが無いとして破棄
使う側からはメリットである帯域もただでさえ少ない容量も減るというスペースシャトル並みの本末転倒
そしてFabはTSVの熟成用生贄が欲しいのに使わないなら態々金掛けて新規格を採用する意味がないという
まぁ色々思うところはあるが、現存のHBM規格は価格以外のデメリットが取り敢えず無いからして
低価格化して普及するなんて今までも山程あったわけで
取り敢えずは問題なかろう
問題は値段下がるより先にプロセッサのUMC部の値段がソイツを上回りそうって事か
まぁそうなったらそうなったでみんな美味しいから良いか >>10
現状のHBMはコストこそが絶対的なデメリットで
そこには技術的な背景があるから問題になっていて
用途拡大も進められれずにいるんだよ とりあえずLCもスタックドメモリでTSVを使う規格だった
TSVには工程としてのコストとダイエリアのコストと歩留まりコストがあり
高コストな技術だと言われてる
だからニアメモリで別途ファーメモリのDDRを使うAPUなんかには
初めから容量は捨ててTSVの無い1枚チップで良いじゃんって話をした
また帯域を落とすのが本末転倒なのでLC規格とは違いバス密度は落とさない
バス幅半分にするのと同時にエッジ長と面積も同時に半分にする
実装の最小単位を落とせば使いやすくなるだろうって話であって
エッジ幅や面積あたりで見た時の帯域効率はHBMと同じって話 今の性能、ダイサイズ位のAPUならGDDR5で十分
なんでそんなにHBMに執着するのか >>12
それこそ本末転倒なんだよなぁ
そんなんならダイのDRAMコン増やすかSRAM増やすで十二分に効果がある範囲にしかならない
寧ろダイの拡大の方が現実的だろう
何でLCで密度を落とす選択をしたかと言えばインターポーザにSiがどうしても必要だからだ
またTSV“自体”のイールドは改善のしようがある
だがこれはメインのロジックダイとHBMを貼り付ける都合上かなり大きくなってしまう、配線も増える
半導体のイールドとコストはインターポーザと言えどウェハから作る関係上、影響を受ける
どころかコレを作るためだけにラインを一つ消費するだけのコストが掛かる
その上共通化できないから製品毎に専用、しかもサイズの異なるダイを二つかそれ以上接合しないといけないという地味に難易度の高い実装
一方スタックドDRAMであるだけのHBM自体は小さくその上安価なDRAMプロセス製の規格量産品
故にHBM“自体”のモンキーモデルはこれを必要とはしない
どーやって引っ付けるかがネック
>>14
上がらねぇんだよ
論理的にも物理的にもほぼ限界
だから現状唯一面積さえ差し出せば向上出来るポイントである粗粒度並列化、その為の帯域要求
現状、コレ以外のソリューションは軒並みデファクトを置き換えられる程のものじゃない
他に方法があればこんな米帝プレイ的なピン数のゴリ押しに頼ったりしないさ >>13
GDDRにすると
・チップあたりの帯域幅が数分の１
・転送1bitあたりの電力が数倍
・チップあたりのch数が少なくレイテンシが長くなる
といった辺りがいまいち >>15
DRAMプロセスだから１ダイあたりで16Gbit
只のニアメモリであってダイコストはまったく普通のDRAMだよ
SRAMはどんなに増やしても数百Mbitが限界
DRAMコントローラが増やすためにはダイを大きくする必要があり
それはまさにコスト直結、電力増大、用途限定の本末転倒
逆に高密度インターコネクトパッケージは2.1Dのファンアウト技術を中心に遥かに開発が進んでる
インターコネクトが進化してる状況ではLC版で規格を低密度化する意味が無い 例えば2.1DではFuryやVegaで2.5D実装を手掛けてたASEの準備が出来たと言ってる
https://www.nikkei.com/article/DGXLRSP470309_R00C18A2000000/
https://semiengineering.com/wp-content/uploads/2018/03/fig2fanout.png
半年前の発表資料ではチップ合計624mm2、配線3層、パッケージ45mm角だったのに対して
858mm2、4層、67mm角にまで強化Vega64クラスに対応出来るスペックになった
真っ先にAPU + Memoryとも書かれてる
歩留まりが2.5umスペースの4層で99%まで上がったんだそう メモリをWideI/O的な一層メモリ、ロジック無しにすると
メモリベンダー側の原理的なダイ製造コストは通常のDDR系とほとんど差がなくなる
つまりベンダー側が極端なプレミアムを付ける一方的な根拠が無くなる
マイクロバンプによる高密度WideI/O系単層メモリは
昔からソニーがプレステポータブルとか携帯機で使い続けてる
なので幅広く使えないようなコスト的な根拠は無いだろう >>7
(ターゲットとしているx86の範疇外かもしれないが)ロードマップで見えてきている製品でも
Xeon Scalable ProccesorだとIce Lake-SPが最大38コアとの噂で
2way SMT/4way SMPだとシステムとしては304スレッド
Xeon PhiだとKnights Landing/Millが最大72コア/288スレッド
Knights Runでは〜88コア程度との予測がある
Xeon Phiのコアアーキテクチャが現在のSilvermontベースから
次のKnights CoveからはSkylake-SPベースに変わるとの噂なので
SMTが現在の4wayからKnights Cove/Runで変化するかもしれんし
SMPの対応有無も不明なので
Knights Runのシステムとしての最大スレッド数がどの程度になるかは現状不明 APUのキャッシュ用メモリに欲しいスペックは、100GB/s程度の帯域、1GBの容量なんで、これを達成できれば何でもいい
似たようなスペックがHBM1の1スタックで、面積も小さいからCPUソケットに収まる範囲に出来ると思った
APUに求めるのはローエンドGPU並の性能だし、HBCC使って1GB HBM + 8GB DDR4の階層メモリなら必要十分な性能出せると思う
普通のAPUに+5000円くらいで追加できるなら大歓迎 >>13
今のデスクトップ/モバイルのAPUですらDDR4では足りないし
GDDRのM/B実装なんて需要が無い→現状ではHBM系しかない
別にAPU作ってるAMDだけじゃなく、IntelもHBMの規格作りに参画してるんだし
dGPUと家庭用ゲーム機ぐらいでしか脚光を浴びないGDDR推しの必要はないのでは >>21
HBCCのキャッシュは名ばかりキャッシュだから
CPUのキャッシュと同列に並べるのに違和感
CPU、GPU、HPC向けCPUのカテゴリを書いてから書いたほうがいいよ >>23
CPUと同列なんて欠片も言ってないけど？
カテゴリ分けとかそんな面倒なことはする気ないし
ついでにいうと、メモリやキャッシュの階層制御は、一般的で普通の技術だよ、大抵のプロセッサで普通に使われてる
それをiGPU+HBM+DDRでやろうってだけの話
iGPUに少量の高性能メモリを使うってのは、IntelのeDRAMやXBOXのeRAMとか先例もある
技術的やコスト的に1GB 100GB/sを5000円は可能と踏んでるけどどうかな 100GB/sだったらDDR5 2chで良いじゃん
少なくともメインメモリの5倍くらいの帯域はないとCPUに使う意味はないと思う iGPUとの接続の話がメインならこのスレの話題対象外じゃないの？
前スレでももめてたしさ >>26
あんま電力が下がらんのとプロセスが微細化するので現存の概ねCCX一発分を維持すると仮定すれば
丁度クロスする辺りかもな DDR5自体ペーパーローンチなのに対応したメモコン積んだCPUなんていつの話やら >>21
今年(2018年)はGDDR6の年となる。データ転送レートは最大で18Gbps、高性能GPU
クラスのx384インターフェイスならメモリ帯域は864GB/sとなる。メモリ帯域だけ
なら、これまでのHBM2(まだ広帯域化が続いている)に匹敵する。
https://pc.watch.impress.co.jp/docs/column/kaigai/1106510.html またまた家庭用ゲーム機、PC向けのAPU/CPU、HPC向けプロセッサのごった煮論議の開始か・・
>>30
DDR5の仕様って固まったの？ 一応実質的には去年のワークショップで決まったようなもんではある
DDR4も最終確定は2014年9月だったけど、それ以前からエンプラ向けには売ってたし >>34
メモリは積層して何とかスペース確保するにしても、
ソケットタイプだと配線の引き回しが極めて厳しくなりそうだなぁ
M/B直付けタイプならなんとかなるかもしれんけど
M/Bベンダーもうちら顧客も極めて選択肢が狭まりそうな気がする Ravenと同じくらいのサイズのVega Mobileがこんな感じだから、APU+HBMもAM4ソケットに載りそうな気はするんだけど
http://ascii.jp/elem/000/001/620/1620182/Photo03_500x375.jpg
AM4で無理ならAM5まで待つから、いつかは作って欲しい >>36
今んとこライバルは256GB/sあるから、16Gbpsだとして4枚程そこに入れなきゃ対等ですらないがよろしいか コストかけて微細化しても、消費電力は減らず、性能を上げられない
コストに関しては減価償却が進めば下げられるとしても、今後は「CPUの価格が下がるだけ」で性能向上は見込めないのかも なのなの
MIPS、初のnanoMIPS命令セット対応CPUコア「I7200」
ttps://pc.watch.impress.co.jp/docs/news/1120074.html ＞ コアに密接し、高速アクセスが可能で決定論的なスクラッチパッドRAM(SPRAM)も最大1MBまで搭載可能
これうまくやればHPC向けにそこそこ使えそう
適度なローカルメモリやスクラッチパッドがあれば大幅に高速化する種類の演算は、
これで大幅に早くなるはず >>37
BGAで基板に実装できるものと、配線引き回しや物理的な制限に苦労しそうなソケットとを単純に比較するのは無理じゃないかなぁ >>33
電源がDIMMに乗るんだっけか
出始めの相性問題は激しくなりそうではあるね
>>42
1MBじゃ・・ L1 1MBとかできたらいいな
100%無理だけど キャッシュサイズとレイテンシは大体比例するから、L1 1MBとかにしたらL2と変わらない性能になるだろうな
L1 64kB、 L2 512kB、L3 2MBくらいが一番バランスがいい x8づつくらいが良いんでないかな
64-512-4096
ただ共有とか相互がある場合ちょっと工夫は要るだろうね 個人的には新世代メモリがきたらL2も分離型になるかと思ってたけど
よくてLLC（共有型）どまりみたいで残念 Skylake以降のXeonではL2:1MB、L3:1.375MB
L3 victimにして低用量で済む処理の速さに重点を置く形に
DRAM高速化やSSDの普及でまあこれがとりあえずはいい形なのかね CPUのキャッシュはこういう階層になる。
L0:デコード済み命令
L1:コードデータ分離
L2:コア毎独立
L3:チップ内統合
L4:ボード内統合
L0はRISCには不要
L4はメインメモリの管理方法が内蔵キャッシュとの間でのある程度のサイズのブロック単位のバースト転送になったこと、チップ毎のローカルメモリをチップ間通信で共有する形になったことから短レイテンシを特長とする外部SRAMによるものは存在価値を失った。
現在ではメインメモリ内に設けられたボード間通信バッファをL4とみることはできる。 eDRAMや2.5DでL4$を持つのはわるくないとおもうよ
L4$っていっても、タグ領域はCPUダイ内のSRAMに置いておけば性能低下は最小限にできる
問題はコストとパフォーマンスの関係があまり良くないってところか？ タグRAMにシリコンを使うくらいならコアを増やす方が良いという考えもあるからなぁ そんなに大きかったっけか？
>>51
（一般的な）キャッシュだとiGPU以外では目立った効果がなく
モバイルの上位モデルぐらいでしか価値が見いだせられないからおいしくない 1T-SRAMが存在できるのは40nmとかまでで、
現状の14nmとか10nmだと実装できないって話だったような。 eDRAMはUMAグラフィックでは性能が出ないためVRAMのうちアクセス頻度の高い部分をローカルメモリ上に確保する目的以外ではほとんど効果がない。
intelはキャッシュの体を取ることでソフトウェアの変更なしにアクセス頻度の高い領域がeDRAM上に確保されるようにした。結果としてCPUから見たL4になったがL4としては多大なコストに見合うだけの効果は無かった。 >>57
そっか
Trのラッチアップを意図的に制御出来ればSRAMは楽そうだよな
ん?、、、 >>59
理由と結果がつながってないと思うんだけど・・ >>61
OSやグラフィックライブラリーを変更しなくて済むようGPUのキャッシュとして作ったけどメモリが共有だからCPUからもキャッシュとして使えた。でもそれは無意味だった。 >>33
ついにきたな
今夏最終仕様発表で来年から出荷開始
まずは3200なのか、それとも4400からなのか 2〜3年後にはメモリ容量1TB、帯域300GB/s以上とかになるのか‥‥ メモリ帯域はCPUにはあまり関係ないからなあ
今以上にあってもあまり意味無いと思う >65
現状のレイテンシ、帯域、容量を暗黙のうちに前提にするなら
そういう表現になるかもしれないが、前提にしないなら
「レイテンシとつり合いの取れてない帯域があっても用途が狭い」
今のDRAMメモリはレイテンシの役割をキャッシュに丸投げ、
容量の役割をSSD、HDDに丸投げして中継ぎしてるだけだ
（「メイン」メモリの名が泣いている）。
もしもDRAMのレイテンシがキャッシュの階層を減らすことができるくらい
小さければ、帯域増のメリットは大きい。 CPUのボトルネックはストレージだから、メモリをいくら速くしても意味ない
CPUベンチ以外ではメモリは既にボトルネックじゃないよ サーバや業務用ストレージ用途はともかく、
個人向けじゃ動画編集とかやってる人以外はSSDなんてSATAで十分だけどな
むしろDRAM高騰で、メーカーPCのメインメモリが減ってるからスワップが増えて
低速化してる気はするな
かつて8GBデュアルチャネル積むのが当たり前だったメモリが、
4GBシングルチャネルになったし データセンターは知らんが、水力学や大気力学じゃ、メインメモリの帯域重要なんだが PCだってメインメモリのないソリューションがないんだから
CPUの理論値を下回らない程度の帯域を確保したメモリは必要 階層毎に1/10くらいかな
0.1%以下が当たり前だし 中国でA12プロセッサのスコアがリーク：
アップル新iPhone性能20％向上か
http://ascii.jp/elem/000/001/673/1673232/
リーク通りだと順調に早くなってるね tsmcの10nmから7nmで20％クロックアップできるから、アーキテクチャとしてはほぼ変わってないな まだまだ発売日まで時間あるから
最適化されるかも分からん なーに、OSアプデで遅くすれば
40%向上達成は容易よ 林檎の脱インテルはラインナップ全部ではなくとも一部ではやりそうだ 新しく発表されたnanoMIPS32だけど命令の長さが16bit、32bit、48bitあるのな
48bitの長さの命令には32bitイミディエイトロードの命令もあるみたい
nanoMIPS32 Instruction Set TechnicalReference Manual
https://s3-eu-west-1.amazonaws.com/downloads-mips/I7200/I7200+product+launch/MIPS_nanomips32_ISA_TRM_01_01_MD01247.pdf nanoMIPS32は範囲が32bitのPC相対アドレッシングのロード、ストアがあったりとか
GP(グローバルポインタ)間接のdispが21bitあったりとか
(GOTテーブルのサイズが多く取れて扱えるグローバル変数の数が増える)
ポジションインディペンデントなコードを作る場合の改善とかあるのな TSMCがロードマップを発表、EUV導入は19年前半 (1/2)
http://eetimes.jp/ee/articles/1805/10/news033.html
パッケージングの技術開発もかなり進んでる模様 >>87
CISCとまではいかないだろう
CISCだとアドレッシングモードによって命令の長さが全く違ってくるしもっと複雑
nanoMIPS32だと48bit命令の最初の6bitは全部011000で始まってるようだし
簡単に命令長を区別できるようにデコードに負荷がかからないような仕組みが導入されてるはず
>>88
コード密度を上げるためかもな
lui $4, %hi(0x12345678)
addiu $4, $4, %lo(0x12345678)
と命令を2つ使うと8バイトになるが
li $4, 0x12345678
こっちの方が48bit(6バイト)で短くなるから
C言語にアセンブラコードを吐かせたのを見るとシンボル値のロードは頻繁に使ってるしな
余談だが64bitCPUの場合でも、デフォルトではシンボル値は32bitに制限してたりする
Linuxでもx86_64はシンボル値を32bit、ARM64はシンボル値を33bitにするのがデフォルトになってる
おそらく64bitのシンボル値を読むようにすると性能が落ちるんだろうね あとnanomips32ではPC相対のロードストア命令の他に
PC相対で指定したアドレスをレジスタに読み込む命令も用意されてるから
簡単にリロケータブルなコードを生成できる
PC相対の範囲も32bitのアドレスを指定できる48bit命令が用意されてる アセンブラがあまりわからない人のために補足しておくと
シンボル値は主に関数のラベルやグローバル変数名に使われる
上にも書いたがたとえ64bitのプログラムでもシンボル値は32bitに制限されてる場合が多い
x86_64やARM64でもだいたい32bitくらいに制限されてる
gccには-mcmodelオプションで指定できるメモリモデルがあるのだが
デフォルトはx86_64でもARM64でもsmallになってて
x86_64だと2GB、ARM64だと4GBの範囲でしかシンボルを扱えない
largeだとシンボル値を64bitとして扱う
x86_64だとmediumが指定できて
これを指定するとグローバル変数のシンボル値に64bitの値が使われる
スパコンのソフトだとこのオプションを使ったりする場合も多いらしい
PGIのコンパイラのサイトにわかりやすい説明が載ってる
64ビット環境 2GB 以上の生成オプション
https://www.softek.co.jp/SPG/Pgi/TIPS/opt_64.html アセンブラというよりCコンパイラ側が吐き出すコードが
デフォルトだとシンボル値が32bit(ARM64だと33bit)を想定したアセンブラコードになってる
ほぼすべての64bit CPUのCコンパイラがそんな感じになってる
シンボル値のロードは頻繁に発生するので速度低下を抑えるためにそういう仕様になってると思われる まあ、32bitのイミディエイトロードはアドレスの読み込みで頻繁に使うからな
その部分で1回当たり、2バイトも削減できるのは大きいね
1命令4バイト固定にこだわらないのはRISC-Vの影響もあるかもね アドレスに32bit使うならabs32よりbase+(index+disp20)*scaleの方が使い手がある。 ザーッと見た感じ48bitの長さの命令は6命令しかなさそう
addiu rt, s32 レジスタと32bitイミディエイトの加算(ソースとディスティネーションが同じレジスタ)
addiu rt, gp, s32 グローバルポインタと32bitイミディエイトとの加算
addiupc rt, s32 PCとイミディエイトの加算
li rt, s32 32bitイミディエイトのロード
lwpc rt, addr PC相対アドレス指定の32bitロード
swpc rt, addr PC相対アドレス指定の32bitストア
lapc rt, addr PC相対アドレスのロード(addiupcのエイリアス) MIPSの場合、GP(グローバルポインタ)は汎用レジスタの$28な しかし、全く違う命令セットで来るとはな
MIPS32R6やMIPS64R6はまともな応用製品が出る前に終焉なのかな？
命令セットを変えまくって、32bitのLinuxは対応するにしても、他のリアルタイムOSが対応してくるのか？
IoTの時代に、リアルタイムOSなしでの開発とかやってられないでしょ ThreadXとNucleus RTOSがnanoMIPSに対応するみたいだな
ちなみに、どちらもμITRONの互換機能をもつバージョンも持ってる模様
アドバンストlte/5gコミュニケーションとネットワーキングicデザインにおいて、抜群のパフォーマンスと効率性を実現する、mips I7200プロセッサコア
https://globenewswire.com/news-release/2018/05/03/1496280/0/ja/%E3%82%A2%E3%83%89%E3%83%90%E3%83%B3%E3%82%B9%E3%83%88lte-5g
%E3%82%B3%E3%83%9F%E3%83%A5%E3%83%8B%E3%82%B1%E3%83%BC%E3%82%B7%E3%83%A7%E3%83%B3%E3%81%A8%E3%83%8D%E3%83%83%E3%83%88
%E3%83%AF%E3%83%BC%E3%82%AD%E3%83%B3%E3%82%B0ic%E3%83%87%E3%82%B6%E3%82%A4%E3%83%B3%E3%81%AB%E3%81%8A%E3%81%84%E3%81
%A6-%E6%8A%9C%E7%BE%A4%E3%81%AE%E3%83%91%E3%83%95%E3%82%A9%E3%83%BC%E3%83%9E%E3%83%B3%E3%82%B9%E3%81%A8%E5%8A%B9
%E7%8E%87%E6%80%A7%E3%82%92%E5%AE%9F%E7%8F%BE%E3%81%99%E3%82%8B-mips-I7200%E3%83%97%E3%83%AD%E3%82%BB%E3%83%83%E3%82%B5%E3%82%B3%E3%82%A2.html
(URLが長いので改行してます)
> Express LogicのCEOであるWilliam Lamie は次のように述べている。
> 「I7200は、リアルタイムイベントに対する高い性能と高速応答の両方を必要とする通信、
> ネットワーキング、その他のアプリケーション向けの高性能プロセッサとして活躍するでしょう。
> 当社の産業用Grade X-Ware IoT Platform (ThreadX RTOS基盤) に新しいI7200コアを追加し、
> MIPS CPUの長期サポートをより拡大することを楽しみにしています。」
>
>
> Siemens傘下事業であるMentorの組み込みプラットフォームテクノロジーのジェネラルマネージャであるScot Morrisonは次のように述べている。
> 「MIPSの長年にわたるパートナーとして、当社のNucleus RTOSは、両社お客様がより低リスク、
> より短期間で製品を市場に投入することができるように支援しています。
> 当社のSMPバージョンは既にMIPSラインナップで既存のマルチスレッドおよびマルチコア製品をサポートしています。
> 新しいMIPS I7200プロセッサコアは、優れた性能と最適化された機能を提供し、
> MIPSのお客様が複雑なLTE/5G通信アプリケーションを含めた幅広い組み込みソリューションを開発するために役立ちます。」 ■ このスレッドは過去ログ倉庫に格納されています
