Intelの次世代技術について語ろう 91©2ch.net

**Socket774 転載ダメ©2ch.net** · 2017/08/29(火) 16:36:43.16

Intelの次世代製品や、それに関連する技術についてのスレッドです。　　　　

■前スレ
Intelの次世代技術について語ろう 90
http://egg.2ch.net/test/read.cgi/jisaku/1499796238/

**Socket774** · 2017/10/21(土) 02:04:23.83

>>720-721
なんだいつものアンチIntelで無駄な人生を費やしている無職のAA貼りオヤジのキチガイだったか
寝言はIntelの10nmより先に自称ではなく本物の7nmを出してから言いましょう

**Socket774** · 2017/10/21(土) 02:08:38.63

>>722
それでもサムスンの自称10nmである12nm相当を世に送り出してるから一応トップを走ってるでしょ

**Socket774** · 2017/10/21(土) 02:11:09.39

Samsungの1ヶ月半後に出たTSMCの10nmにもう引き離されてるよ

**Socket774** · 2017/10/21(土) 02:27:21.56

>>723
まだ出てない10nmを引き合いに出すのはブーメランになるって何度言われれば目が覚めるんだろう。

**Socket774** · 2017/10/21(土) 02:34:03.50

>>726
うん
だからまだ出てないファウンドリの自称7nmがなぜIntelの10nmより先に出ると確信しているのか不思議でしょうがないｗ

**Socket774** · 2017/10/21(土) 02:40:44.13

>>725
Samsungの10nmとTSMCの10nmは大差ないやん

**Socket774** · 2017/10/21(土) 02:58:12.12

>>728
大差ないよ
発表値でも各種の調査でも2割程度の差しかない

問題はそのあと
Samsungが1割縮小の10LPUを名前だけの8nmにしちゃったこと
これから登場する10LPPも陳腐化するし
TSMCのN7が早く進んでるからこっちのたった1nmの差が1.7～1.8倍の大差になった

基本的にはSamsungのマーケティング戦術がLEDテレビ()ばりにダサく感じたから
サムスン上げのレスを見たらサムスンを馬鹿にするレスを返してるだけ

**Socket774** · 2017/10/21(土) 03:12:22.22

サムスン嫌いなのは結構だけど別にそんな上げてるレスには見えんけどな

**Socket774** · 2017/10/21(土) 03:16:25.08

>>658>>719>>724
前も同じ論調でサムスントップって言い続けてるから
Intel上げと見せかけたサムスン上げだと判断する

**Socket774** · 2017/10/21(土) 03:27:07.28

他社が既に手掛けてたLEDバックライト液晶を
LEDテレビと名付けて液晶はもう古い、とやったり
OLEDテレビが本格化してきたら
液晶にQLEDテレビと名付けてOLEDより優れてる、とやったり
3DXPの量産発表されたらSLC NANDがZ-NAND、みたいな
そういう技術を煙に巻こう的な発想
11nm、8nm、6nm、5nmもそれらと似たようなマーケティング施策

Samsungの技術や馬力は間違いなく実力があると評価するが
その分だけこういう軽薄な手口はハッキリ言って悪徳的でイケ好かないね

**Socket774** · 2017/10/21(土) 04:00:26.79

プロセスルールに関しては対ファブレスメーカー向けのマーケッチングだし、ここでド素人が火病起こしても・・・
日本の電気産業を完全に駆逐してしまったSamsungが嫌いなのは解るがそれは日本の責任だし・・・

**Socket774** · 2017/10/21(土) 04:03:43.04

いくつかの面で立派な企業に至ったのだから、もう昔のような姑息な
手管は持ち出さずに実力だけで勝負しよう、という発想が
無いみたいなんだよなsamsung とかには。三下だった頃と同じことをやる

**Socket774** · 2017/10/21(土) 04:06:25.43

＞電気産業
電気は弱電だけじゃないよー

**Socket774** · 2017/10/21(土) 04:09:45.78

>>733
こんなスレでのサムスン上げの方が無謀
サムスンの名ばかりな部分をデータで指摘するのはむしろ当然のこと

**Socket774** · 2017/10/21(土) 04:18:37.58

http://ascii.jp/elem/000/000/911/911409/index-3.html
http://ascii.jp/elem/000/000/911/911419/Photo08_800x450.jpg

この頃は威勢が良かったのにどうしてこんなことに

**Socket774** · 2017/10/21(土) 07:10:17.93

>>737
Intel信者の妄想って多分ココから来てるんだと思う

**Socket774** · 2017/10/21(土) 07:54:31.40

>>735
会社に弱電室ってあるけどなんなの？
強電とかもあるの？

**Socket774** · 2017/10/21(土) 08:05:57.21

PCは弱電
送電線や発電所は強電

**Socket774** · 2017/10/21(土) 08:23:01.53

>>714
むかしはIntelより日本勢のほうが進んでた
日本勢が脱落して2番手だったIntelがトップに出た

**Socket774** · 2017/10/21(土) 08:25:27.60

22nmから製造ラインが埋まらなくなり
14nmは大量生産がSkylakeまで遅れた
10nmは既に2年遅れで来年ですらあやしい
そして7nmがロードマップから消えた

**Socket774** · 2017/10/21(土) 10:31:38.82

>>737
４年前「10nmは2015年にファウンドリの顧客に提供します。
競合するファウンドリより３年以上先をいってます。」

今「10nmは2018年にファウンドリの顧客に提供します。
競合するファウンドリはより高密度の7nmを同じ2018年に提供します。」

信用って大事

**Socket774** · 2017/10/21(土) 10:58:05.57

強電より重電ということの方が多い
弱電より軽電ということの方が少ない　バランスがとれてない

**Socket774** · 2017/10/21(土) 13:34:30.68

10nm難産に焦る淫厨www

**Socket774** · 2017/10/21(土) 14:53:43.35

何でここまで苦労してるのかよくわからんね
何らかの新技術を導入するつもりだったけど上手くいかなかったのかな
Intelは10nm以降のどこかでIII-V族のQWFETに移るなんて予測もあったけど…

他の開発状況を見るに、FinFETの次は横AAG-FETへ移行するというのが主流みたいだね

**Socket774** · 2017/10/21(土) 16:03:59.29

AAGじゃなくてGAAだった

最先端プロセスの最新論文が一堂に IEDM 2017
http://eetimes.jp/ee/spv/1710/20/news070.html

今度のIEDMでIntelの10nmとGFの7nmについての発表があるみたい
TSMCは7nmについて去年発表済み

**Socket774** · 2017/10/21(土) 16:10:29.82

>>746
ファウンドリと違って真正面から微細化の先頭を突き進み、製造コスト低減のためにハイパースケーリングなんてやってるからね

あとCannon Lakeの難産はずっとIntelを苦しめ続けるiGPUのトラブルが原因とも言われてる

**Socket774** · 2017/10/21(土) 16:19:56.54

>>748
> あとCannon Lakeの難産はずっとIntelを苦しめ続けるiGPUのトラブルが原因とも言われてる

閃いた！GPUコアをMCMで分離すれば問題解決w

**Socket774** · 2017/10/21(土) 16:36:45.68

Intelが10nmプロセスの詳細を明らかに (1/2)
http://eetimes.jp/ee/spv/1704/04/news040.html

３月のカンファレンスではFin Heightが56nmだったのに>>747では46nmになってるな
これが本当なら、高アスペクト比のFinの量産が上手くいかず断念した感じか
これだとトランジスタ性能が落ちるから、CPUの物理設計をやり直して一年延期というのも理解できる
従来の設計でもSKUを絞れば少量は生産できるかも

**Socket774** · 2017/10/21(土) 17:11:39.13

3月時点でのFin Heightは56nmではなく53nmだった

22nm → 14nmでFin Heightが34nm → 42nmと23%向上してるので、
14nm → 10nmでも42nm → 53nmと同程度向上させようとしていた、といったところか

**Socket774** · 2017/10/21(土) 17:16:26.65

>>749
KabyLake-Gとは何だったのか

**Socket774** · 2017/10/21(土) 17:49:08.50

>>752
ZEN APUに完全敗北するだろ？いい加減忘れろ

**Socket774** · 2017/10/21(土) 18:25:22.72

>>749
GPUコアはamdかnvidiaから調達すればさらにいいな

**Socket774** · 2017/10/21(土) 20:01:35.17

intelは新しいsimd導入するときはとりあえず動きます程度だからな・・・・

**Socket774** · 2017/10/21(土) 22:24:00.88

命令セット全体でとりあえず動くけどスループットは今までと同じです実装だったのってSSE2整数ぐらいで
そんなに多くないよ

**Socket774** · 2017/10/22(日) 00:11:23.68

>>750
90nmの再来

**Socket774** · 2017/10/22(日) 00:55:20.54

AVX512は256bitで使っても機能面でメリットがあるんだが。

**Socket774** · 2017/10/22(日) 04:04:57.80

>>758
まずグッチャになった命令の整理をしなきゃ
話はそれから

**Socket774** · 2017/10/22(日) 04:20:51.82

>>750
https://twitter.com/search?q=46nm%20%40intel&;src=typd
intelの株屋の話だとfin heightが46nmになったみたいだね、@intelで確認したと言ってるが実際確認できなかった

**Socket774** · 2017/10/22(日) 04:59:24.83

人権なんてあったもんじゃない
人権無視の国日本！

広告配信システムのOpenXにバックドアが仕掛けられる
電通のおわり！
OpenXは2010年8月より電通子会社のサイバー・コミュニケーションズとアドエクスチェンジの独占的パートナーシップを締結、広告リクエストは開始当初より600％と急成長を遂げてきた・・・・
だってお！ｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗ

嘘も百回言えば真実となる広告産業のナチス的手法
電通自殺者を
ホロコーストを忘れるな諸君！
芸術よ永遠なれ！
自由主義者よ永遠なれ！

**Socket774** · 2017/10/22(日) 05:00:06.95

intel fin heightの遷移
34nm(22nm)→42nm(14nm)→46nm(14nm+)→46nm(10nm)→53nm(10nm+or++)?

**Socket774** · 2017/10/22(日) 05:05:40.61

これで10nmが14nm++に比べて冴えないのがなんとなく理解できるし性能が飛躍する10nm++でfin heightを53nmにする計画？

**Socket774** · 2017/10/22(日) 05:21:02.01

>>759
x64がひどいのは事実だが今さら変えられん。
SSEのオペコードもどうしようもない。
SSEのプリフィクスだけはAVXで整理して
拡張部分のエンコーディングはまあ許容範囲内だから
AVXだけなら合格点だ。

2017/10/22(日) 09:12:09.80

もう命令セットを直接いじる事は少なくなってきたから、ライブラリやコンパイラで吸収してもらわんとな。

2017/10/22(日) 09:33:57.77

>>759
実際にそれを用いる人らにとってはどうでもいいというか
整理されてスマートになったアーキテクチャとやらで
RISCみたいにプログラムを行う実際の顧客が発狂するような仕様になるだけ

2017/10/22(日) 10:32:32.23

こういうもん整理するとか行って整理できたためしがない

2017/10/22(日) 10:43:30.13

そうじゃなくてAVX512のサブセットのことだろ

2017/10/22(日) 11:08:35.68

>>762
高けーな
畳一畳の高層ビルみたいな感じになってるな

2017/10/22(日) 11:22:52.81

SSEは最低でもSSE命令のプリフィクスとREXプリフィクスの2つのプリフィクスを処理しないといけない。
AVXにはREXプリフィクスは付かないからデコードが楽になる。
何種類かあるAVXプリフィクスはプリデコーダで較的容易に一番長いタイプに変換可能であり、SSEもREXプリフィクスの処理の分遅くなってもAVXに準拠した命令に変換可能なのでデコーダ以降は一種類でいい。
厳密にはSSEとAVXでレジスタの未使用bitの扱いに非互換の部分があるがこれは内部命令が両方に対応しているがAVX命令の方が処理が軽くて速いまたは消費電力が少ないようになっている。
今後はAVXのSSE代替命令を使うようにすればいい。少なくともコンパイラは対応している。
すでにMMXとx87は代替命令を用意して発展的解消している。互換処理で遅くなっても過去のCPUよりは速いので問題はない。

2017/10/22(日) 11:36:46.69

x64は大枠においては良いのだがプリフィクスの整理をしなかったのと64bitモードからシームレスに16モードに移れず32bitOSと互換性をなくしてしまったのが問題。
Microsoftはこの問題に対して最終的に仮想マシンを立ち上げて32bitOSを走らせるという力業で対応したが、そのサポートもWindows7のProfessional以上にのみ限定で終わった。

2017/10/22(日) 16:12:10.84

>>770
計算ソフトでSSEとAVXで倍以上の速度差が出るときあるんだが
そういうのが原因なのかな

2017/10/22(日) 16:51:04.28

>>772
単純にSSEが128bit/8レジスタ/2オペランド,AVXが256bit/16レジスタ/3オペランドの実装になっていればそうなるな。

2017/10/22(日) 17:34:12.41

純粋に大量の計算をSIMDでガシガシしていく用途では倍近く
動画エンコードのようなシングルの重要な処理が入ると3割程度

2017/10/22(日) 18:31:47.41

AV-X

**Socket774** · 2017/10/22(日) 20:49:34.71

　　　　　　　　　　　　　　　　　　　　　　　　　／＼　　100％
むしろInｔelの方がシェアが高く感じられる　　／.　　　＼
　　　　　　　　　　　　　　　　　　　　　　　　／. 　　　　＼
　　　　　　　　　　　　　　　　　　　　　／　　　　　　　　＼
　　　　　　　　　　　　　　　　　　／　　　　　　　　　＼
　　　　　　　　　　　　　　　　　　　　／　　　　　　　　　　　　　　　＼
　　　　　　　　　　　　　　　　　／　　　　　　　　　　　　　　　　＼
　　　　　　　　　　　　　　／　　　　　　　　　　　　　　　　　　　　　　＼
　　　　　　　　　　　／　　　　　　　　　　　　　　　　　　　　　　　＼
　　　　　　　　　　　　　／　　　　　　　　　　　　　　　　　　,────＞　　　＼　0％
　　　　　　　　　　／　　　　　　　　　　　　　　　／　　　　　　　　　　　／
　　　　　　　／　　　　　　　　　　　　　　　　　　 /　　　　　　　　　　　／
.　　　　　　／　　　　　　　　　　　　　　／￣￣￣　　　　　　　　　／
　　　　　　／　　　　　　　 /￣￣￣　　　　　　　　　　　　　　／
.　　　　　／　　　　　　　　　　　 /　　　　　　　　　　　　　　　　　　／
. 　　／　　　　　　　　　／　　　　　　　　　　　　　　　　　／
　　／　　　　　＿＿＿＿／　　　　　　　　　　　　　　　　　／
　　＼　　　　／　　　　　　　　　　　　　　　　　　　　　　　　／
. 　　＼　　　　　　　　　　　　　　　　　　　　　　　／
.　　　　　＼　　　　　　　　　　　　　　　　　　　　　　／
　　　　　　＼　　　　　　　　　　　　　　　　／
.　　　　　　＼　　　　　　　　　　　　　　　／
　　　　　　　＼　　　　　　　　　／
　　　　　　　　　　＼　　　　　　　　／
　　　　　　　　　　　　　＼. 　　　　／
　　　　　　　　　　　＼.　　　／
　　　　　　　　　　　　　　＼／

**Socket774** · 2017/10/22(日) 22:06:14.87

64bitだとSSEも16レジスタじゃないけ？
AVX512は32本

**Socket774** · 2017/10/23(月) 05:59:34.26

>>777
SSEのレジスタ16本は手作業での最適化を32bit版と別にコーディングしないといけない上にCPUによっては逆に遅くなるから使ってないソフトも多いだろう。

**Socket774** · 2017/10/23(月) 08:49:00.61

visual studioなんかだと、32ビット版でSIMDを使おうとすると、関数の引数に制限があったりと、コードの互換性にかなり手間だった記憶があるな。

**Socket774** · 2017/10/23(月) 09:25:30.13

>>753-754
Raven RidgeのiGPUがMX150（≒GT1030）に迫る性能という話を聞くと、IntelとAMDの奇跡の融合がただのガセネタだったのはちと残念

**Socket774** · 2017/10/24(火) 02:14:29.90

>>778
Intrinsic使えばそんなことはない
逆に言えばアセンブリで書く人は32bitと64bitで別々に最適化したい人

**Socket774** · 2017/10/24(火) 02:36:33.31

>>781
AVX非対応のx64てWindowsだとほとんど32bitで使われてるんじゃない？
SandyBridgeが圧倒的すぎて64bitを使うような人は皆買い換えちゃったでしょ。
誰も使ってない狭い市場向けにオプションを開発しても割に合わないよ。

**Socket774** · 2017/10/24(火) 06:40:16.50

Intrinsicとアセンブラはまだまだ差が大きい

**Socket774** · 2017/10/24(火) 06:44:37.28

32bitはオワコン
レジスタ数も8本から増やしてもらえない
IntelやAMDからも見捨てられてる
パフォーマンスが必要なソフトで32bit環境なんて
考えられない

32bit版の最適化は手を抜いて
64bit版に注力するのが良い

**Socket774** · 2017/10/24(火) 07:17:00.75

　　　　　 """ﾘ"(( （''|ii,,,､-'ｰ-''(:ﾉﾉ
　　　　　ii､-'"―､;; ii､〉　　ひ　7;;
　　　　　省　媚｀(｀ﾉ　　　：　 {彡
　　　　　み　び　 {;;;;）　　退　 >彡
　　　　　ぬ　ぬ　i"::/　! !. か（:::;;;
　　　　　 ! !.　　　|　;;;ヽ＿ぬ / |
　　　　ﾏ-i,､-､r''"　;;;;;;ﾉYi )''"　し
　　　 ::::､ ii､ t;;;　:::::;;;;i':::::U　　::::::::
　　　 ::::::ヽヽ,,~ヽｰ､;; ::::::（　 ::::::::r
　　　 ::U::: ｀' ､ヽ､､ t;;;|ヽ;;;ヽ淫ノ;;;
　　　::::::::::;;､､､;;;;≧ミ=､,n,|ヽ;}ii |;;;;;
　　　 Z:r"タ"'",＝､''''ｰ､~'ｰ､ﾉﾉ|,i;ｰ
　　　　三＞'=='="ﾁ＝ｰ':｀'"､;;;;;ン
　　　U　 "　　::::::::::::::;;;;;;'''"ヽ|;;j彡"
　　､:::　　::::::::::::::,ｲ:::;;;;;;;~'-､,j;;jｰ''":
　　:､ ', U ::::::::::::::U::;;;;;;;;;;;､　ﾘ;;;|　:"
　　:::t ':,　::::::::::::::::::::''"（⌒　/;;ヽ
　　:::::t ヽ ::::::::（j:　　 ::::ヽ｀'（;;;;;;;）''"
　　::::::::t　U:::::::::　　_,,,､;;_ﾞ' ､;;;;;;;､ノ
　　::::::::::',　 ::::::::　ｲ'r､､"'''ｰ―ｰ-''"
　　::::::::::::ヽ　:::::::　ij（'ﾌﾞ｀""｀´´"´
　　 ::::::::::::::ヽ u ......~'''""~~￣￣￣
　　　:::::::::::::::::ヽ :::::J::::::::::::r;;;;;;;;;;;;ヽ
　|.|　::::::::::::::::::::::ヽ::::::::;;;;;::::;;;;;
　U ::::::::::　 :::::::::::::ヽ

**Socket774** · 2017/10/24(火) 16:00:54.45

>>782
Pentium、Celeronとかは今もAVX非対応

**Socket774** · 2017/10/24(火) 16:39:24.72

AVXが効果あるような用途でPentium？
とりあえず動くようにするだけでパフォーマンスは考えなくていい
もともとパフォーマンスとか気にしてない人たち用なんで

最適化が重要なのは、新しいCPUの64bit環境

**Socket774** · 2017/10/24(火) 19:54:28.51

パフォーマンスが必要な一部のソフト以外32bitで問題ない

VMとかで32bitXP動かして、XP時代のMSVCをつかって32bitでビルドすれば
ほとんどの環境で動作する

**Socket774** · 2017/10/24(火) 19:59:30.83

パフォーマンスが必要な一部のソフトの為のハイパフォーマンスCPUだろうが

**Socket774** · 2017/10/24(火) 20:00:19.66

VS2017でもXP用のビルドが出来る

**Socket774** · 2017/10/24(火) 20:01:54.02

Windows 10 64bit
VS2017

でも
32bit XPで動作するバイナリがビルドが出来る

**Socket774** · 2017/10/24(火) 20:04:15.57

パフォーマンスが不要ならネイティブアプリである必要も無いけど

**Socket774** · 2017/10/24(火) 20:58:11.97

>>786
全ラインナップでAVX対応してるのはAMDだけだしな

**Socket774** · 2017/10/25(水) 00:12:06.94

CoffeeのPenGはAVXとHTT有効
CeleronはAVXとHTTと引き換えに１コアにデグレードでいいよ
AVX有効2コアHTT無しだと旧PenG喰っちゃいかねないから

**Socket774** · 2017/10/25(水) 06:05:47.83

　　　ｶﾞﾀｶﾞﾀ　　　　ｵﾛｵﾛ
　　　/Iｎ＿/℡ 　　　ｶﾞﾀｶﾞﾀ
　　<<｀｀ДД´´;>>　　/Iｎ＿/℡,‐, 　　ｸﾞﾗｸﾞﾗ
　　//　　　＼＼　 {{∩∩；｀Д´ >ﾉノノ　　ｵﾛｵﾛ
　⊂⊂　　　ｌﾉつ'　　ヽヽ　　　ｌ'
　　　| |　（⌒）） }}　　　| |　（⌒）） }}
　　　 ,,し'⌒＾　　　　　　 ,,し'⌒＾

**Socket774** · 2017/10/25(水) 13:13:04.64

つかよくレジスタ16本とかでAVX命令行けるよね（512は別だけど）
この辺は可変長の恩恵なんだろうか

**Socket774** · 2017/10/25(水) 14:15:45.32

どの辺に感心してるのかよくわからん

**Socket774** · 2017/10/25(水) 14:19:29.23

AVX512は512bitレジスタがスレッドごとに32本
各コア、クロックごとに512bitFMAを2個ずつ実行可能

**Socket774** · 2017/10/25(水) 14:21:08.40

命令はプレフィックスによる拡張で非常に複雑
8bit時代をいまだに引きずっている

**Socket774** · 2017/10/25(水) 15:07:40.66

64bitは固定長+SIMD
32bitはエミュ
で良かったのに

**Socket774** · 2017/10/25(水) 15:29:31.22

itanium(ﾎﾞｿｯ)

**Socket774** · 2017/10/25(水) 15:49:34.08

>>801
核地雷はNG

**Socket774** · 2017/10/25(水) 16:56:16.11

AVX512のクロックの下がり方はかなり大きいな。
ベクトルが2倍になっても性能は1.45～1.68倍くらい

　　　　　　　　　　　　　　AVX512/AVX2　base/T all/T one　　　　　　　　　　　　　 2→512
Xeon Gold 6126F　12C　　　1.7/2.2　　　2.6/3.3/3.7　　　　135W　652.8GFLOPS　1.5454　$1931
Xeon Gold 6130F　16C　　　1.3/1.7　　　2.1/2.8/3.7　　　　125W　665.6GFLOPS　1.5294　$2049
Xeon Gold 6142F　16C　　　1.6/2.2　　　2.6/3.3/3.7　　　　160W　819.2GFLOPS　1.4545　$3101
Xeon Gold 6138F　20C　　　1.3/1.6　　　2.0/2.7/3.7　　　　135W　832.0GFLOPS　1.6250　$2767
Xeon Gold 6148F　20C　　　1.6/1.9　　　2.4/3.1/3.7　　　　150W　1024.0GFLOPS　1.6842　$3227

Xeon Platinum 8160F　24C　1.4/1.8　　2.1/2.8/3.7　　　　160W　1075.2GFLOPS　1.5555　$4856
Xeon Platinum 8176F　28C　1.3/1.7　　2.1/2.8/3.8　　　　173W　1164.8GFLOPS　1.5294　$8874

**Socket774** · 2017/10/25(水) 17:33:10.05

AVXに絡まない処理が巻き添え食らうペナルティーも見落とせない

**Socket774** · 2017/10/25(水) 17:38:35.72

内部命令にコード変換する時点で外部命令は自由に変えて良かった。
AMDはそこを理解せずに古いコードをそのまま64bitに持ち込んで失敗した。

**Socket774** · 2017/10/25(水) 17:56:17.36

失敗……？

**Socket774** · 2017/10/25(水) 18:12:16.50

x64命令は、駄作ではないが最良でもない、ほどほどの出来栄えの命令セットとして
長く使われる

**Socket774** · 2017/10/25(水) 18:39:14.88

高ベクトル計算を活かすにはRISCじゃ無理
HPC-ACEみたいにレジスタ拡張しまくればいけるかもしらんが

**Socket774** · 2017/10/25(水) 19:02:57.93

メモリーなオペランドもOK（パイプラインストールしまくり
レジスター（SIMD)はどうせ肥大化しまくるし
あとはメニーコア

**Socket774** · 2017/10/25(水) 19:08:40.35

つまりitaniumサイッキョってことですね

**Socket774** · 2017/10/25(水) 19:32:41.23

VLIWにするよりメモリアクセスを含めてOoOするほうが速いってわかっちゃったからなぁ

**Socket774** · 2017/10/25(水) 19:38:21.39

>>803
微妙なトランジスタの増加でその性能なら十分すぎる
コア数を1.5倍にするよりはるかに効率的

**Socket774** · 2017/10/25(水) 19:38:22.62

メモリーなオペランドあるx86のほうがOoOのありがたみがあるという

**Socket774** · 2017/10/25(水) 21:11:51.60

メモリーなオペランドは、内部的には複数命令に分かれる

**Socket774** · 2017/10/25(水) 22:57:53.56

実計算ソフトでSkylake-SPはBDW-EPより最大+138%のパフォーマンスアップ
さらにCST等、自分達の方がIntelライブラリよりさらにXeonのパフォーマンスを向上出来てると宣伝
サードパーティ含めこんだけ上げまくれるのに、ダメ路線とするのは流石にどうかしてる

**Socket774** · 2017/10/26(木) 00:27:51.34

>>812
微妙なトランジスタの数？

ま、3～4割の性能向上というのは大きくはあるけど
それに必要なトランジスタ数は少なくはないはず

**Socket774** · 2017/10/26(木) 00:44:28.54

BDW-EP 485mm^2、7.2B transistors
てのは出てたが（うろ覚え）
Skylake-SPに関しちゃ何もなかったな
けっこう増えてると思う
まあその分きちんと伸ばしてるんでいいんだけど

**Socket774** · 2017/10/26(木) 00:49:40.55

　　　　　　　　　　　　　　　　nonAVX　　　　　　　　　　　AVX512
　　　　　　　　　　　　　base/all T/8C T/1C T　base/all T/8C T/1C T
Xeon Gold 6144 08C　　3.5/4.1/4.1/4.2　　　　　　2.2/2.8/2.8/3.5　　　　$2925
Xeon Gols 6150 18C　　2.7/3.4/3.4/3.7　　　　　　1.9/2.5/3.2/3.5　　　　$3358

nonAVXではどの動作でも6144/8Cの方が動作周波数が高い。
AVX512ではbase clockは6144/8C の方が高いが8C Turbo clockは
6150/18Cの方が高い。逆転している。面白いな

**Socket774** · 2017/10/26(木) 01:07:05.41

>>814
いつの話をしてるんだ。今は1命令で処理してるだろ。

**Socket774** · 2017/10/26(木) 01:22:22.02

>>816 ダイサイズはAMDツェッペリンと大差なさそう。28Cが700平方mm、18Cが480平方mm。
ツェッペリンはインタコネクトとかPCIeの多さで面積食ってるようだけど。
※>>803は３～４割じゃなくて５～６割りでしょ。なぜ小さくなるｗ

**Socket774** · 2017/10/26(木) 01:29:01.22

>>818 8C稼働/10Cダイ、8C稼働/18Cダイで、放熱は後者が楽だからとか。

**Socket774** · 2017/10/26(木) 01:35:29.50

コア間のインターコネクトでも面積に差が出るので
ちゃんと見積もるならコアとキャッシュの面積で比べないと駄目