Thanks for the PR @zackcquic.
1. Why would you like to keep runtime profiling and pass profiling separate?
The benefit I see is that a lot of the code is similar. We could avoid a lot of
code duplication. On the other hand runtime profiling has does have a lot of
code around handling timing o
Thanks @zackcquic . To follow up on naming,
My understanding is that instrument goes beyond profiling(e.g. can use to
collect the IRs being passed around, dump the IR across pass runs for generate
debugging purposes). The proposal is essentially a structured form of tracing.
Because of that
hi @Mousius,
thanks for your proposal and your detailed evaluation of its impact on runtime
resources! i agree these improvements will simplify the generated code and
improve performance. Some thoughts below:
> When we packed and unpack values, we make use of the `data` portion of a
> DLTens
hi @tgall_foo,
I'm in support of this and would be happy to attend! It would be great if we
launched a thread a few days beforehand collecting some proposed topics.
cc @mehrdadh @thierry @tqchen @ramana-arm @aca88 @stoa @r.stahl @hogepodge
@jknight
Andrew
---
[Visit
Topic](https://dis
Fantastic! Thanks so much for stepping forward to lead something like this
@tgall_foo. I believe @hogepodge can give you access to add the uTVM meetup
calendar hit to the public TVM calendar.
---
[Visit
Topic](https://discuss.tvm.apache.org/t/proposal-regular-tvm-meet-up/9863/4) to
respo
Hi @comaniac , subgraph executor get renamed into pipeline executor, and the PR
now only include pipeline executor and schedule logic, could you help for a
review?
---
[Visit
Topic](https://discuss.tvm.apache.org/t/rfc-compute-graph-pipeline-with-new-subgraph-executor/9839/7)
to respond.
