The Far Future of Programming: Ems

[fare]

I had the privilege of reading a draft of Robin Hanson's upcoming book on ems: emulated brains, that with specialized hardware could possibly run thousands or millions of times faster than the actual brain they were once templated from. This got me thinking about what kind of programming languages these ems would use - though most arguments would

Comments

[anhinga_anhinga]

> machine time is much cheaper than brain time, as long as it can be parallelized

Is this correct in this context?

[fare]

Yes, this is correct. Running an EM may require simulating hundreds of trillions of synapses, each requiring at least a transistor, possibly many more, though there is an obvious speed/time tradeoff. Whatever counts as a CPU cycle todays will be extremely cheap in comparison to that. On the other hand, fast ems are extremely latency-sensitive, and so "CPU cycles" are only cheap if they can be computed in parallel.

Transputer, Occam

[natmaka]

You may be interested in the good ole "Occam" language, associated to the Imos Transputer, and its derivatives.

Re: Transputer, Occam

[fare]

I saw transputers and Occam long ago and while it's OK, it's not as impressive as to e.g. the Connection Machine and *Lisp (also written and pronounced StarLisp), which are much more powerful and interesting.

I mean, implementing the Occam primitives is something I could trivially do with green-threads-on-top-delimited-continuations on Common Lisp + arnesi, and then I had higher-order parallel maps, etc., that you couldn't do well in Occam.

Meanwhile, in *Lisp you had interesting backquoting-like syntax to specify SIMD constructs, as well as all the higher-order functional toolkit of CL. (With delimited continuations, this backquoting would be trivial to reimplement.)