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
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
> 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
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-
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
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)
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
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
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
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
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:
11 matches
Mail list logo