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.
Factor subsystems out out for removing redundancy
Factoring out subsystems for them to
not be unnecessarily replicated and badly bottleneck underutilized
Blueprint data:
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.
Computing logic:
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 perspective 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 replicatibe capability.
Efficiency is not entirely irrelevant for for early systems
Beside the difficulty of compact self contained replication for bootstrapping Proto-assembler (outdated)
efficiency is not completely irrelevant for early systems either because
extreme inefficiency translates into additional difficulty.
More parts are less parts (smaller replication time)
A replicative system that shares parts with neighboring adjacent replicative 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 compactly self-contained monolithic.
Hugely reduced time of replication (by more parts):
Several mechanosynthesis units per heavily shared infrastructure
give a decent natural throughput efficiency.
Much higher than that of a compact self-contained self-replicator systems.
Good chance this is a 10x to 100x in gain not just a few percent.
No need for optimizing towards assembly lines:
Note that this higher efficiency is achievable entirely without
going to any fancy advanced optimizations like nanofactory like assembly line processes.
How desperately pressing for the smallest possible atom-count fatally backfires
When one is desperately pressing for the minimum atom count
due to one (unnecessary) assuming just one singe macroscopically local SPM tip
(as what is where many authors did and till do),
then one theoretically could go smaller by a a monolithic self-contained system, yes but …
There is caveat that makes this badly backfire.
If the necessary replication times goes up into the months and years range due to
the single mechanosynthesis stage having the responsibility to replicate infrastructure around
that has an atom count far beyond just the mechanosyntehsis stage itself,
then for a self replicating "protoassembler seed unit" with a mandatorily needed debugging cycle
getting to a working system in one fell swoop becomes just FAPP impossible.
Side-notes:
- Monolitic compact self-contained self-replicators usually assume just one single mechanosynthesis stage as that is what maximally compact an absolute minimum atom count means.
Also no space for luxuries like pick-n-place that could make tings enormously easier. - SThe packaged infrastructure is necessarily heavily bottle-necked and underused by the stage.
- Early nanoscale mechanosynthesis stages will run at lower frequency than advanced ones (there used sparingly for custom post-processing of molecular mill results).
And that difficulty from 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 experimental acessibility/observaliity/analytics/IO.
It is a big if here to assume there is a turnaround at all …
– with such a compact cube shape causing bad accessibility for debugging and
– with absence of any sellable side products for sustained long term funding of directed engineering efforts.
… Government funding for directed R&D has its suspense of disbelief limits too,
… and research funding is just not directed and
… needs to justify itself to people with finite suspense of disbelief too.
Related
- Why ultra-compact molecular assemblers are too difficult
- Molecular assemblers as advanced productive nanosystem (outdated)