Using simpler¶
Documentation for building on simpler — writing kernels and orchestration, running them on a device or the simulator, measuring them, and diagnosing failures. If you are changing simpler's own runtime internals, start from the documentation index instead; the architecture and internals pages are written for that audience.
The path through¶
| Step | Go to |
|---|---|
| 1. Install and get a device visible | Getting Started, Installation and Runtime Environment |
| 2. Prove your setup works, no kernels involved | examples/workers/l2/hello_worker/ — constructs a Worker, init(), malloc/free, close() |
| 3. Compile and run your first kernel | How-to: write and run a kernel |
| 4. Spread work across chips | How-to: run on multiple chips |
| 5. Find out where the time goes | How-to: profile a kernel |
| 6. Something failed | How-to: debug a failed run |
Reference¶
| Document | What it covers |
|---|---|
| Python API | The types and methods you call: Worker, callables, task args, CallConfig |
| Command-line flags and tools | pytest flags for platform/device/diagnostics, and the analysis CLIs |
Which package do I import from?¶
Both simpler and simpler_setup are part of the surface you write against:
simpler— the runtime itself.Worker, and the task/callable types insimpler.task_interface.simpler_setup— compilation and test scaffolding:KernelCompiler,SceneTestCase/scene_test,Tensor,TaskArgsBuilder,ensure_pto_isa_root,make_tensor_arg. Also the analysis CLIs undersimpler_setup.tools.
You cannot compile a kernel without simpler_setup, so treat both as yours to
use. from simpler import Worker works; the task and callable types come from
simpler.task_interface. One name to watch:
simpler.task_interface.Tensor is a device tensor descriptor while
simpler_setup.Tensor is a scene-test argument spec — same name, different
types.
Where the worked examples live¶
The example trees are the tutorial layer, and several carry their own walkthrough README:
| Tree | What is in it |
|---|---|
examples/workers/l2/ |
Single-chip Worker API: hello_worker, vector_add, worker_malloc, per_task_runtime_env |
examples/workers/l3/ |
Host-level multi-chip: allreduce, multi_chip_dispatch, child_memory |
examples/a2a3/, examples/a5/ |
Per-arch, per-runtime scene tests — the @scene_test style you will most often copy |
examples/workers/l2/vector_add/main.py
is the most useful single file to read: it walks the whole pipeline explicitly
(compile → wrap into callables → allocate → copy → run → verify) with a diagram
in its module docstring, precisely because @scene_test normally hides those
stages.