Hello NVIDIA Developer Community,
I was recently directed to the NVIDIA Developer Forums by the NVIDIA Inception team after asking where an unconventional computing project could be discussed technically.
I want to present enough evidence here to make clear that this is a working experimental software system, not only a concept or a set of unusual names.
## Short version
MONOLYTH is an experimental reversible-computation research project built around exact, deterministic state transformations.
The current research family contains four systems:
1. MONOLYTH
2. BIREALITY ENGINE
3. RHAPSODY OF ABSURDITY
4. NEMESIS
The names are intentionally unconventional. The important part is the implementation and the measured behavior.
All four have been exercised as reversible software transformations, and they have also been integrated into a common 5,456-bit carrier and tested as a complete forward-and-reverse cascade.
The practical question for this forum is:
**Does this kind of workload have a technically meaningful CUDA/GPU path, and if so, what should be measured first?**
-
## 1. MONOLYTH
The native MONOLYTH state is:
- 1,984 bits
- 248 bytes
- 496 x 4-bit cells
- 8 transformation rounds
A dedicated bidirectional authority campaign tested 101,992 cases.
Result:
- forward/reverse mismatches: 0
- reverse/forward mismatches: 0
- total bidirectional mismatches: 0
- reversibility status: SUCCESS
This means the implemented transform is not merely statistically similar after reversal. The original state is recovered exactly, bit for bit, under the tested authority.
MONOLYTH has also been developed through optimization, scaling, real-corpus, inverse-performance, structural-execution, and utility experiments.
One frozen MONOLYTH-R authority was recently rebuilt and reverified from its protected source tree:
- FREEZE_HASH_CHECK = SUCCESS
- DEPENDENCY_HASH_CHECK = SUCCESS
- BUILD = SUCCESS
- DP_PLAIN_STREAM_MISMATCHES = 0
- DP_PROTECTED_STREAM_MISMATCHES = 0
- DP_EQUIVALENCE_STATUS = SUCCESS
- FINAL_FREEZE_STATUS = SUCCESS
The frozen authority contains source, accepted reference code, SHA-256 manifests, lineage records, and tribunal results.
-
## 2. BIREALITY ENGINE
BIREALITY ENGINE is a separate reversible transformation system developed above the same research lineage.
A frozen BIREALITY configuration operates on a 4,960-bit output field.
It was developed and frozen independently before being used in the later four-system integration.
The reason for mentioning it separately is important: the project is not one reversible function with several marketing labels. Different transformation structures were developed independently and then tested together.
-
## 3. RHAPSODY OF ABSURDITY
RHAPSODY OF ABSURDITY is another independently developed reversible transformation system.
Its later frozen integration vessel is:
- 5,456 bits
- 682 bytes
The current integration uses a reversible meeting/bijection structure over that field.
Like the other systems, RHAPSODY has its own frozen authorities and optimization/security records.
-
## 4. NEMESIS and the role of Gravity
NEMESIS is the fourth system in the four-system family.
Gravity is not a fifth member of the family.
Gravity was a separate experimental transformation line that became important in constructing the demonstrated combined MONOLYTH + Gravity reversible boundary used by NEMESIS.
This distinction matters:
**Gravity alone is NOT claimed to have a proven native inverse.**
The demonstrated reversible object is the combined MONOLYTH + Gravity boundary.
For that boundary:
- native state size: 1,984 bits
- preserved region: 1,024 bits
- masked/reversibly coupled region: 960 bits
- structural base cases: 8
- walking-one cases: 1,984
- random cases: 7,819
- total cases: 9,811
Measured result:
- boundary involution mismatches: 0
- forward/reverse mismatches: 0
- reverse/forward mismatches: 0
- invalid-state outputs: 0
- total bidirectional mismatches: 0
- combined reversible boundary: TRUE
So the claim is deliberately narrow: the combined boundary is reversible under the tested authority; Gravity by itself is not being advertised as something it has not been shown to be.
-
## 5. Four-system reversible cascade
The four systems were then lifted into a common carrier:
- carrier size: 5,456 bits
- carrier size: 682 bytes
The integration applies the four systems as distinct reversible operators and then executes the exact inverse path.
Conceptually:
MONOLYTH
↓
BIREALITY ENGINE
↓
RHAPSODY OF ABSURDITY
↓
NEMESIS
↓
inverse NEMESIS
↓
inverse RHAPSODY
↓
inverse BIREALITY
↓
inverse MONOLYTH
↓
original state
Four-system cascade authority:
- tested cases: 4,997
- failed final recoveries: 0
- cell errors: 0
- bit errors: 0
- full cascade status: SUCCESS
The final state recovered after the complete inverse path is byte/bit exact to the original input in the tested campaign.
-
## 6. Some measured software characteristics
A separate MONOLYTH-R research branch investigated whether the reversible representation has useful computational structure rather than only reversibility.
A few results from that work include:
- fixed general representation density: approximately 1.552555x
- optimized inverse throughput measured at approximately 160.43 MiB/s in the accepted optimization lineage
- measured structural-execution speedups on selected real workloads of approximately:
- 1.563x
- 1.627x
- 13.988x
These numbers belong to specific experiments and workloads. They are NOT a claim that MONOLYTH is generally 14x faster than conventional computation.
Likewise, none of these software measurements establishes a hardware energy advantage.
They are included because they suggest there may be enough nontrivial execution structure here to justify asking whether GPU mapping is worth investigating.
-
## 7. What is already demonstrated
At the software level, the project has evidence for:
- exact reversible state transformation
- exact forward/inverse recovery
- composition of heterogeneous reversible transforms
- reversible lifting into a common 5,456-bit carrier
- deterministic state preservation across inactive carrier regions
- reproducible frozen authorities
- SHA-256 protected source/reference packages
- clean rebuild and self-test of frozen authority code
- experiments on inverse execution, scaling, real datasets, and structural execution
The project contains source code and test records for these claims.
-
## 8. What is NOT demonstrated
I do not want to overstate the project.
The current evidence does NOT establish:
- that MONOLYTH replaces CUDA
- that it replaces a CPU or GPU
- a general-purpose processor
- a proven NVIDIA hardware advantage
- a proven transistor-count advantage
- a proven adiabatic implementation
- a proven reduction in physical energy dissipation
- a universal performance advantage
- that every part of the architecture is naturally parallel
- that reversible software automatically becomes useful reversible silicon
Those are open questions.
-
## 9. Why NVIDIA / CUDA is interesting to us
The architecture performs many deterministic transformations over fixed-size states and repeatedly exposes operations that may potentially be decomposed across cells, fields, carriers, or independent populations.
That makes several GPU questions interesting:
- Can independent states be processed efficiently as GPU batches?
- Can internal transformation structure expose useful thread-level parallelism?
- Is the workload compute-bound, memory-bound, or register-bound on modern NVIDIA hardware?
- Does exact inverse execution introduce synchronization or register-pressure problems?
- Could forward and inverse kernels share useful data layouts?
- Does the unusual 4-bit-cell / fixed-field structure map badly or well to CUDA integer instructions?
- At what population size does GPU launch/data-transfer overhead stop dominating?
- Would shared memory help, or would register/local-memory pressure destroy occupancy?
- Are there opportunities for warp-level operations or bit-sliced execution?
- Would a GPU implementation preserve bit-exact reproducibility across architectures?
-
## 10. What I would like advice on from CUDA developers
Before writing a large CUDA port, I would like to establish the correct experimental methodology.
Specifically:
1. **First CUDA prototype**
What is the smallest credible CUDA experiment for determining whether a fixed 1,984-bit reversible transform has useful GPU parallelism?
2. **Parallelization level**
Would you initially assign:
- one complete state per thread,
- one state per warp,
- groups of cells to threads,
- or many independent states per block?
3. **Data representation**
For a 496 x 4-bit-cell structure, would experienced CUDA developers first test packed nibbles, bytes, 32/64-bit words, or a bit-sliced representation?
4. **Performance counters**
Which Nsight Compute metrics would be most useful for deciding early whether the architecture is viable:
occupancy, achieved bandwidth, register count, warp execution efficiency, instruction mix, local-memory spills, cache behavior, or something else?
5. **Benchmark design**
What would this community consider a fair CPU-vs-GPU comparison for:
- forward transformation,
- inverse transformation,
- forward + inverse round trip,
- and large independent populations?
6. **Kernel fusion**
Would it be more sensible to benchmark each reversible stage separately first, or attempt a fused multi-stage kernel to reduce memory traffic?
7. **Architecture question**
If the strongest result eventually concerns reversible hardware structure rather than CUDA acceleration, is there another NVIDIA research/developer venue that would be more appropriate?
-
## 11. Reproducibility material
I have prepared a compact independent-review package containing the strongest current evidence rather than the entire historical development tree.
It includes:
- frozen MONOLYTH authority
- frozen BIREALITY authority
- frozen RHAPSODY authority
- MONOLYTH + Gravity bidirectional authority
- four-system integration source
- four-system cascade source
- post-freeze cascade regression
- evaluation launchpad
- technical dossier
- SHA-256 checksums
I can make the relevant source and verification material available for technical review.
I am deliberately not dumping thousands of historical experiment files into the first forum post. If someone wants to examine a particular claim, I can provide the exact corresponding authority and test record.
-
## 12. Why I am posting
The project has reached the point where another CPU-only experiment is less interesting than learning whether the architecture exposes anything meaningful on highly parallel hardware.
A positive answer would justify building a CUDA branch.
A negative answer would also be valuable. If experienced CUDA developers look at the workload and conclude that its dependency structure, state size, register requirements, or memory behavior make it fundamentally unattractive for GPUs, that is useful experimental information.
I am not looking for validation of the names or the concept.
I am looking for a technically defensible answer to:
**Is this reversible transformation architecture worth putting on an NVIDIA GPU, and what is the cleanest experiment that would tell us?**
Thank you.
Of course you can implement it in Cuda. Cuda has high parallelization, computation and memory throughput.
A FPGA may be another possible architecture.
(Another theoretical platform would be quantum computers, which - by design - have reversal computations. They use unitary evolution.)
1984 bits are 62 x 4 bytes. From the size it would just fit into a thread (a thread would need 62 registers to just contain one state), but would also fit well into a warp, however, processing as a warp you probably would have to mix data (with shuffle instructions and shared memory), and the lanes are quite separated.
How is the data operation on the state done?
If you represent one state as a warp, can you produce branchless, but possibly predicated code that operates on this state?
Then a whole warp can operate on 32 independent states with the same operations.
Do you even want to operate with the same operations (stages) on different states at the same time?
What kind of operations would you need? Table look-ups, matrix multiplications, bit shifts, arithmetic operations like polynoms?
Thank you,
this is exactly the kind of architectural feedback I was hoping for.
Your 62-register observation is particularly useful.
At the structural level, MONOLYTH operates on a fixed 1,984-bit state through a fixed sequence of 8 transformation rounds. The execution path is deterministic and the corresponding inverse executes the exact reverse transformation sequence.
For a first CUDA experiment, I am especially interested in the case of many independent states undergoing the same transformation at the same time. So yes, processing a large population of independent MONOLYTH states with the same stages is a very natural target.
My first thought had also been one complete state per thread, because it gives the simplest mapping:
one CUDA thread
one independent 1,984-bit MONOLYTH state
But as you pointed out, 62 x 32-bit words means 62 registers just to hold the state, before temporary values are counted. So register pressure and occupancy could become the limiting factor very quickly.
A warp-per-state implementation is therefore also interesting, especially because:
1 state = 1,984 bits
= 62 x uint32
which is close to two 32-bit words per lane across a 32-lane warp.
The question then becomes whether the additional lane communication through shuffle/shared-memory operations costs more than the register pressure saved by distributing the state.
Regarding the operations themselves, at a high level this is not a floating-point or large matrix-multiplication workload.
The architecture is dominated by deterministic fixed-width integer/state transformations: bit-level and small-cell operations, fixed state rearrangement/mixing, and reversible transformation stages. The native MONOLYTH representation is 496 cells of 4 bits each.
I do not want to publish the exact internal transformation mechanism in the first forum exchange, but I can provide a more precise operation profile next, for example:
XOR / logical operations
shifts / masks
indexed state movement
local cell operations
temporary-state requirements
dependency depth
amount of cross-word communication
measured directly from the current frozen implementation rather than describing it approximately.
One point I should also verify from the actual source before making a stronger statement is whether the complete current implementation can be expressed fully branchless. The round structure itself is fixed, but I would rather inspect the frozen implementation and report the exact amount of data-dependent branching than guess.
Your suggestion about FPGA is also interesting. I had been thinking primarily about CUDA because it gives us an accessible way to test massive parallel populations before considering dedicated hardware.
So I think the first experiment could be deliberately simple:
CPU reference:
N independent 1,984-bit states
CUDA:
N independent 1,984-bit states
same forward transformation
same inverse transformation
exact byte-for-byte verification
Then compare at least:
states/second
bytes/second
register count
occupancy
local-memory spills
memory bandwidth
kernel time
forward time
inverse time
forward+inverse round-trip time
I can prepare the exact operation profile from the frozen MONOLYTH source next. That should make the thread-per-state versus warp-per-state question much less speculative.
Thank you again, this already gives me a much clearer CUDA experiment to build.
I would go with one state per thread as a start.
You can have 256 registers per thread as a maximum with 256 threads (= 8 warps) running per SM. That is a good occupancy, especially if you have no or few memory operations.
The disadvantage of operating on registers is that you cannot index them. So if one cell of 4 bits determines the source or target of a data move within the state, you would have to
- use a switch case with up to 16x diverging lanes within the word
- or use dynamic bitmasks or dynamic shift/amounts
to select the correct source or target nibble (4 bits).
As overall data unit, I would use 32 bits (as is native for GPUs) and 8 cells per 32 bits.
You also should have an eye on the length of the resulting transformation stage. If it gets too long (many thousand SASS instructions), the instruction cache size can get the performance limiting factor.
With register accesses, you can typically read 2 registers and write 1 register per cycle per SM Partition (there are 4 SM partitions per SM).
With shared memory accesses, you can either read or write 1 32-bit value per lane per cycle per SM, if you can avoid all bank conflicts.
If each lane only operates on a single lane, you never will have bank conflicts. So using the shared memory instead of registers and being able to index is a real possibility. Also a mixed (registers+shared memory) architecture. Shared memory is up to 12x slower (4 SM partitions per SM and 1 instead of 3 accesses per cycle). If your GPU has 96 KiB of shared memory, and you want to use 256 threads, each could store 1.55 full states. So the size of shared memory is also limiting your occupancy, perhaps even more so than the number of registers.
Overall I think that a register-stored full state architecture using shared memory with fixed bank per lane (to fully avoid bank conflicts), and shared memory only for caching and indexed operations instead of full state storage, would be best. Target around 256-512 threads per SM.
If you need look-up tables, e.g. 4 bits → 16 possible results:
- if they determine instructions, use switch case
- if you need values (e.g. amount of shift, masks, etc.), don’t use constant memory, as it is slow for different values per lane. Also use shared memory look-up tables with individual copies per lane. A 16 entry lookup with a 32-bit result with copies for all 32 lanes has a size of 2 KiB. So you can store several of such look-up tables free of bank-conflicts.
Good Cuda primitives are the funnel shifter, the byte permutation and the LOP3 LUT for arbitrary 3 operand logical operations, which can use dynamic bitmasks. The first two can use a dynamic shift amount or a dynamic permutation. This enables to compute different operations on all 32 lanes without diverging threads. Additionally the select operation can select different operands and predicated instructions can turn on/off instructions per lane.
(Using a full warp to operate on one state would probably be too slow, except if your state really can be separated quite well into sub-states and most operations would only read and write within those sub-states and all sub-states would have the same operations in parallel. Even then your program gets a 32x penalty, because you only operate on one state at a time. With your numbers the occupancy of 256-512 threads per SM should be enough. So the only reason I would go with warp processing of a state is, if your stage gets too long and the instruction caches can’t cope. And even then, I would first divide the full stage into smaller sub-stages before switching to full warp per single state operation. It sounds good in practice, but is probably the wrong direction in your case with your numbers. The lanes are (data-wise) separated more than one would think. Even shuffle instructions use the shared memory hardware to combine different lanes.)
Your kernels should have 0 local memory spills. If you have them, you have done something wrong (e.g. dynamically indexed registers or used too many registers).
Reading and writing the initial and final state can be done with the lanes of the warp in cooperation by first storing in shared memory reading again to resort. Or by having a memory format with the same 4 byte parts of states beside each other in memory.
It can be that you have to generate your Cuda program, i.e. write code that writes your Cuda program. The final CUDA program can have many thousands of lines. The Cuda compiler (nvcc+ptxas) will be happier to operate on a linear static code and optimize the registers instead of feeding them a highly generic code with many sub-program calls or loops. You have to see, whether you create C++ or (inline) PTX.
I would expect your Cuda implementation to be around 100x-1000x faster than a CPU implementation. A bit less, if your transformations allow heavy use of AVX/SSE.