Mercurial > hg > Members > anatofuz > slides
view slides/2018/06/05/memo.txt @ 47:32e35be2ce71
auto-Update generated slides by script
author | Takahiro SHIMIZU <anatofuz@cr.ie.u-ryukyu.ac.jp> |
---|---|
date | Tue, 26 Jun 2018 22:41:26 +0900 |
parents | |
children |
line wrap: on
line source
MoarVMが実際にインタプリタとして走っているのはMVM_interp_runという関数らしい. これはスレッド毎に用意されるらしい 定義自体は `src/core/interp.c`に書かれている MVMInstancとかいう構造体に全ての情報が入っている MVM_cu_map_from_fileでスレッド情報とファイルから生成した結果をMVMCompUnit構造体として生成している DISPATCHでNEXT_OPを判断している,これはオペランドリストとswitch文が同じオーダーで書かれているので 最適化しやすいらしい MVM_interp_runの後DISPATCHというマクロでNEXT_OPというマクロに応じて処理を行っているが これがMoarVMのバイトコードを一対一対応しているので5000行のcase文が生成されている --- - Ruby のJITはunreadableなので,とりあえずCbCで実装しても良いのでは - ()の中にいるなどの情報 - コンパイラをデーモン化してオブジェクトファイルなどを共通化 - パースの並列化 - パースに当てられる箇所 - gccのパスは50個くらい,その内の1つがパーサーっぽい - FileIOを食う例題とFileIOを食わないでCPUを食う例題 - HTMLジェネレーターとかでも良いのでは - Perl5 to Perl6的なのは無い? - Rustのメモリ管理周り - Perl5との互換性? - JIT - MoarVM ByteCode - 実測する!!! - Perl5からMoarVMに変換するスクリプトを作成する!? - JIT - 並列処理 - パイプライン処理(コンパイラ) - 前段の処理を止めないといけない - 1つのコンパイラがCPUを異常に使うと帰って遅くなるのでは?? - ローカルな作業を分割しても全体としては遅くなるのでは? - JIT - アプリケーションをCbCで書く - それが早くなるまでチューニングする - 最初はコンパイルしちゃって良いのでは? - いきなりCbCを吐く感じにする - (いかに早い正規表現を書くか) - 作った文だけメモリをallocateして返却しない(linear memory) - 一旦メモリを保存させて渡す(OBject table, OBlist) - Copying GC conversation - incrementalに出来ない為,中途半端にコピーされた状況になる可能性がある - 1MBのファイルを読み込んで処理するレベルではGCがそんなに走らないので無視しても良いのでは…!? - GC memory allocate