The lazy-fortran stack has an in-flight programme of ~35 issues to generate numerical kernels from symbolic definitions, emit them to four targets (CPU Fortran, OpenMP offload, OpenACC, native CUDA), and measure their distance from theoretical optimality. Tracker: lazy-fortran/fortgen#1.
Every one of those issues ends inside that stack. None of them touches code that publishes a physics number. That is the gap this issue exists to close, and it is the one that decides whether the whole programme was worth doing.
Concretely, lazy-fortran/fortnum#78 declares benchmark-orbit-proxima as its end-to-end objective -- while measuring a kernel SIMPLE does not call. That is a benchmark measuring itself.
What to decide
Which SIMPLE kernel is the first generated consumer.
Candidates, in the order I would rank them:
1. Splined field evaluation -- src/field/field_splined.f90, splined_evaluate and splined_evaluate_with_der. Straight-line, arithmetic-heavy, the hottest path in the code, and the derivative variant is exactly the shape symbolic AD produces well. libneo#408's 2.16x spline improvement is evidence this path is where time goes.
2. Canonical-coordinate transformation kernels -- the field_can_* family. Larger and with more control flow; a poorer first target.
3. RK stage evaluation -- already generated in fortnum, but SIMPLE does not consume the generated version.
Option 1 is almost certainly right, but the choice needs someone who knows where the time actually goes, not an inference from file size.
What to do
- Pick the kernel and say why.
- Write its symbolic definition in fortsym -- either natively, or from an existing Mathematica derivation if one covers it (see lazy-fortran/fortsym#59).
- Generate it, verify by readback against the symbolic source (lazy-fortran/fortnum#70), and check it against the current hand-written implementation numerically.
- Run the full instrument on it: four counts, accuracy, and end-to-end timing on the real workload.
Acceptance
Golden records unchanged. This is a production physics path; the numerical gate is the existing one and it is not negotiable.
Beyond that, the deliverable is a statement nobody in this field can currently make about their own code:
for this kernel, the arithmetic the mathematics requires is N_sym, the generated code emits N_emit, the compiler produces N_machine, the hardware delivers T, and the accuracy is X ulp against a high-precision reference.
Why this is worth a SIMPLE issue rather than a fortnum one
If the generated kernel is slower, or less accurate, or harder to maintain than the hand-written one, that is the finding, and it should surface here where the consequence lands -- not inside the toolchain that produced it.
Related
The lazy-fortran stack has an in-flight programme of ~35 issues to generate numerical kernels from symbolic definitions, emit them to four targets (CPU Fortran, OpenMP offload, OpenACC, native CUDA), and measure their distance from theoretical optimality. Tracker: lazy-fortran/fortgen#1.
Every one of those issues ends inside that stack. None of them touches code that publishes a physics number. That is the gap this issue exists to close, and it is the one that decides whether the whole programme was worth doing.
Concretely, lazy-fortran/fortnum#78 declares
benchmark-orbit-proximaas its end-to-end objective -- while measuring a kernel SIMPLE does not call. That is a benchmark measuring itself.What to decide
Which SIMPLE kernel is the first generated consumer.
Candidates, in the order I would rank them:
1. Splined field evaluation --
src/field/field_splined.f90,splined_evaluateandsplined_evaluate_with_der. Straight-line, arithmetic-heavy, the hottest path in the code, and the derivative variant is exactly the shape symbolic AD produces well. libneo#408's 2.16x spline improvement is evidence this path is where time goes.2. Canonical-coordinate transformation kernels -- the
field_can_*family. Larger and with more control flow; a poorer first target.3. RK stage evaluation -- already generated in fortnum, but SIMPLE does not consume the generated version.
Option 1 is almost certainly right, but the choice needs someone who knows where the time actually goes, not an inference from file size.
What to do
Acceptance
Golden records unchanged. This is a production physics path; the numerical gate is the existing one and it is not negotiable.
Beyond that, the deliverable is a statement nobody in this field can currently make about their own code:
Why this is worth a SIMPLE issue rather than a fortnum one
If the generated kernel is slower, or less accurate, or harder to maintain than the hand-written one, that is the finding, and it should surface here where the consequence lands -- not inside the toolchain that produced it.
Related