Pith. sign in

REVIEW 2 major objections 6 minor 35 references

Parallel Cascaded Recursive Filtering on Multi-Core CPUs and GPUs

T0 review · 2 major / 6 minor · reviewed 2026-07-30 · grok-4.5

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗

Pith's one-line read Cascaded recursive filters can run at multi-gigasample rates on multi-core CPUs and GPUs once inter-group state is deferred by superposition and divide-and-conquer cyclic reduction.

desk verdict Solid Part-II systems paper: real multi-core/GPU IIR numbers, clean state fix, and a cost model that explains more than it strictly predicts. read the letter →

arxiv 2607.23763 v1 pith:UC3J7KFA submitted 2026-07-26 eess.SP cs.DC

Haotian Zhai , Bernd-Peter Paris This is my paper
classification eess.SPcs.DC
keywords IIRcascadedsecond-ordersectionsmulti-blockfilteringcyclicreductiondecoupledlookbackmulti-coreCPUGPUlatencyhiding
verification ladder T0 review T1 audit T2 compute T3 formal

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The reading

Recursive (IIR) filters are efficient but sequential: each sample depends on prior outputs, so they resist parallel hardware. This paper takes a block-matrix reformulation of cascaded biquad filters and scales it beyond a single SIMD core. The obstacle is that each signal block group's terminal outputs are the next group's initial conditions, which would serialize work across cores or GPU thread blocks. The authors break that chain by linearity: each group first computes a zero-state response in parallel, then applies a homogeneous correction when the true state arrives; a divide-and-conquer cyclic reduction exposes both terminal blocks early so state can propagate asynchronously. For real-time streaming they pipeline cascade sections across CPU cores with a wavefront TBB flow graph, preserving FIFO order at about 2.4 GS/s for a 16th-order filter on six performance cores. For batched work a single GPU kernel keeps each group in registers through the whole cascade and resolves state with decoupled lookback, guided by a simple communication cost model. Best kernels reach 38.2 GS/s (85% of an RTX 3060 memory-bandwidth roof), beat the strongest published parallel-recurrence baseline at every order, and stay numerically valid at order 16 where the direct-form baseline fails.

What carries the argument

Inter-group state propagation by superposition (zero-state local carry plus homogeneous global-carry correction), paired with divide-and-conquer cyclic reduction that publishes both terminal blocks before back substitution so asynchronous lookback or wavefront handoff can proceed.

What would settle it

On the reported GPUs, check whether the cascade kernels still exceed the published parallel linear-recurrence baseline at every filter order, stay finite and accurate at order 16, and whether the unfitted cost model still ranks PH, STCR, and DTCR configurations as measured when L, N, and device generation change.

Watch

Extended reading notes

Core claim

Inter-group state dependency in multi-block cascaded biquad filtering is not an inherent serial bottleneck: by superposition each group splits into an immediately computable zero-state response plus a homogeneous correction, and a divide-and-conquer form of cyclic reduction exposes both terminal blocks before back substitution, so groups can run concurrently on multi-core CPUs and GPUs while remaining exact and numerically stable through order 16.

Load-bearing premise

The zero-state-plus-correction split and the communication cost model (memory roof, barrier price, hiding floor) are assumed to keep state resolution cheap enough, and rankings predictable without fitted parameters, that parallel group execution actually wins on real hardware.

Editorial extensions

If this is right

  • Real-time software radio and audio chains can run high-order cascaded IIR filters at multi-GS/s on a handful of performance cores while keeping FIFO order.
  • Batched offline filtering can approach the device memory-bandwidth roof with a single register-resident cascade kernel instead of multi-kernel stage pipelines.
  • Cascaded second-order form remains usable on GPUs at orders where direct-form parallel recurrence becomes numerically invalid.
  • Configuration tuning for these kernels collapses to two parameters (L and N) once the memory roof, barrier price, and hiding floor are known for the device.
  • The same state-propagation algebra applies to either architecture; only the treatment of the dependency (wavefront vs lookback) flips with the deployment scenario.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

  • Persistent-kernel or streaming GPU variants could close the latency gap between the batched lookback design and the CPU wavefront, making the same algebra serve live receive chains on GPUs.
  • If barrier price continues to fall on newer GPUs, barrier-tolerant configurations (larger L, DTCR) should keep displacing pure shuffle-only layouts as the default high-throughput choice.
  • Time-varying or adaptive coefficients would stress the precomputed carry matrices and the cost model’s fixed-overhead term; measuring that stress is a direct next experiment the paper flags but does not run.
Share X Bluesky LinkedIn Reddit HN

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, and a circularity audit.

Referee Report

2 major / 6 minor

Summary. This paper (Part II of a two-part series) extends the multi-block filtering framework of Part I — which recast cascaded biquad IIR filtering as a block-tridiagonal linear system solved by PH factorization or cyclic reduction — to multi-core CPUs and GPUs. The key obstacle is the inter-group state dependency: each signal block group's terminal outputs are the next group's initial conditions. The authors resolve it by superposition (zero-state response computable immediately, homogeneous correction applied when state arrives) and by a divide-and-conquer form of cyclic reduction that exposes both terminal blocks before back substitution. Two implementations are given: (i) a real-time streaming CPU version using a TBB flow-graph wavefront pipeline across cascade sections, achieving 3.95x scaling on six Meteor Lake P-cores (~2.4 GS/s for a 16th-order filter); and (ii) a batched single-kernel GPU version carrying each group through the entire cascade in registers with a decoupled-lookback state protocol, reaching 38.2 GS/s for a single biquad on an RTX 3060 (85% of the memory-bandwidth roof). A communication-based cost model (Eq. 27: memory roof + fixed per-group overhead + barrier price + latency-hiding floor) is used to reduce tuning to the parameters L and N and to rationalize rankings across two GPU generations. Against the published PLR recurrence engine, the cascade kernels win at every order and remain numerically valid at order 16, where direct-form PLR diverges.

Significance. If the results hold, this is a strong contribution: it demonstrates that cascaded second-order recursive filtering — conventionally treated as inherently sequential — can be driven to 85% of a consumer GPU's memory-bandwidth roof and to ~4x scaling on a heterogeneous CPU's performance cores, while remaining numerically valid at order 16 where the direct-form state of the art diverges. The manuscript ships several properties referees should credit explicitly: an independent published baseline (PLR) transplanted unchanged into the same harness with an order-2 anchor where both realizations compute the same recurrence; accuracy gates against a float64 reference at every timed cell; careful measurement hygiene (warm-up, keep-alive clocks, L2-defeating buffer rotation, 20th-percentile-of-batches statistics with ±3% cross-session reproducibility); quantitatively falsifiable model predictions that are checked rather than asserted (e.g., PLR's predicted order-8/order-4 ratio of 0.57 vs. measured 0.573; the PH–STCR coincidence inside the noise band; the balance-point boundary of the free-operations claim located on the GTX 1070 at order 16); and a released open-source CUDA library with raw

major comments (2)
  1. [§IV-C, barrier term after Eq. (27)] The claim that a cross-warp barrier 'stalls every warp of the TB, and warp switching cannot hide it, because the waiting warps are the ones that would provide the hiding' is in tension with the residency data in Table II, which shows 5–23 resident TBs per SM. With multiple resident TBs, warps of other TBs remain eligible to issue during one TB's barrier, so the effective barrier price β should depend on occupancy — which itself varies with N via Eq. (30). Treating β as a pure architecture constant therefore risks conflating the σ–β separation the paper relies on: part of the measured STCR–PH gap at 64×64 (Figure 10) and of the DTCR sign map (Figure 11) could be occupancy effects rather than a clean per-barrier price. This does not threaten the directly measured throughput results, and the observed rankings do match the model's signs, but the load-bearing interpretive claim ('σ is the算法's
  2. [§IV-C / §IV-F, Eq. (27)-(29)] §IV-C states that 'no term of (27) is fitted to data', and the abstract/conclusion say the model 'predicts the measured behavior across two GPU generations'. What is actually shown is that signs, floors, and ratios transfer, while the barrier price β is inferred post hoc from the same measurements it explains (the 'three to five times' factor is read off Figure 10). The W_min floor (29) similarly rests on an assumed issue rate I=4 and an ILP≈3 argument from one loop. A short independent anchor would substantially strengthen this section: e.g., a __syncthreads latency microbenchmark on both devices (in the spirit of the cited [32], [33]) to establish β's order of magnitude independently, or a brief sensitivity statement showing the predicted rankings survive a plausible range of β. Alternatively, temper the wording from 'predicts' to 'ranks/classifies' where only signs are established. As
minor comments (6)
  1. [§III-E] §III-E: the processor has six hyperthreaded P-cores. The text says threads are 'pinned to P-cores first; E-cores are used only when the thread count exceeds six', but does not state whether SMT siblings were used or excluded in the 7–10 thread configurations. Since the 8- and 10-thread curves are interpreted as E-core effects (one/two E-cores 'per cluster'), please state the exact mapping and whether hyperthreading was disabled or avoided.
  2. [§II-B/§II-C] Terminology: §II-B and §II-C refer to 'the theory paper' while the rest of the manuscript says 'Part I' [14]. Please unify.
  3. [§II-D, Eq. (15)] Eq. (15): the matrix layout of A_-^(i) is hard to parse — the 'd^(i)e0' entry floats between rows and it is unclear which entries align with which block rows. A clearer typesetting or an explicit small-N example would help.
  4. [§IV-D, Table II] Table II: register counts are given for PH/STCR with the note that DTCR 'uses about half'. Please report the ptxas-measured DTCR number explicitly, since register pressure is argued never to bind before shared memory and this claim should be checkable for all three kernels.
  5. [Figures 2 and 8] Figures 2 and 8 label groups 0, 1, 4; if intermediate groups are omitted for space, indicate the ellipsis explicitly to avoid the suggestion of a non-unit stride.
  6. [§IV-F] §IV-F defines the plateau as the mean of the 2^24 and 2^25 points, while the batch range is stated as 2^16 to 2^25; a one-line restatement near Figure 9 would make the plateau markers in Figure 13 easier to connect to the curves in Figure 9.

Circularity Check

0 steps flagged · score 0.0 of 10

No significant circularity: measured throughputs and external baselines stand independently of the companion paper and the unfitted cost model.

full rationale

This is a systems scaling paper whose load-bearing claims are empirical throughputs (2.4 GS/s multi-core; 38.2 GS/s GPU), accuracy gates, and head-to-head comparison against a transplanted external PLR baseline, all checked against device memory roofs (BW/8). The companion Part I supplies the single-group PH/CR block algebra; this paper’s new content—superposition state split, divide-and-conquer CR, wavefront TBB pipeline, decoupled lookback, and the communication cost model—is derived or implemented here and validated by measurement, not by renaming Part I results. Equation (27) is explicitly unfitted (signs/floors/ratios only); even if β or ILP accounting is incomplete, that is a model-validity concern, not Eq.X≡Eq.Y by construction or a fitted input called a prediction. Self-citation of the companion is ordinary two-part modularization, not a uniqueness theorem or ansatz smuggled in to force the central claim. No circular steps identified.

Assumptions & free parameters 3 free parameters · 5 assumptions · 2 invented entities

Core math is standard linear IIR and block tridiagonal solution theory from Part I plus classical parallel prefix/CR. Empirical claims rest on named microarchitectural budgets (bandwidth, shared memory, FMA latency, residency) treated as datasheet/microbenchmark inputs, not fitted free constants. No new physical entities. Tuning parameters L, N, grain size are engineering knobs with stated constraints, not hidden fits that define the scientific claim.

free parameters (3)
  • Grain size (CPU TBB node aggregation) = 512 groups (best multi-core point)
    Chosen to amortize ~150 ns task overhead vs per-node work; best reported at 512 groups for the 16th-order CR case. Affects achieved scaling/latency but is an implementation knob, not a fitted physical constant.
  • L×N GPU configuration among {32×32, 32×64, 32×128, 64×64} = device-dependent crowning config per order
    Discrete search under shared-memory and hiding-floor constraints; best cell is device-dependent (e.g., DTCR 64×64 on RTX 3060). Selection is empirical among four survivors, not a continuous fit disguised as theory.
  • Function size N L (e.g., L=8, N=64 on CPU) = NL=512 samples (CPU CR)
    Inherited from Part I single-core optimum; multi-core results fix this rather than re-derive it.
assumptions (5)
  • domain assumption Linear time-invariant second-order sections; superposition splits zero-state response and homogeneous state correction.
    Invoked throughout §II-F and GPU lookback; standard for fixed-coefficient IIR, not proved here.
  • domain assumption Part I block-tridiagonal multi-block formulation, PH factorization, and one-sided cyclic reduction are correct and numerically as reported.
    This paper extends those kernels; single-core 616 MS/s baseline and algebra are imported from the companion.
  • ad hoc to paper GPU steady-state time per sample ≈ t_mem + F/C + βσ + ε_hide with arithmetic term negligible when intensity is below device balance.
    §IV-C cost model assembled from roofline/BSP/latency-hiding ideas; used to predict rankings without fitting coefficients to the throughput curves.
  • domain assumption Decoupled lookback with ticket ordering and global descriptors correctly realizes the upper-level carry recurrence (25) per section.
    Extends Merrill–Garland/Maleki-style protocols (§IV-B); correctness assumed given fences/flags and predecessor monotonicity.
  • standard math Standard parallel primitive complexity: length-L recurrence needs ≥ log2 L exchange rounds; DRAM roof is 8 bytes/sample at float32 in+out.
    Cited via Hyafil–Kung-style bounds and roofline; anchors L role and t_mem.
invented entities (2)
  • Divide-and-conquer (double-parity) cyclic reduction exposing both terminal blocks before back-substitution independent evidence
    purpose: Enable publishing full group terminal state for asynchronous inter-group propagation on GPUs; DTCR splits parities across two thread groups.
    Algorithmic variant of classical CR, specialized to the paper’s async state requirement; not a new physical object.
  • Communication cost model with explicit barrier price β and hiding floor W_min for multi-block IIR configs
    purpose: Reduce GPU tuning to L,N and explain PH/STCR/DTCR and Pascal vs Ampere differences.
    Modeling framework internal to the paper; validated by qualitative agreement with measurements, not an external entity.

how reviews work

0 comments
Cite this review

Pith. "Pith review of Parallel Cascaded Recursive Filtering on Multi-Core CPUs and GPUs." pith.science (2026). https://pith.science/paper/UC3J7KFA

@misc{pith2026260723763,
  author       = {Pith},
  title        = {Pith review of: Parallel Cascaded Recursive Filtering on Multi-Core CPUs and GPUs},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/UC3J7KFA}},
  note         = {Machine review of arXiv:2607.23763}
}
read the original abstract

The companion of this paper reformulated cascaded second-order (biquad) recursive filtering as a block-tridiagonal linear system and developed two parallel solution algorithms, PH factorization and cyclic reduction, reaching over 600 Megasamples per second on a single SIMD core. This paper scales that framework to multi-core CPUs and GPUs, where a new obstacle appears: the terminal outputs of each signal block group are the initial conditions of the next, so naively distributed groups serialize. The dependency is resolved by superposition -- each group's output splits into a zero-state response, computable immediately, and a homogeneous correction applied when the state arrives -- and by a divide-and-conquer form of cyclic reduction that exposes both terminal blocks before back substitution, as asynchronous state propagation requires. Two implementations pair the two dominant deployment scenarios with opposite treatments of the dependency. For real-time streaming, a wavefront pipeline realized with TBB flow graphs parallelizes across cascade sections, preserves first-in-first-out order, and achieves 3.95x scaling on six performance cores, about 2.4 Gigasamples per second for a 16th-order filter. For batched processing, a single-kernel GPU implementation carries each group through the entire cascade in registers and parallelizes across groups with a decoupled look-back protocol; a communication-based cost model, comprising a memory roof, a barrier price, and a latency-hiding floor, reduces tuning to two parameters and predicts the measured behavior across two GPU generations. The best kernels reach 38.2 Gigasamples per second for a single second-order section on an RTX~3060, 85% of the memory-bandwidth roof, exceed the strongest published parallel recurrence baseline at every filter order, and remain numerically valid at order 16, where the direct-form baseline fails.

Figures

Figures reproduced from arXiv: 2607.23763 by the authors.

Figure 1
Figure 1. Sklansky construction [24] for the matrix scan (13) with L = 8. The initial state y−1 of the group enters the network at ye[0]. the homogeneous solution (11) follow the particular solution directly. Under parallel group execution, however, every group other than the first obtains y−1 from the recursive doubling of its predecessor: later groups cannot complete their homogeneous solution until the terminal states of a… view at source ↗
Figure 4
Figure 4. Node-level execution timeline of a 16th-order IIR filter on 6 Meteor [PITH_FULL_IMAGE:figures/full_fig_p006_4.png] view at source ↗
Figure 3
Figure 3. TBB flow graph for a 16th-order cascaded IIR filter. Each node has [PITH_FULL_IMAGE:figures/full_fig_p006_3.png] view at source ↗
Figures from the paper (8 more)
Figure 5
Figure 5. Figure 5: Execution timeline with 8 threads (6 P-cores + 2 E-cores). The slower [PITH_FULL_IMAGE:figures/full_fig_p007_5.png]
Figure 6
Figure 6. Figure 6: Normalized multi-core throughput of the 16th-order CR-based IIR filter [PITH_FULL_IMAGE:figures/full_fig_p007_6.png]
Figure 7
Figure 7. Figure 7: Memory-access pattern at group entry and exit ( [PITH_FULL_IMAGE:figures/full_fig_p008_7.png]
Figure 8
Figure 8. Figure 8: Decoupled lookback execution of the same cascade as Figure 2; one [PITH_FULL_IMAGE:figures/full_fig_p009_8.png]
Figure 9
Figure 9. Figure 9: PH throughput across the four L×N configurations, against each device’s memory roof (28) (dashed). carry footprint grows with the order: block sizes must halve per order doubling to stay ahead of the register budget, and at order 16 no spill-free configuration exists o…
Figure 11
Figure 11. Figure 11: DTCR against PH at the plateau, per order and [PITH_FULL_IMAGE:figures/full_fig_p012_11.png]
Figure 12
Figure 12. Figure 12: The same map at the smallest batch (2 16): with too few groups resident to hide latency, DTCR’s doubled warps win almost unconditionally— every cell on the RTX 3060, and the losses on the GTX 1070 confined to the 32×32 column and order 16. PH 32×64 at 21.1 GS/s on the…
Figure 13
Figure 13. Figure 13: The four algorithms at their best configuration per order (marker: [PITH_FULL_IMAGE:figures/full_fig_p013_13.png]

Discussion (0). Sign in to comment.

Reference graph

Works this paper leans on

35 extracted references · 2 linked inside Pith

  1. [32]

    Dissecting the NVidia Turing T4 GPU via microbenchmarking,

    Z. Jia, M. Maggioni, J. Smith, and D. P. Scarpazza, “Dissecting the NVidia Turing T4 GPU via microbenchmarking,” arXiv:1903.07486, 2019

    arXiv 1903

  2. [33]

    Demysti- fying the Nvidia Ampere architecture through microbenchmarking and instruction-level analysis,

    H. Abdelkhalik, Y . Arafa, N. Santhi, and A.-H. A. Badawy, “Demysti- fying the Nvidia Ampere architecture through microbenchmarking and instruction-level analysis,” inProc. IEEE High Performance Extreme Computing Conf. (HPEC), 2022

    2022

  3. [1]

    Advanced methods for I/Q imbalance compensation in communication receivers,

    M. Valkama, M. Renfors, and V . Koivunen, “Advanced methods for I/Q imbalance compensation in communication receivers,”IEEE Transactions on Signal Processing, vol. 49, no. 10, pp. 2335–2344, 2001

    2001

  4. [2]

    Multi-channel IIR filtering of audio signals using a GPU,

    J. A. Belloch, B. Bank, L. Savioja, A. Gonzalez, and V . V ¨alim¨aki, “Multi-channel IIR filtering of audio signals using a GPU,” in2014 IEEE International Conference on Acoustics, Speech and Signal Processing (ICASSP), 2014, pp. 6692–6696

    2014

  5. [3]

    GPU-efficient recursive filtering and summed-area tables,

    D. Nehab, A. Maximo, R. S. Lima, and H. Hoppe, “GPU-efficient recursive filtering and summed-area tables,”ACM Trans. Graph., vol. 30, no. 6, p. 1–12, Dec. 2011

    2011

  6. [4]

    An exploration on competent video processing architectures,

    P. R. P. Tammana and B. Penumutchi, “An exploration on competent video processing architectures,” in2023 International Conference for Advancement in Technology (ICONAT), 2023, pp. 1–6

    2023

  7. [5]

    Fast fourier transform method of computing difference equations and simulating filters,

    H. Helms, “Fast fourier transform method of computing difference equations and simulating filters,”IEEE Transactions on Audio and Electroacoustics, vol. 15, no. 2, pp. 85–90, 1967

    1967

  8. [6]

    Digital filtering via block recursion,

    H. V oelcker and E. Hartquist, “Digital filtering via block recursion,” IEEE Transactions on Audio and Electroacoustics, vol. 18, no. 2, pp. 169–176, 1970

    1970

Show all 35 references
  1. [7]

    Block implementation of digital filters,

    C. Burrus, “Block implementation of digital filters,”IEEE Transactions on Circuit Theory, vol. 18, no. 6, pp. 697–701, 1971

    1971

  2. [8]

    Block realization of digital filters,

    ——, “Block realization of digital filters,”IEEE Transactions on Audio and Electroacoustics, vol. 20, no. 4, pp. 230–235, 1972. 14

    1972

  3. [9]

    Multiprocessor implementation of digital filtering algorithms using a parallel block processing method,

    W. Sung, S. Mitra, and B. Jeren, “Multiprocessor implementation of digital filtering algorithms using a parallel block processing method,” IEEE Transactions on Parallel and Distributed Systems, vol. 3, no. 1, pp. 110–120, 1992

    1992

  4. [10]

    Parallelization of IIR filters using SIMD extensions,

    R. Kutil, “Parallelization of IIR filters using SIMD extensions,” in2008 15th International Conference on Systems, Signals and Image Processing, 2008, pp. 65–68

    2008

  5. [11]

    SIMD processor based implementation of recursive filtering equations,

    J. Ahn, H. Chang, J. Cho, and W. Sung, “SIMD processor based implementation of recursive filtering equations,” in2009 IEEE Workshop on Signal Processing Systems, 2009, pp. 087–092

    2009

  6. [12]

    Multi-core and SIMD architecture based implementation of recursive digital filtering algorithms,

    D.-h. Lee and W. Sung, “Multi-core and SIMD architecture based implementation of recursive digital filtering algorithms,” in2010 IEEE International Conference on Acoustics, Speech and Signal Processing, 2010, pp. 1550–1553

    2010

  7. [13]

    Accurate and efficient implementations of recursive filtering based on SIMD and cascaded form,

    H. Zhai and B.-P. Paris, “Accurate and efficient implementations of recursive filtering based on SIMD and cascaded form,” in2024 IEEE 14th Annual Computing and Communication Workshop and Conference (CCWC), 2024, pp. 0001–0007

    2024

  8. [14]

    Fast cascaded recursive filtering via a block-matrix reformulation,

    ——, “Fast cascaded recursive filtering via a block-matrix reformulation,”

  9. [15]

    SciPy 1.0: Fundamental algorithms for scientific computing in Python,

    P. Virtanenet al., “SciPy 1.0: Fundamental algorithms for scientific computing in Python,”Nature Methods, vol. 17, no. 3, pp. 261–272, 2020

    2020

  10. [16]

    Understanding latency hiding on GPUs,

    V . V olkov, “Understanding latency hiding on GPUs,” Ph.D. dissertation, University of California, Berkeley, 2016

    2016

  11. [17]

    Programming parallel algorithms,

    G. E. Blelloch, “Programming parallel algorithms,”Commun. ACM, vol. 39, no. 3, p. 85–97, Mar. 1996

    1996

  12. [18]

    J ´aJ´a,An Introduction to Parallel Algorithms

    J. J ´aJ´a,An Introduction to Parallel Algorithms. Addison-Wesley, 1992

    1992

  13. [19]

    Single-pass parallel prefix scan with decoupled look-back,

    D. Merrill and M. Garland, “Single-pass parallel prefix scan with decoupled look-back,” NVIDIA Corporation, Tech. Rep. NVR-2016- 002, Mar. 2016

    2016

  14. [20]

    Automatic hierarchical parallelization of linear recurrences,

    S. Maleki and M. Burtscher, “Automatic hierarchical parallelization of linear recurrences,” inProceedings of the Twenty-Third International Conference on Architectural Support for Programming Languages and Operating Systems, ser. ASPLOS ’18. Williamsburg, V A, USA: ACM, 2018, ...

    2018

  15. [21]

    A. V . Oppenheim and R. W. Schafer,Discrete-time signal processing, 3rd ed. Upper Saddle River, NJ: Prentice Hall, 2010

    2010

  16. [22]

    GPU based implementation of recursive digital filtering algorithms,

    D.-h. Lee and W. Sung, “GPU based implementation of recursive digital filtering algorithms,” in2013 IEEE International Conference on Acoustics, Speech and Signal Processing, 2013, pp. 2684–2687

    2013

  17. [23]

    V oss, R

    M. V oss, R. Asenjo, and J. Reinders,Pro TBB: C++ Parallel Program- ming with Threading Building Blocks. New York: APress, 2019

    2019

  18. [24]

    Conditional-sum addition logic,

    J. Sklansky, “Conditional-sum addition logic,”IRE Trans. Electron. Comput., vol. EC-9, no. 2, pp. 226–231, 1960

    1960

  19. [25]

    Cyclic reduction – history and applications,

    W. Gander and G. H. Golub, “Cyclic reduction – history and applications,” inProceedings of the Workshop on Scientific Computing, 1997, pp. 1–15

    1997

  20. [26]

    Meteor Lake’s E-Cores: Crestmont Makes Incremental Progress,

    C. Lam, “Meteor Lake’s E-Cores: Crestmont Makes Incremental Progress,” May 2024. [Online]. Available: https://chipsandcheese.com/p/ meteor-lakes-e-cores-crestmont-makes-incremental-progress

    2024

  21. [27]

    Vector class library,

    A. Fog, “Vector class library,” https://github.com/vectorclass/version2.git, 2004

    2004

  22. [28]

    Minimizing communication in numerical linear algebra,

    G. Ballard, J. Demmel, O. Holtz, and O. Schwartz, “Minimizing communication in numerical linear algebra,”SIAM J. Matrix Anal. Appl., vol. 32, no. 3, pp. 866–901, 2011

    2011

  23. [29]

    A bridging model for parallel computation,

    L. G. Valiant, “A bridging model for parallel computation,”Commun. ACM, vol. 33, no. 8, pp. 103–111, 1990

    1990

  24. [30]

    Roofline: An insightful visual performance model for multicore architectures,

    S. Williams, A. Waterman, and D. Patterson, “Roofline: An insightful visual performance model for multicore architectures,”Commun. ACM, vol. 52, no. 4, pp. 65–76, 2009

    2009

  25. [31]

    An analytical model for a GPU architecture with memory-level and thread-level parallelism awareness,

    S. Hong and H. Kim, “An analytical model for a GPU architecture with memory-level and thread-level parallelism awareness,” inProc. ISCA, 2009

    2009

  26. [34]

    The complexity of parallel evaluation of linear recurrences,

    L. Hyafil and H. T. Kung, “The complexity of parallel evaluation of linear recurrences,”J. ACM, vol. 24, no. 3, pp. 513–521, 1977

    1977

  27. [2026]

    Available: https://arxiv.org/abs/2607.14054

    [Online]. Available: https://arxiv.org/abs/2607.14054

    arXiv

Pith tools

Reviewed July 30, 2026 · model on record in the stance chip above.