4 ms·
"every function was implemented in its own environment, meaning that every function was in its own context, and that every function call was therefore a context
by zackmorris 12y ago
"every function was implemented in its own environment, meaning that every function was in its own context, and that every function call was therefore a context switch!. As Colwell explains, this software failing was the greatest single inhibitor to performance, costing some 25-35 percent on the benchmarks that he examined."
It's too bad because this is the future of computing. Or more precisely - rather than having a "process" that owns child data and functions, future processors will default to every function running in its own isolated environment, defaulting to no shared state. There will be a more advanced copy-on-write permissions model that determines what's shared (if anything), more like shell processes or channels in languages like Go. To have that kind of scalability (with respect to future goals like multiprocessing) and security at only a 35% performance cost would certainly have been compelling, especially in the 1970s.
It's too bad that they didn't understand the physical limitations that make registers and caching basically a necessity, because it might have saved them. These things are only optimizations, so with today's available chip area and place and route techniques, they could be wedged into a conceptually correct architecture without much trouble.
In short, I would take these findings with a grain of salt and consider how technology has advanced to the point where yesterday's blunders might be tomorrow's breakthroughs.