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

Mio: A High-Performance Multicore IO Manager for GHC [pdf]

haskell.cs.yale.edu

Post reply on HN
Print view View original

61–70 of 81 posts

Re: Mio: A High-Performance Multicore IO Manager for GHC [pdf]

#61

Post by SkyMarshal »

gnuvince wrote: post #51
quchen wrote: post #7

Earlier quoted context omitted.

Installing GHC manually is not hard, the website even provides pre-compiled binaries. I started doing it for different reasons, but was surprised how painless the process was. After doing it multiple times, I wrote together a file that guides me through the process, which you can find here: https://github.com/quchen/articles/blob/master/install_haske...

Thanks for that nice guide! I was actually expecting to install GHC by hand eventually (for now, 7.4 is sufficient).

Since you're on Debian you can use the awesome Update Alternatives to install Haskell, which is an even better way in my opinion:

https://github.com/byrongibson/scripts/blob/master/install/h...

Tons of advantages to doing it that way, including the ability to easily maintain multiple versions of both GHC and Platform on the same system and swap between them with a single command. Also doesn't clutter up /usr/local/ with binaries not managed by apt or dpkg.

More generally, update-alternatives is a godsend for Stable users. It's like RVM or RBENV in the Ruby world - lets you install and manage multiple versions of the same platform and easily swap between them with a single command, including the system version from repos if you want. It frees you from out of date software in the repos while still providing a system to manage the complexities of it all.

Re: Mio: A High-Performance Multicore IO Manager for GHC [pdf]

#62

Post by IsTom »

fauigerzigerk wrote: post #16

I've been wondering about garbage collection in pure functional languages lately. It is often said that statically typed pure functional languages allow the compiler to do a lot more correctness checking. Shouldn't the same formal reasoning features also enable much better garbage collection algorithms? Or would that be asking for a solution to the halting problem?

There are some things to gain, but they're implemented mostly by experimental languages, e.g. DDC has regions.

Re: Mio: A High-Performance Multicore IO Manager for GHC [pdf]

#63

Post by jallmann »

ithkuil wrote: post #59
jallmann wrote: post #40

Earlier quoted context omitted.

With a purely linear type system, memory management could be handled statically, negating the need for traditional GC. The underlying behavior would be closer to C-style just-in-time {de-}allocation, or C++ RAII. LinearML is an attempt at this: https://github.com/pikatchu/LinearML

That's awesome! Any good pointers to interesting articles about that? I found this: http://www.eg.bucknell.edu/~lwittie/research/space04.pdf

Don't know of any articles, but there are a number of papers on linear logic and linear type theory. Most are pretty dense, but the first few pages of Wadler's "Linear types can change the world!" give a very readable overview of the area. http://homepages.inf.ed.ac.uk/wadler/papers/linear/linear.ps

Re: Mio: A High-Performance Multicore IO Manager for GHC [pdf]

#64

Post by chowells »

dons wrote: post #18
fauigerzigerk wrote: post #16

I've been wondering about garbage collection in pure functional languages lately. It is often said that statically typed pure functional languages allow the compiler to do a lot more correctness checking. Shouldn't the same formal reasoning features also enable much better garbage collection algorithms? Or would that be asking for a solution to the halting problem?

There's lots of interesting optimizations enabled by immutable data. E.g. in generational collectors old data can never point at new data, which can be used to gain additional performance. see e.g. http://research.microsoft.com/en-us/um/people/simonpj/papers...

Though the GHC runtime isn't an example of immutable data. Haskell code actually results in a lot of mutation behind the scenes. It's quite possible for older generations to point to data in newer generations in Haskell. It's even likely with some use patterns.

Given that you already know this, I assume you must be talking about strict functional languages specifically.

Re: Mio: A High-Performance Multicore IO Manager for GHC [pdf]

#65

Post by chowells »

bsaul wrote: post #9

Does anyone know why functional programming languages are so much favored by research teams over other types of PL ? Every time i hear someone doing PL research, it's always on some kind of functional programming language such as Haskell or ML.

For this specific example? This isn't really a research project, in the normal sense of the term. This is a report of a very thorough engineering effort to fix the scaling of the IO manager already in GHC. It doesn't invent anything new. It does detail every issue they found and how they dealt with it.

One thing I'm surprised no one has mentioned is that they found a race condition in epoll that's existed since version 2.4 of the linux kernel.

Re: Mio: A High-Performance Multicore IO Manager for GHC [pdf]

#66

Post by tomp »

colanderman wrote: post #49
tomp wrote: post #12

Earlier quoted context omitted.

It's not about functional programming languages per se, it's just that a lot of core/academic PL research often focuses much more on concepts than on implementation , and languages with strong type systems (all of which are functional, in part also because OO/subtyping is hard to reason about formally) are ideal for encoding these concepts. There is, however, a lot of research about implementation going on using othe…

> (all of which are functional, in part also because OO/subtyping is hard to reason about formally) OO/subtyping is NOT orthogonal to functional, nor is it inherently at odds with formal reasoning. OCaml has both imperative and functional objects; Haskell, Mercury, and Coq (a formal logic language) all support typeclasses, which subsume most of OO and provide subtyping. Additionally, strong typing has little to do wi…

Not inherently, no, but practically, yes. The type system of, say, Java, isn't even formally sound; overridden functions can be covariant in parameter types, which would not be permissible in a proper subtype-based type system such as OCaml's.

Re: Mio: A High-Performance Multicore IO Manager for GHC [pdf]

#67

Post by VladRussian2 »

pron wrote: post #41
dubbledidu wrote: post #33

Earlier quoted context omitted.

Eh... what exactly is "lightweight" about your threads? As far as I see you still use the same, standard JVM threads everyone uses, combined with a thread pool. What am I missing?

No, these are true lightweight threads (implemented on top of an OS-thread pool, just as they are in Erlang and, I suppose, Haskell). You can have hundreds of thousands or even millions of these on a single machine. They can block for IO or for any other kind of synchronization (message passing etc.), just like regular threads.

whenever i hear "lightweight threads" my PTSD from experience with Java "green threads" comes back. Of course, my rational mind understands that many years have passed and things may in other runtimes be implemented differently and there are many benefits vs. native, yet ...

Re: Mio: A High-Performance Multicore IO Manager for GHC [pdf]

#68

Post by pron »

VladRussian2 wrote: post #67
pron wrote: post #41

Earlier quoted context omitted.

No, these are true lightweight threads (implemented on top of an OS-thread pool, just as they are in Erlang and, I suppose, Haskell). You can have hundreds of thousands or even millions of these on a single machine. They can block for IO or for any other kind of synchronization (message passing etc.), just like regular threads.

whenever i hear "lightweight threads" my PTSD from experience with Java "green threads" comes back. Of course, my rational mind understands that many years have passed and things may in other runtimes be implemented differently and there are many benefits vs. native, yet ...

This has little, if any, to do with that. These lightweight threads are implemented pretty much exactly as they're implemented in Erlang or Go.

Re: Mio: A High-Performance Multicore IO Manager for GHC [pdf]

#69

Post by ezyang »

chowells wrote: post #64
dons wrote: post #18

Earlier quoted context omitted.

There's lots of interesting optimizations enabled by immutable data. E.g. in generational collectors old data can never point at new data, which can be used to gain additional performance. see e.g. http://research.microsoft.com/en-us/um/people/simonpj/papers...

Though the GHC runtime isn't an example of immutable data. Haskell code actually results in a lot of mutation behind the scenes. It's quite possible for older generations to point to data in newer generations in Haskell. It's even likely with some use patterns. Given that you already know this, I assume you must be talking about strict functional languages specifically.

Are you referring to thunk update after lazy evaluation? This is a very special kind of mutation, because after the update, it is guaranteed never to be mutated again. This is quite helpful for generational GC, actually, and underlies the concept of "eager promotion".

Re: Mio: A High-Performance Multicore IO Manager for GHC [pdf]

#70

Post by seanmcdirmid »

icarus127 wrote: post #52
seanmcdirmid wrote: post #43

Earlier quoted context omitted.

Symbol table, multiple passes, iterative processing.... The state is not event-based in nature but does exist.

Having state does not mean a function/algorithm is not pure.

http://en.wikipedia.org/wiki/Pure_function
Post reply on HN