[retrac]

Mesa/Cedar, early Smalltalk, and Oberon are/were all primarily interpreted languages. And this was before JIT was common. So, significant overhead. Some of them had special hardware assists, like Mesa and the Xerox Alto with a processor designed around the language. Still not a speed demon, despite that. I believe they were more concerned with code density than speed. Cramming a networked multitasking operating system into about 128 KB of RAM is not trivial.

Such languages would be pretty painful on another architecture implemented as interpreters. I don't have exact numbers. But roughly an order of magnitude slower. Think Perl and Python vs. Pascal and C.

Things have changed a bit since then. Oberon is usually compiled to native code now and Squeak uses a JIT compiler. And Mesa/Cedar are extinct.

[kragen]

Hmm, I think Cedar and Oberon compiled to native code from very early on, perhaps the very beginning (I don't know of an interpreted version of either), and the reason I mentioned Smalltalk-80 in particular was Deutsch & Schiffman 01983 where they popularized JIT compilation and in particular introduced the first version of the inline-cache technique that makes Java monomorphic (and non-megamorphic) method calls fast today.

To quibble about one more thing, multitasking doesn't increase memory requirements significantly on anything big enough to run an interpreter. On this amd64 machine under Linux, sizeof(jmp_buf) is 200 bytes; that's how much space each new task would needs, plus of course the size of its stack. If I build for i386, it's 156 bytes. But of course you can define the calling convention to reduce this: on 16-bit Forth systems a suspended (cooperative!) thread was typically a data stack pointer, a return stack pointer: 4 bytes. (But typically each thread had its own dictionary of at least 4K.) Preemptive multitasking generally requires at least the size of the register file, since you can't discard caller-save registers on every context switch.

What does increase memory requirements enormously is memory protection — not mere multitasking but allocating exclusive segments or pages to each new program. That's a big part of the appeal of systems like Oberon, Smalltalk-80, and of course early Oak/Java: by implementing memory protection at the language level rather than the hardware level, you could get very fine-grained memory sharing without endangering system stability.