# Approximateネットワークに対する速性と計算精度の最適化基盤

- 2000年くらいから計算機は高速化を考えてきたが，クロックや消費電力などの問題があった
- そろそろこのトレードオフだけでは辛くなってきた

- ムーア時代
    - 性能/電力効率を探求
- 厳密さ
    - 数の丸め誤差
    - 複数の出力が解となるアプリ ==> Perfect Executionは不要
- ニューラルネットワークをアナログ演算回路で実現している

- 昨今
    - 不真面目な計算機*真面目なネットワーク
- データ通信帯域が増加するにつれてエラー訂正がレイテンシを低下させてしまう
- Approximate Network
    - 帯域10倍
    - 遅延増えない
    - エラー放置
- アプリによってビット誤りの許容が異なる
    - ビットの保護する場所が変動する
    - 保護するビットをマスクしてあげることで，エラーを考慮しない部分と見ていく
- 正しくない実行結果が出力されるパターンの近くを探索しない

- OpenTunerによる探索空間を定義している



# 大規模ソフトウェアにおけるコンパイル時間の定量的分析と高速化手法の提案

- 90%以上がコンパイラで締められている
- edit-compile-testのサイクルで開発を行っているので厳しい
- Incrementaal BuilDing
    - GNU Make
    - Ninja
    - CMake
- ccache
    - key-value-storeで管理している
- WebKit
    - ほぼ毎日大規模ファイルをコンパイルする必要が出てきている
- コンパイラ単体のスループットを上げる必要がある
    - 同一ヘッダーファイルのコンパイルが2千件行われている
- 再利用時には一貫性が保たれている必要がある
- Hello Worldのコンパイルが最大8.7倍

=> もともと並列性の高いものをターゲットにした場合
        --> オーバーヘッドを考える事はあまり無いのではないのか

# Christie

- ファイルシステムの問題点
    - 型がない
    - トランザクションが提供されてない
        - SQLですら厳しい
    - 分散環境でアクセス方式が定まってない
- Christie
    - Linda
- Christieの

- ファイルシステムの型
    - 不整合時にどうするかの処理を付けないといけない
- annotationを使ったput/takeのもの

- unixファイルシステムは木構造の名前管理構造を持っている
    - ファイル自体もi-nodeを使った木構造が導入されている
- トランザクションの失敗の扱いを上手い具合にする




- メモリ自信のハードエラーは提案論文が少ない

# カーネル内部データのプロセス間分離による堅牢性の向上

## Kernel Failure

- エラー伝搬が発生するとKernel Failureを引き起こす可能性がある
- プロセスコンテキストに閉じて発生する
- プロセスローカルデータ(単一のプロセスコンテキストで使用されるデータ)
    - カーネル内で共有するデータにエラーが伝搬した場合修復が難しい
- プロセスを強制終了させることでプログセスコンテキストを切り離す事ができる
- Software failer
- 'プロセスローカルエラー'


# 耐ビザンチン障害性を持つ分散合意手法の調査

- 決済システムなどでブロックチェーン技術が利用されている
- PoW
- PBFT ( Practical Byzantine Fault Tol)
    - http://pmg.csail.mit.edu/papers/osdi99.pdf
- "スループット"
- rsocketをもちいた場合

[[Perl6]]

* 具体的に遅い箇所を計測した方がいい
* どうやって計測を図るか
* コンパイラ構成論の資料を読んでオブジェクトパターンを理解しておく

- Key Value Store