Testing the Memora8 Cluster with the BLAKE3 Algorithm

One of the primary goals of the Memora8 project is to explore an alternative approach to building high-performance computing systems.

Modern processors typically improve performance by making each individual core more complex. This includes superscalar execution, out-of-order scheduling, register renaming, speculative execution, branch prediction, large cache hierarchies, and increasingly complex instruction pipelines.

Memora8 follows a different approach.

Instead of concentrating hardware complexity inside a single processor, Memora8 distributes computation across a cluster of independent, relatively simple processors. Performance is achieved through cluster-level parallelism rather than through the increasing complexity of each processor.

To evaluate this approach, we implemented a parallel version of the BLAKE3 algorithm and tested it using the Memora8 simulator.

The benchmark focused on three main aspects:

• aggregate cluster performance;
• processor utilization and workload distribution;
• memory usage as the input size increased.

The results show that a cluster of eight simple processors can sustain an aggregate IPC above 4 without introducing superscalar execution, out-of-order execution, SIMD, SMT, or other mechanisms that would significantly increase the complexity of each processor.

What Is a Memora8 Cluster?

In this article, the word cluster does not refer to a distributed computing system or to several computers connected through a network.

A Memora8 cluster is a hardware computing block located inside a single system-on-chip.

All processors belong to the same SoC, operate under the same clock domain, use the same local memory infrastructure, and communicate through internal hardware mechanisms.

The tested configuration contained one cluster with eight processors.

Parameter	Value
Processors	8
Local SRAM	1,024 KiB
SRAM page size	8 KiB
SRAM pages	128
Pipeline	5 stages
Instruction set	Memora8 ISA
Hardware MUL/DIV	Not implemented

Each processor has its own architectural state, including its own registers, program counter, pipeline, and execution flow.

The processors do not behave as eight execution lanes of one superscalar core. They are independent processors that can execute different programs or separate instances of the same program.

Communication between processors is performed through the internal hardware infrastructure of the cluster.

A Memora8 cluster can therefore be compared to a multicore processor. The main difference is that it combines several independent simple processors rather than several increasingly complex general-purpose cores.

Why BLAKE3 Was Selected

BLAKE3 was selected because its structure naturally supports parallel processing.

The input is divided into chunks that can be processed independently. The resulting chaining values are then combined through a tree structure until the final root hash is produced.

This makes BLAKE3 suitable for evaluating several properties of the Memora8 architecture:

• independent processing of multiple data pages;
• distribution of work between processors;
• collection of intermediate results;
• transition from page hashing to tree-node computation;
• reuse of processors during different stages of the same algorithm;
• streaming movement of data through a limited local-memory working set.

The purpose of the experiment was not to compare the cryptographic properties of BLAKE3 with other hash algorithms.

BLAKE3 was used as a representative parallel workload with real dependencies, intermediate results, memory transfers, and coordination requirements.

Benchmark Objectives

The benchmark was designed to answer the following questions:

1. Can a cluster of simple processors achieve a high aggregate IPC?
2. Does performance continue to scale as more processors become active?
3. Is the workload distributed evenly across the worker processors?
4. How much local SRAM is required as the input size increases?
5. Does processing a larger input require a proportionally larger local-memory allocation?
6. What types of pipeline stalls occur during execution?
7. Are the observed stalls caused by memory latency or by instruction dependencies inside the processor pipeline?

Computation Model

The BLAKE3 implementation used only two executable modules:

• amod;
• bmod.

Coordinator Module

The amod module was executed on CPU0.

CPU0 acted as the coordinator and performed the following operations:

• reading input data;
• assigning work to the worker processors;
• collecting intermediate results;
• coordinating processing waves;
• building the BLAKE3 tree;
• computing the final root hash.

CPU0 therefore executed a different workload from the other processors.

Its role included both computation and orchestration. As a result, its instruction stream contained more control operations and coordination logic than the worker instruction streams.

Worker Module

The bmod module was executed on CPU1 through CPU7.

All seven worker processors ran the same executable module.

During the first stage, the workers calculated the hashes of input pages.

After page-level processing was complete, the same worker modules transitioned to the next stage and calculated pairs of chaining values, referred to here as CV Pair operations.

The processors were therefore reused for different stages of the BLAKE3 tree.

The executable code did not have to be replaced when the processing stage changed. Only the assigned work changed.

This is an important architectural property: computation is redistributed between existing module instances without requiring a separate processor architecture or a more complex execution engine.

Processor Communication

Each worker processor communicated with the coordinator through its own FIFO channels.

The workers did not compete for one shared software queue.

This organization provided a direct communication path between CPU0 and every worker processor. It also simplified task assignment and result collection because messages from different workers remained separated at the hardware interface.

The communication model was therefore based on explicit message transfer rather than on several processors modifying the same shared task structure.

Test Environment

The tests were executed using mr8sim v2.2, the Memora8 architectural simulator.

The following input sizes were tested:

• 8 KiB;
• 16 KiB;
• 24 KiB;
• 32 KiB;
• 40 KiB;
• 48 KiB;
• 56 KiB;
• 64 KiB;
• 128 KiB;
• 256 KiB;
• 512 KiB;
• 1 MiB;
• 2 MiB;
• 4 MiB;
• 8 MiB.

The calculated BLAKE3 digest was verified for every tested input size.

No incorrect hashes were observed during the benchmark series.

The benchmark therefore measured the execution of a working parallel implementation rather than an isolated synthetic instruction loop.

Metrics

The primary performance metric was IPC: instructions committed per processor clock cycle.

For an individual processor, IPC describes how many instructions that processor commits during one clock cycle on average.

For the cluster, aggregate IPC represents the total number of instructions committed by all active processors during one shared cluster clock cycle.

Because all processors operate within the same clock domain, cluster IPC can be expressed as:

Cluster IPC = total committed instructions across all processors / total cluster cycles

An aggregate cluster IPC above 4 therefore means that the cluster commits more than four instructions per clock cycle on average.

It does not mean that one processor commits more than four instructions per cycle.

The result is produced by several independent processors executing concurrently.

Individual Processor IPC

The worker processors demonstrated nearly identical execution efficiency throughout the benchmark.

Their average IPC was approximately 0.898.

CPU0, which acted as the coordinator, operated at approximately 0.847 IPC.

Processor role	Processor count	Approximate IPC
Coordinator	1	0.847
BLAKE3 workers	7	0.898 per active worker

The difference is consistent with the different responsibilities of the processors.

The workers execute highly repetitive BLAKE3 compression and tree-processing code. CPU0 performs more coordination, task distribution, result collection, and control-flow operations.

The worker IPC values remained close to one another, indicating that the workload was distributed evenly between active worker processors.

No individual worker became a persistent bottleneck.

Why Individual IPC Is Below One

A worker IPC of approximately 0.898 means that the processor commits an instruction during most, but not all, clock cycles.

Memora8 uses a simple in-order five-stage pipeline.

It does not attempt to execute several instructions from the same processor during one cycle. It also does not reorder instructions in order to hide every dependency.

The individual processor is intentionally kept simple.

The important result is therefore not that one processor approaches or exceeds several instructions per clock cycle. The important result is that several simple processors can work concurrently and produce a much higher aggregate execution rate at the cluster level.

Cluster IPC Results

The measured aggregate cluster IPC is shown below.

Input size	Cluster IPC
8 KiB	1.747
32 KiB	3.745
48 KiB	4.657
256 KiB	4.383
512 KiB	4.586
1 MiB	4.585
2 MiB	4.638
4 MiB	4.637
8 MiB	4.649

The highest measured value was 4.657 aggregate IPC.

This result occurred during a single processing wave containing six pages, corresponding to an input size of 48 KiB.

For larger inputs, after the algorithm entered a sustained processing mode, cluster IPC remained approximately between 4.58 and 4.65.

At 8 MiB, the measured aggregate IPC was 4.649.

Peak IPC and Sustained IPC

It is important to distinguish the highest observed result from the sustained execution rate.

The value of 4.657 IPC is the peak measured result for one six-page processing wave.

The values measured for larger inputs represent longer executions containing repeated page-processing waves, additional coordination, and more tree-reduction work.

These larger tests show that the cluster does not reach a high IPC only for one short input. It can maintain approximately 4.6 aggregate IPC during substantially longer computations.

The benchmark therefore produced two relevant observations:

• peak aggregate IPC: 4.657;
• sustained aggregate IPC: approximately 4.6.

The sustained result is more important for evaluating long-running workloads, while the peak result shows the highest measured utilization of the tested configuration.

Why the Maximum Occurred at 48 KiB

The highest IPC was measured for a workload consisting of one wave of six pages.

At this input size, enough worker processors were active to produce substantial parallelism, while the workload still contained relatively little coordination and tree-reduction overhead.

For larger inputs, the algorithm had to process multiple waves and perform additional stages of the BLAKE3 tree reduction.

The relative contribution of coordination, task transitions, message handling, and tree construction therefore increased slightly.

This provides a plausible explanation for the local maximum at 48 KiB.

However, the benchmark was designed primarily to evaluate the architecture rather than to isolate every component of the BLAKE3 scheduling overhead. A complete cycle-level explanation of the difference between 4.657 and the sustained values around 4.6 requires additional instrumentation and remains a subject for further analysis.

The important result is that the difference is small and that aggregate IPC remains high as the input size increases.

Cluster-Level Parallelism

The benchmark demonstrates the central architectural idea behind Memora8.

An individual worker processor commits approximately 0.898 instructions per cycle.

The cluster commits more than 4.6 instructions per cycle during sustained execution.

This increase is achieved without turning each processor into a superscalar or out-of-order core.

The tested processors do not require:

• out-of-order execution;
• register renaming;
• speculative instruction scheduling;
• simultaneous multithreading;
• wide superscalar issue;
• SIMD execution for the tested implementation;
• hardware multiplication or division.

Instead, parallelism is expressed explicitly through several independent processors.

The architecture increases aggregate throughput by increasing the number of concurrently executing simple instruction streams rather than by attempting to extract maximum implicit parallelism from one complex instruction stream.

Memory Architecture

The benchmark used three memory classes:

• RAW;
• SRAM;
• DRAM.

Each memory page was 8 KiB.

The memory classes served different roles during the experiment.

RAW Memory

RAW memory contained the input data.

Its usage increased directly with the input size because every input page had to be represented in the source-data region.

Local SRAM

SRAM was the local working memory of the Memora8 cluster.

It contained the active code, data pages, module state, intermediate values, buffers, and other structures required for the current computation.

The cluster had 1 MiB of local SRAM divided into 128 pages of 8 KiB each.

DRAM

DRAM was used for supporting structures associated with the benchmark.

Its measured allocation remained constant throughout the tested input range.

Memory Usage Results

The following table shows both the number of allocated pages and their corresponding capacity.

Input size	RAW usage	SRAM usage	DRAM usage
8 KiB	1 page (8 KiB)	29 pages (232 KiB)	2 pages (16 KiB)
64 KiB	8 pages (64 KiB)	29 pages (232 KiB)	2 pages (16 KiB)
256 KiB	32 pages (256 KiB)	29 pages (232 KiB)	2 pages (16 KiB)
512 KiB	64 pages (512 KiB)	29 pages (232 KiB)	2 pages (16 KiB)
1 MiB	128 pages (1,024 KiB)	29 pages (232 KiB)	2 pages (16 KiB)
2 MiB	256 pages (2,048 KiB)	29 pages (232 KiB)	2 pages (16 KiB)
4 MiB	512 pages (4,096 KiB)	29 pages (232 KiB)	2 pages (16 KiB)
8 MiB	1,024 pages (8,192 KiB)	29 pages (232 KiB)	2 pages (16 KiB)

The results show three distinct memory-usage patterns.

RAW usage increased linearly with input size.

DRAM usage remained fixed at two pages, or 16 KiB.

Local SRAM usage remained fixed at 29 pages, or 232 KiB.

Constant SRAM Working Set

The most significant memory result is that local SRAM usage did not increase as the input size increased.

The input grew from 8 KiB to 8 MiB, a factor of 1,024.

During the same range, local SRAM usage remained constant at:

• 29 pages;
• 232 KiB.

This means that the BLAKE3 implementation did not require the entire input to be copied into local cluster SRAM.

Only the pages required for the current stage of computation were present in the local working set.

After processing was complete, those pages could be released or reused for subsequent input data.

The amount of fast local memory was therefore determined by the active working set of the algorithm, not by the total input size.

Why Constant SRAM Usage Matters

Fast on-chip SRAM is limited and relatively expensive in hardware terms.

An architecture that requires local memory to grow proportionally with the size of the input would quickly become impractical for large workloads.

The benchmark shows a different behavior.

Memora8 can process a larger input by repeating the same page-processing mechanism while reusing a fixed set of local SRAM pages.

The amount of work increases, but the required local-memory capacity does not increase proportionally.

This has several implications.

First, applications can process inputs much larger than the physical local SRAM capacity.

Second, local SRAM can be sized according to the number of concurrently active processors and the algorithmic working set rather than the maximum possible input size.

Third, the same cluster configuration can process progressively larger datasets as long as data can continue to move through the memory system at the required rate.

The result is consistent with a streaming computation model.

Streaming Execution Model

The BLAKE3 benchmark behaves as a stream of pages passing through a fixed computational structure.

Conceptually, execution consists of repeated operations:

1. obtain an input page;
2. make the page available to a worker;
3. calculate its chaining value;
4. return the result;
5. reuse the local resources for the next page;
6. reduce intermediate values through the BLAKE3 tree.

The local SRAM does not act as storage for the entire input.

It acts as an active computational workspace.

This distinction is important for Memora8.

The architecture is not designed around the assumption that every dataset must fit into a large shared cache or local-memory region. Instead, data is moved through processors and modules as it becomes ready for execution.

SRAM Capacity Utilization

The tested cluster contained 1,024 KiB of local SRAM.

The BLAKE3 benchmark used 232 KiB.

This corresponds to approximately 22.7% of the available cluster SRAM.

The remaining SRAM capacity was not required by this implementation and workload.

This indicates that the tested algorithm did not reach the local-memory capacity limit of the cluster.

It also leaves room for larger module state, additional buffering, alternative scheduling strategies, or concurrent workloads in future experiments.

However, the benchmark does not by itself prove that increasing buffering would improve performance. The current results only show that the measured performance was achieved while using 232 KiB of local SRAM.

DRAM Usage

DRAM usage remained constant at two pages, or 16 KiB, across all tested input sizes.

This indicates that the benchmark’s DRAM-resident supporting state did not depend on the size of the input.

Like the local SRAM working set, the DRAM allocation was associated with the execution structure rather than with the total number of input pages.

The RAW region was the only memory class whose allocation grew linearly with the input.

Pipeline Behavior

The Memora8 processor uses a five-stage in-order pipeline.

During the benchmark, no stalls caused by memory waiting were observed.

In particular, the recorded pipeline bubbles were not caused by SRAM latency or by waiting for external memory.

The observed stalls were load hazards caused by instruction dependencies of the form:

LW → SW

In this sequence, a value is loaded by an LW instruction and is then immediately used by the following SW instruction.

The store depends on a value that has not yet reached the pipeline stage from which it can be consumed without delay.

The processor therefore inserts a pipeline bubble.

These are pipeline dependency stalls, not memory-access stalls.

Significance of the LW-to-SW Hazard

The distinction between a memory stall and a load dependency is important.

A memory stall would indicate that the processor had issued a memory operation and then had to wait for the memory subsystem to return data.

That did not occur in the measured execution.

The observed LW-to-SW bubbles instead reflect the timing rules of the current in-order pipeline and its forwarding paths.

The memory operation completes according to the expected pipeline schedule, but the immediately following store cannot use the loaded value soon enough to proceed without a bubble.

This behavior is predictable and local to the instruction sequence.

It may potentially be reduced through compiler scheduling, additional forwarding logic, or changes to the pipeline implementation. Such changes would involve a trade-off between hardware complexity and the performance gained from eliminating this specific hazard.

The current design retains the simpler pipeline.

Absence of Arithmetic Dependency Stalls

No stalls caused by dependencies between arithmetic instructions were recorded during the benchmark.

This indicates that the available forwarding behavior was sufficient for the arithmetic instruction sequences used by the BLAKE3 implementation.

The remaining bubbles were associated specifically with load-to-store use.

This result is useful because it isolates the primary pipeline limitation observed in the benchmark.

The cluster IPC was therefore achieved despite a known and identifiable in-order pipeline hazard, rather than through the absence of all instruction dependencies.

Load Distribution Analysis

The seven worker processors reported approximately the same IPC.

This indicates that the page-processing work was distributed evenly during active processing waves.

A highly unbalanced workload would produce a different pattern:

• some workers would remain heavily utilized;
• other workers would become idle;
• the coordinator would wait for one slow processor;
• aggregate IPC would fluctuate more strongly.

That pattern was not observed in the reported worker IPC.

The architecture and software organization therefore succeeded in distributing the BLAKE3 page workload across the available workers with no persistent per-worker imbalance.

Coordinator Overhead

CPU0 had a lower IPC than the worker processors: approximately 0.847 compared with approximately 0.898.

This does not mean that CPU0 was malfunctioning or underperforming.

The coordinator executes a different instruction mix.

Its responsibilities include message processing, task selection, completion tracking, tree management, and final-result construction.

These operations involve more branches and more control dependencies than the repetitive worker workload.

The coordinator also has periods in which its useful role is to wait for worker results rather than to execute continuous compression operations.

The difference between coordinator and worker IPC is therefore expected.

A future benchmark may investigate whether the coordinator becomes a bottleneck when the number of processors per cluster is increased beyond eight.

The current results do not show such a bottleneck for the tested configuration.

Interpretation of the Results

The benchmark should not be interpreted as evidence that a Memora8 processor is individually faster than a modern superscalar CPU core.

That was not the purpose of the experiment.

The experiment evaluates whether an architecture made from several simple processors can produce substantial aggregate instruction throughput when the workload is organized explicitly for parallel execution.

The answer for this BLAKE3 implementation is positive.

An individual worker remained below one instruction per cycle.

The cluster exceeded four instructions per cycle.

The highest measured result was 4.657 IPC, while longer inputs sustained approximately 4.6 IPC.

The performance came from parallel execution across processors, not from increasing issue width inside each processor.

Architectural Implications

The results support several conclusions about the Memora8 design direction.

Complexity Can Be Moved Out of the Individual Processor

High aggregate instruction throughput does not necessarily require a wide out-of-order core.

For workloads that can be decomposed into independent modules or pages, multiple simple processors can provide substantial parallel throughput.

Parallelism Must Be Explicit

Memora8 does not automatically discover arbitrary instruction-level parallelism inside one sequential program.

The software must express work in a form that can be distributed between processors.

BLAKE3 is well suited to this approach because its page hashing and tree operations can be assigned explicitly.

Memory Should Be Treated as a Working Set

The benchmark did not require the full dataset to reside in local SRAM.

A fixed set of pages was reused as the input progressed through the system.

This supports a model in which local memory is an execution resource rather than a complete copy of the dataset.

Hardware and Software Are Co-Designed

The measured result depends on both the processor architecture and the organization of the BLAKE3 implementation.

The hardware provides independent processors, local SRAM, page-based memory, and FIFO communication.

The software assigns work, reuses worker modules, and keeps the active working set bounded.

The resulting performance is produced by their interaction.

Experimental Limitations

The benchmark has several important limitations.

Simulator-Based Measurement

All measurements were collected using mr8sim v2.2.

They describe the behavior of the simulated Memora8 architecture.

They are not yet measurements from an FPGA or ASIC implementation.

The simulator is suitable for verifying architectural behavior, instruction execution, workload distribution, pipeline activity, and memory allocation. It does not by itself provide final hardware frequency, power consumption, thermal characteristics, routing constraints, or physical memory timing.

No Wall-Clock Throughput Claim

This article reports IPC rather than hashes per second or bytes per second.

IPC measures how effectively the processors use the available clock cycles.

It does not provide final throughput without a hardware clock frequency.

The operating frequency will depend on the FPGA implementation and later physical design decisions.

For that reason, the current benchmark does not claim a specific BLAKE3 throughput in MiB/s or GiB/s.

No Energy-Efficiency Measurement

The simulator results do not include physical power consumption.

The benchmark therefore cannot yet provide performance-per-watt measurements.

Energy efficiency will become measurable after the FPGA implementation is operational.

One Algorithm

BLAKE3 is highly parallel and maps naturally to a cluster architecture.

The result does not prove that every workload will achieve similar cluster utilization.

Sequential algorithms, workloads with irregular dependencies, or tasks requiring frequent global synchronization may behave differently.

Additional algorithms must be tested to determine the broader performance characteristics of the architecture.

One Cluster Configuration

The benchmark used one cluster with eight processors.

It does not yet show how performance changes with:

• fewer worker processors;
• more processors per cluster;
• several clusters;
• inter-cluster communication;
• concurrent independent workloads.

These are separate scalability questions.

Peak-IPC Explanation Requires More Instrumentation

The local maximum of 4.657 IPC at 48 KiB is consistent with efficient utilization during one six-page wave and relatively low coordination overhead.

However, a complete explanation requires a more detailed breakdown of committed instructions, idle cycles, FIFO activity, tree-reduction cycles, and coordinator waiting periods.

That analysis has not yet been completed.

Future Work

The next major step is to implement Memora8 on FPGA and compare the hardware behavior with the simulator results.

The FPGA stage should provide several additional measurements:

• achievable clock frequency;
• BLAKE3 throughput in bytes per second;
• power consumption;
• performance per watt;
• SRAM and logic-resource utilization;
• pipeline timing;
• FIFO behavior under physical timing constraints;
• correspondence between simulator cycles and hardware cycles.

Additional software experiments should include workloads with different computational structures.

Possible categories include:

• other cryptographic hash algorithms;
• stream ciphers;
• compression;
• network-packet processing;
• data transformation;
• database filtering;
• tree traversal;
• message-oriented services;
• workloads composed from several cooperating SekuraJS modules.

Future experiments should also compare different numbers of active workers to determine the scaling curve from one processor to the full cluster.

Cryptographic Scope

The cryptography work for Reganta and Memora8 is intentionally limited to a canonical core set.

The final canonical stack is:

• BLAKE3-256 — hashing, integrity checking, keyed mode, and KDF (derive_key);
• Ed25519 — digital signatures;
• X25519 — shared-secret agreement;
• XChaCha20-Poly1305 — authenticated encryption.

This is the intended root cryptographic profile for the architecture.

Everything else:

• SHA-2;
• AES;
• RSA;
• P-256;
• secp256k1;
• X.509;
• PEM;
• DER;
• and similar formats or algorithms

is treated as a compatibility layer.

Compatibility crypto is implemented in userspace JavaScript, and when needed, in SekuraJS.

It is not part of the mandatory cryptographic profile and must not become a dependency of the root trust layer.

Conclusions

The BLAKE3 benchmark confirms that the tested Memora8 cluster can achieve high aggregate instruction throughput without increasing the complexity of each processor.

The cluster consisted of eight independent in-order processors.

The worker processors operated at approximately 0.898 IPC, while the coordinator operated at approximately 0.847 IPC.

The highest measured aggregate cluster IPC was 4.657, reached during one processing wave of six pages.

For larger inputs, aggregate IPC remained approximately between 4.58 and 4.65, demonstrating sustained parallel execution rather than only a short peak.

The benchmark also showed constant local-memory usage.

As the input increased from 8 KiB to 8 MiB, local SRAM usage remained fixed at 29 pages, or 232 KiB.

The algorithm therefore scaled by reusing a bounded working set rather than by increasing the amount of fast local memory in proportion to the input size.

No memory-wait stalls were observed.

The recorded pipeline bubbles were caused by LW-to-SW load dependencies in the five-stage in-order pipeline.

The results support the primary Memora8 design hypothesis:

A cluster of simple independent processors can achieve an aggregate IPC above 4 without making each processor superscalar, out-of-order, or otherwise substantially more complex.

For Memora8, performance is not concentrated inside one increasingly complicated processor.

It emerges from the coordinated execution of several simple processors, explicit workload distribution, hardware message exchange, and repeated reuse of a limited local-memory working set.