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

41–50 of 81 posts

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

#41

Post by pron »

dubbledidu wrote: post #33
pron wrote: post #17

Earlier quoted context omitted.

Exactly. And low-level concurrency research (snapshot algorithms, n-cas) is usually done in C or Java, and so on. BTW, Java has lightweight threads, too: https://github.com/puniverse/quasar (I'm the main author)

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.

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

#42

Post by seanmcdirmid »

dubbledidu wrote: post #34
seanmcdirmid wrote: post #25

Earlier quoted context omitted.

> all of which are functional, in part also because OO/subtyping is hard to reason about formally OO subtyping is hard to reason about formally in formal systems designed for FP...news at 11! I jest. The reason FP does so well academically is that no one knows how to rigorously evaluate something that isn't theoretical (since FP is close to math anyways) or performance-based (most other PL work). The Haskell crowd is…

OO subtyping is hard to reason about formally in formal systems _in general_.

And yet, is-a and has-a relationships predominate natural language. Well, it makes sense: natural language is hard to reason about formally also.

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

#43

Post by seanmcdirmid »

chrisseaton wrote: post #24
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.

I know that part of the reason I like FP is that a compiler is usually a pretty perfect pure function - source code -> machine code. So those people researching languages will often find that FP is the best tool for their job and will be most familiar with it. Then when they come to research something new they do it in the context they're most familiar with.

Symbol table, multiple passes, iterative processing....

The state is not event-based in nature but does exist.

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

#44

Post by dons »

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.

Are they preemptive?

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

#45

Post by pron »

dons wrote: post #44
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.

Are they preemptive?

Absolutely. Currently fibers (lightweight threads) may only be preempted when performing a blocking operation (IO or waiting on some synchronization mechanism). We will implement time-share based preemption if we see a need for that.

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

#46

Post by [deleted] »

seanmcdirmid wrote: post #42
dubbledidu wrote: post #34

Earlier quoted context omitted.

OO subtyping is hard to reason about formally in formal systems _in general_.

And yet, is-a and has-a relationships predominate natural language. Well, it makes sense: natural language is hard to reason about formally also.

[deleted]

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

#47

Post by gtani »

gngeal wrote: post #39
octo_t wrote: post #27

Earlier quoted context omitted.

>> OO subtyping is hard to reason about formally in formal systems designed for FP...news at 11! Well. Even systems like L2 (which are not functional) find subtyping difficult. It becomes difficult in the presence of overloading and overriding.

I believe there's a nice book called Foundations of Object Oriented Languages which dissects the problem in depth.

Pierce's TAPL, also, and Harper's Practical Foundations. There's also some things i've seen about how scala does it, but I'll have to dig for them

http://www.cs.cmu.edu/~rwh/plbook/book.pdf

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

#48

Post by octo_t »

gtani wrote: post #47
gngeal wrote: post #39

Earlier quoted context omitted.

I believe there's a nice book called Foundations of Object Oriented Languages which dissects the problem in depth.

Pierce's TAPL, also, and Harper's Practical Foundations. There's also some things i've seen about how scala does it, but I'll have to dig for them http://www.cs.cmu.edu/~rwh/plbook/book.pdf

See also the DOT calculus[1] (Dependent Object Types) being the basis for a new foundation for scala's type system

[1] - https://github.com/namin/dot

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

#49

Post by colanderman »

tomp wrote: post #12
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.

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 with formal reasoning as well (see: Lisp/Scheme/the lambda calculus). What makes functional languages amenable to formal methods is that they are functional and therefore referentially transparent. Mathematical proofs carry no implicit concept of "state"; hence if you are trying to prove anything about code in, say, C, you need to augment the code with explicit state and remove all non-local effects. (See: the Why language, which attempts to bridge this gap.)

Algebraic/generalized-algebraic type constructors used by most functional languages don't hurt either, as they allow programs to construct complex terms without relying on lower-level stateful abstractions such as memory allocation.

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

#50

Post by jjindev »

helloTree wrote: post #15
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.

Because (static) FP is built on a sound and rich theory (type theory and lambda calculus) unless other language paradigms (e.g. OO). There are also different approaches, IMHO: FPL research: Ok, we have this cool way to describe our computation. But how can we efficiently map this to the HW? In essence build a nice language and find an implementation. Imperative PL research: Ok, we have this HW, how can we build an ex…

Microprocessors evolved while chasing minicomputer features, which in term were shaped by C/UNIX sorts of ideas, which expanded and fed back. That was a very successful co-evolution. COTS supercomputers beat specialized hardware and specialized forms of parallelism not because they were abstractly better, but because markets and economies of scale drive whatever is popular to be the best performing and cheapest over time. (Down to $30 UNIX systems on a board.)

The two language schools you describe seem to be asking whether it is time (whether we have enough capacity) to simply float a new more mathematical world view on top of it all, or whether we should continue to play toward the strengths of the commodity hardware stack.

I personally think that something like Go works for my mind, and the hardware. (I will go make coffee now, rather than "define coffee" and wait for it to appear ;-)

Post reply on HN