サイボウズラボユース中間結果発表会アウトラインメモ
サイボウズ・ラボユース 「中間成果報告会」に参加してきたのでそのときのメモです。
かなり乱雑なメモで正確性など存在していないので、そのまま読まない方がいいです。
(特に手元でスライドがあるわけじゃないので、ちゃんとメモれてすらないです…)
環境記録
メモソフトウェア: bodhi/MarkdownEditor – GitHub
サイボウズラボユース中間結果発表会
NDAは結ばずに、成果をオープンすることを条件に支援を行う。
「ロボット制作を支援するログ解析プログラムの開発」 by @sn_monochr {#bysn_monochr}
マイコンカー
赤外線センサーを使ってリアルタイムで制御するカー。 C言語で開発を行う。
マイコンカーの走行ログ
走行ログ
- 制御プログラムの動作状態
- 赤外線などのセンサー状態
メモリが限られているので、データはシフト演算などを使って一つにまとめて保存、送信を行う。 これらのデータを可視化していくため、解析ソフトウェアを開発する。(Windows)
走行ログの可視化
- データに基づいたマシン調整が可能になる
- 1つのソフトウェアに統合
夏の合宿
目標設定をして合宿を行った
- 走行ログの可視化
ラインの中でモードの変更をライン色の変更してる。
- 無線通信でログのやり取りをするのが今後目標
走るコースに、車線変更や直角カーブなどのマークが書かれていて、それを読み取ってモードを変えることで動きを変える。
「世界最速の正規表現JITエンジンの実装」by @sinya8282 {#jitbysinya8282}
- 正規表現エンジンの作成
- 正規表現の歴史は古い 1960~
-
- 実装はたくさんある
-
- いろいろやられている
「正規表現エンジンの開発」には意義があるのですか? -> 車輪は車輪でも「最速の車輪」を開発する
正規表現エンジンRegen(れーげん)の開発
Regen {#regen}
動的コード生成
- Xbyak でJIT regex
- 正規表現に合わせて、プログラムがプログラムを生成する
- 正規表現コンパイルに最適化レベル導入(O0 – O4)
-
- 最適化しにくいパターンもある
マッチング並列化
- 並列化のための特殊なモデルを実装
ベンチマーク
Google RE2との比較。
JITしても3-5倍の高速化 -> 今はメニーコアの時代 -> 正規表現の並列化
- 6コアでガクって落ちるのはアーキテクチャの問題
まとめ
高速化の二台手法は実装した、成果もでた
- JIT
- 並列化
これからの課題
- 実システムへの応用、ツールの作成
- 正規表現エンジンじゃないと処理できない問題
-
- なければ作る
- ライブラリとして今夏中に整えたい
質問
- 正規表現 <-> インデクシング
- フィルターなどの分野では、流れるデータに対して正規表現の活用などもある。
- 禁止ワードのORつなぎみたいなものは正規表現より向いてる方法があるとか
「JavaScriptによる型推論器の実装と可視化」by takuto_h {#javascriptbytakuto_h}
型推論
- 型を書かなくて楽
- 型があるんで安全
引数の型
function foo(bar){ return bar + 1; }
どのような演算子を呼んでいるかを見て、型を推論する
型推論は方程式
- 値が広志位なら型が等しい
- 方の上での方程式を集めて解くのが型推論
コンピューターでは解くのか
a = b, b = c, c = d, d= int
<a>, <b>, <c>, <d>
というオブジェクトとintという物体を用意する。
- a = b で
<a : <b>>, <b>, <c>, <d>
- b = c で ….
どんどん置き換えて行って型推論を行う。
Ibisという型推論機 {#ibis}
IbisはJavaScriptで書かれている。
- まずはパースして構文木にする
- ここからステップごとに型推論の計算(推論)を表示
- 最終的に、関数の入力と出力の型推論結果が表示される
型推論はパズル
質問
型推論にとってオブジェクトは鬼門
Q . 循環参照の時はどうするの?
2つの考え方
- 禁止する方針
- 再帰的なものも許す方針
OCamlは不健全な循環参照は禁止されている。 再帰的なものはチェックを付けて型推論を続ける。
演算子のオーバーロードがあると型推論はむずい
「世界で一番仕様に忠実なJavaScript処理系の作成」 by Constellation {#javascriptbyconstellation}
iv/lv5
- ESのパーサーiv
- エンジンlv5
sputniktestというECMA262への正確性を測るテスト
- 以前はASTはインタープリンタ
- VMに変えたのでECMAエンジンといえますね。
- インタープリタと共存している(オプションで切り替えが可能)
JITをモジュールとして取り込めるのではないかと。
高速化
いろいろ。11倍近く高速
まだJITはしていない。
今後
- RegisterVmについての検討
- GCの自作
az: ECMAScript Analyzer {#az:ecmascriptanalyzer}
JavaScriptの補完候補を出す
型の推論 Doctorjs {#doctorjs}
- 抽象的なAbstractインタプリターを使って型情報を集めている
- これを元にC++にした
JavaScriptは後ろに関数宣言置けるし、補完するときにシンタックスは壊れてるからどうするの?
方針: シンタックスが不正なASTに対して解析を行う {#ast}
- シンタックスが不正なスクリプトでも常にASTを得る
target.
こういう時はに解析を行うと、式がエラーになるので、ここでステートメントにマークを付ける。
改行があったらそのへんは大丈夫なんじゃないかと、してぶっちぎる。 JavaScriptにはセミコロン自動挿入があるので、改行を判定に使う必要性が出てくる。
問題点
- Abstractインタープリタは状態が有限でないと終わらない
- なので状態を有限して、行う
- jQueryとのfor inとかむず
WebStromの場合
- JSDocで型情報を読んでこれを基準に解析
- 元に情報を用意して何とかする方向
おわり
仕様忠実は第一
「現役高校生の考えるクラウドOSの設計と実装」by liva_s {#osbyliva_s}
クラスドOSって何だろう? {#os}
Googleの場合
- ブラウザ上でWebアプリを走らせている
- 確かにクラウドを利用している
僕の考えるクラウド化
カーネルのクラウド化
- カーネルがやるべきことをクラウドサーバー上で一括処理するのはどうだろか?
- サーバー側に処理を置くことで、クライアント側の負荷が減る
カーネルを分割して、クラウド上でカーネルが動いてるいうという状態
- 当然ローカルでやるべきことも残る(ハードウェア制御)
- ローカルとくらうどの線引きが大事になる
どの境界線はどう測るべきものかがわからない(ベンチマークで?)
マイクロカーネル開発
カーネルには最小限なものにして、Serverというアプリケーションにわけてやるもの。 この時のServerをクラウドに乗っければ、クラウドOSになる。
=> マイクロカーネルの開発がいいのではないかと
Serverを単位にして、ローカルとクラウドでベンチマークを取れば、境界線がわかりやくなる。
モジュール開発とマイクロカーネル
モジュールはプロセス管理を作る前に、モジュールを開発できる。 (後で動かせばいい)
まとめ
クラウドOSはWebアプリベースのOSではない
Q. カーネルでどの辺がボトルネックになってるのか?
A. モジュール化していけばベンチは測りやすいから、これからは。
カーネルのモジュール化はダイナミックに構成を変更できるということが結構面白い事になる
Q.マルチキャストの逆みたいな話。同じような処理をしてるコンピューターはいっぱいあるから、そのへんの処理を効率ができるのではないかと
お知らせ欄
JavaScript Primerの書籍版がAmazonで購入できます。
JavaScriptに関する最新情報は週一でJSer.infoを更新しています。
GitHub Sponsorsでの支援を募集しています。