-
Notifications
You must be signed in to change notification settings - Fork 2
/
Copy pathintroduction.tex
84 lines (77 loc) · 6.53 KB
/
introduction.tex
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
% !TeX root = ./main.tex
\section{はじめに}
% what is this all about !
本論文は,プログラミング言語Juliaで記述されたプログラムを型レベルで抽象解釈することにより,
プログラム中に含まれるバグを静的に検出する解析器を提案する.
% what is julia
Julia\cite{julia}は,
Pythonのような動的型付けの高水準言語が提供するような柔軟な記述性と,
Cのような静的型付けの低水準言語を書くことで得られるようなパフォーマンス
を両立することを目指して作られた,高水準の汎用言語であり,オープンソースで開発されている.
% what good about julia
簡潔なシンタックスを用いて記述された関数は強力な多相性を持ち,
型推論やLLVMフレームワークを用いたJITコンパイルにより最適化される.
プログラマはプロトタイピングに用いたスクリプトのまま良好なパフォーマンスを得ることができるため,
"two-language-problem"
\footnote{
科学計算の場面において,開発の初期段階のプロトタイピングには記述が容易な高水準の動的型付け言語が好まれるが,
開発が進みプログラムの効率性が求められるにつれて,
もともとパフォーマンスを念頭において設計されていない動的言語のままでは期待するパフォーマンスを得られなくなり,
結局CやFortranなど効率的に動作する低級の静的型付け言語にプログラムを書き直さなくてはならなくなることが多い.
この,プログラマの生産性とプログラムの効率性の両立において生じるジレンマを,
Bezanson他は"two langauge problem"\cite{julia-2012, Julia-2017}と表現している.
}
\footnote{
Numpy\cite{numpy}に代表される,
高級な動的言語のインターフェースを通じて内部的にCやFortranで書かれたルーチンを呼び出すような
"two-tiered architecture"の試みは,two-language-problemに対する1つのアプローチであるが,
以下のような問題点を持っている\cite{julia-2012}.
\begin{itemize}
\item 並列プログラミングにおいて複雑性が増大する.
\item 常にvectorizationが求められ,不必要な一時オブジェクトの生成を避けることができない.
\item 複数言語間のインタフェースで生じるオーバヘッドにより,プログラム全体を最適化することが難しい.
\item 動作原理が複雑であり,結果としてユーザが内部を理解しそのシステムの向上に貢献することを妨げる.
\end{itemize}
}
を根本的に解決することができる言語として注目されており,
特に科学計算の場面を中心に既に多くのユーザーを獲得している\cite{julia-growth}.
また,言語のコア機能の実装からユーザコードに至るまで
レイヤーを問わず一貫したシンプルな仕組みを用いるその設計思想は,
結果として開発の容易さと拡張性の高さをもたらしており\cite{julia-2012},
% TODO:
% Juliaの設計が開発の容易さをもたらし,結果としてコミュニティの成熟が早いことにより,コミュニティの広がりを示すreference
2012年に発表された比較的新しい言語であるにも関わらず,
そのコミュニティは既に大きな広がりを見せている.
% what bad about julia (motivation)
一方で,Juliaはあくまで動的型付けの言語であり,Juliaプログラムの型安全性は静的に保証されないが,
型エラーを実行する前に検出しそのプログラム品質を高めようとする取り組みはこれまでの所試みられていない.
今後Juliaがさらに普及し,Juliaで書かれたソフトウェアの規模が大きくになるにつれ,
この問題がさらに深刻になり得ることは,現在広く使われている
他の動的言語における同様の問題意識を鑑みれば明らかであるが\cite{ruby-progress-report},
現行のエコシステムにおいては例えば単なるtypoの検出でさえも正確に行うことは簡単ではない(\ref{paragraph:syntax-analysis-limitation}).
% what we've achived
このような問題意識の下,本論文では,Juliaプログラムに対する静的解析手法の1つとして,
プログラムを型レベルで抽象解釈することにより解析を行う「型プロファイラ」を提案する.
この型プロファイラは静的解析のための追加的な型アノテーションを必要とせず,
素のJuliaプログラムに対して解析を行い,
型レベルのエラーの検出やパフォーマンスの向上に有用な情報を引き出す.
型プロファイラの実装には型推論ルーチンが必要となる.
今回の取り組みでは,
Juliaの核をなす言語機能としてJITコンパイル目的に使用されている型推論のルーチンを用いることで,
% TODO: 言い方を少し変えたい
抽象解釈を用いたプログラム解析において問題となりやすいスケーラビリティを保ちつつ,
実用的なエラー検出機能を実現することを目指している.
% structure of this thesis
本論文では,その取り組みについて以下の構成で説明する.
まずsection~\ref{section:2}では,Juliaの特徴と性質を概観し,ランタイムによらない静的解析の必要性を確認した後,
Julia以外の動的型付け言語における静的解析の取り組みを紹介する.
次のsection~\ref{section:3}でJuliaの型推論を用いた型プロファイリングによる静的解析器を提案し,
まずJuliaの言語機能として実装されている型推論システムについて確認した後,
そのルーチンを内部的に利用する型プロファイラの設計方針を説明し,
最後に型プロファイラの性質や性能について言及する.
% TODO: の簡単な命題の証明を行う.
section~\ref{section:4}では型プロファイラの性能評価を行い,
% TODO: recover this after evaluation finishes
% 本論文で提案する型プロファイラが十分に実用的であることを示すとともに,
現状で把握できている課題についても報告する.
最後のsection~\ref{section:conclusion}で本論文をまとめ,本プロジェクトの今後について述べる.