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-bounces@haskell.org [mailto:ghc-devs-bounces@haskell.org] *On Behalf Of *Johan Tibell *Sent:* 12 February 2013 07:03 *To:* ghc-devs@haskell.org *Cc:* Kazu Yamamoto (山本和彦); Andreas Voellmy *Subject:* Heads-up: new parallel I/O manager merged

Hi,

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 the numbers.

If you see any bugs that you think are related to the new I/O manager, please let Andreas and Kazu know.

* The current one (which replaced an even earlier one) scaled well in the number of open file descriptors and performed better than the I/O manager it replaced, but it didn't scale well to multiple cores.

Cheers,

Johan

_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs

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/haddock haddock.Cabal [stat not good enough] (normal) perf/haddock haddock.base [stat not good enough] (normal) --Kazu

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 the numbers.

Just after Johan's merge, I could build GHC on Mac. But after executing ./sync-all -r git://github.com/ghc --testsuite pull today, I cannot build GHC on Mac:

---- ghc-stage1: could not execute: /usr/bin/gcc make[1]: *** [libraries/template-haskell/dist-install/build/Language/Haskell/TH/Syntax.o] Error 1 make[1]: *** Waiting for unfinished jobs.... make: *** [all] Error 2 ----

I would like to know whether or not this failure is due to our patches. Since building GHC with our patches were unstable on Mac, we made a workaround. Andreas and I need to know that this workaround is stable enough:

https://github.com/ghc/packages-base/commit/bcf8724642f3cec73587313878047c87... https://github.com/ghc/packages-base/commit/51a8b9bb878247675b6e003fa081f1a2... http://hackage.haskell.org/trac/ghc/ticket/7651

Any information is welcome.

Building GHC on FreeBSD is fine.

--Kazu

_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs

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 FreeBSD even if a "-qa" bug of GHC on FreeBSD is fixed. http://hackage.haskell.org/trac/ghc/ticket/7708 - "ab" sucks. We should use "weighttp" instead. I use as weighttp -n 1000000 -c 1000 -k -t 10 "http://X.Y.Z.W:8000/" which creates 10 native threads. For more information, please refer to: http://gwan.com/en_apachebench_httperf.html http://www.iij.ad.jp/company/development/tech/activities/weighttp/index.html (in Japanese, sorry) --Kazu

On Mon, 2013-02-25 at 10:39 +0000, 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[<n>] Use <n> processors (default: 1, -N alone determines the number of processors to use automatically) Nicolas

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" wrote:

...

...

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 FreeBSD even if a "-qa" bug of GHC on FreeBSD is fixed.

http://hackage.haskell.org/trac/ghc/ticket/7708

- "ab" sucks. We should use "weighttp" instead. I use as weighttp -n 1000000 -c 1000 -k -t 10 "http://X.Y.Z.W:8000/" which creates 10 native threads.

For more information, please refer to: http://gwan.com/en_apachebench_httperf.html

http://www.iij.ad.jp/company/development/tech/activities/weighttp/index.html (in Japanese, sorry)

--Kazu

_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs

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" wrote: > 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 FreeBSD even if a "-qa" bug of GHC on FreeBSD is fixed.

http://hackage.haskell.org/trac/ghc/ticket/7708

- "ab" sucks. We should use "weighttp" instead. I use as weighttp -n 1000000 -c 1000 -k -t 10 "http://X.Y.Z.W:8000/" which creates 10 native threads.

For more information, please refer to: http://gwan.com/en_apachebench_httperf.html

http://www.iij.ad.jp/company/development/tech/activities/weighttp/index.html (in Japanese, sorry)

--Kazu

_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs _______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs