@p @scathach @jeffcliff @sicp @Suiseiseki > I have not ever seen a case where serialization was slower than the disk or the network.

Any slowdown including that initial delay is undesirable, but that initial one can't really be eliminated. That's no reason to keep the others.

> I shove a 20GB log file through awk and don't have this problem. Fancy NVMe storage, ARM CPUs (and gcc still sucks for optimizing ARM), and *still* everything is I/O-bound.

You're using a single awk program instead of a bunch of programs with pipes & buffers between each (and no real need for serialization either).

Obviously it'll work fine. Epsecially since awk was designed for the specific kind of text processing you're doing.

Split out every one of the tasks into a different program and pipe them, you'll get the kind of result I'm talking about.

> The perpetual lament: "this machine was written to run C and Unix, Lisp would be faster if the CPU and the OS and the compiler were designed from the ground up to be faster for Lisp". It's always asserted and never backed up with a working CPU design. We've got FPGAs all over now, you can do this at home, implement type-tagging in the MMU, go nuts. Build it and get back to me.

There's no need for that.

>> We've got half of those. I think you could assemble a plausible Lisp workstation if you build out the Lisp environment on top of the rest. That is, you do it like OpenStep/GNUStep, or like Arcan.

That provides the same kind of environment I'm suggesting.

Medley Interlisp would be another historical example of that overlay environment concept.