[code-reflection] RFR: Onnx subgraphs, lambda execution and BB removal [v3]
Paul Sandoz
psandoz at openjdk.org
Wed Feb 26 19:15:06 UTC 2025
On Wed, 26 Feb 2025 18:42:04 GMT, Adam Sotona <asotona at openjdk.org> wrote:
>> Initializers are now on top of my ToDo list. They are technically just differently serialized Constant ops. I'm still not sure how we should model them - maybe Initializer op?
>
> Method call in a lambda is another level of complexity. I guess OnnxTransformer should inline it?
> Initializers are now on top of my ToDo list. They are technically just differently serialized Constant ops. I'm still not sure how we should model them - maybe Initializer op?
My understanding is initializers allow for easier introspection of the ONNX model rather than analyzing the graph's constant operators and deciding which are relevant or not.
I was thinking we should avoid representing initializers explicitly in the ONNX code model, and instead a prefix of parameters can be identified as initializers (with their tensor values) when transforming to an ONNX model. I don't fully know how to connect this to the Java ONNX function and the `OnnxRuntime.execute(() -> ...);` since we cannot distinguish between various kinds of captured arguments. Perhaps we can leverage field access, representing the weights as fields (there could be a large amount of them for larger models). Alternatively, we can use structural quoting, target typing the lambda expression to quoted (no functional interface required) where the lambda's parameters correspond to initializers, captures to inputs, and passing the initializer values to the execute method.
> Method call in a lambda is another level of complexity. I guess OnnxTransformer should inline it?
Possibly, although i think the right approach is to leverage [ONNX functions](https://onnx.ai/onnx/intro/concepts.html#functions).
Still, i believe it would be worth supporting the short cut approach now as that shows where we are heading.
-------------
PR Review Comment: https://git.openjdk.org/babylon/pull/326#discussion_r1972236048
More information about the babylon-dev
mailing list