A team of researchers from the Jülich Supercomputing Centre, KTH Royal Institute of Technology, the University of Bonn and the University of Groningen, led by Carlos Falquez, Shiting Long, Nam Ho, Estela Suarez and Dirk Pleiter, now propose a surprising answer: use a processor simulator not just to design chips, but as a full performance engineering workbench. In a study published in Frontiers in High Performance Computing, they enhanced the widely used open-source simulator gem5 with a performance analysis framework that extends the available performance counters, tracks the temporal behaviour of running applications, and links those statistics automatically to specific code regions. The result is a set of performance profiles that can identify code regions with optimisation potential, monitoring quantities that are usually not directly accessible on real hardware.

The motivation is rooted in the sheer complexity of modern processors. Even a single processor core is a system of interacting subsystems, from the micro-architecture of the front-end pipeline, where various factors influence how efficiently functional units are utilised, to multi-level cache hierarchies and memory prefetchers whose combined behaviour of data transport is notoriously difficult to extrapolate from the behaviour of individual components. On real hardware, Performance Management Units (PMUs) can be programmed at run time to count events such as cache misses, but the set of trackable events is limited, cannot be changed once a processor design is final, and is highly vendor-specific. Even when advanced monitoring features such as Intel’s Processor Event Based Sampling, AMD’s Instruction-Based Sampling or Arm’s Statistical Profiling Extension are available, the context for a particular processor behaviour often cannot be recorded, making root cause analysis a matter of expert guesswork.

Simulators offer an alternative, but they come with a fundamental trade-off. Because cycle-accurate simulation runs many orders of magnitude slower than real hardware, in practice it is only affordable when restricting the scope to a single or a small number of processor cores. gem5, which supports several instruction set architectures including x86, Arm and RISC-V, has become a popular choice and is continuously updated to follow new architectural developments. It has already served as a co-design tool in the development of the A64FX processor and in the European Processor Initiative’s design space explorations. Yet gem5 has been notoriously difficult for computational scientists to use: it was built by and for processor architects, requires significant training, and lacks tools to correlate simulation statistics with application code. Even when an application is instrumented to restrict profiling to a region of interest, gem5’s counters are accumulated over the entire region and typically reported as a single aggregate value, hiding the multiple execution phases with very different performance characteristics that may exist within it.

The new framework tackles this with two key additions: time-binned event counters and automatic labelling of executed code regions. The execution timeline of a region of interest is partitioned into fixed-length intervals, each of duration 5000 cycles, and events such as the commit of an instruction are aggregated per bin, producing a sequence of event counts that provides much finer temporal resolution. To reduce stochastic noise in the plots, a median filter from the scipy Python package is applied, suppressing outliers while preserving sharp changes. For code region detection, the instructions of the executable are grouped according to function entry point labels parsed from the objdump tool of GNU Binutils. For each time bin, the five most frequently occurring events are determined, and a function label is associated with the bin when at least five of those instructions belong to that function. The resulting label sequence is converted into labelled time ranges that can be mapped directly onto the time-binned event counters, revealing which routines were executing during each phase.

The framework also implements algorithms to detect specific classes of performance bottlenecks. One concerns sensitivity to instruction data dependencies: in out-of-order processors, fetched instructions wait in an issue queue until their operands are available, and when an application is ported to an architecture with deeper execution pipelines, the probability of instructions waiting for data dependencies increases while pressure on the execution units decreases, causing unexpectedly low performance. The team added event counters that can differentiate between instruction classes and track both the average number of instructions waiting in the issue queue for dependencies to resolve and the average number of instructions stalled due to busy execution units. A second class concerns memory traffic and the average filling of the queue for pending requests at the memory controller, observables that are difficult or impossible to extract reliably from real hardware. A third concerns long-latency instructions, such as conditioned load instructions whose latency cannot be hidden by out-of-order execution; the simulator detects these by measuring the instruction squashing rate, that is, the rate at which speculatively executed instructions must be discarded because of misspeculation.

Three case studies demonstrate the approach across a broad range of computational science. The first is GROMACS, a very widely used molecular dynamics package, whose most expensive kernel computes non-bonded interactions. Using a recent version of GROMACS with a solvation free energy benchmark, the simulations modelled a single Arm Neoverse V2 core supporting SVE instructions, the same core used by NVIDIA in its Grace processor. The profiles showed that the main numerical kernel achieves a throughput of around 1.7 SIMD floating-point instructions per cycle, almost fully utilising the two available SVE pipelines. Crucially, the new counters revealed that for effective execution latencies of four cycles or more, the vectorised kernel becomes sensitive to data dependencies: the average number of stalled instructions drops below one, signalling a decrease in the rate of dependency resolution, while the number of instructions waiting in the issue queue for missing dependencies remains large, verifying that the front-end keeps sending instructions at sufficient rate.

The second case study concerns a kernel from the Lattice QCD solver DD-αAMG, representative of memory-bandwidth-limited stencil applications. The team investigated a recently extended version of the solver that supports solving linear equations with multiple right-hand sides, an optimisation that increases arithmetic intensity but had not delivered the expected performance improvements on real hardware. Using the A64FX processor on the Ookami system, they had identified that effective memory bandwidth varied across blocking sizes, but comprehensive information from cache and memory controllers is almost impossible to extract from real hardware. The gem5 simulations of a read-intensive inner-product kernel showed that larger blocking sizes enhance performance, mirroring real-hardware trends, but also revealed an unexpected performance drop at a blocking size of eight, where the compiler failed to vectorise the code and generated scalar load instructions instead, halving the rate of read requests.

The third case study targeted the breadth-first search algorithm implemented in the Ligra graph framework, whose irregular control flow and memory access patterns stress the branch predictor. The profiles showed poor execution unit utilisation, with an average commit rate below one instruction per cycle most of the time, and a high rate of squashed instructions. The team traced most of the branch mispredictions to the EdgeMapDense routine, where three specific lines each caused about a third of the mispredictions. By moving a conditioned load instruction outside the branch so it could be initiated earlier, a trade-off accepting some unnecessary data transfers, they benchmarked both implementations on an AWS Graviton 4 bare-metal node with Kronecker graphs of scale 21 to 24 and measured a speed-up of around five percent for all problem sizes, confirming that a simulator-detected bottleneck could be fixed on real hardware.

The authors are careful about the limitations. Single-core simulations run about five to six orders of magnitude slower than execution on real hardware, so simulating many-core architectures or full applications is likely to be prohibitively expensive, although distributed frameworks such as COSSIM may help. Optimising code for specific processors also depends on the availability of validated gem5 configurations, and no library of ready-to-use configurations exists yet; previous validation studies have reported average deviations of about ten percent for simpler Arm cores, with discrepancies of up to forty percent in some cases for complex workloads, and there is a risk of mismatches between a specific processor solution and its gem5 model that only show up under particular circumstances. Still, the benefit of the approach is that gem5 already provides a large and diverse set of statistics that can illuminate the often difficult-to-uncover interplay between observed application performance and the complex hardware on which it executes, with much freedom to add further event monitors and analysis mechanisms. The team plans to extend the list of performance issues for which automatic detection can be integrated into gem5, and to conduct further case studies exploring the benefits and disadvantages of the approach. The modified simulator has been made openly available, potentially also benefiting compiler engineers and system software developers far beyond HPC.

Subject of Research: High Performance Computing

Article Title: Processor simulation as a tool for performance engineering

Article References: Falquez, C., Long, S., Ho, N., Suarez, E., & Pleiter, D. (2025). Processor simulation as a tool for performance engineering. Frontiers in High Performance Computing, 3, Article 1669101. https://doi.org/10.3389/fhpcp.2025.1669101

Image Credits: AI Generated

DOI: 10.3389/fhpcp.2025.1669101

Keywords: processor simulation, gem5, performance engineering, high-performance computing, Arm SVE, RISC-V, GROMACS, Lattice QCD, breadth-first search, performance counters, Processor, simulation

The target of the analysis is a class of image encryption schemes known as DKPC, short for a dynamic key whose position is related to the ciphertext. The appeal of such designs is easy to understand. In classical permutation-diffusion architectures, a static key shuffles pixel positions and then a diffusion stage mixes pixel values so that changing one input pixel alters many output pixels. Cryptanalysts have learned to exploit schemes in which these operations depend only on a fixed key, recovering the equivalent permutation and diffusion machinery once and then decrypting everything. Plaintext-related and ciphertext-related mechanisms were invented precisely to close that door: if the encryption process changes depending on the data being encrypted, the attacker cannot simply replay a recovered equivalent key against new ciphertexts.

DKPC pushes this idea further by introducing an additional dynamic key whose location within the algorithm is associated with the ciphertext itself, layered on top of a static key. The permutation stage is built on a breadth-first search, a graph-traversal technique that determines how pixels are shuffled, and this permutation depends only on the static key. The diffusion stage, which spreads the influence of each pixel across the image, is governed by both the static key and the dynamic key whose position shifts with the ciphertext. The designers of the scheme presented this dynamic key placement as its best innovation, arguing that because the attacker cannot even pin down where the dynamic key acts without knowing the ciphertext relationships, the system gains a substantial security margin over earlier plaintext-related algorithms.

Zhou and Yu’s analysis shows that this margin was largely an illusion. Their first move targets the permutation stage, which they demonstrate can be equivalently transformed into a typical permutation-diffusion structure. Once that structural equivalence is established, the intimidating appearance of the dynamic mechanism dissolves into a familiar form that cryptanalysts have attacked many times before. The breadth-first-search-based permutation, being dependent only on the static key, is deciphered through what the authors describe as an innovative approach — a method that peels away the shuffling layer without needing to know anything about the diffusion that follows it.

With the permutation neutralized, the attack proceeds to the diffusion stage, and here the chosen-ciphertext attack does the heavy lifting. In a chosen-ciphertext scenario, the attacker is granted access to a decryption oracle: they can submit ciphertexts of their choosing and observe the plaintexts that come out. This is a standard and widely accepted model in cryptanalysis, and it is often realistic, since decryption failures, padding errors, and interactive systems can leak exactly this kind of information. By crafting special ciphertexts and observing how the decryption process behaves, the attackers recover the equivalent static key of the diffusion first, then break the equivalent dynamic key separately. The separation is the crucial technical insight: although the dynamic key’s position is entangled with the ciphertext, its effect can be isolated and characterized through carefully chosen queries, allowing the two key components to be dismantled one after the other.

Perhaps the most striking claim in the paper concerns cost. The authors report that the complexity of their attack is much lower than that of cryptanalysis on other plaintext-related algorithms — the very family of schemes that DKPC was meant to outclass. In other words, the mechanism marketed as a security upgrade actually made the system easier to break than its predecessors, at least under the attack strategy Zhou and Yu developed. Theoretical analysis and experimental results both support the conclusion that the cryptanalysis is effective and feasible, meaning the researchers did not merely sketch an attack on paper but demonstrated it working against the actual scheme.

This result lands in a field that has seen a remarkable string of similar collapses. The paper’s reference list reads like a graveyard of chaotic ciphers: image encryption schemes built on two-point diffusion strategies and Hénon maps, algorithms using DNA coding and chaos, ciphers based on compressive sensing, systems built on memristive Hopfield neural networks, and enhanced plaintext-related chaotic schemes have all been broken in recent years by cryptanalysis groups, including Zhou and Yu themselves, who previously published security analyses of chaotic encryption algorithms related to the sum of plaintext pixel values and broke an enhanced plaintext-related chaotic image encryption algorithm. The pattern is consistent: a designer adds a clever twist to resist known attacks, the twist looks impregnable in security analyses that measure statistical randomness, and a cryptanalyst finds an equivalent structure or an oracle-based strategy that renders the twist irrelevant.

Why does this keep happening? Part of the answer lies in how chaotic ciphers are evaluated. Many proposed schemes are validated by showing that encrypted images have uniform histograms, low correlation between adjacent pixels, high entropy, and sensitivity to small key changes. These are necessary properties, but they are nowhere near sufficient. A cipher can produce beautifully random-looking output and still leak enough structure for an attacker to reconstruct equivalent keys. Cryptanalysis, by contrast, works at the level of algorithmic structure: it asks what an attacker with oracle access can infer, not what the ciphertext looks like to the eye. The DKPC break is a textbook illustration — the dynamic key position created a genuine structural complication, but the complication could be equivalently transformed away, and once transformed, standard chosen-ciphertext techniques finished the job.

The broader lesson for the field is that security must be argued against attack models, not against statistical tests. Modern cryptography rests on the principle, articulated by pioneers like Auguste Kerckhoffs, that a system should remain secure even if everything about it is public except the key. Chaos-based designs often implicitly assume that the complexity and apparent randomness of the chaotic dynamics substitute for rigorous proof. The accumulating record of breaks suggests otherwise: nonlinearity and sensitivity to initial conditions do not, by themselves, confer cryptographic strength. What matters is whether the mapping from key and plaintext to ciphertext can be inverted or equivalently reconstructed by an adversary with bounded resources, and that is a question that only formal cryptanalysis — or a proof of security — can answer.

For practitioners choosing encryption for real systems, the practical guidance is sobering and simple. Chaotic image encryption schemes published in the academic literature, however inventive their mechanisms, should not be treated as battle-tested cryptography; established, publicly vetted standards such as AES remain the appropriate choice for protecting data. For researchers, the Zhou and Yu paper is both a warning and a template: any new mechanism that ties key behavior to plaintext or ciphertext should be assumed vulnerable until it has survived chosen-plaintext and chosen-ciphertext analysis, and designers should proactively attempt the kind of equivalent-structure transformation that felled DKPC. The dynamic key idea was meant to move the goalposts; instead, it demonstrated once again that in cryptography, novelty is not security, and every clever twist must ultimately face the cryptanalyst’s oracle.

Subject of Research: Cryptanalysis of a chaos-based image encryption scheme with a ciphertext-related dynamic key

Article Title: Cryptanalysis on a chaos-based cryptosystem with dynamic key

Article References: Zhou, R., & Yu, S. (2026). Cryptanalysis on a chaos-based cryptosystem with dynamic key. Applied Intelligence, 56(14), Article 413. https://doi.org/10.1007/s10489-026-07446-0

Image Credits: AI Generated

DOI: 10.1007/s10489-026-07446-0

Keywords: chaos, cryptography, cryptanalysis, dynamic key, image encryption, chosen-ciphertext attack, permutation-diffusion, breadth-first search, Applied Intelligence, security analysis, nonlinear dynamics, equivalent key