PaperlayerView exact revision on arXiv

Source-linked AI summary

Where does a rust speedup come from? Language and algorithm effects in sliding window threat scorer

Nikolaos D. Tantaroudas, Ilias Karachalios, Andrew J. McCracken

arXiv:2610.07931v1cs.CR

TL;DR

A Python-to-Rust rewrite can change both language and algorithm, making a single speedup factor hard to interpret. This paper separates those effects in a sliding-window scorer; its results show near-quadratic versus near-linear growth in the original rewrite's Python and Rust timings.

  • Problem

    Reported Python-to-Rust speedups can combine language and algorithm changes, leaving their separate contributions unclear.

    Source: §1 · p. 1

  • Method

    The study compares naive rescans and incremental updates in Python and Rust on a shared sliding-window scorer, checking identical scores and timing bounded and burst workloads.

    Source: §1 · p. 1, §2 · p. 2

  • Results

    Power-law fits to the original rewrite's batch timings give growth exponents of 1.85 for Python and 0.88 for Rust; the burst-regime Python algorithm factor reaches 11,652 times at 50,000 events.

    Source: §4 · p. 3, §3 · p. 3

  • Takeaways & Limitations

    Performance claims for rewrites should report language-only and algorithm-only factors with input sizes, since inefficient baselines can inflate reported speedups.

    Source: §4 · pp. 3–4

    The measurements cover one workload on one processor, and energy was not measured.

    Source: §4 · p. 4

Abstract

from arXiv · show

Rewriting a hot path from Python into Rust is a common way to speed up security analytics, and large speedups are routinely reported. A rewrite usually changes the language and the algorithm at once, so a single factor can credit the language with a gain that comes from a better algorithm. We study this on a sliding window threat scorer modelled on the traffic light calculator of the SentinelSphere platform. Five implementations, three in Python and two in Rust, produce bit identical scores, confirmed by a shared checksum, and we time them from 100 to one million events in a bounded and a burst regime. The language alone contributes between about 4 and 29 times. Replacing a per event rescan of the window by an incremental update contributes more than 11,000 times in the burst regime, so the end to end factor reaches about 195,000 times when the window keeps filling and levels off near 13,000 times when it does not. A power law fit to the timings reported for the original rewrite gives growth exponents of 1.85 for Python and 0.88 for Rust, the signature of an algorithmic difference. Performance claims for security tooling should therefore report the language and algorithm contributions separately.

1 Introduction

Security analytics hot paths are often rewritten from Python in Rust, and reported speedups may combine language and algorithm changes. This study separates those contributions while holding scoring semantics fixed.

1 Introduction

  • Reported rewrite speedups can combine a language change with an algorithm change, obscuring how much each contributes.The paper notes that a factor rising with batch size is unusual for a pure language effect, which is roughly constant.Source: §1 · p. 1
  • The motivating SentinelSphere rewrite reported a 5.6-times average speedup in steady operation and 4.3–326-times factors for batches of 1,000–100,000 events.A rising factor with batch size can indicate a change in algorithmic complexity rather than a pure language effect.Source: §1 · p. 1
  • The study asks how much speedup comes from language versus algorithm, using the same scoring semantics in both languages.It presents a clean measurement and reusable harness rather than a new detector.Source: §1 · p. 1

2 Method

The method compares naive rescans and incremental updates in Python and Rust on an equivalent sliding-window threat-scoring workload. It checks score equivalence and measures performance in bounded and burst regimes.

2 Method

  • The scorer processes each event using a 300-second window, a time-decayed severity sum, five contextual factors, and a score cap of 100.The factors are event rate, temporal clusters, source-address concentration, attack-type diversity, and sustained-activity duration.Source: §2 · p. 2
  • Five implementations use naive rescans or incremental updates, and checksums verify identical capped and uncapped score sequences on identical event streams.The implementations comprise three Python versions and two Rust versions.Source: §2 · p. 2
  • In the bounded regime, inter-arrival times keep the window roughly constant; in bursts, near-simultaneous arrivals make it grow with input, while scoring-loop timings are medians of ten fast-run repetitions and fewer slow-run repetitions.Runs used two cores of an Intel Xeon at 2.8 GHz, Python 3.13, and a Rust release build with link-time optimisation.Source: §2 · p. 2

3 Results

The results separate language and algorithm contributions: language factors are comparatively stable, while the algorithm factor grows with input in the burst regime. Naive rescans scale near-quadratically there, whereas incremental versions scale near-linearly.

3 Results

  • In the burst regime, naive Python index, Python iteration, and Rust versions grow with exponents of 2.1, 2.0, and 1.9, while incremental versions grow close to linearly.Figure 1 plots median scoring time against event count on logarithmic axes, with bounded results on the left and burst results on the right.Source: §3 · p. 2, Figure 1 · p. 2
  • In the bounded regime, all implementations grow roughly linearly once the window is full, and naive versions pay a constant-multiple window cost per event.The bounded-regime Python algorithm factor rises from 115 times at 1,000 events to 551 times at 100,000 events, then levels off as the window stops growing.Source: §3 · pp. 2–3
  • 11,652 times at 50,000 events in the burst regime: the Python naive-over-incremental algorithm factor, compared with a 14–29-times incremental language factor.The language factor is Python over Rust on the same algorithm; the table decomposes the end-to-end speedup into language and algorithm factors.Source: §3 · pp. 2–3, Table 1 · p. 3
  • The end-to-end factor is the product of language and algorithm factors, and only the algorithmic component grows with input.Figure 2 tracks end-to-end, algorithm-only, and language-only factors in the burst regime; the language factor stays nearly flat while the other two grow.Source: Figure 2 · p. 3, §3 · p. 3

4 Discussion and conclusions

The reported batch scaling suggests the original rewrite’s large gains chiefly reflect an algorithmic difference, while language adds a bounded factor. The authors recommend reporting both contributions and caution that their measurements are specific to one workload and processor.

4 Discussion and conclusions

  • Power-law fits to the original rewrite’s batch timings give growth exponents of 1.85 for Python and 0.88 for Rust, contrasting near-quadratic and near-linear growth.The authors interpret this contrast as the signature of an algorithmic difference.Source: §4 · p. 3
  • Report language-only and algorithm-only factors with input sizes, since an inefficient baseline can inflate a rewrite’s headline speedup.Separating the costs requires only implementing the original algorithm in the new language or the new algorithm in the original language.Source: §4 · pp. 3–4
  • The measurements cover one workload on one processor, so the authors present them as the shape of the effect rather than constants; energy was not measured.Source: §4 · p. 4
Loading 2610.07931v1…