Inline linear SCC solves share one `LinearCache` per matrix size, so every call refactorizes
まだ誰も着手していません。
評価
- 難易度
- 4/5
- 見積もり時間
- 3〜5日
- 初心者へのやさしさ
- 45/100
- issue の種類
- 機能追加
- 明瞭さ
- おおむね明確
- 活発さ
- 活発
- 領域
- performance
調査の方向性
Start by tracing numeric_ldiv! and solve_into! to see how task-local LinearCache instances are selected and refactorized. The issue suggests adding a solve-site key to emitted safe_ldiv(A, b) calls; compare that approach with keying by A's buffer and consider cache lifetime. Done when unchanged matrices at distinct inline linear SCC solve sites reuse their own factorization without retaining a cache for every problem built.
索引モデルが issue の本文から書いたものです。
説明
numeric_ldiv! keeps one task-local LinearCache per array type and size, shared by every inline linear SCC solve of that shape. So solve_into! copies A in and refactorizes on every call, even when A hasn't changed, since another site of the same size may have used the cache in between.
With one cache per solve site (still task-local), a site whose A depends only on parameters could keep its factorization. On the model below, skipping the refactorization while A is unchanged makes f about 2.5x faster at N = 12 and 1.5x at N = 6 (Julia 1.12).
The emitted safe_ldiv(A, b) would need a site key to key the cache by, e.g. a third argument. Keying by A's buffer instead would leave the emitted code alone, but keep a cache alive for every problem ever built.
@DhairyaLGandhi does this direction sound right? Related: #173.
Model
using ModelingToolkit, LinearAlgebra
using ModelingToolkit: t_nounits as t, D_nounits as D
import ModelingToolkitTearing as MTKTearing
N = 12
@variables x(t)[1:N] y(t)[1:N]
@parameters K[1:N, 1:N]
eqs = [[D(x[i]) ~ -x[i] + y[i] for i in 1:N]; [sum(K[i, j] * y[j] for j in 1:N) ~ x[i] for i in 1:N]]
sys = mtkcompile(System(eqs, t; name = :m);
reassemble_alg = MTKTearing.DefaultReassembleAlgorithm(; inline_linear_sccs = true))
prob = ODEProblem(sys, [x => (1:N) ./ N, K => fill(0.5, N, N) + N * I], (0.0, 1.0))
- 主要言語
- Julia
- スター
- 8
- フォーク
- 14
- 平均マージ
- 8日 8時間
- マージ済み PR（30日）
- 1
環境構築
このプロジェクトには開発コンテナ、Dockerfile、コントリビューションガイドがありません。まず README を読み、一般的な手順ははじめてのコントリビューションガイドを参照してください。
はじめの一歩
- issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
- 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
- リポジトリをフォークし、ブランチを切って変更します。
- issue 番号を参照したプルリクエストを送ります。
JuliaComputing/StateSelection.jl のほかの issue
-
難易度 4/5 3〜5日 初心者へのやさしさ 30/100
-
Inlined linear SCC of three unknowns: the run-time solve dominates the cost of the right-hand sideオープン
難易度 5/5 1週間以上 初心者へのやさしさ 35/100
JuliaComputing/StateSelection.jl#173 · コメント 3 件 ·
-
難易度 4/5 3〜5日 初心者へのやさしさ 52/100
JuliaComputing/StateSelection.jl#172 · コメント 1 件 ·
-
State-machine query operators in ModelingToolkitTearing throw UndefVarError for wrap対応中かも @baggepinnen が 16 日前に担当しました。 オープン
難易度 2/5 1〜3時間 初心者へのやさしさ 35/100
-
`maybe_zeros` check does not look inside a division, so tearing divides by a parameter expression that is zero (NaN in initialization)対応中かも @mwhincup が 19 日前に担当しました。 オープン
難易度 4/5 3〜5日 初心者へのやさしさ 45/100
JuliaComputing/StateSelection.jl#166 · コメント 1 件 ·
JuliaComputing/StateSelection.jl の issue をすべて見る
似ている issue
-
release preparation spack
難易度 2/5 1〜3時間 初心者へのやさしさ 67/100
メンテナーはふだん 1 日以内に返信
-
30-minutes algorithm any-language codewars dart easy elixir hackerrank hacktoberfest haskell help wanted interview-prep julia leetcode lua open-source r scala students zig
難易度 2/5 1〜3時間 初心者へのやさしさ 68/100
Huerte/algo-solutions-python#163 ·
メンテナーはふだん 1 日以内に返信
-
bug
難易度 2/5 1〜3時間 初心者へのやさしさ 76/100
QuantumSavory/QuantumClifford.jl#853 ·
メンテナーはふだん 1 日以内に返信
-
難易度 2/5 1〜3時間 初心者へのやさしさ 66/100
JuliaPackaging/Yggdrasil#15441 · コメント 1 件 ·
メンテナーはふだん 1 日以内に返信
-
bug
難易度 1/5 1時間未満 初心者へのやさしさ 78/100
JuliaSmoothOptimizers/Penelopt.jl#260 ·
メンテナーはふだん 1 日以内に返信