CPUアーキテクチャについて語れ 44
■ このスレッドは過去ログ倉庫に格納されています
そういや消費電力当たりの性能って触れちゃいけないんだっけ? バイクは原付しか乗ったことない
持ってる人て今どんだけいるんだろ >>390
ARM・ISAが消費電力に関係あるかのような酷い言説が流通してたからな
インタビュアーもわかってて否定してもらうために聞いたんじゃないか。 ISAも十分関係あると思うがな
副次的あるいは間接的ではあるだろうけど
大体馬鹿食いと言われるx86にボッコボコにされた時点で前代のアレはつまり、、、 SPARCやMIPSのISAは100万〜1000万トランジスタで最適なマイクロアーキテクチャであるシングルスカラパイプラインの32bitプロセッサに最適化されている。その代表的なものがdisp30の分岐命令と遅延スロット。
これを32bitマイコンからスーパースカラの64bitプロセッサまで広範囲に使えるものに調整したものがRISC-V。
ARMは用途ごとに異なるISAを切り替えて使うがRISC-VはシームレスになっていてOSの対応が楽になるものの実用上差はない。 100万Tr RISCが効率的だよね
1千万Tr VLIWが効率的だよね
1億Tr〜 RISC風CISC?CISC風RISC?が効率的だよね 動作クロックが上限に達すると1サイクルで出来ることが多いCISCが有利になる
ただしこれはシングルスレッド性能に限った話でマルチスレッド性能やワッパはまだRISC有利だと思う 廃れそうなのはマルチプロセサの方か
世界を覆う不況の影〜 一周回ってCISCの次はデータフローだな
ただこれを従来のCPUアーキテクチャといえるかどうかは人によるけど スーパースカラの命令デコードの都合で高性能プロセッサは32bit固定長命令が必須。その上で複雑な命令は複数の命令に分割して実装しデコーダで連結して元に戻すことになる。ついでに32bitに複数の短い命令を詰め込むことも考えられる。これってRISC?CISC?VLIW? >>416
Out of Order実行はデータフローみたいなものだ。 べつにIA-32廃止しなくても、
IA-32コードは高速で動く必要なし扱いにして、実装・デバッグの手間を下げるってのが
いちばん妥当では?
いまは、16bit命令とか、x87命令とかがすでにその扱いだよね
これらは高速で動く必要なしの扱いを受けてるので、レガシーアプリつかってる人は
CPUを新しくしたらパフォーマンスが落ちるとかの現象があった
CPUメーカーのドキュメントで使用を推奨しない命令に設定した後、
ほぼつかわれなくなったレガシー命令は、順序高速化の必要なし扱いにしていけばいい
将来は32bitコードもそうなるでしょう だからIA-32(CPU)の廃止であってWOW64(アプリ)の廃止とは言ってない AMDがプリフィクス増やしてIA32以上にダメなISAになってるx64を何とかしないとな。 AMD64のIA-32互換系をある程度オミットすればスッキリする
足手まとい >>417
>その上で複雑な命令は複数の命令に分割して実装しデコーダで連結して元に戻すことになる。
RISC-Vはマクロフィージョン前提で作られてるようだからな
命令長に関してはx86のようにデコードが複雑な可変長の命令セットは効率悪いけど
RISC-Vのようにデコードしやすい形なら固定長の命令にこだわる必要も無いと思う >>424
デコードしやすい可変長ってなんかおかしくね
長さ変わるから面倒だつってんのにさ >>420
x86のIA-32とx86_64はARMと違って全く違う命令セットじゃないからな
例えば、32bitのオペランドでR8-R15を使わない命令は
IA-32でもx86_64とほぼ同じマシン語になる
微妙に違うところはあるけど、
x86_64はIA-32に必要な時だけREXプレフィックスを付けたものだからな
REXプレイフィックスが付く時はR8-R15レジスタを使う場合と64bitオペランドを使う場合
それ以外はほぼIA-32そのまま
だからIA-32だけを廃止するのは意味がない
ARMの場合はx86とは違い32bitのAArch32と64bitのAArch64は別物だから
富士通のA64FXのようにAArch32をサポートしない設計に意味は出てくる >>425
命令の長さに規則性があって、ある一部分をみただけですぐに判断できるフォーマット
TRONチップのような考え方 >>425
先頭から何bitか見れば長さが分かるだけでデコードしやすい訳じゃない。オペランドごとにオペコードが散らばってたり結構汚い。 RISC-Vの命令長フォーマットはこんな感じ
16bit命令 xxxxxxxx xxxxxxaa aaは11以外
32bit命令 xxxxxxxx xxxxxxxx xxxxxxxx xxxbbb11 bbbは111以外
48bit命令 xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xx011111
64bit命令 xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx x0111111 >>428
複数の命令を同時実行するには命令の切り出しが大事だからな
だから簡単に命令の長さが判別できる必要がある
RISC-Vはそういうように設計されてる
それにRISC-Vの基本命令は
RISC-Vの命令長フォーマットはこんな感じ
このページに書かれてるようにデコードがしやすい
https://news.mynavi.jp/article/risc_v-3/
https://news.mynavi.jp/article/risc_v-3/images/001l.jpg
RISC-Vの基本命令は次の図に示す32ビットの固定長命令で、4種類の形式がある。
どの形式でもrd/rs1/rs2のレジスタ指定ビットの位置は同じでデコードがやり易い設計である。 RISC-Vは完全フリーの命令セットで
RISC-Vで都合がいいのは日本や中国、韓国、インドなどの
独自のCPUの命令セットのエコシステムを持ってない国だよな
特にアメリカと敵対していて
半導体技術向上に力を入れてる中国にはとても都合のいい命令セット
日本や韓国などアメリカと友好的な国ならライセンス料を払ってARMを使ってもいいが
中国の場合、もし、ARMが米国企業に買収されたら
安全保障上の理由から利用が制限される可能性があるからね >>430
だから16bitと32bitを混在させることしか考えてない。
32bit命令のオペランドを拡張した48bit以上の命令は無理に作ってもほぼ別命令扱いになる。 >>426
>x86のIA-32とx86_64はARMと違って全く違う命令セットじゃないからな
そこが一番の問題
x86互換CPUで中国産やロシア産含めMeltdownなんて恥ずかしい脆弱性抱えてるのはIntelだけだからな
>>422
Intelは自社存続というエゴのために脆弱性対策と称したコード汚染を拡大する汚物そのものなのだが
既存のソフトウェア資産を放棄してまで忖度しろと妄言を吐くIntelこそが消えるべき RISC-Vは完全フリーと言ってもある数量以上量産するとパテント料を支払う規則になっているよ
まだ量産品がないから完全フリーに思えるだけ料金が幾らかは判らないが >>427
うーん
判別機構が簡素に成ればコレでも良いとは思うけど、x86系よりは遥かにマシだし
ただ多倍長の時点でデコーダの額面上の幅設計だけでクッソ厄介だろ
長かろうが完全固定長に勝るもんでは無いと思う RISC-Vって、ARMの禿税回避できること以外に利点があるの? A12 biocnicが搭載してる高性能CPU Vortex(2.5Ghz)はgeekbenchの
シングルはCore i7-7700に匹敵する
クロックあたりの性能なら越えてる部分もある
MACもIntel採用止めて高性能コアベースの自社製CPUに切り替えた方が面白いわ
Appleは自社製GPUの詳細もソロソロ明かしてくんないかね
PowerVRの特許の問題があるかもしれんが・・・・・ 2.5GHzのCPUと3.6のCPUのIPCを較べて何の意味があるんだか。 KabylakeのIPCも越え、シングルスレッドも3.6Ghzに匹敵するなら
MACでも使える話をしてる Geekbench自体あまり信じてないし、iOSだとAppleがベンチマークソフトを検出して何かしてそうで余計信じてない geekbenchは3から4になった時にスコアがかなりiPhone寄りに出るようになった
追加するテスト項目次第でスコアの重み付け出来るけど意図的なものかモバイルで重要な項目を重視した結果偶々そうなったのかは不明 iPhoneはOSとSoC共自社製でどこよりも最適化されてる
泥とスナドラのバラバラの組合せよかベンチで高い性能がでるのかもしれん
PS4はPCよりCPU性能貧弱でも直接ハードに叩ける分ゲーム最適化しやすいのと似た理屈 >>405
これか
ヤマハ、NVIDIAと協業し自律動作の農作業車/ヘリ/ボートなどを開発へ
9/13(木) 12:40
スバル、インプレッサにAIドライブコンピュータ「NVIDIA DRIVE PX 2」を搭載した自動運転プロトタイプ車
9/14(金) 5:00
いすゞ自動車がNVIDIAのプラットフォームを使って自動運転技術確立を目指す
9/16(日) 6:03 risc vはARMのシェアを奪うほど伸びるでしょうか? もうちょっと早く出てきてればポスト京に最適だったんだが
そこをARMに取られちゃ後は一銭も払ってくれない中華しか市場はない。 欧州はARM+RISC-Vアクセラレータじゃなかったっけ? 兆芯、“第7世代Core i5並みの性能”を実現した「開先KX-6000」の写真を初公開
ttps://pc.watch.impress.co.jp/docs/news/1143939.html >>448
KX-5000 8C でi3-6100 2C4T 相当と言っていた。
KX-6000 8C はi5-7xxx 4C4T相当に向上したわけか
448からたどれるKX-5000の記事にあるけど
こういう性能でも膨大な開発リソースが費やされたようだ
>x86は1つのアーキテクチャを設計するのにおおむね30億ドル
IntelやAMDに比べたら手本があることやビジネス環境の経費の低さで
30億ドルにはならないだろうけど、それでも多額だろう やっぱ今更x86互換に新規参入ってすっげぇ金かかんのね 街中でiPhoneにマウスとキーボードを接続して使っている人を全然見かけない謎 性能以前にHPCからモバイルデバイスまでターゲットにするとか無茶杉だろ
消費電力100Wのプロセサをスマホに載せるとか あんだけの値段するならキーボード付けてディスプレイに繋げばMacにもなります
くらいな林檎フォンであってくれよ まあモバイルはタブレットとかノートとかが限界だろう
禁輸された時対策だろうけど逆に関税かけられたという。
>>446
ベクトル命令がなんかもめてるみたいなブログ記事読んだけど今はまとまってるのかね?
まあPostKに採用されてたら問答無用でSVE追加されてただろうけど。 >>454
SVEは配列演算専用でベクタ長を意識する必要がないGPGPUの代替目的なんだろうけど全命令がmask指定を持つのは無駄が多いんだよね。
そこまでmaskを多用するならグローバルmaskレジスタを用意してそれを設定したら以後の命令にはすべてそのmaskが適用される仕組みにして演算命令のオペランド数を増やした方がいい。
でもお客さんの言うことなのでお客さん専用命令ということでARMとしては不本意ながらOKを出したってことだろう。 コプロやバリエーションなどのヘテロ編成も視野に入れてるからなのでは ARMじゃVNNIのようなAI用命令は無理だの云々て議論が1年前にあったっけ SVEがお客さん専用なら
そのうちNEON256とか……だいぶ先か。 NEONは64bit演算器を2回回す前提の128bitモードから作り直さないときつい。 次世代京は時期が悪いとしか言えないな
SPARCは実質ディスコン、RISC-Vはまだまだ、っていう微妙な時期に作らないといけない Samsung M3のパイプラインがZenより豪華に見える
プロセスが違うしSMT対応の有無もあるけど、モバイルも力強くなってきたなあ >>461
ちょっと重すぎない?
コレモバイルSoCだろ? いやあれはなんかコンパイラでチートしてんじゃねて気がするが >>464
ARMでそれをやらない所なんて無いだろ
RISCベースなんだから積極的にコンパイラで超最適化しないと性能なんか出ないぞ >>465
この記事この画像を使ってA75より性能/Wが高いって書いてるけどデマじゃん
https://news.mynavi.jp/article/m3-2/images/012l.jpg
https://news.mynavi.jp/article/m3-2/images/013l.jpg
まぎらわしいけど上画像のGBシングルスコアは青ラインがA75だけど
下のパーワットの方だと青ラインはM2に変わっててA75が比較対象に無いっていう M2に比べてM3はサイクルあたりで平均+60%
最高クロック+17%でその時の電力性能は平均80%?
同クロックなら電力性能が平均140%?
ってことは最高クロックだと電力は2.3倍
クロックを2.3GHzまで落としてもM2より電力が多い
M3の2.7GHzはモバイル電力の枠を軽く踏み倒してるが
A75を全ベンチで上回るグラフ作るための見せ球オーバークロック設定ってこった >>471
M2に対してサイクルあたり性能1.6倍
2.7GHzはクロック1.17倍で性能1.87倍
2.7GHzの性能/Wを踏まえ1.87 / 0.8 = 2.34
最高クロック時の電力は比較対象M2の2.3倍程度 それにベンチを見るとAI向けの行列演算で3.4倍と平均を押し上げているが
整数系ベンチでは2.7GHzでもM2比で1.6倍程度の性能に留まってるものが多いことから
実際のアプリ環境では印象ほど性能は伸びず、
また設計として高電力に振れていることからゲーティングが効き難く電力消費が大きくなるだろう
スマホチップとしてはもっと微細化を進めないと厳しいっていうのが実態じゃないか 実際にはベンチほど早くはないが
消費電力シングル〜オールコアで3.1〜3.5Wと
A75搭載スマホとかと消費電力は変わらん デコード幅が1.5倍でIPCが1.6倍に増えてるのは面白いね
さらに広げてもまだ性能伸ばせそうだ 10nmLPPは0.35V
7nmはどうなるんだろうか、Samsungはパフォーマンス寄りにプロセス設計を振ってるが TSMC/Samsungともに、10nmからは~200mm^2以上のビッグダイ(?)チップは作るのが難しくなってきてるとの話があるが
4年前のIntelが味わった地獄を今体感してる感じかね Samsung Galaxy S9 のGeekbenchだとM3は1.8Ghzだとわかる
発熱・消費電力の性でかなり低く抑えられてんだな
シングルで3300程、同クロックならA12bionicのVortexと同等になる
ハイエンドスマホSoCの高性能CPUは、ノートPC並の消費電力枠(15〜25W)に
すれば同枠のCoreやZenにひけはとらんな
AppleがMACを自社製CPUに切り替えるのも時間の問題かもw まずGBに対しては単純に比べられんてのと(特にx86とその他RISC)
TSMCも150mm^2辺りまでが精々なのに、それ以上の巨大なダイを出せるのか?
出せたとしても熱がすごそうな気がするけど……電圧をそんなかけていいのかしら 勿論、HPC用途だとビッグダイでも(多大なコストを転嫁、チップの値段に転嫁することで)いけるだろうけど
コンシューマ用途が殆ど、末端相手しかやっていけないとこは難しいかと
てかMACて書くのはちょっと…… Centriqは10nmで400mm2だし、7nmのVega20やA64FXはまだサンプリング段階だけど200mm2は越えてるでしょう
大きなダイを作れないという問題に直面してるとは特に思えないけど appleがMACを切り替えるっ見て
「え?物理層?モデムチップ、5Gでは自社製使う計画あったっけ?」
と、ちょっとだけ思ったのは秘密だ Centriq 2400は最低でも$888だし
>>466ということもあって、元とろうとしたら難しい
あのAMDちゃんがPOWER9とEPYCでタメ張ってたりするとこみるに
なんていうかかずるい感じがするよ・・・・・誰かも以前書いてたっけ? 連レスだが、なんか結局あれやめてたんじゃ?
カムバックするぜ!的なことは言ってたけど
事業としてはあの値付けでも難しかった可能性も低くはないのでは >>488
厳しいと思うよ
そもそも旧RISC勢が86にボッコボコにやられた理由がそこにある
焼き直したところで所詮は同系列の類似コンセプト
少なくともハイパフォ帯に於いてはあんなもんゴミでしかない
結局ハイパフォ化してもどうせx86_64には勝てん
ワッパが多少いい程度はシステム丸ごと入れ替えるのに見合わない、かと言ってパフォーマンス落としたら論外
結局ISA非互換のデメリットがそっくりそのままなのよ
加えて旧RISC勢は有効なダイ面積の利用が難しい、固定長で単命令を多くってのはキャッシュの利用効率そのものは良いが、サイクル効率はどう見積もっても悪くなる POWERは金融取引ではユニークだったりとかそういう強みはあるけどね
ファイナンス評価(シミュ)だとXeonがくっそ強いけど
他のRISCもSPARCはデータベース処理に一時期強かったりしてた気もする >>476
M3の消費電力はSPECintでA75の概ね2倍、最大は量子計算テスト中で4.8Wにまで達する
https://images.anandtech.com/doci/12520/specint_575px.png
さらにM3スマホの実効の電力性能がベンチに比べ悪すぎたためカスタムファームを用意して改善を模索した話
https://www.anandtech.com/show/12620/improving-the-exynos-9810-galaxy-s9-part-2/3
結局アプリではいまいち性能が出ず、バッテリー持ちはA75にもM2にも劣る結果に
つまるところファーウェイのベンチブーストと根本が一緒だろう
見栄の張りすぎ >>466
コンパイラでチートって演算結果の使われない無意味なループを飛ばして計算量を減らすとかコンパイル時に計算しておいて計算結果を書いて終わりとかを特定ベンチに特化したロジックで派手にやらかすベンチマーク対策のことだぞ。 M3はタブレットかCromebookにも載せてほしいな
高性能と消費電力はトレードオフなので
スマートフォンではサーマルスロットリングで厳しいだろうし >>492
それはそもそもマトモにベンチが走って無いじゃん
論外だよ
コンパイラのチートってのはそれ専用にカリカリにやる事
汎用コードじゃなくてな
SPECでみんなやってる故に数字に意味がないアレね
で有れば何処まで許容されるのかと言うとまたそれは別の問題だけど
コレをやった上で、やって無いヤツと同格では伸び代が違うだろ
そういうことだよ >>494
同一結果になる複数の命令があるとき最も高速なものを使うのは最適化の基本だぞ。×2乗算を加算に置き換えるとか太古のコンパイラからやってる話だ。 x86でx3,x5,x9の乗算にleaを使うテクはそのままARMに応用できる。
特定マイクロアーキテクチャ依存にしてもスーパースカラを前提にした命令スケジューリングとかやってない方がおかしいレベルだし。
L1キャッシュサイズ依存のループアンローリング量の調整とかまでくればどうかという気はするが、数式そのままに計算しないのはそろそろループをSIMDに展開するのが常識になりつつあるからなあ。 https://prtimes.jp/main/html/rd/p/000000093.000012662.html
ゴードン ベル賞のファイナリスト 6チームのうち5チームが、NVIDIA Volta Tensor コア GPUを利用 >>493
ハイエンドスマホ用SoCは高性能CPUだけ
見ると消費電力の制限厳しすぎで勿体よなあ。
リッチすぎてスマホじゃオーバースペックな気がする。 >>495
だから線引きはまた別の問題
本来で有ればベンチマークは実運用でログ取るのが最良だけど
そうはなってない故に、ね
特に単命令主体ともなるとフロー上の仕様を考慮した組み方は特定のプロセッサに向けて効くだろう
ただ、そのコスト分のゲインがあるのかは別とするしかない >>498
実アプリを使うと非効率なメモリアクセスが大量に発生してしまい、それが弱点故に集中して対策を講じてあるIntel大勝利で終わってしまうのだが。 >>499
あたりめというか、手抜きの正当化と言うか
ASLRウォーク可能かつ容易な構造という意味で、受け取り方としては逆が正しい
だからこそ当然そうなると言えるし、MT前提の高負荷条件では軽くひっくり返ったりする
予測のスパンが長く精度が高いほど、スラッシングに弱い スマホ用ゲーミングドックと、対応スマホかあれば、スマホのCPUの性能を出し切れる気がする
ゲーミングドックは、AC電源からの電源供給+空冷ファンでスマホ冷却の両方するとか
ゲーミングドックにとりつけたしたスマホは、リミッター解除して最高速度で動作 ファンと外付け電源追加して可搬性犠牲にした瞬間に高いだけのゴミになるやろ ゲームやりたきゃゲーム機買え
いまんとこポータブルゲーム最強はSwitchだから
SMACH Zがどうなるかはしらんが あんな在庫処分チップがバカ売れなんだから
結局はソフトなんだよなぁ ■ このスレッドは過去ログ倉庫に格納されています