4 ms·

> any language with GC is a complete nonstarter as a systems programming language If it was possible to write whole operating systems in garbage-collected LISP

> any language with GC is a complete nonstarter as a systems programming language If it was possible to write whole operating systems in garbage-collected LISP in the 80s, then it surely is possible to use a GC'ed language for systems programming thirty years later.

monocasa 7y ago
If you dig into those machines, anything vaguely real time including huge chunks of the drivers were written in user writable microcode.
- justin66 7y ago
  Sure, but that's not really a universal indictment of a system or a language. For example, C gets a lot of justifiable criticism, but the ability to drop down to assembly when it's needed is considered a feature and not a bug. The highest-performance gc systems (OCaml?) might very well be associated with functional programming languages, but the more relatable system for a lot of people might be the Oberon system, which did influence Go. I'm pretty certain Oberon did not rely on any hand-coded assembly to build a functioning workstation. (although, on the topic of microcode: the newest Wirth Oberon incarnation does have the student program an FPGA to run the system, as an exercise...)
  - monocasa 7y ago
    Oberon for sure depends on hand coded assembly. It's just in the compiler rather than .asm or .s files, but it's still a big blob of assembly that the type system and GC have no real knowledge of. Right now, state of the art for real time GC is that it's a huge trade-off between throughput and determinism. Like orders of magnitude lower throughput to be able to make guarantees that you'd expect out of a desktop system.
    - justin66 7y ago
      > It's just in the compiler What's your objection to having the compiler emit "hand coded assembly?" It's not clear to me what axe is being ground here. (that's true for me in a big picture way here too. There's a very strong argument against gc languages being made here and I'm not sure if you're saying Oberon doesn't count as a gc language, or what.) > Like orders of magnitude lower throughput to be able to make guarantees that you'd expect out of a desktop system. Do you have a current citation for that?
- nickpsecurity 7y ago
  More recent examples to check out were Spin (Modula-3), JX (Java), and House (Haskell).
mlindner 7y ago
It was also found in the 80s that any operating system written in LISP was dog slow. They even started making dedicated hardware interpreters of LISP to try and get around this. https://en.wikipedia.org/wiki/Lisp_machine https://en.wikipedia.org/wiki/Lisp_machine When you need to start designing your hardware around your computer language you know there's a problem going on.
- monocasa 7y ago
  To be fair those machines made sense at the gate counts we're talking about. They were true von Neumann machines with no caches, so the vast majority of the value add was putting the interpreter in microcode where it doesn't compete with the fetch bandwidth of the rest of the application. That's why CISC machines of the time tend to have mem(cpy/set/cmp) instructions, getting the instruction bandwidth out of the way of data heavy loads in a way that makes sense for the use case. That's also why these dedicated machines tended to disappear right as instruction caches became more standard; an I$ solves the same problem in a way more general way. As long as the hot path to your interpreter fits in I$, it's six of one, half dozen of another.
  - kazinator 7y ago
    It's not just putting the bytecode interpreter into microcode; there is the question of data representations suitable for Lisp, like pointers and numbers with tags. Caching doesn't really help with this. Even when everything is nicely in I$ and L1, it costs cycles to do the type checking. What helps is compiler techniques: type inference to eliminate some of the checks. But hardware can basically bury the cost of the checks; you can do them all the time on all operands.
- lispm 7y ago
  > It was also found in the 80s that any operating system written in LISP was dog slow. Lisp Machine operating systems were written in the mid 70s - developed for a new breed of computers: single user workstations with graphical user interfaces. They were developed at Xerox PARC and at the MIT AI Lab. > They even started making dedicated hardware interpreters of LISP to try and get around this. The machines were built to get around slow Lisp systems on time-shared computers with tiny memory. They wanted to have dedicated machines with memory exclusive memory for that one user. A bunch of stuff was then invented for those systems, including better automatic memory management like generational garbage collectors. Around 1980 (!) such machines were extremely expensive and still had tiny hardware: around 1 MB RAM and approaching 1 VAX MIPS of speed. Mid/end 80s they had 20 MB RAM and 5 MIPS... No wonder: an entirely new class of systems was developed on the slow hardware of the time.

monocasa 7y ago

If you dig into those machines, anything vaguely real time including huge chunks of the drivers were written in user writable microcode.

justin66 7y ago
Sure, but that's not really a universal indictment of a system or a language. For example, C gets a lot of justifiable criticism, but the ability to drop down to assembly when it's needed is considered a feature and not a bug. The highest-performance gc systems (OCaml?) might very well be associated with functional programming languages, but the more relatable system for a lot of people might be the Oberon system, which did influence Go. I'm pretty certain Oberon did not rely on any hand-coded assembly to build a functioning workstation. (although, on the topic of microcode: the newest Wirth Oberon incarnation does have the student program an FPGA to run the system, as an exercise...)
- monocasa 7y ago
  Oberon for sure depends on hand coded assembly. It's just in the compiler rather than .asm or .s files, but it's still a big blob of assembly that the type system and GC have no real knowledge of. Right now, state of the art for real time GC is that it's a huge trade-off between throughput and determinism. Like orders of magnitude lower throughput to be able to make guarantees that you'd expect out of a desktop system.
  - justin66 7y ago
    > It's just in the compiler What's your objection to having the compiler emit "hand coded assembly?" It's not clear to me what axe is being ground here. (that's true for me in a big picture way here too. There's a very strong argument against gc languages being made here and I'm not sure if you're saying Oberon doesn't count as a gc language, or what.) > Like orders of magnitude lower throughput to be able to make guarantees that you'd expect out of a desktop system. Do you have a current citation for that?
nickpsecurity 7y ago
More recent examples to check out were Spin (Modula-3), JX (Java), and House (Haskell).

mlindner 7y ago

It was also found in the 80s that any operating system written in LISP was dog slow. They even started making dedicated hardware interpreters of LISP to try and get around this. https://en.wikipedia.org/wiki/Lisp_machine https://en.wikipedia.org/wiki/Lisp_machine When you need to start designing your hardware around your computer language you know there's a problem going on.

monocasa 7y ago
To be fair those machines made sense at the gate counts we're talking about. They were true von Neumann machines with no caches, so the vast majority of the value add was putting the interpreter in microcode where it doesn't compete with the fetch bandwidth of the rest of the application. That's why CISC machines of the time tend to have mem(cpy/set/cmp) instructions, getting the instruction bandwidth out of the way of data heavy loads in a way that makes sense for the use case. That's also why these dedicated machines tended to disappear right as instruction caches became more standard; an I$ solves the same problem in a way more general way. As long as the hot path to your interpreter fits in I$, it's six of one, half dozen of another.
- kazinator 7y ago
  It's not just putting the bytecode interpreter into microcode; there is the question of data representations suitable for Lisp, like pointers and numbers with tags. Caching doesn't really help with this. Even when everything is nicely in I$ and L1, it costs cycles to do the type checking. What helps is compiler techniques: type inference to eliminate some of the checks. But hardware can basically bury the cost of the checks; you can do them all the time on all operands.
lispm 7y ago
> It was also found in the 80s that any operating system written in LISP was dog slow. Lisp Machine operating systems were written in the mid 70s - developed for a new breed of computers: single user workstations with graphical user interfaces. They were developed at Xerox PARC and at the MIT AI Lab. > They even started making dedicated hardware interpreters of LISP to try and get around this. The machines were built to get around slow Lisp systems on time-shared computers with tiny memory. They wanted to have dedicated machines with memory exclusive memory for that one user. A bunch of stuff was then invented for those systems, including better automatic memory management like generational garbage collectors. Around 1980 (!) such machines were extremely expensive and still had tiny hardware: around 1 MB RAM and approaching 1 VAX MIPS of speed. Mid/end 80s they had 20 MB RAM and 5 MIPS... No wonder: an entirely new class of systems was developed on the slow hardware of the time.