[Performance] Performance regression in AveragePool operator

[junghyunpark2001]

Describe the issue

Description

We observed a significant performance regression in the AveragePool operator between ONNXRuntime v1.20.0 and v1.21.0. The regression affects multiple AveragePool configurations with +17% to +28% kernel slowdown.

Affected Operator

AveragePool

• Opset Version: 11, 18
• Regression: +17% to +30% kernel slowdown

regression commit :

https://github.com/microsoft/onnxruntime/pull/16752/files#diff-4cd5cf24d279e5bd52c1ee3888739b856b62be11d86e3f8271504d631b62af6c

To reproduce

python script_profiling.py averagepool_pool_11_18_average_pool_3d_valid_input 1.20.0 1.21.0

Archive.zip

Urgency

No response

Platform

Linux

OS Version

Ubuntu 24.04.3 LTS

ONNX Runtime Installation

Released Package

ONNX Runtime Version or Commit ID

1.20

ONNX Runtime API

Python

Architecture

X64

Execution Provider

Default CPU

Execution Provider Library Version

No response

Model File

No response

Is this a quantized model?

Yes

[tengli-alaska]

Hi @junghyunpark2001 @titaiwangms , I've been analyzing the regression and I believe I've identified the root cause in the changes from PR #16752.

Root cause: The std::min clamping lines added to pool_functors.h (hend, wend, dend clamping) are placed inside the hot pooling loops for the 1D, 2D, and 3D AveragePool functors. While these clamps are necessary for correctness when ceil_mode=1 (to ensure the last pooling window doesn't extend beyond input_size + pad), they make the inner loop trip count data-dependent. This likely prevents the compiler from auto-vectorizing is what i am guessing the accumulation loops, which would explain the +17% to +28% slowdown.

Proposed fix: Guard the std::min bounds clamping behind a ceil_mode check:

if (ceil_mode) {
    hend = std::min(hend, height + pads[1]);
}

When ceil_mode=0 (the default and vast majority of models), the output size computation already guarantees that pooling windows don't exceed valid bounds, so the clamping is unnecessary. This would restore the original fast path while preserving the correctness fix for ceil_mode=1.

I'd like to work on this fix and submit a PR with before/after benchmarks on x86 which would like a test from my end. Would this approach be acceptable?

[titaiwangms]

Yeah, sure. Feel free to take it

[junghyunpark2001]

Sure. That would be appreciated.

[tengli-alaska]

Submitted a PR to fix this: #27331

[titaiwangms]

@junghyunpark2001 ,
I only observed +3.66% change though, which I think it aligns to what @tengli-alaska found in the PR.

{
  "model": "/home/titaiwang/onnxruntime/profiling_avgpool/averagepool_pool_11_18_average_pool_3d_valid_input/averagepool_pool_11_18_average_pool_3d_valid_input.onnx",
  "operator": "AveragePool",
  "old_version": "1.20.0",
  "new_version": "1.21.0",
  "summary": {
    "kernel_old_ms": 0.191,
    "kernel_new_ms": 0.198,
    "kernel_change_ms": 0.007000000000000006,
    "kernel_change_pct": 3.6649214659685896,
    "total_old_ms": 0.201,
    "total_new_ms": 0.204,
    "is_regression": false
  }
}