CPUの歴史

今回はCPUについてです。
最新のものに目を向けがちですが、
歴史を踏まえて紹介していきたいと思います。

1970年以前
　コンピュータのようなものは存在していましたが、演算装置には
　現在のCPUのような１つのIC（集積回路）ではなく、
　真空管やトランジスタ、複数のICを組み合わせて構成されていました。
　そして、1970年に世界初のワンチップのマイクロプロセッサが登場しました。
　F14戦闘機の飛行制御用に開発され、動作周波数は50Hz程度だったそうです。

1970年代
　性能的にCPUと呼べる程度のものが、この頃から世の中に出回り始めました。
　前半は電卓程度のプロセッサでしたが、後半に入ると8ビットのCPUが主流となり、
　やっとパソコンと認識できるようなものが世に出回りました。
　この年代に開発された8ビットCPUから派生したCPUが、初代ファミコンで採用されています。
　動作周波数は5MHz程度まで上がってきました。

1980年代
　16～32ビットCPUが主流となり、業務用ワークステーションという分野が一気に広がりましたが、
　パソコンの分野では16ビットCPUがまだまだ主流でした。
　Pentiumが登場するのは次の年代ですが、動作周波数は100MHzまで上がりました。
　なお、この時代に開発された32ビットCPUが、初代プレイステーションで採用されています。

1990年代
　初の64ビットCPUが登場し、サーバー用の高性能CPUとして採用されました。
　一方、パソコンの分野では16ビットから32ビットへの転換期でした。
　Windows95が発売された時は、ニュースでも大きく取り上げられましたが、
　OS自体は16ビットでしたので、32ビットOSであるWindowsNTを使用する人もいました。
　この頃から自作パソコンが復旧し始め、速度を求める流れが始まった気がします。
　動作周波数は1GHzを超えてきました。
　プレイステーション２では128ビットCPUが専用開発されたりもしました。
　
2000年代
　中盤までは速度重視の流れを引き継ぎましたが、動作周波数が4GHz程度まで上がると、
　それ以降は技術的な問題で、速度を上げられない領域に入りました。
　CPU内ではプロセッサとレジスタ（プロセッサ内部のメモリ）で
　データの出し入れをしながら演算しますが、すべて電気信号に乗せて行われます。
　電気が伝わる速度は変えられないため、プロセッサとレジスタの距離を近付けて製造することにより
　動作周波数を引き上げてきましたが、それも限界に来たようです。
　では、限界が来たからそのままかと言うと、そうではありません。
　次はマルチコア化と低電力化が進みました。

2010年代
　マルチコア化と低電力化は今も継続されていますが、単にプロセッサ数を増やすだけでなく
　パソコン用途では画像処理用のプロセッサを同居させたり、スマホ・タブレット用途では
　通信制御を行うプロセッサを同居させたり、今までのCPUとは違った付加価値を持たせるようになりました。

最近知って驚いたのですが、あのスパコン（京）の動作周波数が2GHzだという事です。
単に動作周波数だけで性能が決定されるのではなく、ディスク装置とかデータ転送方式とか
全体としての性能を決定付ける部分が重要になってきているのでしょう。

CPUの今後の性能向上はそれほど見込めない模様ですが、
その反面、CPU以外の部分にアイデアが注ぎ込まれるようになったと思います。
なにかいいアイデアを出して、一山当てたいですね（笑）

monipet
　　動物病院の犬猫の見守りをサポート
　　病院を離れる夜間でも安心

ASSE/CORPA
　　センサー、IoT、ビッグデータを活用して新たな価値を創造
　　「できたらいいな」を「できる」に

OSGi対応 ECHONET Lite ミドルウェア
　　短納期HEMS開発をサポート！

GuruPlug
　　カードサイズ スマートサーバ

株式会社ジェイエスピー
　　横浜に拠点を置くソフトウェア開発・システム開発・
　　製品開発(monipet)、それに農業も手がけるIT企業

ServiceWorker

前回の記事を書いてからずいぶんと時間があいてしまいました。
今回は前回の予告通り、「ServiceWorker」についてご紹介したいと思います。

ServiceWorkerとは何かを簡単に説明しますと、「バックグラウンドでJavaScriptを動作させ、
様々な処理をWebページの状態に関係なく実行することができる機能」です。
Webページ上のJavaScriptとは別のスレッドで動作する形となり、Workerの一種となります。
それでは簡単に使い方をご説明します。


■インストール方法
ServiceWorkerを使うにあたってはまず、Webページ上で動作するJavaScriptから
ServiceWorkerとなるJavaScriptファイルをブラウザにインストールする必要があります。
インストール後にServiceWorkerは待機状態となり、画面を更新することで動作が開始します。
ServiceWorkerのJavaScriptに記述することで、独自のインストール処理を指定することもできます。

　　◆UIスレッド
　　// ServiceWorkerをインストールする。
　　navigator.serviceWorker.register("serviceWorker.js");

　　◆ServiceWorkerスレッド(serviceWorker.js)
　　// UIスレッドでnavigator.serviceWorker.register関数が呼ばれると、
　　// ServiceWorker側ではinstallイベントが発火する。
　　// event.waitUntil関数を利用すると、
　　// インストール処理に独自の処理を追加することができる。
　　self.oninstall = function(event) {
　　　　event.waitUntil(
　　　　　　// Promiseを用いた非同期処理を指定する。
　　　　　　new Promise(function(resolve, reject) {
　　　　　　　　// ～処理～

　　　　　　　　// 処理が完了したらresolve関数を呼ぶ。
　　　　　　　　resolve();
　　　　　　});
　　　　);
　　}


■ServiceWorkerの開始方法
先ほどまででServiceWorkerをインストールすることはできました。
しかしそのままでは画面を更新するまでは動作が開始しません。
インストールしてすぐに動作させたい場合はclaim関数を呼ぶ必要があります。

　　◆ServiceWorkerスレッド
　　// ServiceWorkerがactivateされた後でないとclaim関数を呼ぶことができない。
　　// なのでactivateイベント中に実行する。
　　self.onactivate = function(event) {
　　　　event.waitUntil(self.clients.claim());
　　};


■ServiceWorkerとUIスレッドの通信方法
ServiceWorkerはUIとは別のスレッドで動くため、
直接データをやり取りしたり、ServiceWorkerから画面を操作したりすることができません。
そのため、MessageChannelを用いて通信する必要があります。

　　◆UIスレッド
　　// ServiceWorkerからの連絡を受け取れるようにする。
　　var messageChannel = new MessageChannel();
　　messageChannel.port1.onmessage = function(event) {
　　　　// event.dataにデータが格納される。
　　};

　　// ServiceWorkerへデータを送る。
　　navigator.serviceWorker.controller.postMessage("message", [messageChannel.port2]);

　　◆ServiceWorkerスレッド
　　// UIスレッドからの連絡を受け取れるようにする。
　　self.onmessage = function(event) {
　　　　// event.dataにデータが格納される。

　　　　// 応答を返す。
　　　　e.source.postMessage("Response is here.");
　　};

ただし、この方法ではUIスレッドからServiceWorkerへ通信することはできても、
ServiceWorkerからUIスレッドへ通信することができません。
ServiceWorkerから通信するには、ServiceWorkerが保持するClientsを利用する必要があります。
長くなるため、今回は割愛させていただきます。


■ServiceWorkerを使ってできること
ServiceWorker内ではDOMへアクセスすることができません。
また、完全に非同期な設計をされているため、XHRやlocalStorageなどの同期型APIも利用できません。

その代わりに、新たに用意された各種APIを利用することで様々なことが実現できます。

◆Fetch API
XHRの代わりにHTTP通信を可能とするAPIです。
キャッシュの制御やCORSなどをXHRよりも細かく制御することができます。
また、UIスレッドにてXHR通信を行った際に、ServiceWorker側でその通信をフックして、
サーバーの代わりに応答したり、別のリクエストに書き替えたりすることができます。

◆Cache API
詳細なキャッシュ制御を可能とするAPIです。
Fetch APIと組み合わせて、
「キャッシュがあればそこから応答し、なければサーバーに問い合わせる」
というような、これまでブラウザが自動でやっていたキャッシュに関する部分を
自分たちで制御することができます。

◆Push API
スマートフォンなどに通知を出すことができるAPIです。
これまでのWebでは、ブラウザを閉じたり、タブを閉じたりすると、
Webページから何かアクションを起こすことができませんでした。
Push APIを利用することで、ユーザがWebページから離れたあとも
「通知」という形でアクションを起こすことができるようになります。

◆Background Sync
「通信ができるようになったら自動で通信」というような処理を可能とするAPIです。
ServiceWorker、Fetch API、Cache APIを組み合わせることで、
端末がオフライン状態でもWebページを表示することが可能になります。
しかし、コメントを投稿したりすることはできません。
そういった場合に、「通信ができるようになったらあとで投稿」することができます。

他にも例えばこんな使い方ができるようです。
https://www.youtube.com/watch?v=2ugAVXRkr9U


いくつかAPIを紹介しましたが、他にも仕様検討中のAPIがいくつかあります。
上で紹介したAPIについても、仕様検討中の機能があったりします。
これまでの「Webページ」では考えられなかった機能がたくさん実現されそうですね。
今後の動向に期待です。


最後に、現在の仕様をもとに作られたServiceWorkerのデモサイトをご紹介します。

・ServiceWorkerとPush APIを用いたチャットサイト
　http://www.locchat.com/

　簡単な利用手順　
　1.Android端末のChromeブラウザから上記のサイトを開いてください。
　　「通知を送信しようとしています。」というポップアップが出るので、許可してください。
　　そうしたら、タブを閉じて、Chromeブラウザを終了してください。
　2.今度はPCのChromeブラウザから上記のサイトを開いてください。
　　画面上部の入力欄からメッセージを入力して、Enterを押してください。
　3.Android端末に通知が届きます。

monipet
　　動物病院の犬猫の見守りをサポート
　　病院を離れる夜間でも安心

ASSE/CORPA
　　センサー、IoT、ビッグデータを活用して新たな価値を創造
　　「できたらいいな」を「できる」に

OSGi対応 ECHONET Lite ミドルウェア
　　短納期HEMS開発をサポート！

GuruPlug
　　カードサイズ スマートサーバ

株式会社ジェイエスピー
　　横浜に拠点を置くソフトウェア開発・システム開発・
　　製品開発(monipet)、それに農業も手がけるIT企業

ジェット

日本国産のジェット旅客機(MRJ)が、そろそろ就航するだろうということで、
今回は飛行機のエンジンに関する技術の話題です。

好奇心を刺激する点では、やはりジェットの方が魅力あります。
プロペラ機のエンジンは自動車のエンジンとあまり変わらないので、
ここでは特に触れません。

ジェットエンジンを簡単に説明しますと、形は筒状になっていて
前方から取り込んだ空気を圧縮しながら燃焼室へ運び、
燃料と圧縮空気を燃やして後方から排気する流れです。

１．吸気
２．圧縮
３．燃焼
４．排気

自動車のエンジンは燃焼の力を回転として取り出しますが、
飛行機のジェットエンジンは排気を推進力として取り出す方式です。

全く異なるアプローチでエネルギーを取り出すので、２つの技術に接点など無いと思っていましたが、
エネルギーを取り出すまでの工程（プロセス）を整理してみると、
実は同じ工程を経てエネルギーを取り出していることに気が付きます。

経験上の話ですが、色々な事象には、効率の良い工程というものがあって、
突き詰めて行くとだいたい同じ方針になると思っています。
つまり、飛行機のエンジンの工程を改善して効率を上げる事に成功したなら、
自動車のエンジンにも応用ができると必然的に期待してしまいます。

ここで、ジェットエンジンの種類について確認しますと、
大きく２つに分類されます。

①ターボジェットエンジン
　自然吸気でエンジン内に空気を取り込み、圧縮室にある低圧コンプレッサで圧縮し、
　燃焼室で圧縮した空気に燃料を混ぜて連続的に燃焼させます。
　車のエンジンと違い、常に燃焼が続くので大きな力を発生させられますが、
　その分、燃料の消費が激しいことが想像できます。
　燃焼した空気は後方から排出する際、低圧コンプレッサを稼働させるためのタービンを回します。
　排気でタービンを回して空気を圧縮する力を取り出しているので、
　名称にターボと付いているわけです。

②ターボファンエンジン
　ターボジェットエンジンに吸気ファンを追加したものを指し、
　ほとんどのジャンボジェットで、この方式を採用しています。
　コアとなる部分は同じですが、低圧コンプレッサと同じ回転軸で吸気ファンを回します。
　推進力は吸気ファンによるものが主となり、吸気された空気はバイパスエアと呼ばれ
　圧縮室や燃焼室の外側を通りますので、音を遮る効果もあるそうです。
　ちなみに、ジャンボジェットの吸気ファンのブレード１枚の価格は１千万円ほどで、
　エンジン１機で約２０枚ほど付いています。

ターボファンエンジンでは、比較的新しい技術として
吸気ファンの回転数を変則ギアで制御する仕組みがあります。

燃費を良くするためには、吸気ファンを大型化するのが近道でしたが、
タービンと同一軸では毎分１万回転以上で回転する事となり、
ブレード先端が音速を突破して衝撃波を伴う騒音が問題となりました。
そこで、吸気ファンの回転軸をタービンと別軸とした上で
変速ギアにより回転数を下げる手法が取られました。

しかし、変速ギアを組み込む事により、燃費は良くなるものの
信頼性やメンテナンス性の問題が大きいため、あまり実用化が進んでいないようです。

MRJが就航する頃、問題点が解決されていれば、
燃費面が向上されているはずなので、航空機料金が安くなるかも知れませんね。


monipet
　　動物病院の犬猫の見守りをサポート
　　病院を離れる夜間でも安心

ASSE/CORPA
　　センサー、IoT、ビッグデータを活用して新たな価値を創造
　　「できたらいいな」を「できる」に

OSGi対応 ECHONET Lite ミドルウェア
　　短納期HEMS開発をサポート！

GuruPlug
　　カードサイズ スマートサーバ

株式会社ジェイエスピー
　　横浜に拠点を置くソフトウェア開発・システム開発・
　　製品開発(monipet)、それに農業も手がけるIT企業

ディープラーニング～Deep Learning(深層学習)【利用編】

先月7/7の「ディープラーニング～Deep Learning(深層学習)【学習編】」にて、
「Google Photos」について頭出ししましたが改めて。

今年の5月末頃に発表された「Google Photos」は衝撃でした。
ストレージの容量を気にせず写真をアップロード出来ることは衝撃です。
さらに驚いたのが、アップロードした写真が自動的に分類されることです。
「小人さんが分類するわけでもないし、すごい！」なんて思いましたが、
この分類を実現しているのが、ディープラーニングの力なのです。
ディープラーニングを使って写真を分析することで、
人や場所、出来事を自動的に分類できるのです。

例えば、
衣食住の情報を大量にあつめて、これらを学習させることでニューラルネットワークを構築するとします。
多種多様の大量なデータで構築されたニューラルネットワークを利用することで、
特定のインプット情報をキーとしてパターンを特定することができます。
「いま食べたいのはきっとこれだ！」とか「これを食べ続けるとこうなってしまいますよ・・・」とか、
ある入力情報をもとに結果を出す事ができます。出来るはずです。

大量なデータでニューラルネットワークを構築して、
これを利用すればディープラーニングを体感できるわけです。

机上レベルでは分かってきた気がしますので、実際に体感してみたいと思います。

ディープラーニングのフレームワークとしては、「Caffe」、「Theano」、「Chainer」などがあるようです。
本記事では、「Chainer」に注目してみたいと思います。

「Chainer」は「Preferred Networks（PFN）」が公開するディープラーニングを実現するための
オープンソース（OSS）です。Pythonのライブラリとして提供されています。

Pythonのプログラムを書いたり、「Chainer」付属のサンプルを使用して、
「Chainer」の理解を深めていきたいと思います。

現在、「Chainer」の実行環境を構築中です。

次回に続く。


monipet
　　動物病院の犬猫の見守りをサポート
　　病院を離れる夜間でも安心

ASSE/CORPA
　　センサー、IoT、ビッグデータを活用して新たな価値を創造
　　「できたらいいな」を「できる」に

OSGi対応 ECHONET Lite ミドルウェア
　　短納期HEMS開発をサポート！

GuruPlug
　　カードサイズ スマートサーバ

株式会社ジェイエスピー
　　横浜に拠点を置くソフトウェア開発・システム開発・
　　製品開発(monipet)、それに農業も手がけるIT企業

ディープラーニング～Deep Learning(深層学習)【学習編】

人工知能の分野で非常に大きな注目を集めている技術です。
ディープラーニングとは、
“ニューラルネットワークを使ったパターン認識技術”です。
今年の5月末頃に発表された“Google Photos”の写真の自動分類を実現している技術です。

ではでは、少しずつ噛み砕いて理解していきましょう。
“ニューラルネットワーク”とは何でしょうか。

ニューラルネットワークとは、脳内の神経回路のネットワークモデルをコンピュータ内で実現しようとしたものです。
脳内には多数のニューロンと呼ばれる神経細胞が存在します。
ニューロンは信号の送受信を双方で行いあうことで、情報処理を行っています。
このモデルをコンピュータ内のネットワークに実現したものがニューラルネットワークです。
複数のニューロンがつながったメッシュの構造をイメージされたかもしれません。
イメージはあっています。特徴的なのが“３種類の層”です。
（そもそも私が図示すればわかりやすいのですよね・・・次回は図を描きますね。）

入力層、隠れ層、出力層の３種類の層（役割）が存在します。
入力に対して単純な変換処理を繰り返し、繰り返し、最後に出力する。
このような処理を３種類の層でこなします。
先に登場した“Google Photos”の写真の自動分類を例に説明します。
入力として画像（写真）が渡され、単純な変換処理を繰り返し繰り返し繰り返し、
最後に「この写真はＸＸで撮られた写真だ！」といった予測結果を出力する。
このような処理が入力層、隠れ層、出力層の３種類の層で行われます。

「繰り返し繰り返し繰り返し・・・」と記しましたが、この部分が隠れ層の役割になります。
隠れ層は１層ではなく、何層にも重なった構造になっており、この層の重なりが
ニューラルネットの処理精度の向上のポイントとなります。
何層も何層も、深い構造に。
“深い”というキーワードが登場しましたね。
これが、ディープラーニングという名前の由来でもあります。
ディープラーニングでは何層にも重なって構成されたニューラルネットワークが肝ということです。

何層にも重なったニューラルネットワークがあれば、写真の自動分類も簡単にできそうですね。
さて、このニューラルネットワークはどのように構築するのでしょうか。

そもそもニューラルネットワークは、“学習”と“利用”という概念があります。
先に登場した何層にも重なったニューラルネットワークは“学習済みニューラルネットワーク”とも呼ばれます。

このニューラルネットワークを構築（学習）する方法が大きく分けて２つあります。
この方法を簡単に説明しますと、学習する際に“講師”がいるかいないかの２通りです。

“講師”とは学習する際の見本のようなものです。
入力データを与えてニューラルネットワークを学習させますが、この入力データを与える際に、
「これはこのような分類のデータですよ」といったように教えながら学習させる方法が“講師付き学習”です。
「君たち、自分で学ぶんだぁ！」という方法が“講師なし学習”です。
「先生が教えてくれないと・・・」なんて私は思っていましたが、講師なし学習の手法として
“自己組織化マップ”というモデルも存在します。すごいですね。
自分で覚えられるのですね。「背中をみて育て！」といった職人さんの感覚ですね。
以上、ニューラルネットワークの“学習”についてでした。

次は“利用”について。
“利用”についてはディープラーニングの次回号で記載したいと思います。

monipet
　　動物病院の犬猫の見守りをサポート
　　病院を離れる夜間でも安心

ASSE/CORPA
　　センサー、IoT、ビッグデータを活用して新たな価値を創造
　　「できたらいいな」を「できる」に

OSGi対応 ECHONET Lite ミドルウェア
　　短納期HEMS開発をサポート！

GuruPlug
　　カードサイズ スマートサーバ

株式会社ジェイエスピー
　　横浜に拠点を置くソフトウェア開発・システム開発・
　　製品開発(monipet)、それに農業も手がけるIT企業