Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

An immutable operating system

augustl.com

Post reply on HN
Print view View original

91–100 of 153 posts

Re: An immutable operating system

#91

Post by masklinn »

stcredzero wrote: post #90
masklinn wrote: post #39

Earlier quoted context omitted.

> This might actually have significant performance benefits. Not really. On the other hand, it makes the implementation of GCs much simpler. (immutability semantics also tends to make memory churn much higher, so what little gain you get from a simpler implementation is often lost in the GC having to do more work) Also, it's not like these things are unstudied FFS.

It's not just GC, but virtually pause-less GC that is the possible benefit. Yes, these things are studied, but I would challenge you to find a free high level language implementation with GC suitable for soft real time. Right now, I know of Erlang, which isn't the fastest language and running Clojure on the proprietary Azul VM.

I'm not sure what you're trying to say. If no such implementation exists, even though there are a number of languages predicated upon immutability, one would conclude "virtually pause-less GC" isn't such an obvious or easy "possible benefit" of immutable structures.

Unless you're using refcounting: since immutable structures can't create cycles, a refcounting GC won't need a cycle-breaker, and thus won't need to ever pause. But you'll be using throughput (especially for allocation I'd guess).

Also not sure what your point is re. Azul, immutability is not what enables it since Zing is first and foremost a java VM.

Re: An immutable operating system

#92

Post by procrastitron »

cwzwarich wrote: post #85
sillysaurus2 wrote: post #76

Earlier quoted context omitted.

Forget garbage collection in the sense of any variant of mark-and-sweep. For an operating system latency is more important than through put, so you really want real time memory management. Is the assumption that mark and sweep is slower than real-time memory management? It's actually been proven false, e.g. the .NET CLR runs faster than native C code in certain situations. If you use reference counting, then there is…

Tracing garbage collection has better throughput than reference counting, but reference counting has lower and more predictable latency. If you were actually going to try do tracing GC on the operating system level, you would probably have to use one of the more involved GC algorithms that require kernel support like Azul's C4 collector.

"Tracing garbage collection has better throughput than reference counting, but reference counting has lower and more predictable latency."

Exactly this. I would actually back off a bit and only claim that reference counting has more predictable latency, but the point is to sacrifice throughput in order to reduce worst case latency.

Re: An immutable operating system

#93

Post by chongli »

gohrt wrote: post #89
augustl wrote: post #57

Earlier quoted context omitted.

Author here. The language is the part I also dread the most, and is also the part that will be the least unique and the least interesting to "re-invent".. I'll look into finding an existing language that runs on bare metal and that has (or supports) immutable values.

Haskell

There's actually been a bit of work on this very idea!

http://programatica.cs.pdx.edu/House/

Re: An immutable operating system

#94

Post by masklinn »

stcredzero wrote: post #88
lisper wrote: post #49

Earlier quoted context omitted.

Doesn't matter. In an immutable model, the old copy is guaranteed not to change, so you can safely copy it non-atomically. (That's one of the big benefits of immutability.)

Which makes really good incremental collection much easier to write

But not faster.

Re: An immutable operating system

#95

Post by chubot »

augustl wrote: post #57
procrastitron wrote: post #54

I wrote an operating system in a purely functional dialect of Lisp; http://losak.sf.net There are a few things I learned in the process that I think are relevant here: 1. Forget garbage collection in the sense of any variant of mark-and-sweep. For an operating system latency is more important than through put, so you really want real time memory management. If you use reference counting, then there is a lazy variant…

Author here. The language is the part I also dread the most, and is also the part that will be the least unique and the least interesting to "re-invent".. I'll look into finding an existing language that runs on bare metal and that has (or supports) immutable values.

What about D 2.0? I haven't used it but I think they changed everything to const by default. Maybe you would have to write a collections library, not sure.

Re: An immutable operating system

#96

Post by userbinator »

_delirium wrote: post #23
eloff wrote: post #6

An operating system whose main goal is not performance is forever going to be a toy of professors. Linux is a mess compared to the beautiful code that would comprise this OS, but it's a mess that runs fast on real hardware and let's people get stuff done. That matters.

I think this is becoming less true: people are willing to trade off performance for safety and flexibility, given the right circumstances. For example, running everything inside of virtualized Linux instances is less performant than running in bare-metal Linux, but virtualization is nonetheless taking off like crazy.

> but virtualization is nonetheless taking off like crazy.

I think that's more due to hosting providers being able to sell far more "machines" than they have hardware for.

Re: An immutable operating system

#97

Post by chongli »

thinkpad20 wrote: post #72
obblekk wrote: post #4

I'm not sure how this would look very different from current pure functional languages. Think about programming in Haskell. Everything is immutable but you can compile down to machine level binaries. So at some point the programmer is presented with an abstract immutable model and under the hood some runtime does real pointer arithmetic and all. Even garbage collectors could be optimized already for knowing that the…

He's not designing a language; he's designing an operating system.

The GHC RTS (used in most Haskell programs) is practically a mini-operating system already.

Re: An immutable operating system

#99

Post by weinzierl »

lukego wrote: post #59
procrastitron wrote: post #54

I wrote an operating system in a purely functional dialect of Lisp; http://losak.sf.net There are a few things I learned in the process that I think are relevant here: 1. Forget garbage collection in the sense of any variant of mark-and-sweep. For an operating system latency is more important than through put, so you really want real time memory management. If you use reference counting, then there is a lazy variant…

> For an operating system latency is more important than through put One interesting exception to this rule is operating systems for network packet routers. These need to be optimized for throughput over latency. I mean, the difference between 10 and 20 million packets per second is important, but the difference between 10 and 20 microseconds of processing delay is not. This is a fun area to be in at the moment becau…

> For an operating system latency is more important than through put

The old OS/390 that is still processing your bank statement and your payroll is another counter example that the above statement is too generic.

Re: An immutable operating system

#100

Post by agumonkey »

chongli wrote: post #93
gohrt wrote: post #89

Earlier quoted context omitted.

Haskell

There's actually been a bit of work on this very idea! http://programatica.cs.pdx.edu/House/

funny sidenote, one of House dev (Jeremey Bobbio) had a talk at FOSDEM2014 about reproducible builds for debian, similar to Nix (also immutable in spirit) I believe.

https://fosdem.org/2014/schedule/event/reproducibledebian/

Post reply on HN