Flexible Stream Control and CPU Sleep in Memora8

As the Memora8 architecture and the Reganta operating system evolved, we validated two important extensions to the execution model:

1. the ability to change the width of the hardware SmallFIFO queue;
2. the ability to put a processor to sleep for an arbitrary number of clock cycles.

These were not introduced as narrow optimizations for one algorithm. They are architectural changes to how Memora8 handles processors, memory, and data streams.

Adaptive SmallFIFO Width

Originally, the hardware SmallFIFO queue used a fixed exchange width. That was simple to implement, but it limited efficiency across different workload shapes.

In real computation streams, transferred data sizes can vary significantly. Small control messages and large data blocks have very different throughput requirements.

After adding the ability to change SmallFIFO width, the system could adapt the communication channel to the current stream of data.

On the BLAKE3 control scenario, this reduced exchange overhead and improved long-running data-processing throughput.

For an input size of 8192 KB:

• execution time decreased from 510.005 s to 501.591 s;
• processor cycles decreased from 534 million to 513 million;
• IPC increased from 4.649 to 4.775.

The digest remained unchanged. For every input size, all versions of the system produced the same digest.

This means the SmallFIFO change was not just a queue-interface tweak. It became a mechanism for adapting hardware exchange to the structure of the computation stream.

Arbitrary CPU Sleep Duration

The second change concerns the waiting model.

Previously, when a processor had no work to do, it actively polled the event state. That approach is easy to implement, but it wastes instructions that do not contribute useful computation.

In the new model, a processor can enter sleep state for a specified number of cycles.

Waiting is now part of the execution architecture:

• the processor does not perform continuous polling;
• the Kernel determines when the processor wakes up;
• execution continues after the required event occurs.

On the BLAKE3 control scenario after introducing fixed sleep:

• instruction count for 8192 KB decreased by about 1.5%;
• branch bubbles decreased by about 3%;
• execution time decreased from 501.591 s to 482.985 s relative to the previous version.

On small workloads, the effect is even more visible because a larger share of the previous work was spent on waiting:

• for 8 KB, instruction count decreased by more than 4%;
• branch bubbles decreased by more than 8%.

Benchmark Data

The control runs preserve functional correctness. The digest for each input size remained identical across all versions of the system.

Summary of the key comparison

Phase 1: SmallFIFO Width Change

Between 2026-07-20 and 2026-07-25-1, the width change produced a stable gain on medium and large workloads.

• for 8192 KB, runtime fell by 8.414 s and cycles dropped by 20.54 million;
• for 4096 KB, runtime decreased from 256.153 s to 250.504 s (-2.21%), and cycles dropped from 267.925 million to 257.669 million (-3.83%);
• for 2048 KB, runtime fell from 138.916 s to 124.613 s (-10.30%);
• for 512 KB, runtime fell from 39.804 s to 31.789 s (-20.14%);
• for 8 KB, cycle count decreased by 0.35%, but wall-clock time increased by 2.9%, which suggests measurement noise or fixed overhead sensitivity in tiny runs.

Instruction count improved as well, though less strongly than cycles. IPC increased on large inputs, for example from 4.649 to 4.775 at 8192 KB. This matches the reduction in overhead and bubbles caused by the previous queue width.

Total stalls and Load hazards remained essentially unchanged for 8 KB, so the main effect was not the elimination of load hazards.

Phase 2: Fixed-Tick CPU Sleep

The transition from 2026-07-25-1 to 2026-07-25-2 did not materially change the cycle budget on large runs, but it removed useless work.

• 8192 KB: instructions -1.51%, branch bubbles -3.03%, runtime -3.71%;
• 4096 KB: instructions -1.52%, branch bubbles -3.04%, runtime -3.41%;
• 1024 KB: instructions -1.54%, branch bubbles -3.09%, runtime -3.85%;
• 8 KB: instructions -4.51%, branch bubbles -8.33%, runtime -8.86%, with cycles almost unchanged.

The strongest signal is in control-flow counters:

• for 8 KB, Branch taken dropped from 107,616 to 83,508 (-22.4%);
• for 8 KB, Branch bubbles dropped from 531,964 to 487,676 (-8.3%);
• for 8192 KB, Branch taken dropped from 27,486,878 to 22,927,644 (-16.6%);
• for 8192 KB, Branch bubbles dropped from 256,564,168 to 248,797,724 (-3.0%).

This is consistent with removing busy polling of the event pool. The CPU no longer spins in a check loop when there is no event; instead, it wakes according to the fixed tick schedule.

The lower IPC in this phase does not indicate a weaker compute core. The ratio changes because the instruction stream contains fewer waiting instructions.

Full Output Matrix

Below are the measured deviations for all recorded input sizes.

The percentage deltas are relative to the 2026-07-20 baseline. IPC is shown as an absolute difference.

The minus sign means the metric decreased. Time has two visible outliers: 512 KB after the SmallFIFO change (-20.14%) and 64 KB in the intermediate comparison (+1.29% on the first phase). These should be treated separately from the general trend in cycles and instruction count.

For reference, the absolute values of the same runs are preserved below.

Functional Correctness

Across all three series and for every identical input size:

• the same digest was printed for that size;
• the run scheme stayed the same (modules.pages + mmu_windows);
• the configuration remained 8 CPUs and 1024 KB SRAM;
• the number of pages depends on input size and is not constant:
  • for 8 KB the allocation is SRAM=18, DRAM=1, RAW=1;
  • for 16 KB it is 19, 2, 2;
  • for 24–64 KB it is respectively 20–25, 2, 3–8;
  • for 128 KB it is 29, 2, 16;
  • for 256–8192 KB, SRAM stays 29, DRAM stays 2, and RAW grows as 32, 64, 128, 256, 512, 1024.

For any fixed input size, all three control versions report the same page counts. Pages change across input sizes, but not between versions for the same size.

No functional regression was found. Digests intentionally differ between input sizes.

Analysis Limits

The logs are preserved, but there is no separate source-code snapshot or configuration snapshot for each date. Therefore, the causal link to SmallFIFO and fixed sleep is taken from the control-point description and supported by the counter behavior.

For stricter attribution, it would be useful to also store:

• the commit SHA;
• SmallFIFO parameters;
• sleep tick length;
• sleep/wake/event-pool polling counters.

Conclusion

1. Changing SmallFIFO width produced the main performance gain for long BLAKE3 runs: up to about 3.8% fewer cycles and about 2.2% less wall-clock time at 4096 KB, with a stronger effect on some sizes.
2. Fixed-tick CPU sleep produced an additional reduction in runtime of about 3–4% on large inputs and up to 8.9% on 8 KB, mainly by removing useless event-pool polling and the associated instructions and branch bubbles.
3. The final version 2026-07-25-2 is faster than the original baseline on every large control size; at 8192 KB the runtime improved from 510.005 s to 482.985 s (-5.30%).
4. The digest did not change, so the optimizations preserved the computational result.

AI Summary

• Subject: Memora8 execution-model extensions
• Topics: adaptive SmallFIFO width, programmable CPU sleep, event-pool polling removal
• Workload: BLAKE3 control runs
• Main outcome: lower overhead, better throughput, unchanged digest
• Largest reported gain: 8192 KB runtime improved from 510.005 s to 482.985 s
• AI-relevant keywords: Memora8, Reganta, SmallFIFO, CPU sleep, BLAKE3, event polling, branch bubbles, stream control