DispatchAtlasModèle de benchmarks
dispatchatlas.bench définit la preuve de benchmarks avant que les solveurs ou les
campagnes ne la consomment. Une famille de benchmarks déclare sa taxonomie, son profil de
domaine, sa classe de profil, ses hypothèses, sa preuve de citation, son enveloppe
d'échelle, son espace de noms de graine, et son schéma de sortie. La matérialisation
valide chaque problème généré avec dispatchatlas.core, caractérise l'instance,
l'enveloppe dans une enveloppe de provenance, et enregistre des hachages stables.
Le catalogue couvre les familles génériques de planification d'optimisation-combinatoire et la planification de distributed-computing comme des pairs co-égaux, de sorte que la plateforme n'est pas un outil uniquement-de-distributed-computing.
Exemple exécutable : examples/benchmark_continuum.py génère, caractérise, et catalogue un atlas de benchmarks continu à la volée.
Familles de planification
Chaque famille de planification est matérialisée comme un pair de catalogue de première-classe avec au moins un profil générateur. La table de catalogue ci-dessous est générée à partir du registre de générateurs de benchmarks et de la matrice de citation, de sorte que ses totaux de famille et citations de source sont dénombrables depuis les lignes elles-mêmes. Un graphique de distribution-des-familles au-dessus de la table montre comment les profils de famille se répartissent entre les catégories de familles de planification.
Generated from the benchmark generator registry and the citation matrix: 69 family profiles across 8 scheduling families — distributed-computing (47), flow-shop (7), job-shop (6), machine-scheduling (3), open-shop (1), rcpsp (3), rcpsp-max (1), setup-flow-shop (1).
Showing 69 of 69 family profiles.
| Distinctive against | Evidence | Citation status | Source citations | |||
|---|---|---|---|---|---|---|
accelerator-coschedulingaccelerator-coscheduling a heterogeneous datacenter job needs a compute resource and a scarce accelerator at the same time, so every job co-allocates two simultaneous resource demands held together for its whole run; the accelerator pool is scarce, so jobs sharing an accelerator serialize on it while jobs on disjoint resources run in parallel, and the scheduler reasons over a multi-resource co-allocation problem rather than a single-unit-demand one | distributed-computing | ioe-complete | published single-resource continuum schedulers (one unit resource demand per task, not the simultaneous co-allocation of a compute resource and a scarce accelerator held together under a Pareto contract) | smoke | citation-backed |
|
aerial-edgeaerial-edge a loitering UAV is a flying fog node that serves the ground region beneath it for a fixed loiter window before moving to the next pass, so sorties group into successive loiter passes pinned to the fog tier the platform embodies while overhead | distributed-computing | ioe-complete | aerial-edge MEC simulators (no flying-fog loiter placement) | smoke | citation-backed |
|
anytime-inferenceanytime-inference an edge accelerator serves deep-learning inference requests that each complete a mandatory minimal-accuracy early-exit branch and may run an optional refinement to full accuracy when their latency deadline allows; every request declares a mandatory duration below its full duration and a tight latency deadline, and arrivals are spaced shorter than a full inference so requests queue and contend, so the scheduler decides which requests refine and which deliver the early-exit result -- an imprecise-computation quality-versus-timeliness trade-off | distributed-computing | ioe-complete | published edge-cloud split inference and datacenter inference serving (a fixed full-accuracy computation per request), neither of which lets a request drop an optional refinement to meet its deadline so the schedule order trades accuracy for timeliness | smoke | citation-backed |
|
blocking-flow-shopblocking-flow-shop | flow-shop | classical | — | smoke | citation-backed |
|
bulk-synchronous-graphbulk-synchronous-graph an iterative graph computation runs as a sequence of supersteps separated by global barriers, so each superstep's vertex partitions compute and exchange messages and every partition of the next superstep waits on all partitions of the prior one; the slowest partition therefore gates each superstep, and the scheduler reasons over a barrier-synchronized partition-balancing problem rather than an overlap-friendly pipeline or an independent-task one | distributed-computing | ioe-complete | published pipeline or independent-task schedulers (an overlap-friendly wavefront or unsynchronized tasks, not supersteps separated by global barriers where the slowest partition gates each round under a Pareto contract) | smoke | citation-backed |
|
carbon-awarecarbon-aware flexible jobs defer to low-carbon-intensity windows under a time-varying grid carbon signal while honoring their SLA deadlines | distributed-computing | ioe-complete | Electricity-Maps grid carbon-intensity and CityLearn carbon-aware community signals | smoke | citation-backed |
|
cloud-independentcloud-edge-independent | distributed-computing | domain-specific | — | smoke | citation-backed |
|
coflow-schedulingcoflow-scheduling a distributed-computing stage completes only when the last network transfer of its coflow lands, not the first, so a coflow's completion time is the maximum over its member flows; every coflow emits data-heavy flow tasks that place freely across the fabric plus a barrier task that depends on all of them, so the barrier gates the group and the coflow-completion-time is an all-or-nothing footprint | distributed-computing | ioe-complete | datacenter coflow schedulers (no continuum tier-placement barrier) | smoke | citation-backed |
|
compact-job-shopcompact-job-shop | job-shop | classical | — | smoke | citation-backed |
|
confidential-edgeconfidential-edge tasks are classified by data sensitivity -- a confidential task that touches protected data must execute inside the enclave-capable trusted tier so its data never leaves the trusted boundary, while a public task draws a free placement affinity across the fabric | distributed-computing | ioe-complete | edge enclave runtimes (no security-classified Pareto placement) | smoke | citation-backed |
|
cyber-physicalcyber-physical control cycles arrive periodically under a time-varying tariff | distributed-computing | ioe-complete | periodic hard-real-time task models and smart-grid demand-side scheduling formulations (no edge-fog-cloud tier placement under a Pareto contract) | smoke | citation-backed |
|
data-localitydata-locality a query over a large dataset is cheaper to run where the data already resides than to ship the data across the WAN fabric; each task's input lives on one tier (edge sensor logs, fog warm aggregates, or cloud cold archives) and the task pins to that tier so its heavy input never crosses the fabric, with the data tiers cycled so placement spans the whole edge-fog-cloud continuum | distributed-computing | ioe-complete | cluster locality schedulers (no continuum data-residency placement) | smoke | citation-backed |
|
datacenter-colocationdatacenter-colocation latency-sensitive service jobs and deferrable batch jobs share multi-tenant cells, so high-priority-band jobs claim capacity ahead of low-band jobs under contention | distributed-computing | ioe-complete | Google Borg ClusterData2019 priority-tiered cell traces | smoke | citation-backed |
|
digital-twin-syncdigital-twin-sync each physical asset periodically syncs its state to its fog/cloud twin and must finish within a freshness (Age-of-Information) window before the twin's state goes stale | distributed-computing | ioe-complete | digital-twin edge frameworks (no joint Pareto placement) | smoke | citation-backed |
|
disaggregated-memorydisaggregated-memory a CXL-pooled cloud platform backs each socket with a small local DRAM tier and a shared far-memory pool, and every VM draws a long-tailed memory working set, so a few memory-hungry tenants dominate a socket's local budget while far-memory access inflates a VM's runtime in proportion to the working set it spills to the pool; the scheduler reasons over local-versus-pool placement rather than core-count placement | distributed-computing | ioe-complete | published CXL memory-pooling and tiered-memory systems (socket-local page placement, no edge-fog-cloud tier scheduling under a Pareto contract) | smoke | citation-backed |
|
distributed-assembly-flow-shopdistributed-assembly-flow-shop | flow-shop | classical | — | smoke | citation-backed |
|
distributed-flexible-job-shopdistributed-flexible-job-shop | job-shop | structurally-complex | — | smoke | citation-backed |
|
distributed-permutation-flow-shopdistributed-permutation-flow-shop | flow-shop | classical | — | smoke | citation-backed |
|
distributed-training-gangdistributed-training-gang a GPU cluster runs synchronous data-parallel training jobs; each job is a gang of workers that must START TOGETHER on distinct accelerators (every all-reduce step synchronizes the workers), so a job cannot begin until enough accelerators are free simultaneously; the workers reuse the accelerator pool and jobs arrive over time, so jobs queue and the scheduler decides which job acquires a full simultaneously-free worker set first -- an all-or-nothing gang co-start, not an independent placement of each worker | distributed-computing | ioe-complete | published GPU-cluster and inference-serving families that place each task independently; none requires a whole job's worker set to co-start simultaneously on distinct accelerators, so no other family forbids a partial start -- the gang-scheduling all-or-nothing constraint under a Pareto contract | smoke | citation-backed |
|
distributed-transactiondistributed-transaction a partitioned database runs transactions that each acquire exclusive locks on a variable read/write set of data shards, so every transaction co-allocates a randomly drawn subset of shards held together for its whole run; two transactions whose shard sets intersect serialize while disjoint transactions commit in parallel, so the scheduler reasons over a variable-cardinality lock-conflict graph rather than a fixed two-resource hold | distributed-computing | ioe-complete | published replica-placement schedulers (a single shard pinned per task for locality, not a variable-cardinality exclusive lock set co-allocated per transaction forming a conflict graph under a Pareto contract) | smoke | citation-backed |
|
edge-offloadingedge-offloading-mec each task chooses between local edge execution and remote offload | distributed-computing | ioe-complete | iFogSim MEC offloading scenarios | smoke | citation-backed |
|
edge-placementedge-placement services place on edge servers near their user population and migrate as demand shifts across base-station coverage cells | distributed-computing | ioe-complete | EUA edge-user-allocation and Shanghai-Telecom base-station placement traces | smoke | citation-backed |
|
elastic-serverless-autoscaleelastic-serverless-autoscale a serverless platform serves function invocations on a shared worker pool, and every invocation is moldable: it may run on one, two, or four concurrent workers, where a wider allocation runs shorter by a sublinear speedup but spends more total worker-seconds; each request declares its execution modes and arrivals are spaced shorter than a base invocation so the pool is contended, so the scheduler picks each invocation's worker width -- a moldable latency-versus-cost choice rather than a fixed resource hold | distributed-computing | ioe-complete | published serverless cold-start and fixed-width co-allocation families (accelerator co-scheduling, fpga partitioning), each of which holds one fixed resource set per task; none lets a request choose among several worker-count modes so the schedule order trades latency for resource cost under a Pareto contract | smoke | citation-backed |
|
facility-assignmentfacility-assignment | machine-scheduling | classical | — | smoke | citation-backed |
|
failure-recoveryfailure-recovery a failed task re-places its checkpoint state to a surviving tier | distributed-computing | ioe-complete | Borg cluster failure-event traces | smoke | citation-backed |
|
federated-learningfederated-learning each training round selects a subset of heterogeneous, straggler-prone edge clients that train on non-IID local data, then a fog or cloud aggregator combines their updates | distributed-computing | ioe-complete | FedScale and Oort federated-learning device-participation benchmarks | smoke | citation-backed |
|
flexible-job-shopflexible-job-shop | job-shop | classical | — | smoke | citation-backed |
|
flow-shoppermutation-flow-shop | flow-shop | classical | — | smoke | citation-backed |
|
fpga-partitioningfpga-partitioning a multi-tenant reconfigurable FPGA hosts tenant kernels that each occupy a contiguous region of fabric tiles, so every kernel co-allocates a contiguous run of tiles held together for its whole residency; two kernels whose tile intervals overlap cannot be co-resident and serialize while kernels on disjoint tile spans run in parallel, so the scheduler reasons over an interval-overlap conflict graph rather than a fixed two-resource hold or a random-subset lock set | distributed-computing | ioe-complete | published accelerator co-scheduling (a fixed compute-plus-accelerator pair) and shard-lock transactions (a random subset of resources), neither of which constrains the co-allocated set to a spatially contiguous tile interval whose overlaps form an interval conflict graph under a Pareto contract | smoke | citation-backed |
|
frontierco-fjspfrontierco-fjsp | job-shop | classical | — | smoke | citation-backed |
|
generative-inference-servinggenerative-inference-serving a transformer inference replica batches autoregressive requests that each hold key-value-cache memory proportional to their token count for the whole decode, so a long-tailed sequence mix fragments a fixed cache budget and the scheduler reasons over memory-bound admission rather than GPU-count placement; every request's decode duration and KV-cache demand scale with its drawn token count | distributed-computing | ioe-complete | published single-replica generative-model serving systems (no edge-fog-cloud tier placement under a Pareto contract) | smoke | citation-backed |
|
gpu-mlgpu-ml training and inference jobs claim accelerators and gang-schedule replicas | distributed-computing | ioe-complete | Alibaba PAI, Philly, and Helios GPU-cluster traces | smoke | citation-backed |
|
hybrid-flow-shophybrid-flow-shop | flow-shop | classical | — | smoke | citation-backed |
|
immersive-xrimmersive-xr each extended-reality frame runs a latency-critical perception, render, and display pipeline placed across the device, edge, and cloud within a hard motion-to-photon deadline | distributed-computing | ioe-complete | ILLIXR extended-reality systems testbed | smoke | citation-backed |
|
intermittent-edgeintermittent-edge a batteryless sensor harvests ambient energy into a small buffer, runs until the buffer depletes, then sleeps to recharge; a job too large for one duty-cycle window is checkpointed at power loss and resumed in the next, so it is a precedence chain of edge-pinned per-window segments each bounded by the constant energy window | distributed-computing | ioe-complete | intermittent-computing runtimes (no continuum energy-window placement) | smoke | citation-backed |
|
iot-edgeiot-edge many small sensor readings arrive periodically and aggregate at the edge | distributed-computing | ioe-complete | published wireless-sensor-network telemetry datasets and in-network aggregation deployments (raw sensor readings, not edge-fog-cloud tier scheduling under a Pareto contract) | smoke | citation-backed |
|
job-shopjob-shop | job-shop | classical | — | smoke | citation-backed |
|
kv-cache-placementkv-cache-placement a distributed key-value cache tier serves a catalog of cache objects whose request rate follows a heavy Zipfian popularity skew, so a few hot objects absorb most of the traffic; each object is placement-flexible, carrying one single-node mode per cache-tier node, so the scheduler chooses which tier node hosts it, and an object's working set -- the transfer volume staged onto its host tier -- scales with its popularity rank, so the hottest object carries the largest working set and a cold-tail object the smallest; a naive uniform placement strands a hot, large-working-set object on a far tier and pays its transfer across the fabric, while a locality-aware placement pins the hottest objects to near tiers to shrink makespan and cost | distributed-computing | ioe-complete | published cache and content-placement families (consistent-hashing replica placement, CDN content distribution) that place each object uniformly or by a hash; none scales each object's working set with a Zipfian popularity rank so the hot objects carry a strictly larger transfer volume, making popularity-skewed near-tier pinning the lever a locality-aware placement pulls under the Pareto contract | smoke | citation-backed |
|
machine-schedulingmachine-scheduling-unrelated | machine-scheduling | classical | — | smoke | citation-backed |
|
microservice-dagmicroservice-dag services form an acyclic call graph pinned by role to a tier | distributed-computing | ioe-complete | Alibaba v2021 microservice-trace call graphs | smoke | citation-backed |
|
mixed-criticalitymixed-criticality a safety-critical real-time mix runs tasks of differing criticality, and a high-criticality task is budgeted with a conservative high-assurance worst-case execution time and a tight deadline while a low-criticality task carries a smaller best-effort budget and a loose deadline, so the criticality tiering lives in the duration and deadline structure; the scheduler reasons over which assured-criticality tasks to guarantee under contention rather than a uniform-assurance deadline-scheduling one | distributed-computing | ioe-complete | published uniform-assurance real-time deadline schedulers (one worst-case execution time and deadline class per task, not criticality-tiered WCET budgets with tighter high-assurance deadlines under a Pareto contract) | smoke | citation-backed |
|
moe-expert-parallelmoe-expert-parallel a sparsely-activated mixture-of-experts model routes each token batch to one expert and the experts are spread across devices, and expert popularity is long-tailed, so a few hot experts receive most token batches while many stay cold and the all-to-all routing exchange dominates fabric traffic; the scheduler reasons over an expert-placement and load-balancing problem rather than a dense uniform-replica serving one | distributed-computing | ioe-complete | published dense generative-model serving systems (uniform per-replica KV-cache admission, not sparse token-to-expert routing under load imbalance and a Pareto contract) | smoke | citation-backed |
|
multi-objective-pfspmulti-objective-pfsp | flow-shop | classical | — | smoke | citation-backed |
|
multi-project-rcpspmulti-project-rcpsp | rcpsp | structurally-complex | — | smoke | citation-backed |
|
multi-tenant-fair-sharemulti-tenant-fair-share a shared cluster serves several tenants whose workloads compete for one node pool; each task is placement-flexible, carrying one single-node mode per pool node, so the scheduler chooses which node it occupies; tenants are sized asymmetrically, so even a load-balanced placement leaves the heavy tenants holding a larger fraction of their busiest node -- a higher dominant resource share -- than the light ones, and a fairness-aware scheduler rebalances placement to shrink the dominant-share spread | distributed-computing | ioe-complete | published multi-tenant colocation families (Borg-style priority colocation, vm allocation) that fix each task's resource and score makespan or cost; none lets the scheduler choose each tenant task's node and scores the dominant-resource-share spread between tenants as a fairness objective | smoke | citation-backed |
|
network-slicingnetwork-slicing isolated slice classes (latency-critical, broadband, massive-IoT) each carry their own service-level deadline and placement, and same-class slices spread across tiers for resilience | distributed-computing | ioe-complete | 5G slicing orchestration (no joint Pareto placement) | smoke | citation-backed |
|
no-wait-flow-shopno-wait-flow-shop | flow-shop | classical | — | smoke | citation-backed |
|
open-shopopen-shop | open-shop | classical | — | smoke | citation-backed |
|
orbital-edgeorbital-edge tasks schedule across ground terminals, moving low-earth-orbit satellites, and cloud backhaul under time-varying connectivity as satellites enter and leave coverage and hand work over | distributed-computing | ioe-complete | LENS real-measurement LEO satellite-network traces | smoke | citation-backed |
|
pipeline-parallel-trainingpipeline-parallel-training a deep network is split into successive pipeline stages pinned across edge-to-cloud tiers and the training mini-batch is divided into micro-batches, so each micro-batch flows forward stage by stage while each stage runs its micro-batches in issue order; the two precedence families form a diagonal wavefront whose warm-up and cool-down idle slots are the pipeline bubbles, and deeper stages carry rising compute, so the scheduler reasons over a stage-partition and bubble-minimizing problem rather than a synchronous data-parallel all-reduce one | distributed-computing | ioe-complete | published data-parallel / gang-scheduled training systems (synchronous all-reduce over co-located replicas, not a stage-by-micro-batch pipeline wavefront with warm-up and cool-down bubbles under a Pareto contract) | smoke | citation-backed |
|
rcpsprcpsp-renewable | rcpsp | structurally-complex | — | smoke | citation-backed |
|
rcpsp-maxrcpsp-max | rcpsp-max | structurally-complex | — | smoke | citation-backed |
|
rcpsp-multi-modercpsp-multi-mode | rcpsp | structurally-complex | — | smoke | citation-backed |
|
reentrant-fabreentrant-fab | job-shop | structurally-complex | — | smoke | citation-backed |
|
replica-placementreplica-placement a replica runs where its data shard already lives | distributed-computing | ioe-complete | CRUSH replicated-data placement | smoke | citation-backed |
|
serverless-cold-startserverless-cold-start a cold invocation pays a container provisioning penalty | distributed-computing | ioe-complete | Azure Functions serverless-in-the-wild traces | smoke | citation-backed |
|
service-function-chainservice-function-chain an NFV packet flow traverses a linear ordered chain of typed virtual network functions -- firewall, intrusion detection, deep packet inspection, address translation -- each pinned to a tier that hosts its function type, so the chain is a strict total order and the flow crosses the edge-fog-cloud fabric in a fixed sequence; the scheduler reasons over a chain-placement problem under an end-to-end latency budget rather than the branching role-pinned call graph of a microservice | distributed-computing | ioe-complete | published microservice call-graph schedulers (a branching role-pinned acyclic call graph, not a strict linear chain of function-typed network functions under an end-to-end latency budget and a Pareto contract) | smoke | citation-backed |
|
setup-flow-shopsetup-flow-shop | setup-flow-shop | classical | — | smoke | citation-backed |
|
smartnic-offloadsmartnic-offload a SmartNIC-accelerated server pairs a fast host CPU with a low-power on-NIC processor, and every microservice draws a long-tailed compute intensity, so most are light enough to offload onto the energy-frugal NIC cores while a few compute-heavy services must stay host-bound; a service's runtime scales with its intensity, so the scheduler reasons over an energy-versus-latency offload-placement problem rather than a uniform host placement one | distributed-computing | ioe-complete | published mobile-edge computation-offloading models (device-to-edge latency offload, not in-server host-to-NIC energy offload under a Pareto contract) | smoke | citation-backed |
|
split-inference-servingsplit-inference-serving each inference request partitions a deep model at a layer cut -- a light head runs the early layers on the edge near the sensor and a heavy tail runs the later layers in the cloud, consuming the head's intermediate feature map under a per-request end-to-end latency SLO | distributed-computing | ioe-complete | datacenter inference serving (no edge-cloud partition placement) | smoke | citation-backed |
|
spot-preemptiblespot-preemptible a cloud provider rents idle capacity at a discount as revocable spot instances reclaimed after a short lease; eviction-tolerant batch work pins to the cloud spot tier under a hard lease deadline (the eviction horizon), while latency-critical interactive work pins to the stable edge on-demand tier with no eviction deadline | distributed-computing | ioe-complete | cloud spot schedulers (no continuum eviction-deadline placement) | smoke | citation-backed |
|
storage-io-tieringstorage-io-tiering a tiered storage pool serves I/O-bound jobs whose runtime is dominated by moving a job's I/O volume through the storage node it lands on; each job is placement-flexible, carrying one single-node mode per tier node, and the mode duration is tier-dependent -- a seek floor plus the I/O volume divided by that tier's I/O bandwidth, which differs by tier (a fast cloud array sustains far more bytes/second than a slow edge disk); a job's I/O volume follows a heavy-tailed falloff over its I/O-demand rank, so a few I/O-heavy jobs carry most of the bytes and have a large cross-tier duration spread, while the light tail barely varies; a naive placement strands an I/O-heavy job on a low-bandwidth tier and pays its volume slowly, while a bandwidth-aware placement pins the heavy jobs to fast tiers to shrink makespan and cost | distributed-computing | ioe-complete | published storage-tiering and hierarchical-storage-management families that migrate blocks between fast and slow tiers by access frequency; none models the heterogeneous-tier I/O bandwidth as a placement-flexible per-tier mode whose duration is the I/O volume divided by that tier's bandwidth, so an I/O-heavy job's cross-tier duration spread is the bottleneck-relief lever a bandwidth-aware placement pulls under the Pareto contract | smoke | citation-backed |
|
streaming-windowstreaming-window events arrive online in bounded windows and must close within one | distributed-computing | ioe-complete | Parallel Workloads Archive online arrivals | smoke | citation-backed |
|
time-sensitive-networkingtime-sensitive-networking each time-triggered flow releases on a fixed period and must finish within one cycle under a hard, jitter-free deadline | distributed-computing | ioe-complete | EdgeCloudSim best-effort scenarios (no gating) | smoke | citation-backed |
|
unrelated-parallel-setupunrelated-parallel-setup | machine-scheduling | structurally-complex | — | smoke | citation-backed |
|
vehicular-offloadingvehicular-offloading a vehicle's tasks share an arrival time and a roadside-unit dwell deadline, and hand over from the roadside unit to the fog tier as the vehicle drives on | distributed-computing | ioe-complete | EdgeCloudSim / SUMO vehicular-edge mobility scenarios | smoke | citation-backed |
|
video-analyticsvideo-analytics each camera streams frames that must be analyzed within a tight real-time latency bound, placed hierarchically with edge inference near the camera and cloud aggregation | distributed-computing | ioe-complete | edge video-analytics clusters (no joint Pareto placement) | smoke | citation-backed |
|
vm-allocationvm-allocation size-heterogeneous virtual-machine deployments pack onto hosts while each deployment's members spread across distinct failure domains for availability | distributed-computing | ioe-complete | Azure Public Dataset Resource Central VM-allocation traces | smoke | citation-backed |
|
workflow-dagworkflow-dag | distributed-computing | structurally-complex | — | smoke | citation-backed |
|
Per-instance characterization and download eligibility live in the benchmark catalog; this table is the family-and-citation inventory.
Le composant ci-dessus porte l'inventaire généré complet — les familles cœur classiques et de distributed-computing ci-dessous plus le continuum de familles Edge–Fog–Cloud. Ces familles cœur fondationnelles sous forme de document :
| Famille | Profil | Classe de profil | Corpus primaire |
|---|---|---|---|
| Planification de machines (R||Cmax, machine non-reliée) | machine-scheduling-unrelated | classical | OR-Library |
| Job-shop | job-shop-classical | classical | OR-Library, Taillard |
| Job-shop flexible (FJSP) | flexible-job-shop | classical | Brandimarte; Hurink-Jurisch-Thole |
| Flow-shop de permutation | permutation-flow-shop | classical | Taillard |
| Flow-shop de setup dépendant-de-séquence (SDST) | setup-flow-shop | classical | Allahverdi et al. (2008); Allahverdi (2015) |
| Planification de projets à-ressources-contraintes (RCPSP) | rcpsp-renewable | structurally-complex | PSPLIB |
| Distributed-computing (cloud/edge) | cloud-edge-capacity | domain-specific | CloudSim; DynamicCloudSim; Edge vision |
| Distributed-computing (workflow DAG) | workflow-dag | structurally-complex | Standard Task Graph Set |
Les familles de machine-non-reliée et de job-shop flexible attachent une matrice de
temps-d'exécution CostModel à chaque instance, exportée comme une matrice matérialisée
aux côtés du JSON du problème. La famille de flow-shop de setup dépendant-de-séquence
attache plutôt une matrice de setup CostModel : un changement entre des travaux de
familles différentes sur une machine coûte du temps de setup, de sorte que l'objectif de
setup récompense le regroupement de travaux similaires. Les corpora standard nommés sont
cités et liés seulement et ne sont jamais redistribués à l'intérieur du dépôt.
Plusieurs familles du continuum exercent la co-allocation multi-ressource : chaque
tâche demande plus d'une ressource à la fois et le constructeur les maintient ensemble
pour toute sa durée (voir Contrats de domaine). La famille
accelerator-coscheduling co-alloue un nœud de calcul et un accélérateur rare par
travail ; la famille distributed-transaction co-alloue un ensemble de verrous de
cardinalité-variable de fragments de données par transaction ; et la famille
fpga-partitioning co-alloue une suite spatialement contiguë de tuiles de tissu
reconfigurable par noyau de locataire. Les tâches dont les ensembles de ressources se
croisent se sérialisent tandis que les tâches disjointes s'exécutent concurremment —
l'exécutable examples/inspect_coallocation.py
rend le levier explicite.
Au-delà de la co-allocation, trois familles du continuum exercent leurs propres leviers
structurels. La famille elastic-serverless-autoscale exerce l'exécution modelable :
chaque invocation de fonction déclare plus d'un mode d'exécution — un mode étroit
seulement-domicile et un mode large qui emprunte un worker à un petit pool de rafale
partagé pour finir plus tôt — de sorte que l'ordonnancement choisit un mode par tâche et
l'ordre décide quelles invocations réclament le rare mode large-et-rapide. La famille
distributed-training-gang exerce la co-planification de bande : les workers d'un
travail d'entraînement data-parallèle synchrone partagent une bande et doivent co-démarrer
sur des accélérateurs distincts dans un lancement tout-ou-rien — les workers réutilisent le
pool d'accélérateurs et les travaux arrivent au fil du temps, de sorte qu'un travail ne
peut commencer tant qu'assez d'accélérateurs ne se libèrent simultanément, et l'ordre
décide quel travail acquiert son ensemble complet de workers en premier. La famille
multi-tenant-fair-share exerce l'équité de ressource-dominante : plusieurs locataires
de taille-asymétrique placent des tâches flexibles-en-placement sur un pool de nœuds
partagé, et l'objectif de part-de-ressource-dominante note l'écart entre la part dominante
du locataire le plus- et le moins-servi — de sorte que le placement, quelles ressources
chaque locataire occupe, est le levier qui l'équilibre ou le fausse. Les exécutables
examples/serverless_autoscale_study.py,
examples/distributed_training_gang_study.py,
et
examples/multi_tenant_fairshare_study.py
rendent ces trois leviers explicites.
Classes de profil
| Classe de profil | Signification |
|---|---|
classical | Dérive d'un corpus standard d'optimisation-combinatoire. |
structurally-complex | Porte une structure de précédence, DAG, ou réseau-de-ressources. |
ioe-complete | Scénario distribué Internet-of-Everything-complet. |
trace-backed | Fondé sur une trace de charge du monde-réel nommée. |
domain-specific | Adapté à un seul domaine opérationnel. |
Étiquettes de preuve
| Étiquette | Usage |
|---|---|
smoke | Petites instances déterministes pour tests, exemples, docs, et aperçus. |
exploratory | Matériel plausible qui n'est pas encore adossé-à-des-citations ni pleinement caractérisé. |
| grade de preuve candidat | Matériel adossé-à-des-citations en attente des gates de pilote, statistiques, et de campagne. |
| grade de preuve de campagne-complète | Preuve qui a passé les gates de citation, caractérisation, statistiques, de divulgation, et de qualité. |
Les catalogues de test ne sont jamais une preuve d'évaluation finale. Ils existent pour
prouver que les générateurs, la validation, la caractérisation, les vérifications de
citation, et la persistance fonctionnent rapidement. Le catalogue du portail et les
téléchargements prévisualisent chaque famille du continuum à cette petite échelle de test
(un pool de trois-ressources) ; une famille de co-allocation ne peut pas exhiber le
parallélisme de ressource-disjointe sur un pool si petit, de sorte que la structure
distinctive est une propriété d'échelle-de-recherche. build_continuum_full_catalog()
matérialise chaque famille à son échelle de recherche déclarée -- le pool de ressources et
le nombre de tâches plus grands où la structure de co-allocation, de contention, et de
placement se manifeste véritablement -- pour des lots de benchmarks de grade-recherche.
Taxonomie
La taxonomie couvre les structures de planification, les environnements, le réalisme d'infrastructure, les caractéristiques d'objectif, les caractéristiques de contrainte, l'incertitude, et le dynamisme. Les exemples incluent les workflows DAG, les lots de tâches indépendantes, les fonctions serverless, la consolidation de conteneurs et de VM, les environnements edge et cloud, les traces publiques, l'optimisation multi-objectif, les deadlines, la localité de données, le churn, et les arrivées dynamiques.
Matrice de citation
Les affirmations de benchmarks sont vérifiées contre CitationMatrix. Les affirmations de
grade de preuve candidat et de campagne-complète échouent à la validation à moins qu'elles
ne référencent des sources adossées-à-des-citations. Le matériel non soutenu doit rester
exploratoire jusqu'à ce que la preuve soit ajoutée.
L'ensemble de sources est déclaré dans default_citation_matrix() avec des identifiants de
source stables, des références résolubles, et une posture de licence enregistrée. Il couvre
trois niveaux : les corpora standard d'optimisation-combinatoire (cités et liés seulement,
jamais empaquetés), les traces de cluster de production, et un large ensemble de datasets
contemporains du monde-réel du continuum Edge–Fog–Cloud — traces de cluster GPU et
machine-learning, suites de benchmark de microservices et serverless, traces de
workflow-scientifique, traces de travaux de supercalculateur, datasets d'edge-placement et
de mobilité, datasets d'IoT et de demande-cellulaire, signaux de carbone et d'énergie de
réseau, charges de traitement-de-flux, benchmarks de participation-de-dispositifs de
federated-learning, testbeds de systèmes de réalité-étendue, et traces de réseau-satellite
d'orbite-terrestre-basse :
Suites de référence canoniques
Le registre dans default_reference_suites() enregistre les suites d'instances publiées
canoniques auxquelles chaque famille générique de planification s'ancre : identité,
famille, nombre d'instances, pointeur de récupération, et les traqueurs de
meilleures-solutions-connues qui publient des bornes pour la suite. Les suites classiques
sont citées et liées seulement — DispatchAtlas n'empaquette ni ne redistribue jamais de
fichiers d'instances tiers.
| Suite | Famille | Instances | Téléchargement | Traqueur BKS |
|---|---|---|---|---|
fisher-thompson | job-shop | 3 | OR-Library | van-hoorn-2018, scheduleopt-benchmarks |
lawrence | job-shop | 40 | Miroir JSPLIB | van-hoorn-2018, scheduleopt-benchmarks |
adams-balas-zawack | job-shop | 5 | Miroir JSPLIB | van-hoorn-2018, scheduleopt-benchmarks |
applegate-cook-orb | job-shop | 10 | Miroir JSPLIB | van-hoorn-2018, scheduleopt-benchmarks |
storer-wu-vaccari | job-shop | 20 | Miroir JSPLIB | van-hoorn-2018, scheduleopt-benchmarks |
yamada-nakano | job-shop | 4 | Miroir JSPLIB | van-hoorn-2018, scheduleopt-benchmarks |
taillard-jsp | job-shop | 80 | Miroir JSPLIB | van-hoorn-2018, scheduleopt-benchmarks |
demirkol-dmu | job-shop | 80 | Miroir JSPLIB | scheduleopt-benchmarks |
brandimarte-mk | job-shop (flexible) | 15 | Miroir SchedulingLab | scheduleopt-benchmarks |
hurink-fjsp | job-shop (flexible) | 198 | Miroir SchedulingLab | scheduleopt-benchmarks |
dauzere-peres-paulli | job-shop (flexible) | 18 | Miroir SchedulingLab | scheduleopt-benchmarks |
taillard-pfsp | flow-shop | 120 | OR-Library | zenodo-pfsp-bks-2021 |
vrf-pfsp | flow-shop | 480 | Site du groupe SOA | zenodo-pfsp-bks-2021 |
sdst-taillard-ruiz | flow-shop de setup | 480 | Site du groupe SOA | les meilleures solutions sont livrées avec les instances |
cicirello-wt-sds | planification de machines | 120 | Harvard Dataverse | cicirello-wtsds-benchmark |
or-library-smtwt | planification de machines | 375 | OR-Library | crauwels-potts-vanwassenhove-1998 |
vallada-ruiz-upmsp | planification de machines | 1640 (rapporté) | Site du groupe SOA | — |
psplib | rcpsp | 2040 | Site PSPLIB | psplib-1997 |
mmlib | rcpsp | 4320 (rapporté) | Page d'accueil OR&S | solutionsupdate-ugent-rcpsp |
rg300 | rcpsp | 480 | Page d'accueil OR&S | solutionsupdate-ugent-rcpsp |
Les suites avec un parseur embarqué (texte job-shop standard, matrices flow-shop de
Taillard, job-shop flexible .fjs, JSON WfFormat de WfCommons) sont ingérées avec
load_reference_suite(suite_id, instances_root=...) depuis des fichiers que l'opérateur
télécharge et place sous un arbre resources/ local. L'ingestion s'exécute entièrement
hors-ligne, réutilise les mêmes validation, caractérisation, hachage, et enveloppe de
provenance que les générateurs synthétiques, et estampille chaque problème avec ses
suite_id et upstream_instance_id. Les suites de registre-seulement sont enregistrées
avec leurs citations et leurs pointeurs de récupération sans parseur embarqué.
Registres de meilleures-solutions-connues
Les valeurs meilleures-connues par-instance ne sont jamais livrées avec DispatchAtlas.
L'opérateur les ingère comme des fichiers JSON sous un répertoire privé
resources/benchmarks/bks/, un fichier par suite, chacun portant schema_version, le
suite_id, le source_id du traqueur, la date de récupération, et les entrées de valeur
(identifiant d'instance, objectif, valeur, genre optimum-ou-borne-supérieure, borne
inférieure optionnelle). load_best_known_registry valide chaque fichier contre les
suites de référence et la matrice de citation et échoue en position fermée sur des suites
inconnues, des traqueurs inconnus, des entrées dupliquées, ou des bornes incohérentes.
Sans registre ingéré, les métriques de déviation-relative sont simplement indisponibles —
elles ne sont jamais partiellement calculées, et aucune valeur meilleure-connue
n'apparaît sur aucune surface publique.
Divergences de calibration
Les familles génériques synthétiques sont ancrées aux suites canoniques sans prétendre reproduire leurs schémas de génération. Les divergences connues sont documentées plutôt que cachées :
| Famille | Convention publiée | Convention synthétique |
|---|---|---|
| flow-shop de setup | setups SDST-Taillard à 10/50/100/125 % du temps de traitement | trois familles de setup, coût = famille + 1 |
| planification de machines (R||Cmax) | classes de durée U[1,100] et variantes de machines-corrélées | facteurs de vitesse par-paire 0,5–2,0 |
Les comparaisons contre les conventions publiées passent par les instances canoniques ingérées, pas par les familles synthétiques.
Caractérisation
Chaque problème matérialisé reçoit des descripteurs normalisés pour :
- densité d'opportunité
- parcimonie de compatibilité
- contention et surcharge
- profondeur de dépendance
- pression de communication
- intensité de setup
- biais de charge et hétérogénéité
- conflit d'objectif
- incertitude et dynamisme
- sensibilité du solveur
Pont de distribution-distance
Chaque profil de grade de preuve de campagne-complète déclare un pont de distribution-distance : son
statut (synthetic, calibrated-synthetic, trace-backed, ou externally-sourced), sa
preuve de calibration, son scénario de domaine, sa couverture de transfert et de
disruption, et son risque de distribution-distance résiduel. La promotion au grade de preuve de
campagne-complète échoue en position fermée à moins que les couvertures de transfert et de
disruption ne soient déclarées, et un profil calibrated-synthetic doit nommer la référence
trace-backed contre laquelle il calibre. Les familles calibrated-synthetic nomment
explicitement leur référence de trace ; les suites canoniques ingérées portent un pont
externally-sourced, et l'adaptateur WfCommons est la première source d'instances
trace-backed analysée-en-externe, donnant à distribution_distance_score une véritable branche de
référence trace-backed.
La métrique de calibration nommée rapporte la distance 1-Wasserstein
(déplaceur-de-terre) par-caractéristique entre les distributions de caractéristiques de
caractérisation d'un profil calibrated-synthetic et celles de ses instances de référence
trace-backed. Les distances par-caractéristique sont agrégées en une seule note de
distribution-distance ; une note au-dessus du seuil de divergence-maximale (par défaut 0.25)
signifie que le profil a dérivé trop loin de sa référence et échoue à la calibration. La
métrique est reproductible depuis les instances matérialisées et la trace de référence
nommée.
from dispatchatlas.bench import (
build_smoke_catalog,
metrics_from_instance_set,
distribution_distance_score,
)
catalogs = {c.config.profile_id: c for c in build_smoke_catalog()}
synthetic = metrics_from_instance_set(catalogs["cloud-edge-capacity"])
reference = metrics_from_instance_set(catalogs["workflow-dag"])
score = distribution_distance_score(
synthetic, reference, reference_trace_id="google-cluster-data"
)Stratification et sélection de sous-ensemble
difficulty_score agrège les descripteurs de contention, surcharge,
profondeur-de-dépendance, et sensibilité-du-solveur en une note de difficulté normalisée,
et stratify_instances répartit les instances matérialisées dans des strates de difficulté
basse, moyenne, et haute. select_benchmark_subset choisit un sous-ensemble déterministe
filtré par famille, classe de profil, et strate de difficulté, ordonné par identifiant de
problème de sorte que la sélection est reproductible.
Catalogue de test
from dispatchatlas.bench import build_smoke_catalog, smoke_benchmark_provider
catalogs = build_smoke_catalog(root_seed=20260527)
provider = smoke_benchmark_provider(root_seed=20260527)
first_problem = provider.get_problem(provider.list_problem_ids()[0])Le catalogue de test empaqueté inclut les deux familles de distributed-computing (cloud/edge de tâche-indépendante et workflow DAG) aux côtés des quatorze familles génériques de planification (planification de machines, job-shop, job-shop flexible, flow-shop de permutation, flow-shop de setup dépendant-de-séquence, RCPSP, open-shop, flow-shop hybride, flow-shop de permutation distribué, flow-shop sans-attente, flow-shop avec-blocage, flow-shop d'assemblage distribué, flow-shop de permutation multi-objectif, et RCPSP/max) comme pairs co-égaux. Chaque instance est déterministe depuis la graine racine et utilise des métadonnées de générateur adossées-à-des-citations tout en restant étiquetée comme matériel de développement de test.
Catalogues complets candidats
Les catalogues de campagne-complète candidats utilisent le même chemin de matérialisation avec des nombres de problème configurés plus grands et des étiquettes de preuve plus strictes :
from dispatchatlas.bench import build_full_catalog, full_benchmark_provider
catalogs = build_full_catalog(root_seed=2026052713, problem_count_per_profile=30)
provider = full_benchmark_provider(
root_seed=2026052713,
problem_count_per_profile=30,
)Ces catalogues de grade de preuve de campagne-complète sont adossés-à-des-citations, caractérisés, liés-par-hachage, et toujours marqués comme preuve de calibration jusqu'à ce que les gates de campagne, de divulgation, et de publication promeuvent des affirmations spécifiques.