アカウント名:
パスワード:
>10nmは低消費電力にフォーカスしており、演算性能自体は14nm++の方が高い周波数が上げられないという事かな?Caffe lakeは熱的条件が厳しので、シングルスレッド性能を犠牲にしてでもRyzen同様8コア積んで貰えれば、それで十分だと思う。7nmのZen2が控えているので、Intelもぱっと花を咲かせて貰いたいところ。
コアが増えて性能が上がるならいいが、今でもコアの負荷が100%になることはなくて、よくて2コアで50%ぐらいなんだよね。しかも4コアに比べて8コアが性能2倍になるかといえば、メモリ帯域を食い合うので、そんなことはない。
逆に言うとトランジスタは余っているので、コア数減らして、その分、シングルスレッド上げてほしい。それができないからコア数を増やしているんだろうし、単純にキャッシュをこれ以上増やしても性能上がらないし、となるとAES-NIのような専用回路を増やすしかないのかもしれない。でも専用回路で性能を上げる処理もネタ切れなんだろう。
個人的には、x86でないコアも載せて、新しいソフトは新コア、古いソフトはx86コアにしてほしいけど、最初は使われない新コア分はまるまる無駄だから、そんなことしないよなあ。デコーダだけ二つ用意して、切り替えるという手もあるが、デコーダはクリティカルパスだろうし、そんなこと無理か。
じゃあ今度はCPUコア毎にメインメモリも実装すればいいのよ。(=キャッシュメモリの大容量化)
まあ、MS-DOS時代から考えたら、メインメモリ全部、2次キャッシュに入っているようなもんだけどな。
Cell Broadband Engineは10年早かった!?
コンパイルとかしたら簡単に全コア100%いくから単純にコア増やして欲しい。x86じゃないコアってGPU載ってるじゃん。x86ではない汎用CPUという意味ならそんなもの載せても意味が無い
コンパイルとか、動画のエンコードとか、仮想化とかするとコア数はもっと多くても問題ないですよね。
ストレージが遅いのでコンパイルで全コア100%って言うほど簡単ではないと思うんですが……
言語にもよりますかね
Node.js使うと割とCPU食い尽くす印象があります。JavaScriptへの変換をコンパイルと呼ばないとは思いますが・・・
んなこたない。SSD使ってる?
linuxのカーネルのコンパイルでは、HDD使っていても、"よくて2コアで50%"って事はないでしょう。
templateゴリゴリなコードをコンパイルしたらあっという間に100%張り付きですよ。linux kernelをmake -j 64してみてください。
>>逆に言うとトランジスタは余っているので、コア数減らして、その分、シングルスレッド上げてほしい。
それはプログラマ側からの切実な要望だが、それで性能上げようにもクロック周波数が頭打ちだからどうにもならんのよね(プロセッサ・メーカーの技術屋に同じ文句言ったことがあるが、その意見は理解できるがやっぱりクロック周波数がぁ~というご返事でした)
ローエンドの組込プロセッサでもプロセスの微細化が進み、余ったシリコンの使い道に困っている(?)というような状態で、パッケージのピン数と比較してやたらペリフェラルの数と機能がリッチなデバイスばかりシリコンが余ってるならメモリ沢山積んで欲しいのだが、もともとアドレス空間が狭いのと命令セットの制約でどうにもならない.......
Tr.だけで構成しているSRAM以外のメモリ素子ってCMOSロジックプロセスと相性が悪いんだよ。追加のプロセスが必要だったり、余計な材料使う必要があったりするから。#1T SRAMなら通常のCMOSプロセスで作れるけど、DRAMとしての性能はイマイチだしDRAMとしてはデカい。
ここにぶら下げさせていただきますわよ、先程メモリの価格調べたらDDR4-2666 16GB(8GBx2)で2万円なんですね。
#20年前はEDO DRAMのSIMMが16MBで2万円だったのよ。#Windowsも8MBのメモリで動いてたのよ。
んで、SRAMが6TでDRAMが1Tと1Cで、単純に同容量比で6倍価格が高いとしても、たかだか12万円なんだから、主記憶がSRAMの製品もあればと思ってるんでザマス。CPUのレジスタからL3キャッシュは、もちSRAMだしApple Watchの主記憶もSRAM。
だけど下の書き込みだと、今でもL3までのキャッシュで十分だから、主記憶が速くなっても100%超えないくらいの性能向上なのかな。
L3キャッシュへのアクセスが20サイクルくらいで、主記憶へが300サイクルくらいのが60サイクルくらいのレイテンシになっても、遅いのかな。だれかシュミレーションして結果知りたい。
もうこのストーリーは賞味期限切れかもしれませんが、一応コメントを。
LSIの業界では、メタル配線の最小ピッチの「F」としたとき、「Fの2乗」=「F2」を基本単位として面積を比較するのが一般的です。SRAMが6T、DRAMが1Tなのは確かなのですが、面積は6:1ではなく、200:6か200:4ぐらいです。 http://www.nims.go.jp/AAA_ReRAM/research_2.html [nims.go.jp] リンク先の比較ではSRAMが130F2になっていますが、最新プロセスだと200F2以上に悪化しています。なぜそうなるかというと、サイズがトランジスタ密度で決まっているのではなく、配線密度で決まってしまうからです。
その上、配線が複
今日のプロセッサは(2次)キャッシュミスが律速しているのでシングルスレッド性能を上げるのは難しいキャッシュにデータが載ってなければどうしようもないので、容量を増やすか賢くプリフェッチするしかないが、前者はすでに最適化されている
PC用途の場合、現時点でもキャッシュのヒット率は高い。
R3000での調査によると、100%ヒットする魔法のキャッシュがあったとしても、性能向上は68%でしかない。PentiumM発表時の情報によるとデータミスでCPU動作時間の20%がデータミスで失われているらしい。この場合、100%ヒットするキャッシュがあっても、25%しか性能向上しない。
なのでキャッシュでの性能向上の余地はあまりない。
実行モデルも知らずに数字を出しても意味がない
演算器の数を増やしても並列性を抽出できなければ意味がないが、今のプロセッサはそろそろその上限に近づいている分岐予測はとても効率が良くなった残るはキャッシュだが、これは昔からメカニズムも変わっていないし足を引っ張り続けている自動プリフェッチは分岐予測ほど賢くはないとにかくキャッシュ(とプリフェッチ)以外はできることをやりつくした感があるね無限の演算器と100%あたるキャッシュがあったところで、非数値計算であれば内在する並列度は5-10命令と言われているので、アグレッシブな投機実行をしない限りはそこまで
キャッシュの効率を上げたいなら、まずマルチタスクを止めることだな。OSもノンプリエンティティブなやつにして、カーネルなどが定期的にキャッシュを使用してしまうことを防ぐのがいい。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
クラックを法規制強化で止められると思ってる奴は頭がおかしい -- あるアレゲ人
マルチスレッド性能の時代 (スコア:1)
>10nmは低消費電力にフォーカスしており、演算性能自体は14nm++の方が高い
周波数が上げられないという事かな?Caffe lakeは熱的条件が厳しので、シングルスレッド性能を犠牲にしてでもRyzen同様8コア積んで貰えれば、それで十分だと思う。
7nmのZen2が控えているので、Intelもぱっと花を咲かせて貰いたいところ。
Re:マルチスレッド性能の時代 (スコア:0)
コアが増えて性能が上がるならいいが、今でもコアの負荷が100%になることはなくて、よくて2コアで50%ぐらいなんだよね。
しかも4コアに比べて8コアが性能2倍になるかといえば、メモリ帯域を食い合うので、そんなことはない。
逆に言うとトランジスタは余っているので、コア数減らして、その分、シングルスレッド上げてほしい。
それができないからコア数を増やしているんだろうし、単純にキャッシュをこれ以上増やしても性能上がらないし、となるとAES-NIのような専用回路を増やすしかないのかもしれない。
でも専用回路で性能を上げる処理もネタ切れなんだろう。
個人的には、x86でないコアも載せて、新しいソフトは新コア、古いソフトはx86コアにしてほしいけど、最初は使われない新コア分はまるまる無駄だから、そんなことしないよなあ。
デコーダだけ二つ用意して、切り替えるという手もあるが、デコーダはクリティカルパスだろうし、そんなこと無理か。
Re: (スコア:0)
じゃあ今度はCPUコア毎にメインメモリも実装すればいいのよ。(=キャッシュメモリの大容量化)
Re: (スコア:0)
まあ、MS-DOS時代から考えたら、メインメモリ全部、2次キャッシュに入っているようなもんだけどな。
Re: (スコア:0)
Cell Broadband Engineは10年早かった!?
Re: (スコア:0)
コンパイルとかしたら簡単に全コア100%いくから単純にコア増やして欲しい。
x86じゃないコアってGPU載ってるじゃん。x86ではない汎用CPUという意味ならそんなもの載せても意味が無い
Re: (スコア:0)
コンパイルとか、動画のエンコードとか、仮想化とかするとコア数はもっと多くても問題ないですよね。
Re: (スコア:0)
ストレージが遅いので
コンパイルで全コア100%って言うほど簡単ではないと思うんですが……
Re: (スコア:0)
言語にもよりますかね
Node.js使うと割とCPU食い尽くす印象があります。
JavaScriptへの変換をコンパイルと呼ばないとは思いますが・・・
Re: (スコア:0)
んなこたない。SSD使ってる?
Re: (スコア:0)
linuxのカーネルのコンパイルでは、
HDD使っていても、"よくて2コアで50%"って事はないでしょう。
Re: (スコア:0)
templateゴリゴリなコードをコンパイルしたらあっという間に100%張り付きですよ。
linux kernelをmake -j 64
してみてください。
Re: (スコア:0)
>>逆に言うとトランジスタは余っているので、コア数減らして、その分、シングルスレッド上げてほしい。
それはプログラマ側からの切実な要望だが、それで性能上げようにもクロック周波数が頭打ちだからどうにもならんのよね
(プロセッサ・メーカーの技術屋に同じ文句言ったことがあるが、その意見は理解できるがやっぱりクロック周波数がぁ~というご返事でした)
ローエンドの組込プロセッサでもプロセスの微細化が進み、余ったシリコンの使い道に困っている(?)というような状態で、パッケージのピン数と比較してやたらペリフェラルの数と機能がリッチなデバイスばかり
シリコンが余ってるならメモリ沢山積んで欲しいのだが、もともとアドレス空間が狭いのと命令セットの制約でどうにもならない.......
Re: (スコア:0)
Tr.だけで構成しているSRAM以外のメモリ素子ってCMOSロジックプロセスと相性が悪いんだよ。
追加のプロセスが必要だったり、余計な材料使う必要があったりするから。
#1T SRAMなら通常のCMOSプロセスで作れるけど、DRAMとしての性能はイマイチだしDRAMとしてはデカい。
Re:マルチスレッド性能の時代 (スコア:2)
ここにぶら下げさせていただきますわよ、
先程メモリの価格調べたらDDR4-2666 16GB(8GBx2)で2万円なんですね。
#20年前はEDO DRAMのSIMMが16MBで2万円だったのよ。
#Windowsも8MBのメモリで動いてたのよ。
んで、SRAMが6TでDRAMが1Tと1Cで、
単純に同容量比で6倍価格が高いとしても、たかだか12万円なんだから、
主記憶がSRAMの製品もあればと思ってるんでザマス。
CPUのレジスタからL3キャッシュは、もちSRAMだしApple Watchの主記憶もSRAM。
だけど下の書き込みだと、今でもL3までのキャッシュで十分だから、
主記憶が速くなっても100%超えないくらいの性能向上なのかな。
L3キャッシュへのアクセスが20サイクルくらいで、
主記憶へが300サイクルくらいのが60サイクルくらいのレイテンシになっても、
遅いのかな。だれかシュミレーションして結果知りたい。
Re: (スコア:0)
もうこのストーリーは賞味期限切れかもしれませんが、一応コメントを。
LSIの業界では、メタル配線の最小ピッチの「F」としたとき、「Fの2乗」=「F2」を基本単位として面積を比較するのが一般的です。
SRAMが6T、DRAMが1Tなのは確かなのですが、面積は6:1ではなく、200:6か200:4ぐらいです。
http://www.nims.go.jp/AAA_ReRAM/research_2.html [nims.go.jp]
リンク先の比較ではSRAMが130F2になっていますが、最新プロセスだと200F2以上に悪化しています。
なぜそうなるかというと、サイズがトランジスタ密度で決まっているのではなく、配線密度で決まってしまうからです。
その上、配線が複
Re: (スコア:0)
今日のプロセッサは(2次)キャッシュミスが律速しているのでシングルスレッド性能を上げるのは難しい
キャッシュにデータが載ってなければどうしようもないので、容量を増やすか賢くプリフェッチするしかないが、前者はすでに最適化されている
Re: (スコア:0)
PC用途の場合、現時点でもキャッシュのヒット率は高い。
R3000での調査によると、100%ヒットする魔法のキャッシュがあったとしても、性能向上は68%でしかない。
PentiumM発表時の情報によるとデータミスでCPU動作時間の20%がデータミスで失われているらしい。この場合、100%ヒットするキャッシュがあっても、25%しか性能向上しない。
なのでキャッシュでの性能向上の余地はあまりない。
Re: (スコア:0)
実行モデルも知らずに数字を出しても意味がない
演算器の数を増やしても並列性を抽出できなければ意味がないが、今のプロセッサはそろそろその上限に近づいている
分岐予測はとても効率が良くなった
残るはキャッシュだが、これは昔からメカニズムも変わっていないし足を引っ張り続けている
自動プリフェッチは分岐予測ほど賢くはない
とにかくキャッシュ(とプリフェッチ)以外はできることをやりつくした感があるね
無限の演算器と100%あたるキャッシュがあったところで、非数値計算であれば内在する並列度は5-10命令と言われているので、アグレッシブな投機実行をしない限りはそこまで
Re: (スコア:0)
キャッシュの効率を上げたいなら、まずマルチタスクを止めることだな。
OSもノンプリエンティティブなやつにして、カーネルなどが定期的にキャッシュを使用してしまうことを防ぐのがいい。