Skip to content

Add more profiler counters, and a system of performance warnings driven by them - #9344

Open
abadams wants to merge 2 commits into
mainfrom
abadams/profiler_warnings
Open

Add more profiler counters, and a system of performance warnings driven by them#9344
abadams wants to merge 2 commits into
mainfrom
abadams/profiler_warnings

Conversation

@abadams

@abadams abadams commented Aug 14, 2026

Copy link
Copy Markdown
Member

LLMs scheduling Halide code need more explicit guidance on things that might be wrong with the schedule. We've found this set of warnings to be helpful to them. Example output:

--------------------------------------------------------------------------------------------------------
camera_pipe
 total time: 3.010486 ms  samples: 4  runs: 5 (2 timed)  time per run: 1.505243 ms
 average threads used: 29.500000  parallel loops: 1  parallel tasks: 60
 heap allocations: 1500  peak heap usage: 6582K
  name                   │ time     percent │ active│  parallel   │ heap │ peak │ avg  │recompute│notes│
                         │                  │threads│ loops│ tasks│allocs│  mem │  mem │  ratio  │     │
  thread idle            │   0.00ms ( 0.0%) │  0.00 │      │      │      │      │      │         │     │
  malloc                 │   0.00ms ( 0.0%) │       │      │      │      │      │      │         │     │
  free                   │   0.00ms ( 0.0%) │       │      │      │      │      │      │         │     │
  curve                  │   0.00ms ( 0.0%) │       │      │      │      │ 1024 │      │    1.00 │     │
  f26                    │   0.00ms ( 0.0%) │       │      │      │      │   24 │      │    1.00 │     │
  sharpen_strength_x32   │   0.00ms ( 0.0%) │       │      │      │      │    1 │      │    1.00 │     │
  processed              │   0.83ms (55.6%) │ 39.33 │    1 │   60 │      │      │      │    1.00 │1    │
  ├f13                   │   (allocation)   │       │      │      │   60 │  602K│   11K│         │     │
  ├f1                    │   0.00ms ( 0.0%) │       │      │      │   60 │ 1269K│   22K│    1.27 │     │
  ├deinterleaved         │   0.00ms ( 0.0%) │       │      │      │   60 │ 2410K│   43K│    1.30 │     │
  ├f7                    │   0.00ms ( 0.0%) │       │      │      │   60 │  602K│   11K│    0.00 │     │
  │└f13                  │   0.00ms ( 0.0%) │       │      │      │      │      │      │    1.24 │     │
  └f28                   │   0.66ms (44.3%) │ 36.00 │      │      │   60 │ 1763K│   31K│    1.08 │     │
   ├output               │   0.00ms ( 0.0%) │       │      │      │      │  768 │      │    1.08 │     │
   └f27                  │   0.00ms ( 0.0%) │       │      │      │      │  768 │      │    1.08 │     │
  f7                     │   0.00ms ( 0.0%) │       │      │      │      │      │      │    1.24 │     │
 Performance warnings:
  - 8 Funcs have auto-generated names and collectively take up a significant fraction of the total
    runtime. Consider giving them explicit names by passing a string to the Func constructor. This will
    make this profile easier to read.
  - Only 4 profiling samples taken. Consider running the pipeline more times in a loop for more
    accurate results.
  1) processed's parallel loop has only 60 tasks per run, fewer than the 64 available threads; the loop
     may be too coarse-grained. Consider either splitting it more finely or finding other loops that
     can be parallel too. Each task currently takes 0.010032ms.
--------------------------------------------------------------------------------------------------------

--------------------------------------------------------------------------------------------------------
bilateral_grid
 total time: 8744.154297 ms  samples: 9038  runs: 10001 (8894 timed)  time per run: 0.983152 ms
 average threads used: 36.100132  parallel loops: 2  parallel tasks: 645
 heap allocations: 9710971  peak heap usage: 8802K
  name                   │ time     percent │ active│  parallel   │ heap │ peak │ avg  │recompute│notes│
                         │                  │threads│ loops│ tasks│allocs│  mem │  mem │  ratio  │     │
  overhead               │   0.00ms ( 0.0%) │  0.22 │      │      │      │      │      │         │     │
  thread idle            │   0.47ms (48.0%) │ 25.36 │      │      │      │      │      │         │     │
  malloc                 │   0.00ms ( 0.5%) │ 42.05 │      │      │      │      │      │         │     │
  free                   │   0.00ms ( 0.8%) │ 44.74 │      │      │      │      │      │         │     │
  blurx                  │   0.20ms (20.7%) │ 41.96 │    1 │  325 │    1 │ 6022K│ 6022K│    1.03 │1,2  │
  └blurz                 │   0.00ms ( 0.9%) │ 38.36 │      │      │  325 │ 1210K│   19K│    1.01 │     │
   └histogram            │   0.00ms ( 0.5%) │ 32.01 │      │      │  325 │ 1589K│   25K│    1.00 │     │
  bilateral_grid         │   0.26ms (27.3%) │ 49.43 │    1 │  320 │      │      │      │    1.00 │3    │
  └blury                 │   0.00ms ( 0.6%) │ 45.73 │      │      │  320 │ 2372K│   37K│    2.06 │     │
 Performance warnings:
  1) blurx spawns 325 parallel tasks per parallel loop and shows poor utilization of the thread pool.
     The parallel loop may be too fine-grained. Consider splitting it into a parallel outer loop and a
     serial inner loop. Each task currently takes 0.000601ms.
  2) Stores to blurx only write an average of 32 bytes each. This is less than the machine native
     vector width. Consider using wider vectors.
  3) Stores to bilateral_grid only write an average of 32 bytes each. This is less than the machine
     native vector width. Consider using wider vectors.
--------------------------------------------------------------------------------------------------------

Still TODO is to include the warnings in the JSON version of the output, for tools that would rather ingest that.

abadams and others added 2 commits August 14, 2026 11:12
Reintroduces the per-Func warnings system (stripped when the profiler was
merged in smaller pieces) for the rules that need no counters beyond those
already tracked in main:

  - allocs_in_parallel_loop
  - poor_thread_utilization_{many_loops,fine_tasks}
  - too_few_parallel_tasks
  - not_parallelized
  - high_recompute (basic message)
  - approximated_counters
  - device_bouncing

plus the pipeline-wide heuristics (too few samples, too many anonymous
Funcs, expensive frees). Each Func's row gains a "notes" cell listing the
numbers of the warnings that apply; the messages print after the table.

The rules run against a per-canonical rollup (canon_fs/canon_cs) that sums
each Func's instances. The approximated flag is read from the uint32
counters_approximated bitmask rather than the old single-bit flags byte.

Vectorization warnings and the recompute-locality warning depend on
counters not yet restored, and follow in later commits.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Adds eight per-Func counters classifying the loads and stores done while
computing each Func, by index expression: scalar (scalar index), vector
(unit-stride ramp), or gather/scatter (anything else), plus total bytes
loaded/stored. They're counted in Profiling.cpp's visit(Load)/visit(Store),
threaded through halide_profiler_update_counters, stored on
halide_profiler_func_stats, and dumped to the JSON report.

These drive five reinstated vectorization warnings:
  - no_vector_ops
  - more_gathers_than_vector_loads
  - more_scatters_than_vector_stores
  - many_scalar_stores
  - narrow_vector_stores (uses the pipeline's native_vector_bytes)

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant