これからのコンピューティングの変化とこれからのプログラミング at 広島

これからの
コンピューティングの変化と
これからの
プログラミング
2018/6/9 きしだなおき

自己紹介
● きしだなおき
● LINE Fukuokaで働いています
● プログラミング言語は主にJava
● Twitter:@kis

今日の話
● プログラマが知っておくこと
● ここ最近の変化

プログラマが知っておくこと

プログラマが知っておくこと
● コンピュータサイエンス
– プログラムとはなにか
– 広義にはここに挙げてるものを全部含む
● ソフトウェア工学
– プログラムをどう作るか
● アーキテクチャ
– プログラムをどう動かすか
● UI/UX
– ...

コンピュータサイエンス
● 計算理論
● アルゴリズム
● データ構造
● ラムダ計算
● 型理論
● コンパイラ
● etc…

アーキテクチャ
● プロセッサ
● メモリ
● ストレージ
● ネットワーク

ソフトウェア工学
● プロジェクト管理
● プロセス
● 設計手法
● プログラミング言語
● テスト

ムーアの法則
● 18-24ヶ月でトランジスタの数が倍になる
● 寸法半減→スピード2倍、消費電力1/4
https://en.wikipedia.org/wiki/Moore's_law

ムーアの法則の終焉
● 物理的に配置できない
– 5nm=水素原子50個分
● 電子が漏洩する
– 電気を余分に消耗する
● 歩留まりがあがらない
– 製造コスト増

微細化が進んでも今までとは違う
● コストが下がらない
● 低消費電力と高速化を同時に実現できない
● たくさん回路をつんでも、発熱の問題ですべての回路
に電気を流せない
– ダークシリコン問題
● 電力あたりで動かせるトランジスタ数が決まって...

処理を速くするには
● CPUを載せ換えたら勝手に速くなる時代は
10年以上前に終わった
● 並列度をあげる
● より近いところにデータを置く
● 処理に適した計算ユニットを使う

コンピュータの種類
● 古典コンピュータ
– ノイマン型アーキテクチャ
– 非ノイマン型アーキテクチャ
● 量子コンピュータ
– 量子アニーリング
– 量子ゲート

ノイマン型アーキテクチャ
● メモリから命令をよびだして、命令にしたがっ
た回路で処理を行う
● CPU
● GPU

CPU
● 高機能・高性能・高粒度
● 割り込み、権限制御、仮想化、など実行以外の機能
● OSが実行できる
● 演算器はコアあたり10個程度
– 一チップに100個程度
● コアは多くて数十コア
● 明示的にメモリを制御できない
– いかにキ...

GPU
● GPU
– ちょうたくさんコアがある
– 同じ処理を行う
– 行列計算に向いてる
● GTX 1080Ti
– 3584コア！

GPUの構成
● いくつかのコアでグループを作る
– 同時に同じ命令を実行する
– グループだけからアクセスできるメモリをもつ
● 明示的にデータを転送する
● コアのグループが多数ある
● コアあたり数個の演算器
– 数千から数万の演算器

非ノイマン型アーキテクチャ
● ノイマン型では命令の読み込みや解析にトランジス
タを使う
– 電力を食う
– やりたいこと通りに演算器を並べればいいじゃない
● ノイマン型じゃないコンピュータ全体
– FPGA
– ニューラルネット型コンピュータ

FPGA
● Field Programmable Gate Array
– Field 現場で
– Programmable プログラム可能な
– Gate 論理素子が
– Array いっぱい並んだやつ
● 現場でプログラムできる論理回路

回路の入出力の組み合わせ
入力出力
000 0
100 0
010 0
110 1
001 1
101 1
011 1
111 1

LUT(LookUp Table)
● 入出力をあらかじめメモリにもっておく
● 製品としては4入力LUTや6入力LUT
入力出力
000 0
100 0
010 0
110 1
001 1
101 1
011 1
111 1

論理ブロック
● Logical Element(LE) Altera
● Logical Cell(LC) Xilinx

配線
● 論理ブロックが格子状に配置
● 周囲に配線
● アイランドスタイル

乗算回路とメモリ
● 乗算やメモリを論理ブロックの組み合わせで
実現すると効率がわるい
● 乗算回路やメモリ(SRAM)がのってる
– 演算器は数百から数千

FPGAなら
● 命令を読み込む必要なく、回路をやりたい
処理のとおり並べることができる

FPGAの利点
● 命令を読み込む必要がない
– 処理を行うまでのタイムラグが少ない
● 低レイテンシ
– 命令解析のための回路が不要
● 余分な回路がないので低消費電力
● 細かな並列化

ディープラーニング(深層学習)
● 階層の深いニューラルネット
● 最近、人工知能っていわれてるのは、ほぼこれ
● 学習には大量のデータを処理する必要がある
● 計算的には行列の積和演算
– ab+c

機械学習用演算器
● Google
– Tensor Processing Unit(TPU)
● NVIDIA
– Tensor core
– 4x4行列積和演算
● FPGAなら？
– ネットワークをそのまま回路にできる(かも)

量子コンピュータ
● 量子効果を計算原理に使う
● 通常のコンピュータを古典コンピュータという
● 0と1の重ね合わせの状態をもつ
– 古典コンピュータは0か1かを状態としてもつ

量子コンピュータの種類
● 量子ゲート型
– 量子ビットで論理計算を行う
– 8ビットのすべての組み合わせの処理を行うとき
● 古典コンピュータだと256回繰り返すか256回路必要
● 量子コンピュータだと256パターンの重ね合わせについて一度...

量子コンピュータの使い道
● 化学計算
● 暗号が解読できるかも？
● 機械学習？

量子耐性暗号
● 量子コンピュータでも解読されない暗号
● 格子暗号など

メモリの変化
● 不揮発メモリ(Non-Volatile Memory:NVM)の
実用化
● Intelの3D XPointなど
– 相変化型メモリ
● DRAMより大容量
● NANDフラッシュより速い

NVMでどうかわるか
● データベースの高速化
– データベースが不要になる？
● 超省電力コンピュータ
– 実行時だけ電気をとおす

データベースとは
● クエリ言語エンジン
● インデクサ
● トランザクション管理
● ブロック型ストレージ管理
● クラスタ管理

言語間でメモリを共有できるか
● NVMに乗せたデータをいろいろな言語で
使いたい
● いちいちシリアライズしたくない
● 言語共通のモデルが必要

GraalとTrufe
● Graal
– Javaで書いたJava JITコンパイラ
● Trufe
– 構文木処理エンジン
– 言語処理が書きやすい
– 言語共通オブジェクトモデル
● Object Strage Model(OSM)
● ...

インフラの変化
● サーバー群の構成の変化

クラウド
● 多数のサーバー
● PaaS(Platform as a Service)
● IaaS(Infra as a Service)

サーバー構成自動化
● 多数のサーバーを手作業で構築できない
● サーバー構築をスクリプト化する

仮想化
● サーバー仮想化
– OSの上で仮想マシンをたてて別のOSを動かす
● ネットワーク仮想化

コンテナ
● サーバー仮想化には目的に対して無駄が多い
● OSカーネルを共通化してファイルパスや
ユーザー、ファイルディスクリプタなど
サーバーリソースだけ隔離
● プロセスごとにコンテナ化もできる

マイクロサービス
● サーバーの構成の自由度があがった
● 機能ごとにサーバーを立てれる
● プラットフォームの自由度があがる
– 基本はJavaだけど課金管理だけGoで書く、など
● 監視やトレースの重要度は上がる

サーバーレス
● リクエストがきたときだけプロセスが起動
● つまりCGI
● (アプリケーション)サーバー(プロセス)レス
● メモリ管理や死活管理が不要
● リソース割り当ての自由度があがる

コンテナオーケストレーション
● 多数のコンテナが必要になる
● コンテナの管理
● Kubernetes
● 監視やトレースなどを仕込める
– 通常はフレームワークごとに設定が必要
● サーバー構築の自動化からサーバー群構築の自動化へ

ソフトウェア工学的変化
● ハードウェアやインフラが変化
● プログラムの作り方も変化

自動テスト
● 関数単位でプログラマが関数によるテストを
書く

CI
● 継続的インテグレーション
– (Continuous Integration)
● ビルドプロセスの自動化
● 自動テストなどを組み込む
● 頻繁なビルドが可能に

Github
● Git
– 分散バージョン管理
● PullRequestによる機能実装の管理
● PullRequestを取り込むときにコードレビュー
● GitにcommitがあったときにCIでビルド・テスト
● なんならそのままデプロイ

SRE
● Site Reliability Engineering
● 運用と信頼性向上を行う
● インフラがソフトウェア化
● 開発作業も自動化
● 全部プログラマができる

プログラミング言語の変化
● 開発マシンや開発対象の変化によりプログラミ
ング言語にも変化

オブジェクト主体から関数主体へ
● Javaにもラムダが！(Java 8)
● GUIからWebへ
– 状態管理からリクエスト管理へ
– ステートフルからステートレスへ
– オブジェクトから関数へ
● メモリ容量が増える
– メモリを使い回す必...

型推論の普及
● Javaにも型推論が！(Java 10)
– 正確にはいままでないと言われていたのは
ローカル変数型推論
● 型が複雑になり、手書きしにくくなる
● 型理論の進化
● コンパイルの高速化

型がなぜ重要か
● B foo(A a) があるとき C baz(A a) を作れる？
C bar(B b)
– つくれる
●
C baz(A a) { return bar(foo(a)) }

カリーハワード同型対応
● 鮭は魚があるとき鮭は泳ぐといえる？
魚は泳ぐ
● 魚 foo(鮭 a) があるとき泳ぐ baz(鮭 a)を作れる？
泳ぐ bar(魚 b)
● 型と論理は同型
● 型によるプログラムは論理の証明

並列処理対応
● マイクロサービスや外部サービス連携など
サーバー連携の増加
● 待ち時間の増加
– スレッドが無駄に
● ノンブロッキングによるスレッドの効率利用
● リアクティブプログラミング

データによるプログラミング
● 機械学習では学習データの質・量が大事
– データをたくさん集める
– データを適切に前処理する
● 投入データで同じニューラルネットでも処理が
変わる

ユーザーインタフェースの変化
● 機械学習による言語処理性能や画像・音声認識
性能の向上でインタフェースにも変化

チャットボット
● LINEなどチャット上での対話によりプログラ
ムを実行

音声インタフェース
● Clova WAVEやAlexa、Google Homeなど音声
で操作できるスマートスピーカの普及
● 音声で照明やエアコンなどの操作

Virtual Reality
● ヘッドマウントディスプレイでの没入感
● ジェスチャーによる操作

まとめ
● コンピュータは変わる
● みんなも変わろう

これからのコンピューティングの変化とこれからのプログラミング at 広島

なおき きしだ

これからのコンピューティングの変化とこれからのプログラミング at 広島

なおききしだ