Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

feat(api): explicit distributed-backend selection (MDLABackend / IGGBackend), mirroring AbstractJVPBackend

Abierto
  • ¿Algo no está bien?
#47 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
5/5
Tiempo estimado
Más de una semana
Aptitud para principiantes
35/100
Tipo de issue
Nueva funcionalidad
Claridad
Bastante claro
Estado de actividad
Tranquilo
Stack tecnológico
julia
Área
backend-api-design, distributed-systems, documentation, testing

Línea de trabajo

Start with src/operators/linearize.jl to follow the existing explicit-backend pattern, then inspect the distributed entry point in ext/MatrixFreeOperatorsMDLAExt.jl and DESIGN.md §10.4. Review the relationship with #46 and the existing distributed tests. Done means the core tags and fallback, the MDLA implementation, unloaded-backend error test, documentation distinction from KernelAbstractions devices, and the IGG integration are all covered.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

enhancement

Problem

There is no way to choose a distributed backend. prepare_distributed is exported from the core, but its only method is defined inside ext/MatrixFreeOperatorsMDLAExt.jl:

function prepare_distributed(L0::AbstractOperator, nparts::Integer; devices=nothing)

So today the backend is whatever extension happens to be loaded, selected implicitly. Two consequences:

  1. Calling it without MDLA loaded gives a bare MethodError on an exported symbol, with no hint that the fix is using MultiDeviceLinearAlgebra.
  2. It does not survive a second backend. Once the IGG halo lands (#46), two extensions would define competing methods with the same (operator, integer) signature. That is an ambiguity, and disambiguating it by keyword is worse.

Selection should be explicit and declarative, the way choosing an AD backend or a KernelAbstractions device is.

Proposal — mirror AbstractJVPBackend

We already have exactly this pattern in-repo, and it should be the model rather than inventing a second convention. src/operators/linearize.jl defines the abstract type and both concrete tags in the core, exports them, and lets the extension implement the behaviour:

abstract type AbstractJVPBackend end
struct FiniteDifferenceJVP <: AbstractJVPBackend end
struct EnzymeJVP           <: AbstractJVPBackend end   # core-defined; Enzyme ext implements

Its docstring already states the principle we want here — "Selecting the backend is deliberately explicit rather than ambient: the backends differ in ... which operations they support, so which one you get must not depend on load order." That reasoning applies verbatim to MDLA vs IGG.

This is also the ADTypes/DifferentiationInterface model the request pointed at: AutoEnzyme() lives in ADTypes, not in Enzyme, so you can name and dispatch on a backend you have not loaded.

Sketch:

# core
abstract type AbstractDistributedBackend end

struct MDLABackend <: AbstractDistributedBackend    # single-node multi-GPU, slab decomposition
    nparts::Int
    devices::Union{Nothing,Vector{Int}}
end

struct IGGBackend <: AbstractDistributedBackend     # multi-node MPI, 3D blocking
    dims::NTuple{3,Int}
    periodic::NTuple{3,Bool}
end

prepare_distributed(L, backend::AbstractDistributedBackend; kwargs...)

with a core fallback whose whole job is a good error:

prepare_distributed(::AbstractOperator, b::AbstractDistributedBackend; kwargs...) =
    error("no distributed method for $(nameof(typeof(b))) — load the backing package (e.g. `using MultiDeviceLinearAlgebra`)")

Extensions then implement prepare_distributed(L, ::MDLABackend) / (L, ::IGGBackend) against the existing _dist_scatter! / _dist_reduce! seam. Nothing about the seam itself changes.

Constraints

  • Tags must be config-only and free of backend types. An MDLABackend holding a PartitionSpec, or an IGGBackend holding an MPI communicator, would drag the dependency into the core and defeat the point. Ints, tuples, symbols only.
  • This is orthogonal to the KernelAbstractions device, and the docs must say so explicitly — the analogy that motivates the API is also the easiest thing for a reader to conflate. The KA backend answers which device runs the kernel; this answers how partitions talk to each other. A real run picks both (CUDABackend() device + IGGBackend() distribution), and CartesianGrid's Dev parameter is the former, not the latter.
  • Construction-time only. Like EnzymeJVP, the tag selects behaviour when the prepared operator is built and must not leak into the operator tree or the mul! hot path.
  • Does not change prepare's contract — still stateful and single-threaded, one per concurrent solve.

Decisions to make while implementing

  • Whether the existing prepare_distributed(L, nparts::Integer; devices) stays as a deprecated shim forwarding to MDLABackend(nparts; devices), or goes away outright. It is unregistered and pre-v1, so removing it is defensible; a shim is cheap.
  • Whether AbstractJVPBackend and AbstractDistributedBackend get documented together as one "explicit backend selection" concept in the docs, since they now share a rationale. Recommend yes — one section, two axes.
  • Whether a trivial SerialBackend() is worth having so single-rank code paths are expressible without nothing.

Done when

  • AbstractDistributedBackend + MDLABackend + IGGBackend defined and exported from core
  • prepare_distributed(L, backend; …) is the documented entry point; core fallback errors with a "load X" message
  • MDLA extension implements its tag; existing tests pass through the new entry point
  • Requesting an unloaded backend is tested for the error message, not just the throw
  • Docs state the KA-device vs distributed-backend distinction explicitly
  • #46's IGG extension implements IGGBackend against this API rather than adding another entry point

Related: #46 (IGG halo backend), DESIGN.md §10.4.

🤖 Written by Claude — Kyle pointed at the shape, I filled in the paperwork.

Lenguaje dominante
Julia
Estrellas
3
Forks
1
Merge medio
1 d 28 min
PR fusionados (30 d)
6

Preparar el entorno

Este proyecto no incluye contenedor de desarrollo, Dockerfile ni guía de contribución, así que la configuración corre por tu cuenta: empieza por su README y consulta nuestra guía para la primera contribución para los pasos generales.

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de RallypointOne/MatrixFreeOperators.jl

Todos los issues de RallypointOne/MatrixFreeOperators.jl

Issues similares

Más issues de Julia

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.