Parallelism
It’s about divergences in computer technology —
Or in other words, some conversations elsewhere have made it evident that it would be useful to have some of these things out here for discussion, and since this is going to involve comparisons to Earthling ways of doing things, it’s going to be a worldbuilding article rather than an in-universe one.
Some of this has been implied previously – for those of you who remember the little piece I wrote on programming languages in particular, in the opening phrase “The typical computer in use in the modern Empire remains the parallel array of binary-encoded Stannic-complete processors that has been in use since the days of the first settled Stannic cogitator architecture”.
So what does that actually mean?
Well, it means that while the individual elements of computation would be familiar to us – if you are reading this, you are almost certain to be doing so on something describable as a binary-encoded Stannic-complete processor – how they were arranged took a sharp left turn way back in the day.
Most of our computing is fundamentally serial. We may have fancy multicore processors these days, but we’re still pretty much scratching the surface or real parallelism; most systems are still operating in a serial paradigm in which you work on one task, switch to another, work on that, etc., etc. If you write a complex, multithreaded program, it may look like things are happening in parallel, but most of the time, they won’t be.
For various reasons – which may have something to do with the relative ease of adding power to the old brass-and-steam Stannic cogitators by adding more processor modules vis-à-vis trying to get faster reciprocation and higher steam pressures without exploding; or it may have something to do with older forms of computation involving hiring a bunch of smart lads and lasses from the Guild of Numbers and arranging them in a Chinese room; or… – once they got into the electronic (and spintronic, and optronic) era instead of trying to make faster and faster serial processors¹, designers concentrated on making processors – with onboard fast memory and communications links – that could be stacked up, networked, and parallelized really well, complete with dedicated hardware and microcode to manage interprocessor links.
(You could look at something like Inmos’s Transputer as similar to early examples of this.)
Open up an Imperial computer, you’ll find a neat little stack of processor modules meshed together, working away on things in parallel and passing messages back and forth to stay coordinated. In modern designs, they share access to a big block of “slow memory”, possibly via one or more partially-shared caches, just like here‘s multicore processors do, but that doesn’t change the fundamentals of the parallel design.
And this architecture doesn’t change with scale, either. From the tiniest grain-of-rice picoframe found in any living object (three processing cores for redundancy, maybe even only one in the tiniest disposables) to the somewhere-between-building-and-city-sized megaframes running planetary management applications, they’re all built out of massively parallel networks of simple processing modules.
[Digression: this is also where the gentle art of computational origami comes into play. In the magical world in which the speed of light, bandwidth, and information density are conveniently infinite, you could fully mesh all your processing modules and everything would be wonderful. In the real world in which light is a sluggard and bit must be it, you can only have and handle so many short-range communications links – and so computational origami teaches you how to arrange your processing modules in optimally sized and structured networks, then stack them together in endless fractal layers for best throughput. More importantly, it teaches the processors how to manage this environment.]
[Second digression: having spent a lot of time and effort producing simple, networkable processor cores, this also rewrote a lot of how peripheral devices worked – because why would you waste a lot of time fabbing specialized silicon for disk controllers, or GPUs, or floating-point units, or whatever, when you could simply throw some processing cores in there with some “firmware” – for which read “software flagged as tied to hardware feature flag foo, instance bar” – and get to the same place?
So, for example, when you think “printer”, don’t think “dumb hardware operated by a device driver”. Think “processor that knows how to draw on paper; all I have to do is send it a picture”. Pretty much every peripheral device you can think of is implemented in this way.]
This has also had rather a profound effect on how everything built on top of it works. I spent quite some time discussing how programming languages worked, along with MetaLanguage (the bytecode that these processors have more or less standardized on speaking) in the above-linked post, but you may note:
Polychora: a general-purpose, multi-paradigm programming language designed to support object-, aspect-, concurrency-, channel-, ‘weave-, contract- and actor-oriented programming across shared-memory, mesh-based, and pervasively networked parallel-processing systems.
…because once you grow to the size – and it doesn’t take much size – at which programming your parallel arrays in relatively low-level languages similar to Occam begins to pall, you start getting very interested in paradigms like object/aspect/actor programming that can handle a lot of the fun of massively parallel systems for you. This has shaped a lot of how environments have developed, and all the above language environments include compilers that are more than happy to distribute your solution for you unless you’ve worked hard to be egregiously out-of-paradigm.
And the whys and hows of WeaveControl, and the Living Object Protocol.
This has also, obviously, made distributed computing a lot more popular a lot more rapidly, because having been built for parallel operation anyway, farming out processing to remote nodes isn’t all that more complicated, be they your remote nodes, or hired remote nodes, or just the cycle spot market. Operating systems for these systems have already developed, to stretch a mite, a certain Kubernetes-like quality of “describe for me the service you want, and I’ll take care of the details of how to spin it up”.
In accordance with configurable policy, of course, but except in special cases, people don’t care much more about which modules are allocated to do the thing any more than they care about which neurons are allocated to catch the ball. In the modern, mature computing environment, it has long since become something safely left to the extremely reliable optronic equivalent of the cerebellum and brainstem.
Now as for how this relates to, going back to some of the original conversations, starships and AI:
Well, obviously for one, there isn’t a single computer core, or even several explicitly-designed-as-redundant-nodes computer cores. There are computers all over the ship, from microcontrollers running individual pieces of equipment up – and while this probably does include a few engineering spaces labeled “data center” and stacked floor to ceiling with nanocircs (and backing store devices), the ship’s intelligence isn’t localized to any one of them, or couple of them. It’s everywhere.
If your plan to disable the ship involves a physical attack on the shipmind, you’ve got a lot of computing hardware to hunt down, including everything from the microcontrollers that water the potted plants on G deck to the chief engineer’s slipstick. You have fun with that. Briefly.
As for AI – well, digisapiences and thinkers operate on the same society-of-mind structure that other minds do, as described here. When this interrelates with the structure of parallel, distributed computing, you can assume that while they are one data-structure identity-wise, the processing of an AI is organized such that every part of the psyche, agent, talent, personality, subpersonality, talent, mental model, daimon, etc., etc., etc., is a process wrapped up in its own little pod, off running… somewhere in what looks like a unified cognitive/computational space, but is actually an arbitrary number of processing cores distributed wherever policy permits them to be put.
(If you choose to look down that far, but outwith special circumstances, this is like a biosapience poking around their brain trying to find out exactly which cells that particular thought is located in.
Said policy usually mandates some degree of locality for core functions, inasmuch as light-lag induced mind-lag is an unpleasant dissociative feeling of stupidity that folk prefer not to experience, but in practice this non-locality manifests itself as things like “Our departure will be delayed for 0.46 seconds while the remainder of my mind boards, Captain.” Not a big deal, especially since even protein intelligences don’t keep their whole minds in the same place these days. They wouldn’t fit, for one thing.)
But suffice it to say, when the avatar interface tells you that she is the ship, she ain’t just being metaphorical.
- Well, sort of. It’s not like hardware engineers and semiconductor fabs were any less obsessed with making smaller, faster, better, etc. processors than they were here, but they were doing so within a parallel paradigm. “Two-point-four-billion stacked-mesh processing cores in a nanocirc the size of your pinky nail!”, that sort of thing.