Starting in Akita v4.9.0 (and MGPUSim v4.1.5), trace capture is now interactive. You can start and stop Daisen trace collection directly from AkitaRTM while the simulation is running.

This change also removes the old --trace-start-time and --trace-end-time arguments. Those options only worked if you already knew the exact cycle range ahead of time—which is rarely the case.

The New Workflow​

Typically, the goal is to record a short period of stable execution, not the entire run. You can now do that with a simple record-button flow:

1. Launch the simulation and open AkitaRTM.
2. Wait for warm-up to finish until the metrics stabilize.
3. Click Start Tracing in AkitaRTM when you're ready to record.
   
4. AkitaRTM displays a recording indicator so you can confirm collection is active.
   
5. Click Stop Tracing once you've captured enough cycles.
6. Open Daisen and analyze the collected window.

The same workflow applies when you want to capture a specific event mid-run—say, a sudden performance drop. Just start tracing near the moment you care about and stop after you have enough data.

Simpler Setup​

You no longer need to manually attach visualization tracers in your configuration code.

As long as your components are registered with the simulation (the standard pattern), the framework automatically wires up AkitaRTM and the Daisen trace collector. The tracing button just works.

What You'll See in Daisen​

Daisen clearly distinguishes recorded regions from unrecorded ones. Shaded areas mark the time ranges where traces were not collected.

A task appears in the trace if it overlaps the collection window by at least one cycle. This inclusive boundary makes the data easy to work with—tasks that barely cross the start or stop point still show up.

Tracing from Cycle 0​

If you know upfront that you want traces from the very beginning, --trace-vis still does exactly that: it starts collection immediately when the simulation launches.

Without --trace-vis, you can still collect traces later. The Start Tracing button in AkitaRTM works at any point during execution, even if the simulation started with tracing disabled.

Why This Matters​

This feature aligns with how tracing is actually used in practice:

• Run first, then record—capture a short, stable window (or any window you care about).
• No guesswork—stop estimating cycle ranges ahead of time.
• Smaller, focused traces—keep output files manageable.
• Seamless handoff—go directly from "I see it in AkitaRTM" to "I can analyze it in Daisen."

At its core, this change reflects a broader design philosophy: simulation tools should adapt to how researchers actually work, not the other way around. The old approach—predicting cycle ranges before running—forced users into a tedious guess-and-rerun loop. Interactive tracing eliminates that friction, making detailed performance analysis accessible without requiring clairvoyance or patience for multi-hour trace dumps.

Problems​

In the past, we use rather ad-hoc methods to record data in Akita. For example, MGPUSim metrics are dumped into a CSV file named metrics.csv in the working directory. Daisen traces are recorded in a SQLite file. We also collect traces for Vis4Mesh, but the code was not fully integrated into the main codebase. We consider this is not a good practice as users may not be able to find the data and matches the data with the simulation executed.

Solution​

We create a dedicated service package called datarecording to record data in Akita. With datarecording, we can record all the data from one simulation run into a SQLite file. Different data types are stored in different tables. Users can use a few simple APIs to record any type of data easily.

How to Use​

It is very easy to use datarecording service package. It only takes a few simple steps.

First, create a new data recorder:

recorder := datarecording.NewDataRecorder("data")

Alternatively, rather than creating a DataRecorder object, we recommend to directly create a Simulation object, which automatically creates several elements, including the Engine, the DataRecorder, the AkitaRTM Monitor, and the Daisen VisTracer. Then, users can simply use simulation.GetDataRecorder() to retrieve the DataRecorder object.

s := simulation.MakeBuilder().Build()
recorder := s.GetDataRecorder()

Then, users can create a table that represent a certain type of data. For example, to record the metrics of a simulation, users can create a table called metrics with the following code:

type metric struct {
	Location string
	What     string
	Value    float64
	Unit     string
}

recorder.CreateTable("metrics", metric{})

Here, we pass a metric struct to the CreateTable function. The metric struct serves as the schema of the table.

After creating the table, users can record data into the table by calling InsertData method. For example, to record a metric, users can call the following code:

recorder.InsertData("metrics", metric{
	Location: "GPU",
	What:     "Memory Usage",
	Value:    100,
	Unit:     "MB",
})

Performance Optimization​

Often, we want to create indices on fields to define data constrains or speed up data retrieval. We allow users to add struct tags to the fields to specify the index. For example, to create an index on the Location field, users can add the following tag to the Location field:

type metric struct {
	ID       int    `akita_data:"unique"`
	Location string `akita_data:"index"`
	What     string
	Value    float64
	Unit     string
}

The akita_data:"index" tag will create an index on the Location field. The akita_data:"unique" tag will create a unique index on the ID field.

Recording the Execution​

Every time a data recorder is created, we always record the execution information into a table called exec_info. The tables contains a few fields, including the working directory, the command line arguments, the start time, and the end time.

What's Next?​

Providing easy analysis capability is always a main goal of Akita. We will continue to add more features to the datarecording package to make it easier to use. Moreover, we will adapt the current simulator code to use the datarecording package. For more information, please refer to the documentation.

Yet another 3000+/4000- line of code pull request.

Problems​

If you have used MGPUSim before, you may hate the runner code as it is probably the most messy part of the codebase. Now, it is time to rewrite it.

So, what is the problem before? Several things:

• The filenames are not easy to understand and search.
• Complex dependencies between different components.
• There are several simulation-level elements, such as the monitor, the visualization tracer, etc. are mixed in the configuration code. What is worse, every component may have a different way to link with those simulation-level elements.

Therefore, we want to have a new runner that is more organized and easier to understand.

Domain-Based Configuration​

Two related concepts here: (1) A Component is a struct that implements some hardware logic. For example, a command processor, a compute unit, a memory controller, etc. (2) A Domain is a collection of components that are connected closely together. For example, we consider a GPU as a domain, which contains a command processor, several compute units, and several memory controllers, etc.

So the most critical change is to have one package to build each domain. Instead of a flat structure, we now have the file structure as follows:

runner/
├── emusystem/
│   ├── emugpu/
│   │   ├── builder.go
│   └── builder.go
├── timingconfig/
│   ├── r9nano/
│   │   ├── builder.go
│   ├── shaderarray/
│   │   ├── builder.go
│   └── builder.go
└── runner.go

For example, now, a ShaderArray is a domain. For each domain, we have a builder.go file that defines the components and how they are internally connected together. Also, the builder.go file will determine what components' ports are exposed to the outside of the domain. Even the outside-most level is considered a domain (e.g., timingconfig). It just have no exposed ports.

We require an outer-level domain to only interact with the exposed ports of the inside domains. For example, the r9nano domain can only interact with the exposed ports of the ShaderArray domain. It cannot directly access the ShaderArray components.

Use of Simulation Struct from Akita.​

A recent update in Akita is that now we have a Simulation struct. It bundles commonly used resources, such as the Data Recorder, the Monitor, and the Visualization Tracer. Simulation struct also centrally manages all the components and ports used in the system. The simulation struct totally changed how to link the global resources to the components.

Previously, we are likely need to pass the Monitor and the DataRecorder to each builder, which adds complexity and make the code difficult to maintain. Now, we centralize the linking process.

When a component is created, we need to register it to the Simulation struct. But that is all we need to do when we create components. When registering the component, the Simulation struct will automatically register it to the monitor.

For attaching tracers or hooks, we now process them after all the components are created. Since the Simulation struct can list all the components, we use a string matching method to identify the components that need to be attached with a tracer or hook. Users can always use a regular expression to match the component name for finer-grained control.

Below is an example of how to attach a tracer to all the Command Processors in the system. While this is not particularly efficient, since it is only executed once during the configuration, it is still acceptable.

for _, comp := range s.Components() {
  if strings.Contains(comp.Name(), "CommandProcessor") {
    tracer := tracing.NewBusyTimeTracer(...)
    tracing.CollectTrace(comp, tracer)
  }
}

What's Next?​

The MGPUSim runner always provides examples for configuration of Akita-based simulators. So we hope other simulators can follow the pattern.

There are still some problems with circular dependencies between domains and components. So, we will continue to improve the runner logic.