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

131–140 of 153 posts

Re: An immutable operating system

#131

Post by stcredzero »

barrkel wrote: post #115
stcredzero wrote: post #86

Earlier quoted context omitted.

In the case of Clojure, log is log base 32, so it's close enough to O(1) as to make no difference in most circumstances.

Many immutable algorithms replace arrays with trees. Trees are pointer-heavy, and pointers are less cache-friendly than arrays. Memory access is often over 100x the cost of an L1 cache hit. It doesn't take too many of those to make a big difference if you're CPU bound. My comments are general, I'm sure Clojure has access to arrays where necessary for interop at least.

Again, true, but the big problem I'm facing isn't raw performance so much as it's guaranteed latency.

Re: An immutable operating system

#132

Post by stcredzero »

masklinn wrote: post #91
stcredzero wrote: post #90

Earlier quoted context omitted.

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…

I was thinking about refcounting, actually, but not exclusively. My point is that there aren't that many systems where you can build in a high level language, deal elegantly with concurrency, but still have really good latency guarantees. This project might improve on that.

Re: An immutable operating system

#133

Post by 1amzave »

masklinn wrote: post #91
stcredzero wrote: post #90

Earlier quoted context omitted.

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…

> immutable structures can't create cycles

Perhaps I'm misunderstanding something, but doesn't "tying the knot" in Haskell do just that? (Create a cycle from immutable structures.)

Re: An immutable operating system

#134

Post by Mikeb85 »

ksk wrote: post #30
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.

The goal of Linux was not performance, it was to create a free OS. The fact that it has become a high quality performant OS is a side-benefit (driven by external commercial factors, much later in its development timeline).

I'm not sure that was even the goal. Seems Linus just wanted to create it for the hell of it, didn't think it was going anywhere, and released it as free software just because... From everything I've read of the history of Linux it seems it was mostly an accident (a pleasant one) of history. (I use Linux BTW)

Re: An immutable operating system

#135

Post by augustl »

timclassic wrote: post #121
augustl wrote: post #106

Earlier quoted context omitted.

I'm an Erlang noob, but afail the model is pretty different. I'm imagining a shared-everything system, where immutable values are freely passed around with no copying. Erlang is more of a shared-nothing system. Also, Erlang requires multiple machines to shine, but an OS is more about managing one machine. I do think message passing have a bright future, though, and my OS will not work at all in a shared-nothing manyc…

I see. You are correct, Erlang definitely falls on the shared-nothing side if you ignore some uses of ETS and ref-counted binaries (binaries above 64 bytes, I believe). I disagree with the statement "Erlang requires multiple machines to shine," but my motivations, and my definition of "shine," are likely different from yours. Erlang only requires >1 machines if you are creating a system with proper fault-tolerance. I…

I once skimmed Armstrong's dissertation, it was mentioned how the JVM is bad for fault tolerance, because it's possible for a run-away thread to break the entire VM. Apparently, the Erlang VM manages isolation better, in such a way that it's impossible for one process to take down the entire system. That is definitely something I want to bring along to this OS :) I'm toying a lot with Erlang these days, to ensure Clojure and Linux isn't the only prior art..

And you're right, "shine" is a generalization, I actually had fault tolerance in mind when I wrote that.

Re: An immutable operating system

#136

Post by spc476 »

raganwald wrote: post #40
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.

An operating system whose main goal is not performance is forever going to be a toy of professors. Be careful! That statement was once true of programming languages. Over time, larger and larger numbers of people relaxed their expectations for performance in exchange for benefits like greater safety. Simultaneously, implementors invested in optimizing the performance of languages previously considered "slow." Operati…

But only because hardware got much faster, with larger resources (memory, disk). I just did a Stupid Benchmark, compiling this code:

    /*
     * Standard 'C' demo... Say hello to the world
     *
     * Compile command: cc hello
     */
    #include 
    
    main()
    {
      printf("Hello world\n");
    }
(I know, not completely valid ANSI C code). On my home system (32 bit 2.6GHz intel gobs of RAM yada yada) it took GCC 0.2 seconds to compile and link the program (as a static program---by default it did it in 0.05 seconds). On the system I grabbed the code from (an operating system for the 8-bit MC6809) it took 35 seconds. And that was on a simulated MC6809 running on said 2.6GHz system, which is still faster, at approximately 50MHz, than a real MC6809 system of 1MHz (I thing you could get a 2MHz MC6809, but not much faster than that).

Even a state-of-the-art computer in 1980 (say, a Cray supercomputer) would have a hard time keeping up with hobbyist" rel="nofollow">http://www.chrisfenton.com/homebrew-cray-1a/">hobbyist system of today, and it's because of this increase in computing power that we've been able to have the "toy languages" of yesterday be useful languages today.

But given that CPU speeds have leveled off, the easy performance gains are pretty much gone these days.

Re: An immutable operating system

#137

Post by tkirchner »

I really doubt the practical usefulness of such an operation system other than pure fun and skill development (and maybe some tools that fall out at the end...).

Isn't the main purpose of an OS to bridge between the applications and the hardware? The hardware is pretty accurately abstracted as sth. with a state and input/output streams.

What is the purpose of abstracting the hardware as sth. without a state?

Re: An immutable operating system

#138

Post by tkirchner »

I really doubt the practical usefulness of such an operation system other than pure fun and skill development (and maybe some tools that fall out at the end...).

Isn't the main purpose of an OS to bridge between the applications and the hardware? The hardware is pretty accurately abstracted as sth. with a state and input/output streams.

What is the advantage of abstracting the hardware as sth. without a state?

Re: An immutable operating system

#139

Post by tkirchner »

I really doubt the practical usefulness of such an operation system other than pure fun and skill development (and maybe some tools that fall out at the end...).

Isn't the main purpose of an OS to bridge between the applications and the hardware? The hardware is pretty accurately abstracted as sth. with a state and input/output streams.

What is the purpose of abstracting the hardware as sth. without a state?

Re: An immutable operating system

#140

Post by cgrand-net »

1amzave wrote: post #133
masklinn wrote: post #91

Earlier quoted context omitted.

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…

> immutable structures can't create cycles Perhaps I'm misunderstanding something, but doesn't "tying the knot" in Haskell do just that? (Create a cycle from immutable structures.)

Tying the knot is possible only if you have pervasive laziness.
Post reply on HN