Re: Heads-up: new parallel I/O manager merged

2013-02-25 Thread Nicolas Trangez
On Mon, 2013-02-25 at 10:39 +, Svein Ove Aas wrote: > In this day and age, it seems odd that we have to explicitly specify the > number of cores. Detecting it would be pretty simple, on all systems I know > of. With some executable compiled using GHC 7.6.1 & threaded RTS, from +RTS --help: -N

Re: Heads-up: new parallel I/O manager merged

2013-02-25 Thread Svein Ove Aas
In this day and age, it seems odd that we have to explicitly specify the number of cores. Detecting it would be pretty simple, on all systems I know of. Before I go ahead and write a patch, I'd there some technical or political reason we're boy doing that? On 25 Feb 2013 00:58, "Kazu Yamamoto" wr

Re: Heads-up: new parallel I/O manager merged

2013-02-24 Thread 山本和彦
> We should really publish a blog post about this. - If we will take benchmark, "+RTS -Nx -qa -Aym" should be specified to a server. "y" should be changed according to "x", the number of core. I'm using "+RTS -N10 -qa -A32m" on a 12 core machine. "-qa" improves performance on Linux but not F

Re: Heads-up: new parallel I/O manager merged

2013-02-24 Thread Johan Tibell
We should really publish a blog post about this. On Sun, Feb 24, 2013 at 8:34 AM, Don Stewart wrote: > Do we get some benchmarks -- 32x better req/sec would be a good smackdown > of some recent posts floating around. > > > http://techblog.safaribooksonline.com/2013/02/22/go-as-an-alternative-to-

Re: Heads-up: new parallel I/O manager merged

2013-02-24 Thread Don Stewart
Do we get some benchmarks -- 32x better req/sec would be a good smackdown of some recent posts floating around. http://techblog.safaribooksonline.com/2013/02/22/go-as-an-alternative-to-node-js-for-very-fast-servers/ etc etc. On Tue, Feb 12, 2013 at 7:02 AM, Johan Tibell wrote: > Hi, > > I've me

Re: Heads-up: new parallel I/O manager merged

2013-02-17 Thread 山本和彦
Hello, This phenomenon has gone away today. Building is OK on Mac. Also "validate" resulted in: Unexpected failures: codeGen/should_run cgrun071 [bad exit code] (normal) perf/compiler T4801 [stat too good] (normal) perf/haddockhaddock.Cabal [stat not good enough] (normal)

Re: Heads-up: new parallel I/O manager merged

2013-02-16 Thread Bill Tutt
Yes, it should. Here's the combined patch that just succeded in being built. Bill On Sat, Feb 16, 2013 at 11:26 AM, Andreas Voellmy wrote: > > > in rts/ThrIOManager.hs >> > > Sorry, this should have been rts/win32/ThrIOManager.c. > win32IOManager_thr_dyn_BuildFix.patch Description: Binary da

Re: Heads-up: new parallel I/O manager merged

2013-02-15 Thread Bill Tutt
This sounds cool, unforunately this caused a build failure in the threaded+dynamic way build on Windows 32bit build. PRELUDE_CLOSUREs use DLL_IMPORT_DATA_VARNAME() so when you use them you should use the macro definition for them that hides the DLL_IMPORT_DATA_REF usage. Additionally, the new clo

Re: Heads-up: new parallel I/O manager merged

2013-02-12 Thread 山本和彦
Hi all, > I've merged the new parallel I/O manager that Andreas Voellmy and Kazu > Yamamoto have been working on. The new parallel I/O manager scales much better > than the current one*: the number of requests per second scales almost > linearly up to 32 cores I believe. Perhaps Andreas could post

Re: Heads-up: new parallel I/O manager merged

2013-02-12 Thread Simon Marlow
Seconded. Well done guys. Cheers, Simon On 12/02/13 08:46, Simon Peyton-Jones wrote: Andreas, Kazu, Johan That is a truly monumental sequence of patches! Thank you all for working so hard on making GHC better. Better together! Onward and upward. Simon *From:*ghc-devs-boun...@haske

RE: Heads-up: new parallel I/O manager merged

2013-02-12 Thread Simon Peyton-Jones
Andreas, Kazu, Johan That is a truly monumental sequence of patches! Thank you all for working so hard on making GHC better. Better together! Onward and upward. Simon From: ghc-devs-boun...@haskell.org [mailto:ghc-devs-boun...@haskell.org] On Behalf Of Johan Tibell Sent: 12 February 2013 07: