haskell threads vs os threads

[15:24] is it true that os level threads can be outperformed by some kind of lightweight forking?
[15:24] Shouldn't genus be a nonnegative integer?
[15:24] 5
[15:24] or by anything?
[15:24] yes
[15:25] the_unmaker, in as much as that's a very vague statement, yes, i can instantiate it to a true statement
[15:25] the_unmaker: OS threads are typically quite expensive
[15:25] the definition of "lightweight" presumes that they're lighter than the OS threads
[15:25] == sidek [~shiduke@209.89.186.136] has joined #haskell
[15:25] kmc: geek :P
[15:25] but purely green threads won't use multiple CPUs
[15:25] == andycoder [~andycoder@cpe-174-101-18-254.columbus.res.rr.com] has quit [Remote host closed the connection]
[15:25] but systems like GHC's runtime system will
[15:25] trivial example: create a thread whose code immediately quits. os threading cannot compete with green threading at this.
[15:26] sure, it's a hybrid thing
[15:26] multiplexing hundreds of thousands of green threads across a configurable number of OS threads
[15:26] == cpressey_ [~CPressey@173-9-215-173-Illinois.hfc.comcastbusiness.net] has quit [Ping timeout: 265 seconds]
[15:26] Haskell gets an advantage too from purity (which makes it easy to exploit parallelism without explicit threads) and non-sucky abstraction (which makes it easy to do explicit threading when you like)
[15:26] OS threads are getting better, but its hard to compete with having no context switch at all
[15:27] the_unmaker: it's not uncommon to use hundreds of haskell threads, where using more than a dozen or so OS threads would be quite rare almost anywhere
[15:27] == tnks [~tnks@24-155-229-138.dyn.grandenetworks.net] has joined #haskell
[15:27] ok to be clear, these haskell threads CAN use a 8 cpu box?
[15:27] yes
[15:27] am it true that you can't define custom data types in ghci?
[15:27] or are they stuck on 1 cpu?
[15:27] == edon [~edon@albalug/edon] has quit [Remote host closed the connection]
[15:27] the_unmaker, anyway, Haskell or Erlang systems with green threading regularly spawn hundreds of thousands of threads on a modest desktop-class machine. Linux will shit itself totally at that stage, that's almost 200 GB of stack alone with default config
[15:27] the_unmaker: you can ask the haskell runtime to use any number of OS threads
[15:27] is it, sorry.
[15:27] it is good news that os threading keeps improving. more choices for everyone!
[15:28] the_unmaker: it will take care of distributing the haskell threads over the OS ones
[15:28] == jsgf [~jeremy@c-98-210-109-72.hsd1.ca.comcast.net] has quit [Ping timeout: 255 seconds]
[15:28] and haskell will spread its green threads accross the 8 cpus?
[15:28] the_unmaker, yes. compile with «ghc -threaded --make foo.hs»; run with «./foo +RTS -N8»
[15:28] the_unmaker: under GHC, you run programs using a certain number of OS threads, which you specify, and all your haskell threads are spread among those OS threads
[15:28] NICe
[15:28] you now have all your Haskell threads multiplexed onto those 8 OS threads
[15:28] just liek that?
[15:28] ?seen saizan
[15:28] tnks: yes, ghci has a limited ability to create new definitions. you generally need full blown ghc for that
[15:28] Unknown command, try @list
[15:28] yup
[15:28] preflex: seen saizan
[15:28] saizan was last seen on #haskell 2 hours, 5 minutes and 10 seconds ago, saying: solved?
[15:28] WOW
[15:28] newsham: pong?
[15:28] == Rayne [~Rayne@pD954BB19.dip.t-dialin.net] has quit [Quit: FATAL ERROR]
[15:28] this sounds like something lisp even would have a problem doing
[15:29] saizan: I came up with a soln I like for that applicative thing I asked earlier
[15:29] I am a novice programmer.....
[15:29] the_unmaker, and this includes not only explicit threading but parallelism annotations, which are just like "compute x and y in parallel". no explicit thread, no synchronization or communication on your part
[15:29] newsham: oh, I'm curious too
[15:29] == mode/#haskell [+o mauke] by ChanServ
[15:29] == mode/#haskell [+q *!*@gateway/web/freenode/ip.216.52.235.101] by mauke
[15:29] but I mnage unix boxes so love good performance
[15:29] == Cannot send to channel: #haskell
[15:29] NPTL can deal with thousands of threads without breaking a sweat
[15:29] <@mauke> @protontorpedo
[15:29] help please
[15:29] the_unmaker: threading in haskell is much easier than any other language i've used. and parallelism is even easier
[15:29] <@mauke> @protontorpedo
[15:29] why did someone create haskell?
[15:29] newsham: nice, paste?
[15:29] the_unmaker, it's just an implementation thing. Lisp could have implementations that work this way; I'm not sure if it does
[15:29] saizan: I have "type ESnap = ErrorT String Snap". my soln is to write a simple ejoin :: ESnap (Snap x) -> Snap x
[15:29] mauke: why'd you quiet him?
[15:30] the_unmaker, this is not really a property of Haskell, but of GHC. the basic Haskell specs don't even say anything about threading