Re: Race-condition in alternative 'System.Timeout.timeout' implementation
You might want to take a look at https://github.com/alphaHeavy/timeout-control/blob/master/System/Timeout/Control.hs#L72too, though I'd guess it is subject to the same race condition. I have a few other fixes (for dealing with lifted bracket iirc) I still need to merge back from a private branch. On Sun, Feb 24, 2013 at 2:31 PM, Herbert Valerio Riedel h...@gnu.org wrote: Hello *, I've been experimenting with an alternative implementation of 'System.Timeout.timeout'[1] which avoids the overhead of spawning a new thread for each invocation. Part of my motivation is to see if I can implement a faster version of threadWaitReadTimeout :: Int - Fd - IO Bool threadWaitReadTimeout to = liftM (maybe False (const True)) . timeout to . threadWaitRead and thus exploit GHC's event notification system instead of having to reimplement a timeout-manager myself (like popular HTTP server libraries such as Snap or Warp do currently). The following Haskell program shows a proof-of-concept implementation derived directly from 'System.Timeout.timeout' together with a Criterion benchmark comparing the performance between the original and the alternative 'timeout' function wrapping a 'readMVar' call. On a i7-3770 with GHC-7.6.2/Linux/64bit ran with +RTS -A4m -N4, the benchmark shows a 15x improvement for the new implementation (below 1 uS) compared to the original implementation (~13 uS): , | benchmarking id | mean: 22.60933 ns, lb 22.50331 ns, ub 22.73515 ns, ci 0.950 | std dev: 591.0383 ps, lb 509.6189 ps, ub 663.2670 ps, ci 0.950 | found 17 outliers among 100 samples (17.0%) | 17 (17.0%) high mild | variance introduced by outliers: 19.992% | variance is moderately inflated by outliers | | benchmarking timeout_1ms | mean: 13.79584 us, lb 13.62939 us, ub 13.92814 us, ci 0.950 | std dev: 756.3080 ns, lb 524.7628 ns, ub 1.068547 us, ci 0.950 | found 14 outliers among 100 samples (14.0%) | 4 (4.0%) low severe | 5 (5.0%) high mild | 5 (5.0%) high severe | variance introduced by outliers: 52.484% | variance is severely inflated by outliers | | benchmarking timeout2_1ms | mean: 879.8152 ns, lb 874.5223 ns, ub 885.9759 ns, ci 0.950 | std dev: 29.31963 ns, lb 25.65941 ns, ub 32.98116 ns, ci 0.950 | found 9 outliers among 100 samples (9.0%) | 9 (9.0%) high mild | variance introduced by outliers: 28.734% | variance is moderately inflated by outliers | ... ` Alas there's a race-condition hidden somewhere I'm struggling with; When the timeout is set low enough, the internal 'Timeout2' exceptions leaks outside the 'timeout2' wrapper: , | ... | benchmarking timeout2_10us | newtimeout: timeout2 ` I've tried rewriting the code but couldn't figure out a way to keep the exception from escaping 'timeout2'. Does the race-condition actually lie in the 'timeout2' implementation -- and if so, is it possible to rewrite 'timeout2' to solve it? [1]: http://hackage.haskell.org/packages/archive/base/latest/doc/html/System-Timeout.html#v:timeout cheers, hvr ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Dynamic libraries by default and GHC 7.8
Would the SxS loader (with associated manifests, etc) work? I've used it to support similar scenarios in a former job without any PE32 hacking. Unless things have changed recently, the APIs aren't super well documented but they are supported and there are a handful of tools for tracing the loader through various activation contexts. On Thu, Dec 6, 2012 at 5:34 AM, Max Bolingbroke batterseapo...@hotmail.com wrote: On 6 December 2012 10:05, Max Bolingbroke batterseapo...@hotmail.com wrote: I've tested this by hand and it seems like it works: the absolute paths you hack into the import library are not messed with by the later link step. The resulting executables run flawlessly. Job done. To continue spamming the list, I'd just like to advertise my blog post explaining the proposed technique, with a worked example: http://blog.omega-prime.co.uk/?p=138 Cheers, Max ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: parallelizing ghc
On Thu, Jan 26, 2012 at 3:44 PM, Evan Laforge qdun...@gmail.com wrote: I'd think apple would care about linker performance... I'm even a little surprised Xcode doesn't have something better than a lightly hacked gnu ld. Someone mentioned that it was on their wish-list at LLVM 2010 conference... it's hinted at here too: http://llvm.org/devmtg/2010-11/Spencer-ObjectFiles.pdf. He might know if anyone is actually working on one. -n ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHC 7.2.2 RC 1
We're hitting something that looks similar with a Chan on 7.2.1, though they might be related.. On Fri, Nov 11, 2011 at 4:52 AM, Simon Marlow marlo...@gmail.com wrote: Sorry, no. That one has a workaround: define your own fixIO: fixIO :: (a - IO a) - IO a fixIO k = do m - newEmptyMVar ans - unsafeInterleaveIO (takeMVar m) result - k ans putMVar m result return result ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHC 7.2.2 RC 1
Any chance #5421 (loop in withMVar (reproducible, but with large test case) could be backported to 7.2.2? -n On Sun, Nov 6, 2011 at 5:18 AM, Ian Lynagh ig...@earth.li wrote: 7.2.2 will be a minimal bugfix release, fixing only bugs that cannot be worked around. Please let us know if you find any showstoppers. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Should GHC default to -O1 ?
On Tue, Nov 8, 2011 at 11:28 PM, wagne...@seas.upenn.edu wrote: I don't agree that GHC's user interface should be optimized for newcomers to Haskell. GHC is an industrial-strength compiler with some very advanced features; the majority of its target audience is professional programmers. Let its interface reflect that fact. As Simon explained, GHC's current defaults are a very nice point in the programming space for people who are actively building and changing their programs. It's easy to build arguments for either side, but my experience as a professional developer is that new devs don't know what arguments they need for reasonable performance, often knowing even what various optimization flags do, but experienced developers do know the difference between -O0 and -O1, and frequently need -debug (not a default option) more than -O0. Seasoned GHC users can find that -O0 gives miserably slow compile times, and fall back to GHCi for edit/rebuild cycles... which still aren't terribly fast if you're using GHC's advanced features. I have a couple small modules that take 10 minutes each to compile on a current Core i7 at -O0, and -O2 really doesn't take much longer. GHCi is very slightly faster but I'll still head directly downstairs for a coffee as soon as either of these bad boys need rebuilding... and still make it back upstairs before they're done. And so I'd prefer the default to be -O1 or even -O2 and have people who really need it use -O0. GHC shouldn't be painful on purpose, industrial strength or not. -n ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
#ifdef'd code in Printer.c
For production debugging, I find printObj and friends to be rather useful... and I wonder if it would be a good idea to make these part of the release builds, instead of being relegated to -debug? Alternatively, should these debugging functions be moved to a separate library? I have some other heap debugging functions that I'd like to include but they take a dependency on libxml2... which seems fine for hackage but probably not the GHC RTS. I've investigated doing this from cabal-install but there doesn't seem to be support for building libraries for the full RTS build matrix (threaded/profiling/debugging). -n ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Faster Array#/MutableArray# copies
On Mon, Feb 28, 2011 at 9:01 AM, Simon Marlow marlo...@gmail.com wrote: Ideally you'd want the heap check in the primop to be aggregated into the calling function's heap check, and the primop should allocate directly from the heap instead of calling out to the RTS allocate(). All this is a bit much to expect LLVM to do, but we could do it in the Glorious New Code Generator... It's probably (certainly) better to do it in the code generator but it is rather easy to perform in LLVM and might be a worthwhile optimization during LTO/LTCG. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
