Skip to content

Conversation

@Lunderberg
Copy link
Contributor

Whether an optimizations should be performed may depend on when the variables in an expression are known.

For example, consider a LoRA-adjusted model, with base weights W of shape [m,n], LoRA components A and B with shapes [r,n] and [m,r] respectively, and activations x with shape [n,1]. The LoRA-adjusted matmul could be computed either as (W + B*A)*x or as (W*x + B*(A*x)).

If A and B are provided at run-time, then computing (W + B*(A*x)) requires significantly fewer computations.

  • (W + B*A)*x: m*n*(2*r + 3) operations

    1. B*A: 2*m*n*r operations using a naive matmul
    2. Adding W to (1): m*n operations
    3. Multiplying x by (2): 2*m*n operations
  • (W*x + B*(A*x)): (2mn + r*(2n + 2m + 1))

    1. W*x: 2*m*n operations
    2. A*x: 2*r*n operations
    3. Multiplying B by (2): 2*m*r operations
    4. Adding (1) and (3): m` operations

However, if A and B are known at compile-time, then computing `(W

  • B*A)*xgroups all compile-time values together, allowing them to be computed earlier (i.e. usingLiftTransformParams`)
  • (W + B*A)*x: 2*m*n operations
    1. B*A: 0 operations, computed at compile-time
    2. Adding W to (1): 0 operations, computed at compile-time
    3. Multiplying x by (2): 2*m*n operations

Since the choice of optimized expression depends on which parameters can be computed at compile-time, it is useful to have a utility that identifies values that can be computed at compile-time.

Whether an optimizations should be performed may depend on when the
variables in an expression are known.

For example, consider a LoRA-adjusted model, with base weights `W` of
shape `[m,n]`, LoRA components `A` and `B` with shapes `[r,n]` and
`[m,r]` respectively, and activations `x` with shape `[n,1]`.  The
LoRA-adjusted matmul could be computed either as `(W + B*A)*x` or as
`(W*x + B*(A*x))`.

If `A` and `B` are provided at run-time, then computing `(W +
B*(A*x))` requires significantly fewer computations.

* `(W + B*A)*x`: `m*n*(2*r + 3)` operations
  1. `B*A`: `2*m*n*r` operations using a naive matmul
  2. Adding `W` to (1): `m*n` operations
  3. Multiplying `x` by (2): `2*m*n` operations

* `(W*x + B*(A*x))`: (2*m*n + r*(2*n + 2*m + 1))
  1. `W*x`: `2*m*n` operations
  2. `A*x`: `2*r*n` operations
  3. Multiplying `B` by (2): `2*m*r` operations
  4. Adding (1) and (3)`: `m` operations

However, if `A` and `B` are known at compile-time, then computing `(W
+ B*A)*x` groups all compile-time values together, allowing them to be
computed earlier (i.e. using `LiftTransformParams`)

* `(W + B*A)*x`: `2*m*n` operations
  1. `B*A`: 0 operations, computed at compile-time
  2. Adding `W` to (1): 0 operations, computed at compile-time
  3. Multiplying `x` by (2): `2*m*n` operations

Since the choice of optimized expression depends on which parameters
can be computed at compile-time, it is useful to have a utility that
identifies values that can be computed at compile-time.
@slyubomirsky
Copy link
Contributor

The logic seems fine here, but what is the kNumInput attribute used for? Distinguishing weights from inputs?

@Lunderberg
Copy link
Contributor Author

The logic seems fine here, but what is the kNumInput attribute used for? Distinguishing weights from inputs?

That's correct. The attribute was initially added for LiftTransformParams, to distinguish between parameters available at compile-time, and parameters not available until runtime. It was later expanded to be available for more transforms in #15736, and to be automatically generated for the nn.Module interface in #16247.

Copy link
Contributor

@slyubomirsky slyubomirsky left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This makes sense then, thanks for implementing the pass.

@Lunderberg Lunderberg merged commit c3aa71a into apache:unity Jan 4, 2024
@Lunderberg Lunderberg deleted the unity_analysis_collect_compile_time_bindings branch January 4, 2024 18:06
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants