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

Show HN: Lightweight Threads, Channels and Actors for the JVM

blog.paralleluniverse.co

Post reply on HN
Print view View original

51–56 of 56 posts

Re: Show HN: Lightweight Threads, Channels and Actors for the JVM

#51

Post by chongli »

saurik wrote: post #38
zmmmmm wrote: post #24

Ignorant newbie here, but would love to hear views on this: I always treat with great skepticism claims that you can implement an inherent operating system function (eg: threads) on top of said operating system more efficiently than can be done by the OS itself. Usually it means the implementor simply didn't understand the next level down (eg: how the kernel works) and therefore couldn't tune it to their needs. But t…

I don't disagree with other answers, but I believe the situation can be described more easily: it isn't the same primitive, so, it isn't actually the case that someone is attempting to provide the same thing but faster: the OS is giving you "pre-emptive threads", whereas these alternatives are giving you "cooperative threads". The argument is that for restricted use cases "cooperative threads" (which are the "dual",…

GHC's runtime (an implementation of Haskell) uses pre-emptive scheduling for its threads and has no problem handling millions of lightweight threads.

Re: Show HN: Lightweight Threads, Channels and Actors for the JVM

#52

Post by saurik »

chongli wrote: post #51
saurik wrote: post #38

Earlier quoted context omitted.

I don't disagree with other answers, but I believe the situation can be described more easily: it isn't the same primitive, so, it isn't actually the case that someone is attempting to provide the same thing but faster: the OS is giving you "pre-emptive threads", whereas these alternatives are giving you "cooperative threads". The argument is that for restricted use cases "cooperative threads" (which are the "dual",…

GHC's runtime (an implementation of Haskell) uses pre-emptive scheduling for its threads and has no problem handling millions of lightweight threads.

This starts turning into a semantics problem. GHC is a compiler that modifies the code it has compiled to add "synchronization points" that are used under a cooperative threading model, allowing it to know with certainty that certain kinds of operations or even functions it detects to have certain properties will not be pre-empted. Given that the overall language semantics are then pure functional, the costs associated with pre-emptive scheduling are removed, but again this is only because they "cheated" and didn't build a real "preemptive" scheduler: tasks must cooperate.

In fact, there are trivial kinds of operations you can perform (such as involving FFI) that simply will never pre-empt. The primitive the operating system provides, which I maintain is a fundamentally different primitive than what people are building in these user-space modifications, is "no matter what you do, whether on accident or on purpose, whether with benign or malicious intent, you will be time-sliced; your time-slicing will thereby happen at the discretion of the system, and you will not be trusted to request or demand excessive modifications to your time". GHC is not some magic exception: it is still cooperative multitasking.

Re: Show HN: Lightweight Threads, Channels and Actors for the JVM

#54

Post by SatishPuranam »

pron wrote: post #50
SatishPuranam wrote: post #43

I am newbie to go, but running the go version took about 186.053167ms, wonder how to explain this behavior http://play.golang.org/p/flK5QV-mDC Go Version : devel +740d244b2047 Thu May 02 18:59:39 2013 -0700

What was MAXPROCS set to? It's a lot faster to run this particular benchmark with only one thread.

1

Re: Show HN: Lightweight Threads, Channels and Actors for the JVM

#55

Post by pron »

SatishPuranam wrote: post #54
pron wrote: post #50

Earlier quoted context omitted.

What was MAXPROCS set to? It's a lot faster to run this particular benchmark with only one thread.

1

Yeah, that's what I figured :) Set it to the number of (virtual) cores on your machine.

Re: Show HN: Lightweight Threads, Channels and Actors for the JVM

#56

Post by pron »

willemsst wrote: post #53

Interesting ! Regarding to your own Queue implementations, did you consider using the disruptor ( http://lmax-exchange.github.io/disruptor/ - which is actually an advanced ring buffer)? Martin Thompson was also involved in that project.

Yes. I've been asked that elsewhere. See my reply here: http://www.java-gaming.org/index.php/topic,29466
Post reply on HN