Module scheduling 

Orchestrator for the Phase 6b probe → judge → dispatch pipeline.

Wraps the three pieces so callers get a ready-to-query DispatchTable from one call. Does the right thing re: reuse across restarts: if the persisted probe matches the current hardware and a persisted profile is present, the Judge is skipped entirely.

One-call API

use fuel_tensor::scheduling::{prepare_dispatch_table, ScheduleOptions};
let (table, _report) = prepare_dispatch_table(ScheduleOptions::default())
    .expect("prepare_dispatch_table");
// `table` is now queryable with `.pick(op, dtype, size, criterion)`.

Reuse rules

1. Probe the current hardware.
2. If a persisted ProbeReport exists and probe.diff(&prior) is HardwareChange::Unchanged, look for a persisted ProfileReport.
3. If a persisted profile is present and its schema version matches, skip the Judge and build the dispatch table from the persisted profile. Save cost on every startup.
4. Otherwise re-run the Judge and persist both reports.

Where the reports live

By default, both reports live under the OS cache dir (%LOCALAPPDATA%\fuel\ on Windows, $XDG_CACHE_HOME/fuel/ on Linux). Callers that want explicit paths (for CI, containers, per-user config) can override via ScheduleOptions.

Structs

ScheduleOptions

Options for prepare_dispatch_table and the Phase 6c prepare_dp_inputs / auto_place_and_route_with_transfer_cost — lets callers override paths, force re-measurement, and tune dispatch-table construction.

Functions

apply_placement_plan

Apply a placement plan to a Graph — set per-node placement hints for every entry that doesn’t already have one. Skipping pre-set hints is the safe default: a user who explicitly pinned a node to a device shouldn’t have that overridden by the dispatch table’s recommendation. Use force_apply_placement_plan when the override is intentional.

auto_place_and_route

One-call Phase 6b auto-router: runs recommend_placement, applies the resulting hints (skip-existing semantics), and runs fuel_graph::opt::insert_copies to materialise the cross- device transfers. Returns the new root IDs from insert_copies (which may have been remapped if any of roots’s ops were rewritten as part of inserting Copy nodes).

auto_place_and_route_with_transfer_cost

One-call Phase 6c auto-router: probe → load-or-judge → load-or- measure-bandwidth → DP-plan → apply hints → insert_copies. Returns the new root IDs after Op::Copy insertion.

dp_plan

Phase 6c DP-based placement planner. Produces a per-node placement that minimises total cost = compute + transfer, via forward dynamic programming over the topo-sorted graph.

force_apply_placement_plan

Like apply_placement_plan but overwrites existing hints. Useful when a re-Judge produces fresher recommendations or when a user wants to dispatch-route a graph that’s been hand-pinned in an earlier pass.

prepare_dispatch_table

Probe → [load / re-Judge] → build dispatch. Persists both reports on a fresh Judge run. Returns the dispatch table paired with the profile report it was built from (callers often want the raw measurements too — for logging, debugging, or a custom secondary dispatch table).

prepare_dp_inputs

Probe → load-or-judge → load-or-measure-bandwidth, returning all three Phase 6c inputs in one call. Reuses persisted reports when the current probe matches the prior one (same hardware-change rule the Judge uses); re-measures any piece marked force_* in the options or that’s missing a persisted file.

recommend_for_node

Single-node recommendation. Public so callers that already have a node in hand (e.g. during a custom graph rewrite pass) can ask the dispatch table directly without building the full plan.

recommend_placement

Walk every node in graph and produce a recommended DeviceLocation per node. Ops the Judge profiled produce a dispatch-table-driven recommendation; ops it didn’t profile fall back to fallback_device (typically the router’s default).