アカウント名:
パスワード:
SVEは第一義的にはARMが開発しているもので、富士通はパートナー企業のひとつってだけでは?
ARMの新ベクトル命令「SVE」、ポスト京に採用へhttp://eetimes.jp/ee/articles/1608/25/news036.html [eetimes.jp]
リンク先に「SIMD拡張命令セットにArmと富士通が共同開発したSVE(Scalable Vector Extensions)を採用。」とか「富士通は、この拡張命令の開発をサポートしており」とか書いてあるんだから、富士通も入れたあげてら、開発者に。
2016年の記事だけど、この記事 [hpcwire.jp]によれば、
富士通は(今のところ)この取り組みにおけるリード・シリコンパートナーであり、2020年のタイムフレームで計画されている日本の次期主力スーパーコンピュータにSVE技術を使ったARMを使用する。
とある。主にチップの実装・試験レベルの関与だと思うけど、共同開発といえば共同開発かな。
ARMにとっては、新アーキテクチャの最初の1台がTOP500でトップ級の性能のマシンになるわけで、この上ないロンチカスタマーだよな。
社内にSPARC64の設計チームがいるんだからSVE関連の設計からやってるんじゃないの?
SPARC64もSPARCのIPの上にHPC向けの機能を追加してる製品だったので、今回のプロセッサでも同じような体制なんじゃね。
> とある。主にチップの実装・試験レベルの関与だと思うけど、
これにどういう根拠があるのかわからないのだが、ARMはHPCの経験がないので命令セットの策定には富士通に教えてもらう立場だったというのが事実
その話が本当なのか前にいろいろググってみたが具体的に富士通が何をしたという話は見つからなかった。むしろここで話題になってない某社が重要な役割を果たしたということが分かった。
プレスリリース [fujitsu.com]ぐらい読め
富士通はアームとの協業によりHPC(High Performance Computing)システムのベクトル処理能力を大幅に拡張するArmv8-Aアーキテクチャの拡張命令セットアーキテクチャ(SVE:Scalable Vector Extension)の策定に貢献するとともに、その成果を採用しました
プレスリリースなのでウソは言わないと思うし、全部やったとはいってないから、いくつかあるパートナーの一つ、でしょ?
富士通が協力してないとは思ってないが、「富士通が開発したSVE」と言えるような状況ではなさそうだ、ということ。「富士通も開発に協力したSVE」だな。
http://www.ssken.gr.jp/MAINSITE/event/2016/20160826-hpcf/lecture-04/SS... [ssken.gr.jp] これの12ページには> 富士通のHPCの経験・技術を活かし、ARMと共同設計って書いてますね。
今回のCPUのマイクロアーキテクチャは富士通で開発していますね http://journal.jp.fujitsu.com/2016/08/23/01/ [fujitsu.com]
命令セット
> SVEの各命令の詳細やソースやディスティネーションのレジスタ番号の指定に使えるのは、24bitである。データのサイズやプレディケートの指定のビットが必要であるので、2つのソースオペランドと1つのディスティネーションのレジスタの番号を指定するのには24bitでは足りない。このため、大部分のSVE命令では、結果がソース1のレジスタを上書きする2アドレス命令となっている。ただし、MOVPRFX命令とADD命令を連続して書くと、実質的に結果を別のレジスタに格納する3アドレス命令として動作するという仕掛けが組み込まれている。京コンピュータのSPARCプロセサでは、このような命令が設けられていたので、この部分は、富士通の貢献の1つではないかと思われる。
プリフィックス命令はHPC-ACEにもあるが他の命令と同じく32ビット幅もあるからで命令発行に負担をかけるのだARMとしては他の解決もあったのだが富士通が説得力あるデータを示してMOVPRFX方式を採用させたわけ富士通の貢献というのはこういうところ
命令セットは非常に長生きするから設計はとても難しい実装を考えない命令は役立たずだが、かといってmipsやsparcの近視眼的な遅延スロットもあっというまに盲腸化するヘネシーやパターソンが阿呆だったからではない本質的に難しいのだだから命令セットの評価も専門家でも難しく、スラド民の手に負えるものではない(難しいからCISCvsRISC論争などが起きるのだ)しかしどの世界でも言えることはあって、それはデータを持っているやつが偉いとうことだこの場合は富士通が相当する
そう思ってるだけでしょ
富士通様がわざわざ教えてやったんだとはどこにも書いてないって言ってんだけど
「ARMと富士通が共同開発したSVE」じゃないの?
富士通はsparcとARMとGS21でマイクロアーキテクチャを共通化する気なのかAMDはx64とARMの共通化を実質断念したようだけど
> 富士通はsparcとARMとGS21でマイクロアーキテクチャを共通化する気なのか
そのようですよ。デコーダーだけは別だけど、それ以降は共通化するのでマイクロアーキテクチャ開発の負担は少ないって発表を読んだことがあります。
> AMDはx64とARMの共通化を実質断念したようだけど
K12 を中止したのは、ARMのサーバー市場がまだ立ち上がってないこの状況で、Intelに比べると相当限られているリソースを Ryzen に集中させるのが得策だという経営上の判断でしょう。K12 もテープアウトまでは行ってたので、断念したのは技術的理由ではなく市場的理由だと思います。
そういえばSH-4なんかも16bitと短い命令セットだから2オペランドなんだけど、MOVとADDとか単純な演算命令の組み合わせだとMOVによっては0レイテンシで実行できたりする。実質2命令で3オペランドの1命令っぽく実行できて面白いなと思ったことがあった。命令セットって色々奥が深くて面白い。
HPC拡張(SVE)の策定には協力しているでしょうhttp://www.ssken.gr.jp/MAINSITE/event/2017/20170830-hpcf/lecture-04/SS... [ssken.gr.jp]
協力したって書いてあるだけでその具体的な内容は分からない
そりゃ、そんな細かいところに価値を見出す人は一般にいないからね
下のandoさんの記事で↓の記載があったから富士通の知見はSVE策定に生かされてるといえるのでは
>SVEの各命令の詳細やソースやディスティネーションのレジスタ番号の指定に使えるのは、24bitである。データのサイズやプレディケートの指定のビットが必要であるので、2つのソースオペランドと1つのディスティネーションのレジスタの番号を指定するのには24bitでは足りない。
>このため、大部分のSVE命令では、結果がソース1のレジスタを上書きする2アドレス命令となっている。ただし、MOVPRFX命令とADD命令を連続して書くと、実質的に結果を別のレジスタに格納する3アドレス命令として動作するという仕掛けが組み込まれている。京コンピュータのSPARCプロセサでは、このような命令が設けられていたので、この部分は、富士通の貢献の1つではないかと思われる。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
あつくて寝られない時はhackしろ! 386BSD(98)はそうやってつくられましたよ? -- あるハッカー
富士通が開発? (スコア:1)
SVEは第一義的にはARMが開発しているもので、富士通はパートナー企業のひとつってだけでは?
ARMの新ベクトル命令「SVE」、ポスト京に採用へ
http://eetimes.jp/ee/articles/1608/25/news036.html [eetimes.jp]
Re: (スコア:0)
リンク先に「SIMD拡張命令セットにArmと富士通が共同開発したSVE(Scalable Vector Extensions)を採用。」
とか「富士通は、この拡張命令の開発をサポートしており」
とか書いてあるんだから、富士通も入れたあげてら、開発者に。
Re:富士通が開発? (スコア:0)
2016年の記事だけど、この記事 [hpcwire.jp]によれば、
富士通は(今のところ)この取り組みにおけるリード・シリコンパートナーであり、2020年のタイムフレームで計画されている日本の次期主力スーパーコンピュータにSVE技術を使ったARMを使用する。
とある。主にチップの実装・試験レベルの関与だと思うけど、共同開発といえば共同開発かな。
Re: (スコア:0)
ARMにとっては、新アーキテクチャの最初の1台がTOP500でトップ級の性能のマシンになるわけで、この上ないロンチカスタマーだよな。
Re: (スコア:0)
社内にSPARC64の設計チームがいるんだからSVE関連の設計からやってるんじゃないの?
SPARC64もSPARCのIPの上にHPC向けの機能を追加してる製品だったので、
今回のプロセッサでも同じような体制なんじゃね。
Re: (スコア:0)
> とある。主にチップの実装・試験レベルの関与だと思うけど、
これにどういう根拠があるのかわからないのだが、ARMはHPCの経験がないので命令セットの策定には富士通に教えてもらう立場だったというのが事実
Re: (スコア:0)
その話が本当なのか前にいろいろググってみたが具体的に富士通が何をしたという話は見つからなかった。
むしろここで話題になってない某社が重要な役割を果たしたということが分かった。
Re:富士通が開発? (スコア:1)
プレスリリース [fujitsu.com]ぐらい読め
富士通はアームとの協業によりHPC(High Performance Computing)システムのベクトル処理能力を大幅に拡張するArmv8-Aアーキテクチャの拡張命令セットアーキテクチャ(SVE:Scalable Vector Extension)の策定に貢献するとともに、その成果を採用しました
プレスリリースなのでウソは言わないと思うし、全部やったとはいってないから、いくつかあるパートナーの一つ、でしょ?
Re: (スコア:0)
富士通が協力してないとは思ってないが、
「富士通が開発したSVE」と言えるような状況ではなさそうだ、ということ。
「富士通も開発に協力したSVE」だな。
Re: (スコア:0)
http://www.ssken.gr.jp/MAINSITE/event/2016/20160826-hpcf/lecture-04/SS... [ssken.gr.jp]
これの12ページには
> 富士通のHPCの経験・技術を活かし、ARMと共同設計
って書いてますね。
今回のCPUのマイクロアーキテクチャは富士通で開発していますね
http://journal.jp.fujitsu.com/2016/08/23/01/ [fujitsu.com]
命令セット
Re:富士通が開発? (スコア:1)
> SVEの各命令の詳細やソースやディスティネーションのレジスタ番号の指定に使えるのは、24bitである。データのサイズやプレディケートの指定のビットが必要であるので、2つのソースオペランドと1つのディスティネーションのレジスタの番号を指定するのには24bitでは足りない。
このため、大部分のSVE命令では、結果がソース1のレジスタを上書きする2アドレス命令となっている。ただし、MOVPRFX命令とADD命令を連続して書くと、実質的に結果を別のレジスタに格納する3アドレス命令として動作するという仕掛けが組み込まれている。京コンピュータのSPARCプロセサでは、このような命令が設けられていたので、この部分は、富士通の貢献の1つではないかと思われる。
プリフィックス命令はHPC-ACEにもあるが他の命令と同じく32ビット幅もあるからで命令発行に負担をかけるのだ
ARMとしては他の解決もあったのだが富士通が説得力あるデータを示してMOVPRFX方式を採用させたわけ
富士通の貢献というのはこういうところ
Re:富士通が開発? (スコア:3, 興味深い)
命令セットは非常に長生きするから設計はとても難しい
実装を考えない命令は役立たずだが、かといってmipsやsparcの近視眼的な遅延スロットもあっというまに盲腸化する
ヘネシーやパターソンが阿呆だったからではない
本質的に難しいのだ
だから命令セットの評価も専門家でも難しく、スラド民の手に負えるものではない(難しいからCISCvsRISC論争などが起きるのだ)
しかしどの世界でも言えることはあって、それはデータを持っているやつが偉いとうことだ
この場合は富士通が相当する
Re: (スコア:0)
そう思ってるだけでしょ
Re: (スコア:0)
富士通様がわざわざ教えてやったんだとはどこにも書いてないって言ってんだけど
Re: (スコア:0)
「ARMと富士通が共同開発したSVE」じゃないの?
Re: (スコア:0)
富士通はsparcとARMとGS21でマイクロアーキテクチャを共通化する気なのか
AMDはx64とARMの共通化を実質断念したようだけど
Re: (スコア:0)
> 富士通はsparcとARMとGS21でマイクロアーキテクチャを共通化する気なのか
そのようですよ。
デコーダーだけは別だけど、それ以降は共通化するのでマイクロアーキテクチャ開発の負担は少ないって発表を読んだことがあります。
> AMDはx64とARMの共通化を実質断念したようだけど
K12 を中止したのは、ARMのサーバー市場がまだ立ち上がってないこの状況で、
Intelに比べると相当限られているリソースを Ryzen に集中させるのが得策だという
経営上の判断でしょう。
K12 もテープアウトまでは行ってたので、断念したのは技術的理由ではなく市場的理由だと思います。
Re: (スコア:0)
そういえばSH-4なんかも16bitと短い命令セットだから2オペランドなんだけど、MOVとADDとか単純な演算命令の組み合わせだとMOVによっては0レイテンシで実行できたりする。実質2命令で3オペランドの1命令っぽく実行できて面白いなと思ったことがあった。
命令セットって色々奥が深くて面白い。
Re: (スコア:0)
HPC拡張(SVE)の策定には協力しているでしょう
http://www.ssken.gr.jp/MAINSITE/event/2017/20170830-hpcf/lecture-04/SS... [ssken.gr.jp]
Re: (スコア:0)
協力したって書いてあるだけでその具体的な内容は分からない
Re: (スコア:0)
そりゃ、そんな細かいところに価値を見出す人は一般にいないからね
下のandoさんの記事で↓の記載があったから富士通の知見はSVE策定に生かされてるといえるのでは
>SVEの各命令の詳細やソースやディスティネーションのレジスタ番号の指定に使えるのは、24bitである。データのサイズやプレディケートの指定のビットが必要であるので、2つのソースオペランドと1つのディスティネーションのレジスタの番号を指定するのには24bitでは足りない。
>このため、大部分のSVE命令では、結果がソース1のレジスタを上書きする2アドレス命令となっている。ただし、MOVPRFX命令とADD命令を連続して書くと、実質的に結果を別のレジスタに格納する3アドレス命令として動作するという仕掛けが組み込まれている。京コンピュータのSPARCプロセサでは、このような命令が設けられていたので、この部分は、富士通の貢献の1つではないかと思われる。