Thread by @genkuroki

#Julia言語

Juliaでの最適化では、函数の定義で

function f(x::Float64)::Float64
～
end

のように「型指定」しても全然__速くならない__ことを理解しておく必要があります。

function f(x)
～
end

のままで最適化できることを知らずに、一所懸命「型指定」するのは時間の無駄。

#Julia言語 函数の引数の「型指定」をするのは、multiple dispatchを使うためです。例えば

function f(x)
広く通用するアルゴリズムのコード
end

と定義しておいて、Float64専用の同名の函数を

function f(x::Float64)::Float64
Float64に最適化されたコード
end

と定義するとよい。

#Julia言語 しかし、

function f(x)
広く通用するアルゴリズムのコード
end

の段階で十分高速なコードを書ける場合も多いです。

それを可能にするのが、型の伝搬を促すコードの書き方です。

Juliaでは「型指定」ではなく、「引数の型の伝搬」で考える。

#Julia言語

f(x) = 2x

と

g(x::Float64) = 2.0x

のとき、

f(3.0)

と

g(3.0)

は完全に同じネイティブコードにコンパイルされてから実行されます。g(x::Float64)の「型指定」はこの場合には意味がないです。

こういう仕組みになっているので、「型指定」は多くの場合に時間の無駄になります。

#Julia言語

Juliaでは、初心者が素朴に書きそうな

f(x) = 2x

型のコードの書き方が合理的で

g(x::Float64)::Float64 = 2.0x

のような無駄な「型指定」入りにコードを書くのは不合理です。

#Julia言語 「型指定」がないと最適化されたコンパイルが不可能だという誤解が蔓延している。

Juliaのようなjust-in-timeでコンパイルする仕組みなら、実行時の引数の型の情報をコンパイラが利用できるので、函数の引数の「型指定」が無くても、コンパイラは引数の具体的な型の情報を利用できます。

#Julia言語 例えば抽象型Realで引数が型指定されている

function f(x::Real) ～ end

を

f(3.0)

の形で実行するときには、JuliaのコンパイラはRealという抽象型の情報を使ってコンパイルせずに、引数3.0の具体的な型であるFloat64という情報を使ってネイティブコードにコンパイルします。

#Julia言語 f(x::Real, y::Real, ...)のx,y,zとして可能なものすべてに対応できるように前もってコンパイルしておくのではなく(一般に非常に大変なことになる！)、具体的な値を持つx,y,zが与えられた後にそのx,y,zの具体的な型に応じて最適化されたコンパイルを実行する仕組みにJuliaはなっています。

#Julia言語 函数の引数の具体的な型の情報をJuliaのコンパイラは利用できる。

だから、函数の引数以外の変数に型が、函数の引数の方から自動的に決まってしまうようにコードを書けていれば、Juliaはよく最適化されたネイティブコードにコンパイルしてくれます。

これが基本中の基本！

#Julia言語 具体的な型が不明のモノが函数のコードに混じっていても、Juliaはその函数を実行してくれます。

速度だけが重要ではなく、速度はどうでもよい場合もあるので、そういう仕様はありがたいと思います。

具体的な型が不明になるモノも代表例がグローバル変数。速度が重要なら使っちゃダメ。

#Julia言語

具体的な型が不明になるモノの2つ目の代表例は中身の型が抽象型(型指定されていない場合を含む)のstructです。例えば

struct Foo
a::Array{Float64}
end

はアウト。

struct Foo
a::Array{Float64, 1}
end

もしくは

struct Foo
a::Vector{Float64}
end

とする必要あり。

#Julia言語

struct Foo
a::Vector{Float64}
end

だと、中身がVector{Float64}型で決め打ちされてしまい、Juliaの多くの便利なパッケージと組み合わせて使えなくなります。

Juliaでは基本的に「型指定」をすると損になることが多いです。

#Julia言語 Juliaでも「型指定」を無駄な制限が起こらないようにすることはできます。しかし、そのためにはJuliaの型システムの深い理解が必要になって、一般ライトユーザーには厳しい。

しかししかし、一般ライトユーザーが手抜きをしながら、計算効率を落とさない方法もあります。続く

#Julia言語 それは

struct Foo{A}
a::A
end

のように書くことです。

Foo(3)

とすると、3の型Int64が自動的に認識されて

Foo{Int64}(3)

が作られ、

Foo([1.0, 2.0])

は

Foo{Vector{Float64}}([1.0, 2.0])

になります。

Juliaのコンパイラにstructの中身の型が見えるようになる！

#Julia言語 structについても、コンストラクタの引数の具体的な型から型のパラメータが自動的に決まるように(型情報が伝搬するように)書けば、ユーザー側がVector{Float64}のような型名をコード中に書く必要がなくなります。

「型指定」がない部品の方が広く使えるので便利な場合が多いです。

#Julia言語 「前もってすべてをコンパイルしておくので、実行時の状況に合わせてコンパイルできない」という状況では「型指定」がどうしても必要になりますが、「実行直前にコンパイルする」という仕様ならば、「型指定」がなくて「型の伝搬」が保証されている方が便利です(structも含めて！)。

#Julia言語 初期化されていない配列も

A = Array{Float64, 3}(undef, l, m, n)

のように型名を書いて作る必要はなくて、

A = similar([0.0], l, m, n)

のように、Xと似ているサイズ(l, m,n)のモノのsimilar(X, l, m, n)を使える。引数xが配列と期待される函数内なら

A = similar(x)

も可。

#Julia言語 計算速度が気になる人は、公式ドキュメントの

docs.julialang.org/en/v1/manual/p…
Performance Tips

に忠実なコードを書くのが最も楽な道だと思います。

前もってすべてをコンパイルするという縛りに過剰適応してしまったスタイルを訂正するためにも上のTipsは役に立ちます。

#Julia言語

共通のパラメータをグローバル変数で与えたくなる気持ちは分かるのですが、やめた方は良いです。

問題を記述するパラメータを入れておくstructを

struct FooProblem{A,B,C}
a::A
b::B
c::C
end

のように定義しておいて、そこにパラメータを入れておいて～続く

#Julia言語 続き～、問題を解く函数を

using Parameters

function solve(foo::FooProblem, x, y)
@ unpack a, b, c = foo
～a,b,cを使って問題を解くコード～
end

のように書くというスタイルがJulia界では普及していると思います。

#Julia言語 Juliaでなくても、共通のパラメータをグローバル変数にしたりせずに、コードの形で

* 問題そのものの記述
* 問題を解く方法の記述

をきちんと行う方が、見易いコードになり、広く使い易える部品ができ上がるので好ましいと思います。

#Julia言語

docs.julialang.org/en/v1/manual/p…

でも in-place というキーワードで軽く説明されていますが、配列などを使う場合には無駄なメモリ割当をループ内ですると速度的な劣化が激しくなる。

それを防ぐ方法はあるのですが、経験がないと対処できない場合が結構あると思います。質問すると良いです。

#Julia言語

例えば、配列 v の時間発展を

for i in 1:n
v = update(v)
end

のように書くと、update(v)の結果の配列へのメモリ割当がループ内でn回起こります。

一回限りしか使わないコードならそれでも良いと思いますが、ライブラリとして使うコードだと速度劣化がつらいです。続く

#Julia言語

function update!(v)
配列vの中身の書き変え
end

function～
～
v = 初期条件
for i in 1:n
update!(v)
end
～
end

なら、ループ内でvの中身が書き変わるだけで、配列へのメモリ割当が繰り返されません。

#Julia言語 モンテカルロ法でループの内側で配列の乱数を発生させる場合にも同様の注意。

for i in 1:niters
a = rand(n)
～
end

と書くと、rand(n)の分のメモリ割当がniters回発生します。

処方箋↓

using Random

a = similar([0.0], n)
for i in 1:niters
rand!(a)
～
end

#Julia言語

基本原則: !付きの函数を利用できるなら、そうした方がメモリ効率が良くなる。

しかし、どういう!付きの函数があるかはすぐにはわからないと思う。現時点では、知っていそうな人に聞いた方が早い場合が少なくないと思う。

#Julia言語 あと

sum([f(x) for x in X])

は [f(x) for x in X] の配列の分だけメモリ割当が起こるのでやめた方がよいです。

sum(f(x) for x in X)

もしくは

sum(f, X)

と書くべき。

メモリ割当が発生する書き方とそうでない書き方があって、理解が伴っていれば暗記は必要なくなる。

#Julia言語

sum(f, X) 型の函数は沢山ある。

mean(f, X)
maximum(f, X)
minimum(f, X)
...

count(f, X)
all(f, X)
any(f, X)
...

https://twitter.com/genkuroki/status/1348751982408867843

#Julia言語

計算速度を気にするときにやってはいけないのは

a = []

よく見るのが、a = [] としてから、push!やappend!で内容を追加しようとする行為。計算速度が重要な場合には良くないです。

a は要素がAny型の空の配列になり、aを使うごとに計算速度の劣化が引き起こされます。

#Julia言語

作りたい配列のサイズ n が前もって分かっているなら、

a = similar([0.0], n)
for i in 1:n
a[i] = f(i)
end

とか

a = f.(1:n)

のようにした方がお得。

一挙に必要サイズ分の配列を作った方が速い。

#Julia言語

最終サイズが不明の場合は

a = similr([0.0], 0)
for i in 1:n
if c(i)
push!(a, f(i))
end
end

とか

a = [f(i) for i in 1:n if c(i)]

とか。

速度が重要なら

* 最終サイズが既知の場合には一挙に配列を確保。
* 未知の場合はpush!を使う。
* a=[]は避ける。

#Julia言語 速度が重要でない場合には、細かいことを気にする必要はない。効率の悪いコードを書いてもJuliaはきちんと仕事をしてくれます。←これ、実は結構ありがたい。

#Julia言語 インタラクティブにJuliaを使っていて、Vector{Any}やVector{Real}型の配列を間違って作ってしまっても、内容の具体的な型が全部同じなら、

a = Vector{typeof(a[begin])}(a)

のようにして変換してから、aを使えば速度の劣化を防げます。

#Julia言語

a = Real[1, 2, 3.0, 4.0]
↓
4-element Vector{Real}:
1
2
3.0
4.0

a = Vector{typeof(a[begin])}(a)
↓
4-element Vector{Int64}:
1
2
3
4

#Julia言語 Julia側からstructの中身の型がどう見えているかは、fieldtypes(typeof(foo)) のようにすれば分かります。AnyやRealのような抽象型があると速度的劣化が生じる場合が出て来る。

Chain.jl 結構便利。

|> という記号法にこだわるのをやめた方がスッキリする場合がある。