Just another WordPress site
キャッシュはメインメモリの内容をその名の通りキャッシュしておくわけだが、メリットとしては主記憶からわざわざ近くに持って来なくてもアクセス先の周辺やそれ自身がアクセスされたことがあるといつのまにか近くにデータが持って来られているという算段だ。同じ変数を頻繁にアクセスする時間的局所性と近くのデータにアクセスしやすい空間的局所性を利用することで効率的に動作する。
スクラッチパッドメモリのことを知らない人は多いかもしれないが、先ほど説明した通り、スクラッチパッドメモリは小さなキャッシュではない普通のメモリに見える。これを普通のメモリとして変数を割り当てたりするのはナンセンスな使い方だ。せっかくの高速なメモリなのでキャッシュと同じように頻繁にアクセスされるような使い方が望ましい。
僕は大学でHPCやコンピュータアーキテクチャを専攻する身であり、そのような分野では基本的にはISAを直に考え、HW Specificなネイティブコードについて考えたり扱うことが多い。
当然ネイティブコードの方が早いように思われるのかもしれないが、インターネットを介して多くのアプリケーションがやり取りされる今日、一つのアプリケーションでも複数のアーキテクチャに対してサポートしなければならないようになってきた。
今までのPCアプリケーション開発ではi386をターゲットにしてコンパイルしていたかもしれないが、これからはARMノートPCが来る。そして当然ARMノートPCの上でも性能は要求される。常にi386コードをエミュレーションして動作させるのはおそらくユーザーが納得しないだろう。
そこで重宝されるのがインターネット上での頒布はバイトコードで行う手法だと考えている。バイトコードをアーキテクチャから独立した形式で設計し、IA-64でもARMでもMIPSでももしかしたらこれから登場するかもしれないアーキテクチャにも対応させるのだ。
元々このアイディアはAndroidが実装していた。Android開発ではDalvikアーキテクチャという仮想的なアーキテクチャの上でのバイトコードを出力し、それをAndroid上でJITコンパイルで実行していた。これをLolipopになってからはARTという技術が導入されAOTコンパイルを可能にし、実行速度を改善した。しかしインストール時やアップデート時のコンパイルが必要となるため、この部分に時間がかかり、結局JIT形式に落ち着いたようだ。
バイトコードを利用するのはただ単に異なるアーキテクチャに対応させるためだけが目的ではない。たとえばARMで言えばNEON、Intelで言えばAVX/SSEのベクトル命令は性能を上げる上で利用したいものだ。しかし、これらは同じARMやx86_64でもプロセッサのグレードや想定使途などで細かく仕様が異なる。これを吸収することが出来るのがバイトコードなのではないかと考えているのだ。
SIMDを使う以外にもこれからのプロセッサはキャッシュよりもローカルメモリを使うようになるのではないかと思っているので、このローカルメモリのサイズの違いに合わせたネイティブコードを出力できるという点でもJIT/AOTは優れていると感じる。
（さらに抽象度を上げて言えば、ハードウェアスペシフィックな最適化を行うことが可能ということがとても良いのだ）
さっきからバイトコードと言っているものの、単に機械語よりは抽象度が高いが、高機能ではない中間表現として扱っているだけで、JavaバイトコードとかDalvikバイトコードが良いとか言っているわけではない。個人的にはLLVMのbcファイルの”LLVMビットコード”を推している。
Top500は世界で最も計算能力がある500台がリストになって掲載されている。
実際にはリストに載っていないスパコンはいっぱいあるのではないかという話を聞くが、そういうのは大体が軍事目的なのだろう。
さて、今の1位はSunway TaihuLightだ。
神威・太湖之光と書くらしい。
CPUはSW26010という中国独自開発のCPUだ。
これはアメリカの輸出制限の影響だと聞いたことがある。
動作周波数は1.45GHzと低い。これのおかげか、全体の消費電力は15.3MWで電力効率に優れる。
メモリバンドはそこまで大きくないようだ。
2位と比べると3倍程度性能が高く驚くばかりだ。
トップ勢のプロセッサを見ていくと2位、5位、6位とXeonPhiが目立つ。
一方、GPUが優位なはずなのに3位の次は8位だ。
会社で見ていくと3位、5位、8位、それ以降もCray社がとても多い。
Cray社のチップを使っているかどうかは分からないが、やはりそれだけのノウハウを持っていて、スパコンの販売実績も十分だからだろう。
ARMノートPC、絶対に来る。
ARMノートPCが今年発売されるらしいが、恐らくその魅力と言えば電池の持ちの良さになるのではないかなと思っている。今使っているMacBookもノートパソコンの部類の中ではかなりバッテリ持ちが良いほうだが、それでももっと長く電池が持てばと思うことは多い。ARMはIntelアーキと比べたらかなり低消費電力なはずだ。ただ画面の消費電力はARMノートPCでも減らないので、消費電力の低減は限定的にはなるだろう。しかし、画面の消費電力が大きいと認識されれば当然減らそうと躍起になるだろうからそこら辺も進歩するんじゃないのかな。
WindowもARMに対応する。x86のアプリケーションをエミュレーションするとか言っているし力の入れようが伺える。ネイティブアプリも増えるだろう。
ARMに移行するだけで消費電力は減るだろうが、やはり実行速度としては心配だ。Intelと同じくらいのサイズのキャッシュをARMにつけてプロセスサイズも同じなら互角に戦えるはずだが、なにしろそんな製品をまだ見たことが無いのでどうなるか分からない。またARMコアだから16コア程度積むのではないかと思っている。しかし、現在のアプリケーションはあまり並列化されていないしこれからもわざわざプログラマーが並列化して書いてくれるかというと暗雲が立ち込める。ChromeとかSafariあたりのブラウザはちゃんと対応しそうだが、OfficeだったりiTunesだったりは対応するだろうか。ARMノートPCが一般大衆に触れられる頃にはアプリケーションの並列性抽出が広く問題になっているかもしれない。
並列性抽出といえば並列言語だが、並列言語で書いても小さな並列性ばかりが集まってしまうらしい。だから自動解析は大切なのだ。
ツインテールアーキテクチャを提案している論文を読んだ。面白かった。
教授は僕の興味を汲み取ってくれてこの論文を読むことを勧めてくれたのだろう。
単純にまとめれば
評価の結果を見ると平均13.6%の性能向上ということでまずまずの結果かな
今の研究はFPGAとARMがひとつになったXilinx社でいえばZYNQ、Altera社でいえばAltera-SoCというものを触っているのだが、この可能性について書きたい。
ARMは近年いろいろなところで利用されるようになった。CPUの出荷台数で言えばARMはintelの数倍になっている。
本題のARMとFPGAの組み合わせだが、使っているということはアリだと思っているわけである。というのも、ARMが使われている分野は(電池駆動の)組込系が多く消費電力にシビアな世界が多い。だから高性能なCPUは使えない。じゃあGPUはどうかというと更に消費電力が高く組み込み系には使いづらいだろう。
ARMコア単体でも組み込み系で特に電力に関してシビアなものに搭載されているというイメージがある。一方FPGAは今まで単体でカメラなどに採用されてきたが汎用性の問題で置き去りにされてきたイメージだ。この汎用性の問題が解決すれば十分に使い物になると思う。特にCNNを利用した画像処理は大量の計算リソースが必要でFPGAに適しているだろう。
ARMからFPGAがコンフィギュア可能という特徴があるのでアプリケーションごとにFPGAを再構成させることが可能になる。また、全体の再構成だけではなく、部分的再構成させることも可能になるだろう。(今も苦労すれば出来るのかもしれないが)
個人的にはFPGAという細粒度な再構成可能アクセラレータよりCGRAのような粗粒度な再構成可能アクセラレータに分があると考えている。
FPGAは、本当に汎用的に使いたい分野にこそ向かないものの、同じプログラムを頻繁に利用するような組み込みの世界ではスループットを爆発的に改善する大きな一歩になるだろう。
最近のCPUは早いんだからアーキ自体にもっとセキュリティの機能を付けようという発想のコンピュータアーキテクチャ開発の話を聞いた。（読んだ）
確かにそのとおりである。今のアーキテクチャは古い時代に設計されたものが主でセキュリティ関連の甘さを感じることは多い。
特にメモリのアクセス管理はアーキの部分に押し込めるべき部分だ。今まではMMUを使って特権モードとユーザーモードで区別してきたが、正直これだけだとゆるすぎるだろう。プロセス別に分けることを考える余裕はあると思う。
ただ、ここで書いたセキュリティをより強化すべきCPUは全てのCPUに当てはまるわけではない。当然組み込み(やHPC)は別に考えてしかるべきだろう。
アーキにおいて重要なのはバランスだ（うちの先生は「トーレドオフが重要」が口癖）
今のご時勢、生産性が重要視される。
そんななか、最近はPythonやRubyが生産性が高いとして人気だ。
確かにCやC++で書くよりも遅くてもいいならPythonやRubyで書いたほうが良いと思う。
CやC++、Java、C#あたりは開発コストが高くつくといったところだろうか。
Web業界を見ていると生産性だけではなく、セキュリティやスクリプト言語自体が持つ手軽さ(生産性に含まれるが)といったところも重要視される。
一方、アーキテクチャ屋は何を目指しているかというと線形代数の計算高速化だ。主な用途としては流体シミュレーションなんかだろう。
もちろん密行列の計算を高速化するのに文句は言わないが、本当に目指すべきものなのだろうか。Top500は国の威信さえ関わっていると言っても過言ではないが、やはりこればっかりにこだわるのも危険だと思うし、一般大衆に役立つものをコミットしていくという大義を考えた時に目指すべき物が偏りすぎていると思う。
実際にコンピュータを利用する企業という視点から考ると、どうしても生産性の時点でRubyやPythonが強いのならばそれを使うのが当然と言ったところだ。つまり、この部分を高速化することは求められているし、社会貢献でもある。
スクリプト言語処理系の高速化はすすめるべき技術だと思う。
個人的にはまず処理系のソースコードを読んで見ることから始めていこうと思う。（おっとその前にその言語を使えるようにならなければ）
スパコンのベンチマークといえばLINPACKだろう。
Top500で使われているベンチマークで、線形代数の計算を行う。
確かに科学技術計算だと線形代数的な計算は多いのかもしれないが、実用的な計算はもっと複雑なものが多いだろうし、評価の尺度は多面的であるべきだ。
評価の尺度だけでも、演算性能と通信性能で大きく変わってくるだろう。特に通信性能が無視されているのではないかと心配である。
より一般的なアプリケーションを走らせたいと考えたときに通信はやはり多くなると思うのだ。例えばGCCでLinuxのカーネルをコンパイルするときにはメモリへのアクセスは多くなるだろう。また、このような場合はベクトルプロセッサやGPUなどSIMD計算機はあまり意味を為さない。
しかしながら、気象計算を行うときにCPUを使ってちまちま計算することはないはずだ。おそらくベクトルなりGPUを使うだろう。
Top500に縛られすぎて本当に使えるプロセッサを作れていないんじゃないかというのが最近よく思うところだ。
「アーキテクチャの研究に未来はあるか」
ここ数ヶ月の最も大きな悩みの種のひとつである。
コンピュータアーキテクチャと聞いて何を思い浮かべるだろうか。どれほどの数のアーキテクチャを挙げられるだろうか。自分はこの世界に入ったばかりだからか指で数えられる程度しか知らない。
しかしながらこれは数多くのアーキテクチャが提案されたにも関わらず、商業的な成功を収めたアーキテクチャがそれだけしかないという意味である。
更に、今以上に効率的なアーキテクチャを作ることは難しいのではないかという雰囲気すら感じる。
このとても小さいパイの中で研究することはリスクだ。
しかし、諦めたくない。今のプロセッサのアーキが最適だとは思えないし、自分ならもっと良いアーキを提案できると思っている。
アーキを馬鹿にする人たちが居るが、アーキの進歩は確実にコンピュータ・サイエンスの幅を広げているのだ。例えばGPUがなければ機械学習はまだ20年前に失速した技術だっただろう。
アーキの世界には実際には使えないようなオレオレアーキテクチャをたくさん発表している人がいるようだが、そんな人たちを反面教師に実際に使われてコンピュータ・サイエンスの幅を広げられたらなと思う深夜である。