integer_adm: replace float sign check with integer comparison in adm_angle_flag

[GabrielBarros36]

Summary

In adm_decouple and adm_decouple_s123, the first condition of the
angle_flag computation was:

(((float)ot_dp / 4096.0) >= 0.0f)

This promotes an int64 to float and divides by a positive constant solely to
test the sign. Since dividing by a positive constant preserves sign, this is
algebraically equivalent to:

(ot_dp >= 0)

The replacement eliminates an int64→float conversion and a float division on
the hot path. The second condition (magnitude comparison) is left in float to
preserve the original rounding behavior.

Benchmarks

Measured on AWS c6a.metal (AMD EPYC 7R13, 2.65 GHz locked, turbo disabled,
performance governor, pinned to 4 cores on NUMA node 0). Workload: 1080p 48-frame
YUV video scored with default VMAF model, 7 repetitions per configuration (CV <0.15%).

Configuration	Time (s)	Δ vs baseline	Cycles	IPC
Baseline (master)	2.762	—	28.76B	3.18
This change	2.707	−2.0%	28.16B	3.24

Correctness

• 67/67 Python regression tests pass with bit-identical scores across all
  feature extractors and models
• The transformation is provably equivalent: for any integer x and positive
  constant c, sign(x / c) == sign(x)

Test plan

• CI passes (no score regressions)
• meson test in libvmaf builds and passes on x86-64

[kylophone]

I think the logic is sound, but I do not measure a 2% speedup when I test. Any hints?

[GabrielBarros36]

I think the logic is sound, but I do not measure a 2% speedup when I test. Any hints?

@kylophone This was actually a little experiment in long-running agents. I hooked Claude Code up to an Amazon EC2 bare metal instance and told it to look for opportunities to speed VMAF up, then to implement + benchmark each idea. It ran all night and tested its ideas one by one.

This was a really interesting workflow to test. There's some merit to "throwing tokens at the problem" as long as you have a measurable metric to improve and the correctness of each change is verifiable. Let me know if you'd like to talk more about this because I think it could produce significant results as long as we give the agent a solid "harness" - in this case, that'd mean a benchmarking workflow + a test suite comprehensive enough to catch any inconsistencies.

That being said, I concluded doing this with VMAF isn't feasible because 1) I lack understanding of the project itself and I don't know how comprehensive the test suite is, and 2) most of the changes Claude produced were SIMD optimizations I don't fully understand and thus don't feel comfortable proposing.

I know this change is correct, but the performance improvement is probably architecture-specific and I don't know if it'd be worth merging. The 2% number comes from the EC2 instance I let Claude spin up, but I don't even fully understand the settings it used and I don't know if it's reflective of how VA deploys VMAF in any given project.

Later in the experiment I ended up forking VMAF and I put my PRs there to avoid polluting the PRs in this repo.

Thank you for reviewing this! Let me know if there's anything here you want to follow up on, and I'd be happy to test this PR further or to close it!