Just another WordPress site
このサイトが対応し忘れていたのでメモ
まずはDNSレコードの設定でAAAAレコードを設定する。
AAAAレコードというのはドメインに対応するipv6アドレスを記録するレコードでipv4でいうAレコードに相当する。
おわったらnginxの設定を行う。
/etc/nginx/conf.dの中にある設定ファイルで
service{
listen 80;
listen [::]:80;
…
とすればipv4、ipv6どちらからの接続も成功するようになった。
確認は自分の場合wgetを使って、サイトにipv6でアクセス出来る環境から
wget -6 http://code.kashimata.net/
という具合でアクセスして確かめた。
-6というのはipv6の使用を強制するオプションである。
ipv4について確認したいときは-4オプションを使う。
ツインテールアーキテクチャを提案している論文を読んだ。面白かった。
教授は僕の興味を汲み取ってくれてこの論文を読むことを勧めてくれたのだろう。
単純にまとめれば
評価の結果を見ると平均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は、本当に汎用的に使いたい分野にこそ向かないものの、同じプログラムを頻繁に利用するような組み込みの世界ではスループットを爆発的に改善する大きな一歩になるだろう。
物理メモリと仮想メモリのアドレス変換が出来なくて困っていた。
意外とちゃんと説明しているサイトは少ないようだ。
どのサイトもvirt_to_physとphys_to_virtを使えば良いということであったが…
virt_to_physとphys_to_vortを使うにはC言語の範疇には収まらないものをincludeしなければならない。具体的に言えばカーネルのヘッダーだ。
#include <asm/io.h>
こうして変換してみたものの、ペリフェラルにアクセスするとカーネルが落ちてしまった。
実はphys_to_virtは完璧な訳ではなく、io空間にアクセスするにはioremapを使わなければならないらしい。
ということでまとめてみると、
となります。
自分がハードウェアのことばかりを考えるようになってから久しいが、最近コーディング力の減少に悩まされている。
アルバイトを辞めてからだろうか。いや、あのバイトがコーディング力維持に役に立っていたとは思えない。
Atcoderの問題が全然解けなくて焦るばかりだ。
心が折れそうだ
プログラマーという職は100年後も残っているだろうか。
情報工学を扱っている人間としては残って欲しい気持ちが半分、残ってほしくない気持ちが半分だ。
なぜかって、当然プログラミングを機械が行う時代が来ると思っているからだ。
PEZYは本気でシンギュラリティを目指している。計算量的に十分なハードウェアが出来るのは時間とお金の問題だろう。(もしかしたら政治的な問題にも発展するかもしれないが)
そしてソフト的な面で言えば、Googleがやってくれると信じている。
googleがどの程度中を作れているかは分からないが、きっとやってくれるだろう。
僕はこの2社がコンビネーションすることでシンギュラリティに達成出来ると思っている。つまりプログラミングの行為そのものが人間が機械に頼むという行為に取って代わられる時代になると思っている。
一方で計算機科学自体が取って代わられることも機械学習の理論が廃れることも無いだろう。消されるかもしれないのは人間と機械の間のインターフェイスを埋めるというあまり本質的ではない部分だ。
基礎を大事にして勉強していきたいと今一度思う。
最近のCPUは早いんだからアーキ自体にもっとセキュリティの機能を付けようという発想のコンピュータアーキテクチャ開発の話を聞いた。（読んだ）
確かにそのとおりである。今のアーキテクチャは古い時代に設計されたものが主でセキュリティ関連の甘さを感じることは多い。
特にメモリのアクセス管理はアーキの部分に押し込めるべき部分だ。今まではMMUを使って特権モードとユーザーモードで区別してきたが、正直これだけだとゆるすぎるだろう。プロセス別に分けることを考える余裕はあると思う。
ただ、ここで書いたセキュリティをより強化すべきCPUは全てのCPUに当てはまるわけではない。当然組み込み(やHPC)は別に考えてしかるべきだろう。
アーキにおいて重要なのはバランスだ（うちの先生は「トーレドオフが重要」が口癖）
Avalonインターフェイスが良くわからず最近調べていたが単純に言えば
ということのようだ。
AXIより単純そうなので多用していきたいが、もっと標準化してもらえないと困るというのが本音。
Avalon-MMはシンプルなメモリインターフェイスでwaitrequestがアサートされたら待ってるだけなので楽。
Avalon-STに関してはまだ勉強中だが、mSGDMAを使うと良さそう。
Avalonインターフェイスの日本語資料はここにある。
https://www.altera.co.jp/documentation/nik1412467993397.html
今のご時勢、生産性が重要視される。
そんななか、最近はPythonやRubyが生産性が高いとして人気だ。
確かにCやC++で書くよりも遅くてもいいならPythonやRubyで書いたほうが良いと思う。
CやC++、Java、C#あたりは開発コストが高くつくといったところだろうか。
Web業界を見ていると生産性だけではなく、セキュリティやスクリプト言語自体が持つ手軽さ(生産性に含まれるが)といったところも重要視される。
一方、アーキテクチャ屋は何を目指しているかというと線形代数の計算高速化だ。主な用途としては流体シミュレーションなんかだろう。
もちろん密行列の計算を高速化するのに文句は言わないが、本当に目指すべきものなのだろうか。Top500は国の威信さえ関わっていると言っても過言ではないが、やはりこればっかりにこだわるのも危険だと思うし、一般大衆に役立つものをコミットしていくという大義を考えた時に目指すべき物が偏りすぎていると思う。
実際にコンピュータを利用する企業という視点から考ると、どうしても生産性の時点でRubyやPythonが強いのならばそれを使うのが当然と言ったところだ。つまり、この部分を高速化することは求められているし、社会貢献でもある。
スクリプト言語処理系の高速化はすすめるべき技術だと思う。
個人的にはまず処理系のソースコードを読んで見ることから始めていこうと思う。（おっとその前にその言語を使えるようにならなければ）
スパコンのベンチマークといえばLINPACKだろう。
Top500で使われているベンチマークで、線形代数の計算を行う。
確かに科学技術計算だと線形代数的な計算は多いのかもしれないが、実用的な計算はもっと複雑なものが多いだろうし、評価の尺度は多面的であるべきだ。
評価の尺度だけでも、演算性能と通信性能で大きく変わってくるだろう。特に通信性能が無視されているのではないかと心配である。
より一般的なアプリケーションを走らせたいと考えたときに通信はやはり多くなると思うのだ。例えばGCCでLinuxのカーネルをコンパイルするときにはメモリへのアクセスは多くなるだろう。また、このような場合はベクトルプロセッサやGPUなどSIMD計算機はあまり意味を為さない。
しかしながら、気象計算を行うときにCPUを使ってちまちま計算することはないはずだ。おそらくベクトルなりGPUを使うだろう。
Top500に縛られすぎて本当に使えるプロセッサを作れていないんじゃないかというのが最近よく思うところだ。