[RFC] Rename GraphRuntime and ilk to e.g. GraphExecutor

Development pre-RFC
1

Background

We currently have two families of “Runtime” in TVM:

  • c and c++ runtime – describes the implementation of c_runtime_api.h and c_backend_api.h.
  • graph, vm, aot runtime – implements Module-Based Model Runtime API (eventually…), which drives model-level execution by invoking a series of operator functions and handling control flow.

Proposal

Let us rename GraphRuntime, VirtualMachine runtime, and AOT Runtime to something else. It’s too confusing to have the word “runtime” everywhere and not everything is a runtime :slight_smile:. Here are some options:

O1. GraphExecutor, VirtualMachine executor, AOTExecutor

O2. GraphDriver, VirtualMachine driver, AOTDriver

O3. GraphEvaluator, VirtualMachine evaluator, AOTEvaluator

I propose O1. O2 makes sense for GraphDriver but not so much the rest. O3 is overloaded for VirtualMachine (“evaluator” is ambiguous").

Thoughts/opinions/additional name proposals?

@tqchen @jroesch @junrushao @giuseros @manupa-arm @ramana-arm @zhiics @yzhliu @comaniac @haichen

2 Likes
2

The “executor” name sounds good to me. Yeah, I agree that conceptually “runtime” of a language should be a minimal library to support its running, and in TVM, specifically it should be something implementing APIs provided in c_backend_api.h.

3

right, even the c/c++ runtimes encompass more than you would expect of a true “runtime.” in the AOT proposal, I believe that the c_backend_api.h implementation is all that would be needed.

4

O1 sounds better to me! Thanks for the proposal.

5

GraphExecutor sounds good to me, but I think VM can be kept as it is an executor anyways. VM is also a pretty standard term.

1 Like
6

btw, are we going to change APIs as well? It will break downstream deployment

7

O1 is good because it already matches existing apis we have (create_executor).

8

@zhiics I agree we do not have a specific VMExecutor checked-in. It would become the convention should we add one. For now, we would just change the verbiage in VM docstrings, where needed.

By change APIs, do you mean “change to fit the module-based model runtime?” I don’t know that we’ve settled on a specific interface, but I think there is sentiment that having a single interface for all executors is a good thing.

9

@areusch yeah, I was talking about the inference APIs, e.g. graph_runtime.

10

O1 seems good!.

What is the expectation of the user to choose which “executor” to be compiled for ? It would be great if it could be unified under relay.build(…), possibly with an additional argument to specify the executor (default can be the “graph” as to not break any downstream deployments).

11

What is the expectation of the user to choose which “executor” to be compiled for ?

we haven’t settled this. Ideally in my mind, the user could just specify a list of executors, but I’m not sure what the effects of that are on the internals.

12

I agree we should unify them

13

GraphRuntime PR: Rename GraphRuntime to GraphExecutor by areusch · Pull Request #7653 · apache/tvm · GitHub

14

PR 7365 has landed – heads-up that at main, GraphRuntime is now named GraphExecutor! VM version to follow.

15

perhaps we should rename the existing GraphExecutor? tvm/build_module.py at main · apache/tvm · GitHub

16

Yeah that is a good point. I do think that if we are going with Executor to describe the runtime, we should rename the existing tvm.relay.Executor interface to something e.g. ExecutorWrapper. We could also contemplate the future of relay.create_executor, but should probably do that in a separate interface.

do others have thoughts?