Lock in $30 Savings on PRO—Offer Ends Soon! ⏳

Julia本を書いたら技術顧問になった話 for JuliaTokai #17

Julia本を書いたら技術顧問になった話 for JuliaTokai #17

JuliaTokai #17 LT資料

GOTOH Shunsuke

December 10, 2023
Tweet

More Decks by GOTOH Shunsuke

Other Decks in Technology

Transcript

  1. 自己紹介 • 名前:後藤 俊介 • 所属:有限会社 来栖川電算 • コミュニティ:🌟JuliaTokai, 🌟機械学習名古屋,

    ⭐Ruby東海, ⭐Python東海, ⭐jl.dev, … • 言語:Julia, Python, Ruby, … • SNS等:                  (@antimon2) • SNS等(2):      (@antimon2.jl) • 著書:実践Julia入門
  2. Julia とは?(1) • The Julia Language • 最新 v1.9.4(2023/11/14) ◦

    LTS:v1.6.7(2022/07/19) ◦ 次期:v1.10.0-RC2(2023/12/03) • 科学技術計算に強い! • 動作が速い!(LLVM JIT コンパイル)
  3. Julia とは?(2) • Rのように中身がぐちゃぐちゃでなく、 • Rubyのように遅くなく、 • Lispのように原始的またはエレファントでなく、 • Prologのように変態的なところはなく、

    • Javaのように硬すぎることはなく、 • Haskellのように抽象的すぎない ほどよい言語である 引用元:http://www.slideshare.net/Nikoriks/julia-28059489/8
  4. Julia とは?(3) • C のように高速だけど、 Ruby のようなダイナミズムを併せ持っている • Lisp のような真のマクロを持ちながら、

    MATLAB のような直感的な数式表現もできる • Python のように総合的なプログラミングができて、 R のように統計処理も得意で、 Perl のように文字列処理もできて、 MATLAB のように線形代数もできて、 shell のように複数のプログラムを組み合わせることもできる • 超初心者にも習得は容易でありながら、 ハッカーの満足にも応えられる • インタラクティブな動作環境もあって、コンパイルもできる (Why We Created Julia から抜粋・私訳)
  5. 印税 • 2023/06 最初の振込 ◦ 最低保証部数分 ◦ +電子版の売上分 • 2023/12

    2回目の振込(まだ) ◦ 電子版の売上分 • ※詳細割愛
  6. Julia の (もしくは一般的なプログラミングの) お仕事 • 受託開発 ◦ 特定の環境で動くシステムのプログラミング、など • 研究開発

    ◦ 最新技術等を用いて課題を解決する業務、など • (サイエンス) エンジニアリング ◦ 数値計算や各種データ分析手法を用いた分析・提案など • etc… 今回は…
  7. 経緯 (0) お客さま側の経緯 (before first contact)… • ある大規模データを扱うプロダクトを Julia で開発中

    • 共同開発者 もしくは 技術顧問 的な人員を探していた • 拙著 『実践Julia入門』 を参考書の1つとして読んでいただ いていた • 奥付の著者(私)の所属会社名を ググってコンタクト
  8. 経緯 (1) こちら側の経緯 (after first contact)… • 所属会社のお問い合わせフォームにてコンタクトあり • 概要を聞いて

    「ぜひ協力したい!」 と返答 : (メール および オンラインミーティングでのやり取り) • 正式に契約!
  9. 契約内容 • コンサル(技術顧問) っぽい 契約 ◦ 共同開発という形ではない ◦ 作業内容としては技術面 (およびJulia言語的側面)

    でのレビュー およびアドバイス (コンサルティング) • 契約形態としては 請負契約 ◦ (お客さま側の) 都合により コンサル契約(準委任契約) できず ◦ 成果物として指摘内容等をまとめたものを納品すればOK • 期間 ◦ 2023/10~12
  10. レビュー (アドバイス) 基準 的なもの • 見る点 ◦ Julia における 効率の良いコード・悪いコード

    ◦ 特に マルチスレッド 関連 (あまり経験がない) ◦ その他、一般的なコーディング技術面 (下記を除く) • 見ない点 ◦ コードフォーマット (お客さま独自規約のためスルー) ◦ 命名規則 (お客さま独自規約のためスルー)
  11. 指摘・提案例 (1) スレッドの競合 • マルチスレッドで期待 通りに動作しない箇 所の発見 • ⇒「ロック機構 (排他

    制御) 使いましょう」 という指摘・修正提案 例→ q = Vector{DataFrame}() count = 0 some_proc(args...) do ts1, t2, t3 t1 = read_table(ts1) push!(q, t1, t2, t3) count += 1 end q = Vector{DataFrame}() count = 0 spinlock = Threads.SpinLock() some_proc(args...) do ts1, t2, t3 t1 = read_table(ts1) @lock spinlock begin push!(q, t1, t2, t3) count += 1 end end
  12. 指摘・提案例 (2) スレッドによる非同期動作 • マルチスレッドで非同 期で動作するために テストがこける • ⇒無理矢理にでも同 期を取って順序を保

    つテクの提案 例→ q = Vector{DataFrame}() count = 0 spinlock = Threads.SpinLock() some_proc(args...) do ts1, t2, t3 t1 = read_table(ts1) @lock spinlock begin push!(q, t1, t2, t3) count += 1 end end q = Vector{DataFrame}() count = 0 spinlock = Threads.SpinLock() some_proc(args...) do ts1, t2, t3 wait_by_read_air(ts1) # ここで同期を取る t1 = read_table(ts1) @lock spinlock begin push!(q, t1, t2, t3) count += 1 end end
  13. 指摘・提案例 (3) ユーザ定義型の等価性 • パフォーマンス面でよ ろしくないコード • ⇒生成関数 を利用し て半自動化かつパ

    フォーマンスの良い コードの提案 例→ @generated function _equals(a::T, b::T) where T _cmp(name) = :(getfield(a, $(QuoteNode(name))) == getfield(b, $(QuoteNode(name)))) mapfoldr(_cmp, (x,y) -> :($x && $y), fieldnames(T), init=true) end # 無駄なアロケーション発生しない速い Base.:(==)(a::Hoge, b::Hoge) = _equals(a, b) getfields(obj) = [getfield(obj, name) for name in fieldnames(typeof(obj))] _equals(a,b) = getfields(a) == getfields(b) # ←↑無駄なアロケーション発生するし遅い Base.:(==)(a::Hoge, b::Hoge) = _equals(a, b)
  14. 指摘・提案例 (4) マルチスレッド時のメモリ消費問題 • 「スレッド数は増やしたいけれど、闇雲に増やすとその分比 例してメモリ消費するんですよね…」 ◦ ⇒Base.Semaphore() というのがあります! ◦

    FoldsThreads.jl の TaskPoolEx を利用すれば、件 数/スレッド (basesize) と スレッド数/処理 (=セマ フォ、ntasks) 両方指定できます • ※コード例なし(提案を受け先方で検討中)
  15. 指摘・提案例 (5) その他… • パイプライン演算子(|>)や @chain による「全て計算してから次の計 算に渡す」ような実装になってしまっている箇所の発見・指摘 ◦ ⇒遅延リスト(ジェネレータ)

    や any() 関数の適切な使用による パフォーマンス向上案を提案 • ifelse() 関数の問題点の指摘 (第2・第3引数がともに評価(≒実 行)されてしまう) ◦ ⇒普通に 三項演算子 (~ ? ~ : ~) 使いましょう • プロファイリング や @code_warntype とか見た方が良いかも? ◦ 残りの契約時間で可能な限り実施