Neuromorphic hardware promises to spend computation on change. Judging that promise requires following the events, the waiting time and the electricity all the way to a useful answer.
Imagine a machine watching a doorway through a long quiet night. Most of the scene barely changes. A person finally enters, and the machine must respond promptly. An architecture that repeatedly performs the same large calculation on nearly identical inputs may be spending work where little new information exists. An event-driven architecture asks a different question: can useful changes trigger the work, while unchanging regions remain comparatively quiet?
This is one of the practical attractions of neuromorphic computing. The term covers a range of hardware and algorithmic approaches inspired by nervous systems, rather than one universal chip design. Inspiration is not evidence of consciousness, and a count of artificial neurons is not a measure of understanding. The useful engineering questions concern which computations the system performs, how it communicates and what it costs to obtain a reliable result.
Intel's April 17, 2024 announcement of Hala Point described a large Loihi 2-based research prototype initially deployed at Sandia National Laboratories. That dated vendor account establishes a concrete research system and its intended role. It is not a fresh 2026 discovery, an independently verified current size record or proof that every workload outperforms conventional hardware. Intel's originating announcement.
The more revealing question is what happens when the quiet scene becomes busy. A crowd arrives, lighting changes, noise produces extra events and a deadline remains fixed. A system whose cost depends on activity must be tested across that activity. Its advantage may be substantial, but the shape of the workload becomes part of the performance claim rather than background scenery.
The event is a choice about representation
An event can indicate that something changed, crossed a threshold or reached a particular internal state. It may carry a location, time, sign or numerical payload. These design choices determine what information moves through the system and what must be reconstructed or retained elsewhere.
A conventional sampled representation might report a value at regular intervals even when it is unchanged. A change-based representation can instead report differences. Neither is automatically superior. The second can reduce communication when changes are sparse, but it needs an agreed starting state and a way to handle missing, delayed or noisy updates.
Consider an original fictional temperature stream: twenty, twenty, twenty, twenty-one, twenty-one. Sending every value is simple. Sending an initial twenty followed by one positive change is more compact for this short sequence. If the receiver misses that change, however, its reconstructed value remains wrong until another mechanism repairs the discrepancy. The example illustrates an encoding tradeoff, not a claim that any cited processor uses this exact protocol.
The threshold for reporting a change also matters. A high threshold can suppress small fluctuations and reduce activity, but it can discard a small signal that matters to the task. A low threshold can preserve detail while generating many messages. Representation efficiency therefore has to be evaluated alongside task quality.
For the doorway machine, a slight movement might be irrelevant background noise or the first evidence of a person entering. Deciding which is which requires a model and a defined objective. An event-driven system does not avoid that decision; it moves part of it into the representation and processing rules.
Stateful units change the meaning of a computation
A processing unit with internal state can accumulate inputs over time, let an influence decay, or emit an event when a condition is reached. Its output depends on history as well as on the latest input. That differs from treating every incoming sample as an isolated static object.
Garrick Orchard and colleagues' November 2021 paper explored programmable stateful neuron models for streaming signal processing in simulation experiments on emulated Loihi 2 hardware. The distinction is important: the paper's computational demonstrations are not measurements of a complete physical system's electricity use. It illustrates ways to express temporal computations, not a universal hardware-efficiency ratio. The primary author paper.
An original analogy is a bucket with a small leak. Incoming drops raise the level, while the leak removes some influence over time. Whether the bucket reaches a marked line depends on both the recent input and what remains from earlier input. The analogy is intentionally simple; an actual programmable model can have more complicated dynamics and multiple state variables.
This temporal memory can be useful when the task itself unfolds over time. A sound, a moving edge or a control signal is a sequence, not merely a collection of unrelated snapshots. Yet keeping state creates obligations. The system must define how it begins, how it resets and how it behaves after an interruption.
A benchmark that feeds independent clips into a stateful network needs to specify whether the internal state is cleared between clips. Otherwise one sample can influence the next. That influence may be appropriate for a continuous stream and inappropriate for an independent test set. The evaluation should match the intended use rather than letting the ordering of a dataset become an unnoticed source of information.
Sparse arithmetic can still create busy communication
Reducing the number of active units is only one part of reducing work. An event may be delivered to several destinations, routed across multiple links or stored until the receiving unit is ready. The cost of those operations depends on connectivity and placement.
Take an original hypothetical network with one thousand active sources. In one mapping, each source sends to two nearby destinations. In another, each sends to two hundred destinations spread across the device. The source activity is identical, but the communication burden is not. A count of emitted events without a description of their fan-out can conceal the difference.
Locality matters for similar reasons. A message traveling within a small region can require fewer resources than one crossing several chips. A network with fewer mathematical operations can still perform poorly if the necessary data movement is expensive. Conversely, a carefully placed network can exploit local interaction even when its raw operation count is not the smallest.
The doorway application offers a concrete way to think about this. Nearby image regions may exchange information locally to recognize motion, while a later decision combines evidence from across the scene. Those stages create different communication patterns. Mapping both stages as if every connection were equally cheap can miss an important architectural constraint.
The practical unit of comparison should therefore include messages delivered, not merely events produced. It should also preserve where those messages travel and whether their timing creates congestion. Sparse computation is a valuable property, but it is not a complete description of a sparse system.
A benchmark needs a task before it needs a stopwatch
A machine can be fast at producing an answer that is insufficiently accurate, delayed in a way the application cannot tolerate, or based on information that would not be available in real use. A fair comparison defines the acceptable answer before timing the implementation.
The NeuroBench framework separates algorithm-oriented evaluation from hardware-dependent system evaluation. Its author manuscript, revised January 14, 2025, provides a structured way to compare tasks, quality and resource measures without assuming that one abstract operation count determines deployed energy. This article uses that accessible version rather than claiming a reading of an inaccessible publisher PDF. The primary framework manuscript.
For an original hypothetical doorway task, define success as detecting an entering person within a specified delay while limiting false alarms. One system may classify a whole recorded clip accurately but only after the clip ends. Another may make a slightly less accurate immediate decision. Neither result can be ranked sensibly until the service requirement says how delay and errors are valued.
The input conditions belong to the task definition too. A system given pre-cropped images has an easier problem than one that must find a person in the entire scene. A system supplied with precomputed features has outsourced work that another implementation may perform internally. The comparison should either include that work or clearly state the narrower boundary.
This is especially important when an unfamiliar architecture requires a different input format. Converting a task into an event representation can be part of the innovation, but the conversion's cost and information loss remain part of the system. A benchmark should not make the expensive preparation disappear simply because it happens before the timed kernel.
Same quality is more demanding than the same model name
Two implementations can share a network label while using different numerical precision, thresholds, state updates or stopping conditions. Those differences can change both quality and cost. The fair comparison is not necessarily identical internal operations; it is a clearly defined task performed to a comparable standard.
Gavin Parpart and colleagues' 2023 study implemented the Locally Competitive Algorithm on Loihi 2 and compared it with CPU and GPU implementations. Its methods identify fixed inputs used to limit input-output effects, a small image sample and dynamic-power measurements. The experiments are informative about that sparse-coding implementation under its tested conditions, not a general ranking of all processors or a complete streaming pipeline. The full primary conference paper.
An original hypothetical reconstruction task makes the issue intuitive. Suppose one method returns a rough image after ten iterations and another returns a more faithful image after twenty. Reporting only time per image would reward the first even if it failed the intended quality requirement. A more useful curve shows time or energy as a function of achieved error.
The same principle applies to classification. A reduction in activity can save resources while slightly increasing mistakes. Whether that is acceptable depends on the application and on which mistakes increase. An average accuracy score may hide a large change in a rare but important category.
A benchmark can therefore report a frontier rather than one winner: the combinations of quality, delay and energy that each implementation can achieve. That makes tradeoffs visible and allows a reader to select the point relevant to a real service. It also discourages cherry-picking one architecture's best quality setting against another's lowest-energy setting.
A current revision reveals the boundary problem directly
Matthew Brehove and colleagues' sigma-delta conversion manuscript was first posted in May 2025 and revised July 1, 2026. Its methods explicitly distinguish Loihi chip-power accounting from the broader system-on-chip channels available for the Jetson comparison. It also tests replayed on-chip inputs to examine input-output effects. Those qualifications are central to interpreting its results; no universal energy multiplier is repeated here. The accessible version remains an author manuscript with placeholder publication metadata. The full revised manuscript.
The general lesson can be demonstrated without borrowing any of its measured values. Imagine two fictional systems performing the same task at acceptable quality. System A spends one energy unit in its computational core and nine in input preparation and communication. System B spends four in its core and two in the rest. A core-only comparison favors A by a factor of four. The complete totals favor B, six units against ten.
That reversal is not an argument against efficient cores. It is an argument for matching the measurement boundary to the claim. If a paper is about the core, a core measurement is appropriate. If a product claim is about battery life, the battery must supply the rest of the product too.
The input-output boundary also affects timing. Replaying data already on a chip can reveal its internal processing capability. Streaming fresh data from a sensor tests an additional path. Both experiments are useful, but they answer different questions. The first should not be presented as if it includes a path deliberately removed from the test.
An honest benchmark can report several boundaries side by side. Doing so often makes the engineering opportunity clearer: perhaps the core is ready and the interface needs work, or perhaps the interface is efficient while the model generates too much activity. A single total without decomposition can be just as unhelpful as a selective subtotal presented as the whole.
The electricity meter should follow the claim
Original hypothetical energy accounting at equal assumed task quality and deadline. A uses 1 core + 9 other = 10 units; B uses 4 core + 2 other = 6 units. These are not measured processor results.
Power is the rate at which energy is used. Energy is power accumulated over time. A low-power machine can use more energy for a task if it runs much longer, while a high-power burst can consume relatively little energy if it finishes quickly and the system can genuinely return to a low-power state.
In an original fictional comparison, a device drawing two watts for ten milliseconds consumes twenty millijoules. Another drawing half a watt for sixty milliseconds consumes thirty millijoules. The second has lower active power but higher task energy. Neither number says what happens during the rest of the second or whether the application can tolerate the longer response.
Idle consumption is particularly important for always-on systems. Suppose a hypothetical monitor spends nearly all day waiting. Reducing its short bursts of computation may have little effect if the supporting electronics draw substantial power continuously. A design optimized for sustained throughput could therefore be a poor choice for a sparse, intermittent workload despite an attractive energy-per-inference number.
Subtracting idle power can be useful for studying incremental computational activity. It should not erase the idle power from a claim about total operating energy. The system still needs electricity while prepared to respond, and the practical benefit depends on whether that prepared state is required throughout the deployment.
Measurement placement should be documented in ordinary language. Was power measured at a chip rail, a development board input, a wall outlet or estimated by software counters? Which components were included? A reader should not need to infer the boundary from an unexplained acronym beside a bar chart.
Waiting for a batch can be the largest delay
Batching lets some processors amortize overhead and exploit parallelism. It can dramatically improve throughput. A real-time event stream, however, may not be able to wait until a large batch accumulates.
Consider an original hypothetical input arriving at one item per millisecond. Waiting for a batch of one hundred items makes the first item wait roughly ninety-nine milliseconds before processing begins. Even if the batch then finishes quickly, the earliest item's response delay includes that wait. A benchmark reporting only the processing interval would omit the delay introduced by collecting the batch.
The opposite mistake is to prohibit batching when the intended job naturally provides large offline datasets. An architecture should not receive a favorable comparison by forcing its competitor into an artificial operating mode unrelated to the task. The workload determines which batching choices are legitimate.
For the doorway machine, the relevant metric might be the delay from the beginning of an observable event to a usable alert. For an overnight analysis of archived recordings, items processed per second might matter more. These are different services and can reasonably favor different architectures.
A clear evaluation can state both throughput and latency, along with the arrival pattern and batching policy. That makes it possible to distinguish fast service from a large queue being processed efficiently. The distinction is essential whenever a benchmark result is translated into a claim about responsiveness.
A quiet average can hide an overloaded moment
An event-driven system may process very little during calm periods and a great deal during sudden changes. Average event rate can therefore be a poor predictor of worst-case delay. The queue created by a burst is part of the workload.
Imagine an original fictional processor able to handle ten thousand messages per millisecond. A source normally emits one thousand, but occasionally emits one hundred thousand in a millisecond. Even if the long-term average is comfortably below capacity, that burst cannot be consumed instantly. It leaves work waiting unless other resources or a policy absorb the surge.
If new messages continue to arrive while the backlog is processed, clearing it takes longer. If the system drops messages instead, the effect on task quality must be measured. A design cannot claim both complete information retention and bounded delay merely by reporting a low average input rate.
Bursts may also be spatially concentrated. A single region can become overloaded while the rest of the hardware remains underused. Total system capacity does not guarantee that every local route or processing block has enough capacity. Placement and routing therefore influence tail latency as well as energy.
The practical test should include plausible busy conditions: abrupt motion, lighting changes, noisy inputs and transitions between scenes. These need not all be worst-case adversarial constructions. Ordinary deployment can contain moments much busier than the average clip selected for a demonstration.
Synchronization is work even when no arithmetic is visible
Distributed processing needs a way to preserve the intended relationship between events. Some systems coordinate progress globally; others allow local regions to advance under rules that preserve correctness. The cost depends on communication patterns and on how much work different regions have to do.
Congyang Li and colleagues' November 24, 2025 NeuroScale paper combines a small FPGA-based validation with detailed hardware simulations for its scaling study. The large-system comparisons are simulated, not measurements of a newly built giant installation. Its contribution makes synchronization a concrete architectural subject rather than an invisible overhead. The full primary study.
An original analogy is a group completing several stages of a project. If everyone must wait at the end of every stage, the slowest person controls each transition. Letting independent groups move ahead can reduce waiting, but only if dependencies are respected. The challenge is to avoid both unnecessary waiting and incorrect use of results that have not arrived.
The same issue appears in event systems. A local region with little activity may be ready to progress while another region has a large queue. A coordination policy can determine whether the quiet region saves time or merely waits. Changing the policy may require additional state, messages or buffering.
A scaling claim should therefore state the network topology and activity distribution used in the comparison. A method that benefits locally connected workloads may offer a different advantage when communication is dense and global. The number of cores alone is not a sufficient description of the computation being scaled.
Analog hardware makes calibration part of computation
Neuromorphic hardware is not exclusively digital. Some systems use the physical behavior of analog circuits to emulate dynamics directly, often combined with digital communication or control. This can provide a different relationship between modeled time and elapsed time, while introducing device-specific variation that must be managed.
Pehle and colleagues' February 24, 2022 BrainScaleS-2 paper describes an accelerated mixed-signal system with hybrid plasticity and calibration capabilities. The primary work shows why physical emulation, configuration and measurement belong together. Its acceleration of modeled dynamics should not be read as a universal speedup for every externally arriving real-time task. The full originating system paper.
Calibration connects a desired model parameter to a physical circuit's actual behavior. An identical digital setting need not produce identical analog behavior in every circuit. Measuring and adjusting the mapping can make the system more useful, but the required effort should be included when assessing deployment and maintenance.
An original hypothetical device might run a model quickly after a minute of setup. If it performs the same job for many hours, that setup may be negligible. If the task changes every few seconds and requires repeated calibration, the balance changes. The right accounting depends on how often the preparation occurs and how long its benefit lasts.
The distinction between simulated time and real time is equally important. A circuit can emulate a second of a model in much less than a second, which is valuable for some experiments. A live sensor still receives the next second of the outside world over a real second. Acceleration can help process or learn from data, but it does not make future observations arrive early.
A model that fits mathematically may not fit physically
A network description lists units, connections, weights and update rules. Mapping it to hardware adds limits: memory capacity, supported numerical formats, available fan-in and fan-out, routing resources and placement constraints. A model with a modest parameter count can still map awkwardly.
Consider an original fictional network containing several densely connected groups. Each group fits within a processing block, but the connections between groups exceed the available communication capacity. Splitting the groups across more blocks might solve one memory constraint while worsening communication. A simple neuron count would miss the bottleneck.
Another model may require a state update that is inexpensive in software but awkward on the target hardware. Emulating it with several supported operations can increase activity or latency. The relevant comparison is the implemented model, not an abstract count that assumes every operation has equal cost.
Mapping tools are therefore part of the platform's practical capability. They determine whether a researcher can reproduce a result, adapt it to a different network and diagnose a failure. A demonstration using extensive manual tuning may still be scientifically valuable, but that tuning should not disappear from claims about ease of deployment.
This is also why hardware capacity and usable application capacity differ. A system can contain many processing elements while leaving some underutilized because the model's connectivity or resource requirements do not match the available arrangement. Utilization should be measured for the task, not inferred from the nameplate size.
Training and inference spend resources at different times
A deployed network may perform efficient inference after an expensive training process. Another approach may adapt locally during operation. Both can be useful, but their resource requirements occur at different points in the system's life.
An original fictional model costs one thousand energy units to train and one unit per inference. A second costs two thousand to train and half a unit per inference. Ignoring all other costs, the second recovers its additional training energy after two thousand inferences. That simple break-even calculation changes if the model must be retrained frequently or if the training infrastructure is counted differently.
Local adaptation creates another set of questions. What information triggers an update, where is the learning state stored and how is performance checked afterward? A device that changes itself in deployment needs an evaluation covering that change, not only its initial trained state.
The learning rule can also alter traffic and storage requirements. Inference may need a subset of the information required for training. A claim that a model fits or runs efficiently during inference does not establish that the same hardware can train it with comparable efficiency.
A useful report therefore separates initial training, conversion, deployment setup, online adaptation and inference. It should also describe which stages used conventional computers. Hybrid workflows are not a weakness to conceal; they are often the actual system. The important question is whether the complete workflow offers a useful advantage under the intended frequency of updates and use.
Encoding a quiet signal can make it noisy
A change-based representation can amplify the importance of noise near a threshold. A small fluctuation may repeatedly cross the reporting boundary, generating events that carry little task-relevant information. Suppressing those events can save work, but it can also remove weak signals.
An original hypothetical sensor measures a value close to a decision threshold. Random fluctuations move it slightly above and below the threshold many times. A naive event rule reports every crossing. A rule with hysteresis, requiring a larger change before reversing its state, may reduce chattering. The appropriate rule depends on what changes must remain detectable.
Noise can originate at the sensor, in conversion circuitry or in the environment. A benchmark using clean prepared data may therefore understate the activity encountered in deployment. Adding arbitrary synthetic noise is not enough unless its properties resemble the conditions relevant to the task.
There is also a distinction between information loss and harmless compression. If suppressing events leaves the task result unchanged, the reduction is useful. If it removes an early warning that matters under rare conditions, a high average score can conceal the cost. Evaluation should include the situations in which small changes are important.
For the doorway monitor, that might mean testing slow motion as well as fast motion, changing illumination as well as stable illumination, and empty scenes that are not perfectly still. The goal is to learn where the event representation preserves the needed evidence and where it needs a complementary path.
Closed-loop performance includes the consequences of the answer
A classifier evaluated on a stored dataset receives inputs without changing what happens next. A controller or interactive system can influence its future inputs through its actions. That makes the complete loop a different object of evaluation.
Imagine an original fictional robot that turns its camera toward a detected object. A small delay in detection changes where the object appears in the next observation. A false detection can redirect the camera and cause the robot to miss something else. The quality of the initial classifier matters, but the sequence of decisions matters too.
A processor with low average energy may still be unsuitable if occasional delays destabilize the control loop. Another may consume more per decision but complete each within a predictable deadline. The preferred design depends on the system's tolerance for delay, errors and interruptions.
Testing the loop requires a defined environment or a defensible simulation of one. It should distinguish simulated dynamics from physical trials and record which components were actually in the loop. A hardware processor receiving prerecorded inputs is not the same as a complete robot responding to the consequences of its own actions.
This distinction keeps the promise of real-time intelligence grounded. The valuable result is not merely that a chip emits outputs quickly. It is that those outputs arrive with the quality and timing needed to improve the larger system's behavior. That claim requires evidence at the larger boundary.
Reproducibility has several layers
Repeating a benchmark requires more than the model weights. The input preprocessing, event encoding, state initialization, mapping, software version and measurement settings can all influence the result. A small undocumented change can alter activity and therefore alter both quality and resource use.
An original hypothetical reproduction keeps the same network but changes the event threshold slightly. Accuracy might remain close while message traffic changes substantially. Another reproduction retains the threshold but resets state between samples when the original did not. Both researchers can believe they ran the same model while evaluating different computations.
The measurement code matters too. A power profiler may report selected rails or average over a particular interval. A timing function may exclude transfer, initialization or synchronization. Those choices should be explicit enough for another team to reproduce the boundary, even if its hardware instrumentation differs.
Randomness and variation should be handled deliberately. If a result depends on random initialization, stochastic dynamics or a small test sample, multiple runs can reveal sensitivity. Reporting only the best run makes an unstable advantage look more dependable than it is. Reporting the distribution helps distinguish a robust improvement from a favorable realization.
The practical artifact is a runnable description of the experiment plus a readable explanation of what it measures. Neither replaces the other. Code without context can reproduce the wrong interpretation; prose without configuration can leave the claimed result impossible to reconstruct.
The conventional baseline deserves competent treatment
An unfamiliar architecture should be compared with a conventional implementation that is appropriate to the task and reasonably optimized. A large server processor idling through a tiny edge workload can be a poor baseline for a small specialized device. A conventional embedded processor may be a more relevant alternative.
The reverse is also true. For a large offline workload, a specialized system should not claim superiority by comparing against a deliberately unbatched or poorly configured accelerator when batching is allowed by the application. The goal is to compare plausible choices, not to manufacture a dramatic ratio.
An original fictional comparison can make both architectures look favorable. Give a throughput-oriented processor one tiny item at a time and charge its entire idle platform to each item; it may look wasteful. Give an event-driven system dense inputs with no temporal redundancy and require a computation poorly matched to its primitives; it may look inefficient. Neither experiment alone identifies the best architecture for the doorway service.
A strong evaluation states the optimization effort and constraints given to each side. If one implementation is a mature library and the other is an early research prototype, that context helps explain both current performance and potential. It should not be used to erase measured disadvantages, but it can guide the next experiment.
The most useful outcome may be a map of favorable workloads rather than a single overall winner. That map can direct investment toward applications where the architecture's strengths align with real requirements and away from tasks where its distinctive features provide little benefit.
A battery budget makes the tradeoff tangible
Return to the imaginary doorway monitor and assign it a fictional daily energy budget. Suppose its sensor and supporting electronics consume twenty energy units while waiting, and each thousand decisions consume one additional unit. Reducing computation by half saves little on a quiet day with few decisions. Reducing standby consumption could matter much more.
On a busy day, the balance changes. If the system processes hundreds of thousands of decisions, computational efficiency becomes a larger share of the total. The same hardware can therefore have different practical advantages under different activity patterns, even when its per-operation properties are unchanged.
A third condition complicates the picture: false events. If noise doubles the number of decisions without improving the service, a low per-decision energy can coexist with poor daily efficiency. The useful metric is energy for the required service, including unnecessary work generated by the sensing and processing pipeline.
This suggests a concrete test plan. Measure representative quiet, ordinary and busy intervals; preserve the transitions between them; record task quality and missed deadlines; and account for the energy used while the system is ready but not actively processing. These intervals should reflect deployment conditions rather than arbitrary equal-sized laboratory batches.
The resulting profile is more useful than a single best-case number. It tells a designer how the system behaves as the world changes and which component dominates the energy budget in each regime. It also shows whether a proposed improvement affects the conditions that matter most.
What would count as a convincing advance?
A convincing advance could take several forms. One system might preserve task quality with fewer messages across a broad range of activity. Another might reduce tail latency during bursts. A third might make mapping and calibration reproducible enough that a promising result can be transferred to a new application without extensive bespoke work.
The strongest evidence identifies the improvement and the boundary together. It says what was built, what was simulated, which inputs were used, which quality requirement was met and which components consumed the measured energy. It also shows the conditions under which the advantage narrows or disappears. Those limits make the result more useful, not less impressive.
The fictional doorway machine gives the discussion a simple endpoint: a timely, reliable response across quiet and busy conditions within a realistic energy budget. Whether it uses spikes, graded events, analog dynamics or conventional arithmetic is an implementation choice. The architecture earns its place by serving that endpoint.
Neuromorphic computing offers a rich set of ideas for matching computation to change, preserving temporal state and reducing unnecessary movement of information. The fair test is to follow those ideas through the whole machine. When the quiet scene gets busy, the useful question is how well the system keeps its promise—and how clearly the evidence lets someone else check.