Chapter 57: Farker: building a better mousetrap
Farker couldn't believe what he was seeing. “Are you sure this is right?” he asked Finder. “There's no way coherent actions could come out of that. It can't be stable – it's completely chaotic!”
“That's what I thought,” said the Finder. “But it is stable, or at least metastable. The changes are ongoing and endless, yet they never generate a page fault or null pointer errors. I have no explanation for it. From current theories it should be impossible.”
They were looking at a 3D section of the vast spintronic lattice that served the hypercomputer as active working memory. Data was stored here, but it would have been unrecognizable as such to computer scientists of the previous century.
In the earliest days of computing, there was drum, RAM, and ROM. Drum memory derived from ancient magnetic cores, where intersecting currents threaded through tiny iron donuts, magnetizing or demagnetizing them. It took a lot of this 'core' memory to store even a little data.
But the technology continued to evolve, far faster than the species that created it. It evolved into drums and hard drives that used miniature read-write heads that had electromagnets to 'write' data onto magnetizable surfaces. They scribbled magnetic patterns on regions of it like primitive 'tape recorders' did on Mylar-backed magnetic tapes.
A magnetized region held data a long time, even when these primeval computers powered down. But reading and writing this magnetic memory was limited to how fast the drums or discs could spin, because you had to move the written area out of the way to write the next part.
The next kind of memory created was RAM, Random Access Memory. RAM stored data as hordes of tiny transistors, some turned on, some off, to make ones and zeros. The circuits didn't have to move like hard drives did, because you could point to a different circuit just by changing the 'address' you wanted...like dialing a different phone number. RAM could be read and written quickly, but it had the drawback of losing information if it lost power. Handy if you wanted to randomize (erase) a large section of memory, but inconvenient in the days of unreliable power supplies: the RAM without power reverted to meaningless garbage, data-less deserts of random ONs and OFFs.
Thus the technologists created ROM or Read Only memory. It was like RAM, except you couldn't change it. Whenever you turned it on, the exact same bits would go on or off. It was like having a thousand light bulbs in a sign and then deliberately burning some of them out to spell a word or draw a picture with light and dark dots; whenever you turned the sign on, the working bulbs would light up and the burned out ones wouldn't; the exact same word or picture would appear. You never lost information by turning the power off.
This was great for programs that slowly changed, like operating systems. Primitive computers would boot up the OS from ROM chips so that they could hit the ground running and start working. The next generation of computers would use the next generation of chips.
Many other technologies evolved for computer memories, but they could all be treated like RAM or ROM. All you had to ask was, 'does it remember when I turn the power off?' to tell the difference.
The 21st century brought a major change in memory storage with the advent of quantum computers and spintronic memories. Quantum computers performed unbelievably rapid calculations by collapsing the wave functions of group-entangled particle arrays. Spintronics represented a paradigm shift in data storage: data was no longer stored as on or off circuits in RAM or ROM or North or South magnetic domains on discs coated with iron compounds. It was stored in the components of spin of an atom's nucleus, or of its electrons. A single particle could store more than one bit, because it had more than one perpendicular spin component! A single atom with eight electrons in its outer shell could entangle two 8-bit bytes.
It's hard to attach wires to atoms to control them. But quantum dots could function as artificial programmable atoms, 'parking lots' for electrons, larger than actual atoms, where you could stash them in stable pseudo-orbitals that required no nucleus at the center...and you could attach tiny wires to these dots and tweak their properties at will. Connect a lot of these in a dense 3D matrix, and the memory capacity of storage devices became enormous. Big enough, in fact, to satisfy the ravenous hungers of the new quantum computers for working memory. Needless to say, self-assembling nanoparticles were a key ingredient of the process: the quantum dots grew themselves.
It combined the best of RAM and ROM. You could access it quickly, change it quickly...and it needed no power to remember its data, because electrons never stop spinning – they are like perpetual motion gyros. You needed redundancy, of course, because random thermal perturbations could disturb and perturb the wave functions, causing decoherence of the entangled data (and flaws could appear in the best of fabricated devices). But these were mere details. With the vast capacity now possible, there was plenty of room to store the data multiple times and put in checking routines to use majority voting to cancel out any random changes. Spintronic memory was a programmers dream.
At the Dirac Institute, Farker had been a part of the excitement of those early days. He'd worked with people designing the first practical large-scale quantum computers. He knew how they were supposed to work, both the hardware that stored the data, and the software that ran on them. He also had no life at all, because his genius had been spotted at an early age. At thirty he had still been a virgin when he met Cecilia.
Don't dredge all that up, he told himself, looking at what he knew should be impossible.
Farker knew what all programmers know, that the memory changes in a running computer program, no matter what it used for its storage medium, were orderly to the point of obsession. They had to be. Are you copying memory from one place to another? Then the computer reads the first byte, writes a copy of it in the new location, then reads the next byte, stores a copy of it, and so on, with inhuman speed and patience. It's like building a copy of a brick wall; the position of each new brick depends on what you have already placed.
This process is fundamental to orderly processing. Sure, you need to do calculations and lookups and whatnot. But whatever you calculate, look up, compare, or create, the result has to be stored somewhere, in such an orderly way that it can be retrieved as easily as it was written, byte by byte, like reading pages in a book or dealing cards from a deck. Order is crucial to computing. It's why many successful programmers come from obsessive personalities. Order is good. Love the order! Or find another business.
What he was seeing, however, appeared to have no order.
Pieces of Aes's memory region in the PanGames spintronic lattice were changing for no apparent reason. It was like looking at the 3D shadow of a multidimensional kaleidoscope. Parts of it changed themselves. Parts of it changed other parts. Parts of it were changing the parts that were changing them. He could not see any fundamental order to it at all. Madness! It was programming madness. No one would write code like this! For the life of him, he could not see how any of it was avoiding infinite loops or memory boundary errors or a dozen other things that should be going wrong. And yet it continued to hum along perfectly, organically, doing whatever it did. Impossible! his mind wanted to scream.
It was the creation of a madman...or a mind so far beyond his that his own 185 I.Q. brain was laughably retarded in comparison. Since it continued to function, he was forced to admit that it was some kind of super-genius elegance that eluded him. Something he himself would never achieve, no matter how much he studied it. It was like staring at infinity and trying to count it. It was like looking at an ocean, when all you had was a teacup. You could never fit it in, never grasp the entirety of this higher-order elegance. And it was growing.
Farker growled. He did not like feeling retarded! He had never felt this way before in his life, and he was old.
He had a sneaking suspicion that Am-heh's code might look similar...if they could locate it. But how do you scan for a pattern...when you don't know what the pattern is? He growled a
gain. Where are those billion Shakespeare monkeys when you need 'em?
“I'm not asking you to explain it,” he told Finder. “All I want to know is, how fast is it growing? Is the rate stable?”
Finder paused. Was it zerged? “The region is now 18.2 exabytes and is growing at a shallow exponential rate.”
The word exponential had ominous undertones. “How shallow? How long before it becomes a problem?”
“That depends on what you mean by a problem,” said Finder.
“I'll make it simple for you,” Farker growled. “How long at current rate of increase until he'll need so much storage that he'll crash whatever Realm he's in?”
Finder paused. “One month,” it said. “If the rate was linear, I could hold him for a hundred years, assuming no memory upgrades or technological advances extended my room. But the growth is not linear, it is exponential.”
Farker swore. He used words he hadn't needed for decades. “You're telling me he has a month to live.” And it would take me a million lifetimes to understand this code, he thought. Instead, I've got one month, at the outside.
“Less, if the rate itself accelerates,” said Finder. “And less than half that, even at the lower rate, if Am-heh were in the same Realm, assuming his code is similar. ”
So if any more of these anomalies show up in the meantime, he thought grimly, PanGames is toast.
“What happens if the Realm he is in crashes? Would it affect any other Realms?”
“No,” Finder answered promptly. “As you recall, the PanGames design calls for a separate spintronic lattice segment for each Realm, for convenience and security. We have never needed to, but if we did, we could shut down any Realm for maintenance without any impact on other Realms.”
“How much redundancy do we have in the spintronics arrays?” asked Farker.
“There are 32 additional unallocated matrix blocks currently available for future expansion,” Finder informed him. “You never imagined we would go beyond 48 Realms, but your specs allowed for 100% redundancy in the initial design. There is room for 96 total.”
“New project,” said Farker. “Prepare one of the 32 unused segments for content. Designate the new Realm 'Paradise'.”
“Done.”
“Now clone a copy of Hellas into it, excluding everything but Greece, leaving out all other regions, NPCs, and avatars. Just an empty copy of Greece.”
Finder paused for a couple of minutes, the longest pause Farker could recall. “Done.”
“Now, could Paradise hold Aes longer than a month?”
Pause. “By emptying it, you've bought him a few days. No more.”
Farker swore again. “That's all?”
“By the end of a month, the exponential acceleration of the growth reaches a rate such that a completely empty Realm consisting of only one room makes little difference in the deadline.”
Farker sighed. “Well, at least it's a better mousetrap. There are no mobile entities in Paradise now, right?”
“Correct.”
“So if we can get Am-heh to go in there...you will instantly know his program ID, right? No matter what reformatting has done to his name.”
“Affirmative. But how do you propose to do that?”
“We just have to find the right bait,” Farker said, grimly. “I believe he has been looking for Darla ever since she escaped him in Egypt.”
There was a pause. “You cannot use Darla as bait,” the Finder told him. “Placing any registered user in jeopardy would constitute a violation of user safety protocols.”
“FUCK the protocols!” Farker barked. “Letting Am-heh rampage around eating users into vegetables, doesn't THAT violate user safety protocols? It's the lesser of two evils. Look, when we find him, I'll go piss him off myself and lead him in there. Once he follows me in I'll pop back out and we slam the door, disable his command access! You can do that, once you know his program ID, right? Then we let him commit suicide; the bastard will grow himself to death and crash his own Realm. End of problem.”
“It won't work, Farker,” the Finder said.
Farker gritted his teeth. “And why not?” he said defiantly.
“Because you are a registered user. User safety protocols apply to GM-class users as well as mere subscribers. My safety rules would force me to stop you from entering. As the only other mobile entity, you would be his obvious next target, and, thus, exposed to unacceptable risk.”
“Are you saying there is no way to lure him in there?”
“Placing any registered user in jeopardy would constitute a violation of user safety protocols,” Finder repeated.
Farker stopped and took a breath, tasting an idea. The emphasis had seemed slightly different in that last repetition. He had the feeling that Finder was trying to tell him something.
“Aes isn't a registered user, is he?” he said.
“Correct. The anomaly 'Asklepios' is not a registered user. And his name never reformatted, so we know his program ID. Do you wish me to terminate his process execution?”
“No!” Farker bellowed, before he could stop himself. He took another breath to calm himself. That had been a close one. “What you implied, however, is that Aes could act as the bait...the bait we need to get Am-heh in there.”
“Correct. Safety protocols do not apply to either Asklepios or Am-heh, since they both have no user account.”
“But it would be a bigger risk for Aes, wouldn't it?”
“Correct,” said Finder. “If the Realm crashed with you in it, assuming you had not been eaten, you would wake up on your link bed. Collapsing the wave functions would drop you back into your own body, in an automatic logout. Asklepios, on the other hand, has no body to go back to. He therefore has no automatic exit. Collapsing the wave functions would terminate his processes.”
“Couldn't you just take a snapshot of his code before the crash, copy it somewhere else and restart him?”
Pause. “Negative. As you have undoubtedly noticed, his code appears to embody irreducible complexity. We would have no idea where to begin the execution of the code.”
“Oh, come on!” Farker exploded. “It's just code! How hard could it be? You just make a copy of the snapshot, try starting it at one location, and if that fails, make another copy and try one byte over, repeating as necessary until you get it right.”
“Affirmative,” said Finder. “But assuming 18.2 exabytes of active code, as he had a couple of minutes ago...and performing that process one thousand times per second, assuming I could copy memory that fast, would take an average of 2.88 times ten to the eighth years to find the correct starting address.”
Farker swore again. “288 million years? But that's a pessimistic case, right? You might get lucky in the first thousand seconds, right?”
“It is only an average,” Finder agreed. “But you are forgetting an important point that renders such estimates useless.”
“More important than the fact that we'd have to wait for our descendants to crack the problem before the Sun turns into a red giant? What point?”
“You have seen the complexity of his code. It is overwhelmingly probable that it embodies many concurrent processes, all of which would have to be started up...and in the correct order. This increases the complexity of the restart process. Would you like to hear revised estimates?”
“Not if they're more than hundreds of millions of years. Wait a minute! If restart is so hard...how do these entities move from one Realm to another? How does anyone else do it?”
“With ordinary users, all that actually moves is a relatively compact assembly consisting of the avatar description and subroutines that communicate with the link bed sockets. This allows many avatars to coexist in each Realm with plenty of memory to spare for scenery.”
Finder paused. “Since Asklepios and Am-heh have no remote to communicate with, their entire descriptions move. Although this seems cumbersome, it is in fact possible to move running programs in this manner, provided segments are moved
only when execution has passed to other segments. Quantum computation is fast enough to accomplish this in time frames so short as to be imperceptible.”
“All right,” said Farker. He was not giving up this easily. “We could talk Aes into being bait. After all, he's doomed anyway, right? At least this way he can do something noble before he goes.”
“It appears possible,” said Finder.
“Suppose we brief Aes and get him ready. He might be able to lead Am-heh into the dummy Realm, then jump out before Am-heh knows what's happening. Then we scrag the Realm and Am-heh is gone, right? We could even set it up so that Aes leaving is what triggers the Realm crash.”
“It might work,” Finder admitted. “But don't forget, if we assume Am-heh is roughly equivalent to Aes, his reaction time should be the same. It's not a program outsmarting a biological – they're both very fast.”
“Start getting a hackproof crash routine ready, anyway,” Farker ordered. “Who knows? Maybe we'll think of something before then that will keep Am-heh from leaving the killing field.”
Chapter 58: Am-heh: the thrill of the chase
Gamers and Gods: AES Page 65