Replication backpack overhead
Or replication backpack overhead.
The more monolithic, compact, self contained, and complete a self replication process ought to be
the more stuff needs to be replicated and possibly even lugged around (thus replication backpack).
- Replicating the code for replication in hardware storage (like cells in DNA) usually not considered for technical systems.
Note on that further below. - Replicating status bits and compute that otherwise could be broadcast shared for several systems
- Replicating data IO channels rather than saving by sharing them over bigger subsystems
- Replicating higher assembly levels stages for each system making them heavily underutilized rather than sharing
- restricted balancing with power units
- and many more
More distributed systems can avert these issues: See:
Factoring parts out to reduce the replication backpack overhead
If everything is factored out to avoid the replication backpack entirely
then the system is no longer a compactly self-contained self-replicating one
and one instead gets a distributed system of completely different character.
Early diamondoid nanosystem pixel (direct path)
If only parts are factored out
then potentially large parts of the replication backpack overhead remain.
Factoring out subsystems fro them to not be unnecessarily replicated and/or badly bottleneck underutilized
The most self suggesting first step is to factor out the blueprint data.
(i.e. not having the analogy of DNA in every living cell)
Then minimizing local compute as this is a huge dominant part of such systems.
This means more data needs to be transmitted across the interfaces which (depending on design) may be more problematic for self contained replicating units operating in 3D lattices than for more distributed systems that have high enough throughput to stay in 2D.
Up to this point from nanoscale perspectibe replication is still compactly self contained.
Factoring further
But why not go further for massive gains by factoring out: – mechanosynthesis stages units – tooltip magazine units – crystolecule magazine units – stick-n-plave assembly stage units – stage driving motor units – unit carrying units drive units – crystolecule zipper units
All of which can me mixed an matched in willy-nilly ratios. Just as needed for the most feasible way forward. And to eventually relpicatibe capability.
Relevant for early systems
A relplicative system that shares parts with neighboring adjacent repilcative systems i.e. a replicative system that is dispersed and has blurred boundaries between the replicative units needs overall significantly less parts per averaged replicative unit than a replicative system that is comactly self-contained monolithic.
Sevral machanosynthesi units per heavily shared indrastructure give decent natural throughput efficiency and that entirely without going to any fancy optimzations like nanofactotry like assembly line processes.
When one is absolutely desperately pressing for the absolute minimum volume then one theoretically one could go smaller by a monolitic self contained system. Yes but theres is a big caveat. If the necessary replication times goes up into the month and years due to mechanosynthesi stages being massively bottlemecked by responsibility to replicate infrastructure massively beyond their own atom count then for a self repliating unit with a mandatorily needed debugging cycle getting to a working system in one fell swoop becomes just FAPP impossible.
That long turnaround time is multiplicatively exacerbated by compactly self replicating system designs usually taking the form of 3D cubes rather being laid out flat and thin on a chips surface for an as easy as possible expeimental acessibility/observaliity/analytics/IO.
Related
- Why ultra-compact molecular assemblers are too difficult
- Molecular assemblers as advanced productive nanosystem (outdated)