DEV Community

서희준
서희준

Posted on

Can integer arithmetic make wave calculations 10 faster? CPU benchmark results

I recently came across a research paper titled "Paper VIII — Dual-Layer Topological Neuromorphic Architecture."

One of its ideas caught my attention: instead of repeatedly performing trigonometric calculations, certain complex wave operations can be approximated using integer phase addition and precomputed lookup tables (LUTs).

I was curious how much of a difference this could make in practice, so I implemented the approach and ran CPU benchmarks.

Here's what I found.

1. How much faster is it?

I compared several approaches using 10 million unit-magnitude complex wave calculations.

CPU benchmark results:

  • Conventional complex multiplication (four trigonometric evaluations): 330.40 ms
  • Optimized phase-addition approach: 195.61 ms
  • Integer phase addition + LUT (1,024 entries): 36.95 ms
  • Integer phase addition + LUT (2,048 entries): 33.26 ms

The fastest LUT implementation was approximately 9.9× faster than the conventional baseline, or 5.9× faster than the optimized phase-addition baseline in this test.

The key idea isn't simply replacing multiplication with addition.

It's avoiding repeated trigonometric evaluations by representing phases as integers and retrieving precomputed results from memory.

These results come from a specific CPU benchmark, not a universal speedup for multiplication or general computation.

2. How does it actually work?

The principle is surprisingly simple.

For two unit-magnitude complex signals, multiplying them is equivalent to adding their phase angles.

Instead of working with continuous angles, we quantize them into integer positions.

For example, with 1,024 positions:

  • The phase is represented by an integer from 0 to 1023.
  • Phase addition becomes modular integer addition.
  • 1023 + 1 wraps around to 0.
  • The resulting index selects a precomputed value from a lookup table.

This allows certain wave calculations to be performed using integer arithmetic and memory lookups rather than repeated trigonometric evaluations.

Of course, there's a trade-off.

Quantizing continuous angles introduces approximation errors. Increasing the number of positions generally improves precision, but requires more lookup-table storage.

The benchmark therefore compares different computational approaches, not mathematically identical outputs with identical precision.

3. A separate experiment: image noise reduction

I also explored an image-processing experiment inspired by the PLP concepts discussed in the paper's appendix.

The visualization compares conventional filtering with two experimental approaches, showing differences in noise removal, detail preservation, and processing time.

This is a separate experiment from the phase-arithmetic benchmark.

The image filters are experimental interpretations, not faithful implementations of the original PLP equations, and they do not consistently outperform conventional methods across all metrics.

4. What do these results actually demonstrate?

The experiments suggest that integer phase representations and lookup tables can significantly reduce CPU computation time for certain restricted wave operations.

However, there are important limitations:

  • The reported speedups are from CPU measurements, not physical PIM hardware.
  • LUT-based outputs are approximate.
  • The technique does not replace arbitrary floating-point multiplication.
  • The results do not validate the paper's hardware energy, area, or broader performance claims.

The main goal was to examine which ideas could be implemented, measure their behavior, and make the results easier to understand through visualizations.

References and experimental data

Original research paper — Paper VIII (Zenodo):

https://doi.org/10.5281/zenodo.22782241

Implementation, benchmark data, source code, and visualizations (GitHub):

https://github.com/heejun1105/phase-ring-plp-benchmark

I'm particularly interested in hearing thoughts on the practical trade-offs between phase quantization, lookup-table size, approximation error, and CPU performance.

Top comments (0)