Name binding 是一個將資料或是程式碼綁定(binding)到識別符(identifiers)的一個過程。一個識別符綁定到一個物件代表這個識別符會參考(reference)某個物件。
Name binding 在程式語言中式相當重要而複雜的一個議題,而它牽涉到作用域(scope)的問題,物件存在於程式碼的位置(語意)及物件的生命周期(時間)。
繼續閱讀Name binding 是一個將資料或是程式碼綁定(binding)到識別符(identifiers)的一個過程。一個識別符綁定到一個物件代表這個識別符會參考(reference)某個物件。
Name binding 在程式語言中式相當重要而複雜的一個議題,而它牽涉到作用域(scope)的問題,物件存在於程式碼的位置(語意)及物件的生命周期(時間)。
繼續閱讀很多人在寫程式的時候會有些壞習慣,如:
1 | X = rand(3, 4) |
可能多數人看以上這段程式碼並沒有什麼特別的感覺,但是如果要維護的時候就會發現你突然不太理解這段程式碼。
有人知道這邊的 3
是什麼意思嗎?嗯…或許可以從上下文猜出來是陣列的列數的意思。
一旦要更改陣列的大小的時候勢必就要更改這些數字,甚至這些數字散落在程式碼的各個角落就會更加頭痛。
這些數字稱為魔術數字(magic numbers),因為沒有人知道他的意義是什麼!
如果這些數字很常被使用到,而且不會在程式中被變更,請使用常數,像:
1 | const ROWS = 3 |
如此,以後要更改陣列大小只需要更改常數即可,也讓程式碼的可讀性上升。
如果你的程式會更改到這些數字,那麼就用變數。
1 | rows = 3 |
如果陣列的大小不是事先知道的,或是需要動態取得,那麼可以用 size
:
1 | for i = 1:size(X, 1) |
如此可以用在未知大小的陣列上。
有在做套件開發的開發者們應該不陌生 @inbounds
這個 macro,在很多現代程式語言中也有。
在存取陣列時,為了安全性與正確性的考量,避免存取到陣列範圍以外的記憶體位置,很多語言都設置了邊界檢查(bounds check)。
邊界檢查會檢查所存取的索引值是否在陣列的範圍內,但是這樣的檢查會有些微的效能損耗,尤其在迴圈內的情況更有可能被累積而放大,關於 Julia 的 邊界檢查可以參考官方文件 Bounds checking。
如果可以確定所存取的索引值一定在範圍內,我們就可以把邊界檢查給移除,以加速陣列的存取。如以下範例:
1 | A = rand(3, 4) |
或是
1 | A = rand(3, 4) |
@inbounds
會將程式碼區塊中的邊界檢查給移除,可以參考 @inbounds
的官方文件。使用時必須注意存取的索引值,否則小則存取的值錯誤,大則可能導致程式崩潰。
先養成好的索引習慣,再考慮將效能提升,加入 @inbounds
。相關的資訊也紀錄在官方的效能建議中。
剛好看到一些跟編譯器相關的議題,所以來紀錄一下。
在一些語言中會有行內函式(inline function)的設計,使用的話一般會讓程式的效能變好。
最知名應該是 C 跟 C++ 的 inline
。
Inline function 會在編譯時期直接將函式內容展開到程式碼中,不過展開與否是由編譯器決定的,inline
的標記只是告訴編譯器這個函式可以成為 inline function。
Inline expansion 就是編譯時期會由編譯器執行的一個動作,看起來與 macro expansion 相似,但不同的是 macro expansion 是在前處理(preprocessing)時期做的,會直接展開在原始碼裡頭,而 inline expansion 則是在編譯時期做的,會在呼叫位點(call site)直接展開。
展開後編譯器便可以進行最佳化,執行時,就不需要做函式呼叫,也不會在 function stack 上多配置空間。一般使用在短小的函式上會有好處,在巨大的函式上使用不一定會有好處。然而過多的 inline function 反而可能造成過多的指令快取的消耗,造成反效果。
在 Julia 中,編譯器會自動偵測哪些函式可以被展開,會自動做 inline expansion。一般短小的函式會自動被編譯器判定要 inline,不過也可以由程式設計師自己指定哪些巨大函式可以 inline,可以參考[文件]](https://docs.julialang.org/en/v1.2/base/base/#Base.@inline)。
除了 @inline
以外,還有 @noinline
。為了避免過多的 inline 反而傷害效能,也可以標記一些短小的函式不要 inline。
範例:
1 | @inline function bigfunc(x) |
我們來實驗看看,以下有兩個函式,foo
跟 bar
。其中讓 foo
為 inline。
1 | julia> @inline foo(x) = 3x |
你會發現在 lower 的階段仍保留有 foo
的函式呼叫的過程,但是到了 typed 的階段就已經剩下計算的部份了。
所以其實在進入 LLVMIR 以前就已經先做完 inline expansion 了。
相關技術:Inline caching
來分享一下最近貢獻開源專案的小心得,雖然我自己貢獻開源專案的次數跟時間不是很多,不過一個 PR 可以產生不少文字跟討論算是值得紀錄一下的。
我自己在 Julia 的一個統計相關的專案上發了一個 PR,希望補齊在標準化上的一些功能,並且可以支援一維的陣列標準化。
繼續閱讀之前介紹過將值放在參數型別上。
今天來介紹一下如何可以做到類似運算的效果。
1 | struct A{T} |
在一些應用場景上會希望將參數欄位上的值做運算,例如加總。
這時候我們可以這樣做:
1 | import Base:+ |
如此一來,就可以簡單搞定囉!
1 | println(a1 + a2) |
1 | A{8}() |
我在使用的時候有注意到在參數化型別中使用值的方式與傳統封裝的方式有效能上的差異。
所以我就做了一些測試。
在參數化型別中使用值:
1 | struct A{T} |
傳統型別封裝:
1 | struct B |
全文出現的程式碼為實際測試程式碼
因為 Julia 有提供好用的 @code_llvm
及 @code_native
來觀察一行程式碼實際被轉換成 LLVM 或是組合語言的時候會產生多少行的程式碼,藉此我們可以用低階程式碼來評估是否有效率。程式碼的行數愈少是越有效率的。
我們來測試一個物件被建立需要多少行的程式碼。
1 | 5}() A{ |
1 | ; @ REPL[1]:3 within `Type' |
1 | 5) B( |
1 | ; @ REPL[1]:2 within `Type' |
1 | 5}() A{ |
1 | ; ┌ @ REPL[1]:3 within `Type' |
1 | 5) B( |
1 | ; ┌ @ REPL[1]:2 within `Type' |
接著測試從物件當中取值出來的效能。
定義取值的方法:
1 | get_value(::A{T}) where {T} = T |
事先建立好物件:
1 | a = A{5}() |
1 | get_value(a) |
1 | ; @ REPL[8]:1 within `get_value' |
1 | get_value(b) |
1 | ; @ REPL[5]:1 within `get_value' |
1 | get_value(a) |
1 | ; ┌ @ REPL[8]:1 within `get_value' |
1 | get_value(b) |
1 | ; ┌ @ REPL[5]:1 within `get_value' |
給大家參考。
應該不少人看到這個標題會摸不著頭緒到底要做什麼,但是看完 Julia 中常見的程式碼你就會了解了。
1 | Array{Any, 2} |
有沒有曾經納悶過那個數字 2 到底是怎麼進到參數的位置上的呢?
參數的位置不是只能放型別(type)嗎?
這同時也是我困惑已久的問題,就搜尋了一下,果不其然被我找到了方法:
1 | struct A{T} |
1 | A{5}() |
原來這麼簡單就可以完成了!語法上並沒有限定一定要是型別,要放型別以外的東西似乎是可以的。
我目前測試了可以的有:Int64、Float64、Complex、Char、Bool、Symbol,所以估計數字應該都是可以的。
不行的有:String、Array,估計物件或是陣列都是不行的。
不過使用上並沒有任何限制會有點危險,所以還是定義一下範圍會比較好,像是:
1 | struct A{I} |
這樣就可以限制參數要是整數的範圍。
那我們能不能從型別的參數當中取值呢?
可以。
1 | get_value(::A{I}) where A{I} = I |
如此一來,我們就可以從型別中拿到值了。
這麼做有什麼好處?
當你把值的資訊放到型別當中,型別就多了一些資訊可以提供編譯器處理,這對於要自己設計型別階層可是非常好用的。
例如像是你可以將陣列的長度資訊儲存到型別上,這樣編譯器就可以處理陣列的長度資訊了。
這樣的程式風格會跟 dependent type language 有些相似了。
大家可以玩玩看。
目標是計算生物學家!Systems Biology, Computational Biology, Machine LearningJulia Taiwan 發起人
研發替代役研究助理