カテゴリー: Uncategorized

近頃量子コンピュータが話題になってきたが、これによってコンピュータアーキテクチャ界隈がどのような影響を受けることになるのかを考えてみたい。
(とはいえ、量子コンピュータに詳しいわけではないので、このブログを引用してとかあまり当てにするのはやめてほしい。)

量子コンピュータはビットが0か1かを明示せずに計算できるコンピュータだ。
(ちょっと雑な説明だろうか。ただ自分の中では単にこれだけしか理解していない)

世間では現在のスパコンを遥かに凌ぐ性能と言われているが、合っているような間違っているようなという気分だ。
というのも量子コンピュータに合った計算と合わない計算というものがある。
簡単に言ってしまえば探索問題ならスパコンを遥かに凌ぐ性能と言えるだろう。(ビット数の問題はある)
一方で工場の制御をする場面という”制御”が中心となる計算、天気予報などの流体計算、ディープラーニングなど探索的な方法が通じないものは量子コンピュータではあまり速くならない。

量子コンピュータで速くなるもの

• 暗号解読
• ナップザック問題
• SAT
• その他クラスNPに属する問題の一部 (最適化問題のこと)

量子コンピュータで速くならないもの

• 機械の制御
• 天気予報 (速くなる部分は多少あるかも)
• 流体計算
• ディープラーニングによる画像処理
• クラスPに属する問題

どうだろうか。こうしてみると意外と速くならない計算も多いように感じる。

ただ、一番影響が大きいのが暗号解読の問題だ。
おそらくアメリカの国防総省とかNSAあたりは量子コンピュータを持つことになる(多分既にある)。そしてテロリストの暗号化されている通信を傍受するだろう。
今まではrsaを使ってきたから、又はecdsaを使ってきたから安全だと言ってきたが、これだけ量子コンピュータの開発成功例が出てくると本格的に暗号を解ける量子コンピュータが出来上がるのは時間の問題なのかもしれない。
アメリカ政府が持つだけなら日本にとっては大きな問題にはならないだろう。しかし手にするのはアメリカ政府だけだとは思えない。学術的には論文にして発表し、再現性が確保されなくてはならないことを考えると論文になった時点で中国などの金銭的余裕のある国家、またはロシアなどの必要にせまられる国家は持っていると考えた方が良いだろう。
こうした時、企業や政府が機密を守れなくなり、国防、企業テロなどの面で影響が出ることになる。
(プライバシーの問題と言っている人もいるが、国・企業と主な重役しか標的にならないと思う。量子コンピュータが高価だし、通信傍受も難しい)

ここで登場するのがポスト量子暗号だ。
ポスト量子暗号は量子コンピュータでも解けない暗号という意味で、格子暗号というものが有力である。
GoogleがChromeに搭載したことでニュースになったようだ。
http://itpro.nikkeibp.co.jp/atcl/news/16/070802038/

いずれにせよ、量子コンピュータが普及し、ポスト量子暗号が使われる世界でも現代のプロセッサのコンピュータアーキテクチャが要らなくなるわけではない。むしろ量子コンピュータと現代プロセッサの境界に触れることができるかもしれない。これからが楽しみだ。

modelsimがubuntuで起動しなくて困っていた。
以下長々と書く内容をまとめるとライブラリが足らなくて起動できなかったようだ。
vsimというのがmodelsimの実体なのだが、実行しても”No such file or directory”と出てきて起動しなかった。
fileコマンドを使って見てみると
./vsim: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux.so.2, for GNU/Linux 2.6.4, BuildID[sha1]=be0130f25d5768e095133f4ed1d9d69902768269, stripped
と出てくるのでやはりELFでi386の実行ファイルだ。/lib/ld-linux.so.2はさすがにあるだろうと思っていたのだが、探して見たら無かった。どうやらこのマシンには/lib64/ld-linux-x86-64.so.2しか無いようだった。”ldが無い”というのはちょっと最初は信じられなかったがどうやら調べてみるとi386用のlibcが無いらしい。
今までアプリケーションはapt経由かソースを持ってきてコンパイルするかだったのでこの様なことになったのだろう。
ということで
sudo apt install libc6:i386
をした後に./vsimを実行すると
./vish: error while loading shared libraries: libX11.so.6: cannot open shared object file: No such file or directory
というメッセージに変わるのでここからはエラーで出てきたライブラリのi386版をインストールするだけで済むので楽になる。
以下のコマンドで必要だったライブラリを一括インストールできる。
sudo apt install libc6:i386 libx11-6:i386 libxext6:i386 libxft2:i386 libncurses5:i386

#x86のライブラリが全然無いなんて思ってなかった

元々Windowsがインストールされている環境からUbuntuをインストールすれば簡単にデュアルブートさせることができた。

しかしCentOSをここに入れたら詰まったのでメモ

元々OSがインストールされているということと、パーティションは自分で設定したかったので手動で設定することにした。

しかし「partition で ext4 ファイルシステム を 使用する場合、grub2によって組込まれる core.img用領域 が sda には不足している可能性があります。」というエラーがどうしても解決できなかった。

どうやらgrubが問題ということでブートローダのインストールをしないことで解決することができる。

おそらく新しいパーティーションだとここまでで済むはずだが、自分は元々ubuntuが2個入っているうちの1つを潰してCentOSをインストールした関係で間違えてgrubを潰してしまった。そのせいでlive cdから修復させざるを得なかった。この方法は以下を参考にしてほしい。

https://askubuntu.com/questions/145241/how-do-i-run-update-grub-from-a-livecd

研究をしていて壁に行き詰まった。
自分の先行はコンピュータアーキテクチャなのだが、コンピュータアーキテクチャを変えようとすると大体今の汎用プロセッサよりプログラミング、コンパイルが難しくなる。
プログラミング、コンパイルの容易さを表す指標がプログラマビリティなのだが、論文を読んでいてもプログラマビリティが定量的に評価されていない。

定量的に評価されていないものが良くなった、悪くなった、あれより良い、これより良いと言われたところでそれを証明することが出来ない。定性的な評価はされていてもどの程度信頼性を置いて良いものか分からない(これは定量的評価が可能であっても)。

自分としてはプログラマビリティの高いアーキテクチャが作れたつもりなのだが、そのアーキテクチャのプログラマビリティがどうなのか人に説明することが難しい。

こんなんでは新しいISAの形を考える分野が縮小してしまうのではないか。

gem5を使ってみたら”kernel too old”というエラーが出てしまい使えなかった。
ぐぐってみると多くの人がここの部分で躓いていてそれらの回答はいつもソースコードを変えなければならないものだった。

どうにかならないのかなと思いつつメモ。

ターゲットがARMの場合
src/arch/arm/linux/process.cc
の
unameFunc32の中の
strcpy(name->release,”ここにバージョン名”);
という部分のバージョン名を今のカーネルのバージョン名に合わせることで解決した。
ちなみに今のカーネルのバージョン名はuname -rで取得できる。

ターゲットがX86の場合は
src/arch/x86/linux/process.cc
のようだ

アーキテクチャのシミュレータにはgem5を使うと良いと聞き使ってみようとしたが、
以下のようなビルドエラーが発生しコンパイルできなかった。
これが解決出来たのでメモ。

tomoya@tomoya-DESK:~/gem5$ scons -c
scons: Reading SConscript files ...
AttributeError: 'NoneType' object has no attribute 'group':
  File "/home/tomoya/gem5/SConstruct", line 764:
    if not as_version or compareVersions(as_version, "2.23") < 0:
  File "/home/tomoya/gem5/src/python/m5/util/__init__.py", line 131:
    v1 = make_version_list(v1)
  File "/home/tomoya/gem5/src/python/m5/util/__init__.py", line 127:
    return map(lambda x: int(re.match('\d+', x).group()), v.split('.'))
  File "/home/tomoya/gem5/src/python/m5/util/__init__.py", line 127:
    return map(lambda x: int(re.match('\d+', x).group()), v.split('.'))

解決するにはexport LANG=Cを実行してからコンパイルすれば良い。

検索しても見つからず最終的にエラーが起きている部分をPrintfデバッグで突き止めることとなった。トホホ

プログラマーという職は100年後も残っているだろうか。

情報工学を扱っている人間としては残って欲しい気持ちが半分、残ってほしくない気持ちが半分だ。

なぜかって、当然プログラミングを機械が行う時代が来ると思っているからだ。

PEZYは本気でシンギュラリティを目指している。計算量的に十分なハードウェアが出来るのは時間とお金の問題だろう。(もしかしたら政治的な問題にも発展するかもしれないが)

そしてソフト的な面で言えば、Googleがやってくれると信じている。
googleがどの程度中を作れているかは分からないが、きっとやってくれるだろう。

僕はこの2社がコンビネーションすることでシンギュラリティに達成出来ると思っている。つまりプログラミングの行為そのものが人間が機械に頼むという行為に取って代わられる時代になると思っている。

一方で計算機科学自体が取って代わられることも機械学習の理論が廃れることも無いだろう。消されるかもしれないのは人間と機械の間のインターフェイスを埋めるというあまり本質的ではない部分だ。

基礎を大事にして勉強していきたいと今一度思う。

この記事は前の記事を誤って消してしまったので思い出して書いています。間違いがあったらご指摘頂けると嬉しいです。

Androidでstd::to_stringが使えないという事態に遭遇しました。

これはcocos2d-xと言うopenGL系のライブラリを使ってゲームを作っていた時のことなのですが、std::to_stringがundefinedになってしまってリンクできないということがありました。

どうやらこれはgccのARMEABIという ABI(スマホでよく利用されているARMアーキテクチャのCPUで使われているABI)向けの標準ライブラリのバグのようです。

私はgccではなく、clangを代わりに使うことでこのバグは回避しました。