- Glasgow-haskell-users

RE: Cloud Haskell and network latency issues with -threaded
by Simon Peyton-Jones 08 Feb '13

08 Feb '13

I (with help from Kazu and helpful comments from Bryan and Johan) have nearly completed an overhaul to the IO manager based on my observations and we are in the final stages of getting it into GHC This is really helpful. Thank you very much Andreas, Kazu, Bryan, Johan. Simon From: parallel-haskell(a)googlegroups.com [mailto:parallel-haskell@googlegroups.com] On Behalf Of Andreas Voellmy Sent: 06 February 2013 14:28 To: watson.timothy(a)gmail.com Cc: kostirya(a)gmail.com; parallel-haskell; glasgow-haskell-users(a)haskell.org Subject: Re: Cloud Haskell and network latency issues with -threaded Hi all, I haven't followed the conversations around CloudHaskell closely, but I noticed the discussion around latency using the threaded runtime system, and I thought I'd jump in here. I've been developing a server in Haskell that serves hundreds to thousands of clients over very long-lived TCP sockets. I also had latency problems with GHC. For example, with 100 clients I had a 10 ms (millisecond) latency and with 500 clients I had a 29ms latency. I looked into the problem and found that some bottlenecks in the threaded IO manager were the cause. I made some hacks there and got the latency for 100 and 500 clients down to under 0.2 ms. I (with help from Kazu and helpful comments from Bryan and Johan) have nearly completed an overhaul to the IO manager based on my observations and we are in the final stages of getting it into GHC. Hopefully our work will also fix the latency issues in CloudHaskell programs :) It would be very helpful if someone has some benchmark CloudHaskell applications and workloads to test with. Does anyone have these handy? Cheers, Andi On Wed, Feb 6, 2013 at 9:09 AM, Tim Watson <watson.timothy(a)gmail.com<mailto:watson.timothy@gmail.com>> wrote: Hi Kostirya, I'm putting the parallel-haskell and ghc-users lists on cc, just in case other (better informed) folks want to chip in here. ---- First of all, I'm assuming you're talking about network latency when compiling with -threaded - if not I apologise for misunderstanding! There is apparently an outstanding network latency issue when compiling with -threaded, but according to a conversation I had with the other developers on #haskell-distributed, this is not something that's specific to Cloud Haskell. It is something to do with the threaded runtime system, so would need to be solved for GHC (or is it just the Network package!?) in general. Writing up a simple C program and equivalent socket use in Haskell and comparing the latency using -threaded will show this up. See the latency section in http://haskell-distributed.github.com/wiki/networktransport.html for some more details. According to that, there *are* some things we might be able to do, but the 20% latency isn't going to change significantly on the face of things. We have an open ticket to look into this (https://cloud-haskell.atlassian.net/browse/NTTCP-4) and at some point we'll try and put together the sample programs in a github repository (if that's not already done - I might've missed previous spikes done by Edsko or others) and investigate further. One of the other (more experienced!) devs might be able to chip in and proffer a better explanation. Cheers, Tim On 6 Feb 2013, at 13:27, kostirya(a)gmail.com<mailto:kostirya@gmail.com> wrote: > Haven't you had a necessity to launch Haskell in no-threaded mode during the intense network data exchange? > I am getting the double performance penalty in threaded mode. But I must use threaded mode because epoll and kevent are available in the threaded mode only. > [snip] > > > среда, 6 февраля 2013 г., 12:33:36 UTC+2 пользователь Tim Watson написал: > Hello all, > > It's been a busy week for Cloud Haskell and I wanted to share a few of > our news items with you all. > > Firstly, we have a new home page at http://haskell-distributed.github.com, > into which most of the documentation and wiki pages have been merged. Making > sassy looking websites is not really my bag, so I'm very grateful to the > various author's whose Creative Commons licensed designs and layouts made > it easy to put together. We've already had some pull requests to fix minor > problems on the site, so thanks very much to those who've contributed already! > > As well as the new site, you will find a few of us hanging out on the > #haskell-distributed channel on freenode. Please do come along and join in > the conversation. > > We also recently split up the distributed-process project into separate > git repositories, one for each component that makes up Cloud Haskell. This > was done partly for administrative purposes and partly because we're in the > process of setting up CI builds for all the projects. > > Finally, we've moved from Github's issue tracker to a hosted Jira/Bamboo setup > at https://cloud-haskell.atlassian.net - pull requests are naturally still welcome > via Github! Although you can browse issues freely without logging in, you will > need to provide an email address and get an account in order to submit new ones. > If you have any difficulties logging in, please don't hesitate to contact me > directly, via this forum or the cloud-haskell-developers mailing list (on > google groups). > > As always, we'd be delighted to hear any feedback! > > Cheers, > Tim -- You received this message because you are subscribed to the Google Groups "parallel-haskell" group. To unsubscribe from this group and stop receiving emails from it, send an email to parallel-haskell+unsubscribe(a)googlegroups.com<mailto:parallel-haskell%2Bunsubscribe@googlegroups.com>. For more options, visit https://groups.google.com/groups/opt_out. -- You received this message because you are subscribed to the Google Groups "parallel-haskell" group. To unsubscribe from this group and stop receiving emails from it, send an email to parallel-haskell+unsubscribe(a)googlegroups.com<mailto:parallel-haskell+unsubscribe@googlegroups.com>. For more options, visit https://groups.google.com/groups/opt_out.

3 4

GHC 7.8 release?
by Simon Peyton-Jones 07 Feb '13

07 Feb '13

Dear GHC users, Carter: Will this RTS update make it into ghc 7.8 update thats coming up in the next monthish? Andreas: We are almost there - we are now trying to sort out a problem on mac os x. It would be helpful to know if there is a cutoff date for getting things into 7.8. Simon, Ian, and I have just been discussing 7.8, and would be interested in what you guys think. At ICFP we speculated that we'd make a release of GHC soon after Christmas to embody tons of stuff that has been included since 7.6, specifically: · major improvements in DPH (vectorisation avoidance, new vectoriser) · type holes · rebindable list syntax · major changes to the type inference engine · type level natural numbers · overlapping type families · the new code generator · support for vector (SSE/AVX) instructions Whenever it comes it would definitely be great to include Andreas & friends' work: · Scheduler changes to the RTS to improve latency The original major reason for proposing a post-Xmas release was to get DPH in a working state out into the wild. However, making a proper release imposes costs on everyone else. Library authors have to scurry around to make their libraries work, etc. Some of the new stuff hasn't been in HEAD for that long, and hence has not been very thoroughly tested. (But of course making a release unleashes a huge wave of testing that doesn't happen otherwise.) So another alternative is to leave it all as HEAD, and wait another few months before making a release. You can still use all the new stuff by compiling HEAD, or grabbing a snapshot distribution. And it makes it hard for the Haskell platform if GHC moves too fast. Many people are still on 7.4. There seem to be pros and cons each way. I don't have a strong opinion. If you have a view, let us know. Simon

10 9

Re: Cloud Haskell and network latency issues with -threaded
by Andreas Voellmy 06 Feb '13

06 Feb '13

Hi Edsko, Can you explain the figure linked to on that page a bit? E.g. how should the axes be labelled? On Wed, Feb 6, 2013 at 9:33 AM, Edsko de Vries <edsko(a)well-typed.com> wrote: > Hi, > > Just for clarity's sake (as the author of that "Latency" section that Tim > referred to): I have addressed all of the issues listed there in > Network.Transport.TCP, with the exception of the first (the -threaded > issue). As Tim points out, this is not a Cloud Haskell specific issue; I > have written this up as a short blog post at > http://www.edsko.net/2013/02/06/performance-problems-with-threaded . > > Edsko > > > > On Wednesday, 6 February 2013 14:09:22 UTC, Tim Watson wrote: > >> Hi Kostirya, >> >> I'm putting the parallel-haskell and ghc-users lists on cc, just in case >> other (better informed) folks want to chip in here. >> >> ---- >> >> First of all, I'm assuming you're talking about network latency when >> compiling with -threaded - if not I apologise for misunderstanding! >> >> There is apparently an outstanding network latency issue when compiling >> with -threaded, but according to a conversation I had with the other >> developers on #haskell-distributed, this is not something that's specific >> to Cloud Haskell. It is something to do with the threaded runtime system, >> so would need to be solved for GHC (or is it just the Network package!?) in >> general. Writing up a simple C program and equivalent socket use in Haskell >> and comparing the latency using -threaded will show this up. >> >> See the latency section in http://haskell-distributed.**github.com/wiki/* >> *networktransport.html<http://haskell-distributed.github.com/wiki/networktransport.html>for some more details. According to that, there *are* some things we might >> be able to do, but the 20% latency isn't going to change significantly on >> the face of things. >> >> We have an open ticket to look into this (https://cloud-haskell.** >> atlassian.net/browse/NTTCP-4<https://cloud-haskell.atlassian.net/browse/NTTCP-4>) >> and at some point we'll try and put together the sample programs in a >> github repository (if that's not already done - I might've missed previous >> spikes done by Edsko or others) and investigate further. >> >> One of the other (more experienced!) devs might be able to chip in and >> proffer a better explanation. >> >> Cheers, >> Tim >> >> >> On 6 Feb 2013, at 13:27, kost...(a)gmail.com wrote: >> >> > Haven't you had a necessity to launch Haskell in no-threaded mode >> during the intense network data exchange? >> > I am getting the double performance penalty in threaded mode. But I >> must use threaded mode because epoll and kevent are available in the >> threaded mode only. >> > >> >> [snip] >> >> > >> > >> > среда, 6 февраля 2013 г., 12:33:36 UTC+2 пользователь Tim Watson >> написал: >> > Hello all, >> > >> > It's been a busy week for Cloud Haskell and I wanted to share a few of >> > our news items with you all. >> > >> > Firstly, we have a new home page at http://haskell-distributed.** >> github.com <http://haskell-distributed.github.com>, >> > into which most of the documentation and wiki pages have been merged. >> Making >> > sassy looking websites is not really my bag, so I'm very grateful to >> the >> > various author's whose Creative Commons licensed designs and layouts >> made >> > it easy to put together. We've already had some pull requests to fix >> minor >> > problems on the site, so thanks very much to those who've contributed >> already! >> > >> > As well as the new site, you will find a few of us hanging out on the >> > #haskell-distributed channel on freenode. Please do come along and join >> in >> > the conversation. >> > >> > We also recently split up the distributed-process project into separate >> > git repositories, one for each component that makes up Cloud Haskell. >> This >> > was done partly for administrative purposes and partly because we're in >> the >> > process of setting up CI builds for all the projects. >> > >> > Finally, we've moved from Github's issue tracker to a hosted >> Jira/Bamboo setup >> > at https://cloud-haskell.**atlassian.net<https://cloud-haskell.atlassian.net>- pull requests are naturally still welcome >> > via Github! Although you can browse issues freely without logging in, >> you will >> > need to provide an email address and get an account in order to submit >> new ones. >> > If you have any difficulties logging in, please don't hesitate to >> contact me >> > directly, via this forum or the cloud-haskell-developers mailing list >> (on >> > google groups). >> > >> > As always, we'd be delighted to hear any feedback! >> > >> > Cheers, >> > Tim >> >> -- > You received this message because you are subscribed to the Google Groups > "parallel-haskell" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to parallel-haskell+unsubscribe(a)googlegroups.com. > For more options, visit https://groups.google.com/groups/opt_out. > > >

1 0

Re: Cloud Haskell and network latency issues with -threaded
by Tim Watson 06 Feb '13

06 Feb '13

Hi Kostirya, I'm putting the parallel-haskell and ghc-users lists on cc, just in case other (better informed) folks want to chip in here. ---- First of all, I'm assuming you're talking about network latency when compiling with -threaded - if not I apologise for misunderstanding! There is apparently an outstanding network latency issue when compiling with -threaded, but according to a conversation I had with the other developers on #haskell-distributed, this is not something that's specific to Cloud Haskell. It is something to do with the threaded runtime system, so would need to be solved for GHC (or is it just the Network package!?) in general. Writing up a simple C program and equivalent socket use in Haskell and comparing the latency using -threaded will show this up. See the latency section in http://haskell-distributed.github.com/wiki/networktransport.html for some more details. According to that, there *are* some things we might be able to do, but the 20% latency isn't going to change significantly on the face of things. We have an open ticket to look into this (https://cloud-haskell.atlassian.net/browse/NTTCP-4) and at some point we'll try and put together the sample programs in a github repository (if that's not already done - I might've missed previous spikes done by Edsko or others) and investigate further. One of the other (more experienced!) devs might be able to chip in and proffer a better explanation. Cheers, Tim On 6 Feb 2013, at 13:27, kostirya(a)gmail.com wrote: > Haven’t you had a necessity to launch Haskell in no-threaded mode during the intense network data exchange? > I am getting the double performance penalty in threaded mode. But I must use threaded mode because epoll and kevent are available in the threaded mode only. > [snip] > > > среда, 6 февраля 2013 г., 12:33:36 UTC+2 пользователь Tim Watson написал: > Hello all, > > It's been a busy week for Cloud Haskell and I wanted to share a few of > our news items with you all. > > Firstly, we have a new home page at http://haskell-distributed.github.com, > into which most of the documentation and wiki pages have been merged. Making > sassy looking websites is not really my bag, so I'm very grateful to the > various author's whose Creative Commons licensed designs and layouts made > it easy to put together. We've already had some pull requests to fix minor > problems on the site, so thanks very much to those who've contributed already! > > As well as the new site, you will find a few of us hanging out on the > #haskell-distributed channel on freenode. Please do come along and join in > the conversation. > > We also recently split up the distributed-process project into separate > git repositories, one for each component that makes up Cloud Haskell. This > was done partly for administrative purposes and partly because we're in the > process of setting up CI builds for all the projects. > > Finally, we've moved from Github's issue tracker to a hosted Jira/Bamboo setup > at https://cloud-haskell.atlassian.net - pull requests are naturally still welcome > via Github! Although you can browse issues freely without logging in, you will > need to provide an email address and get an account in order to submit new ones. > If you have any difficulties logging in, please don't hesitate to contact me > directly, via this forum or the cloud-haskell-developers mailing list (on > google groups). > > As always, we'd be delighted to hear any feedback! > > Cheers, > Tim

1 0

Validate of GHC HEAD freezes on FreeBSD
by Kazu Yamamoto 04 Feb '13

04 Feb '13

Hello, The "validate" script against GHC HEAD freezes on FreeBSD 9.1. After sync-all, I did as follow: ---------------------------------------------------------------- % config_args="--with-iconv-includes=/usr/local/include --with-iconv-libraries=/usr/local/lib --with-gmp-includes=/usr/local/include --with-gmp-libraries=/usr/local/lib --with-gcc=/usr/local/bin/gcc47" CPUS=10 sh validate ---------------------------------------------------------------- This stopped quickly due to this problem: http://hackage.haskell.org/trac/ghc/ticket/7592 Then I executed "validate" with "--no-clean" again. ---------------------------------------------------------------- % config_args="--with-iconv-includes=/usr/local/include --with-iconv-libraries=/usr/local/lib --with-gmp-includes=/usr/local/include --with-gmp-libraries=/usr/local/lib --with-gcc=/usr/local/bin/gcc47" CPUS=10 sh validate --no-clean ---------------------------------------------------------------- GHC could be compiled and tests started. But this resulted in: ---------------------------------------------------------------- cd ../../libraries/base/tests && '/usr/home/kazu/work/ghc/bindisttest/install dir/bin/ghc' -fforce-recomp -dcore-lint -dcmm-lint -dno-debug-output -no-user-package-db -rtsopts -fno-ghci-history -o qsemn001 qsemn001.hs >qsemn001.comp.stderr 2>&1 cd ../../libraries/base/tests && ./T5962 </dev/null >T5962.run.stdout 2>T5962.run.stderr cd ../../libraries/base/tests && ./5943 </dev/null >5943.run.stdout 2>5943.run.stderr cd ../../libraries/base/tests && ./T7034 </dev/null >T7034.run.stdout 2>T7034.run.stderr cd ../../libraries/base/tests && ./qsem001 </dev/null >qsem001.run.stdout 2>qsem001.run.stderr cd ../../libraries/base/tests && ./qsemn001 </dev/null >qsemn001.run.stdout 2>qsemn001.run.stderr Wrong exit code (expected 0 , actual 9 ) Stdout: Stderr: *** unexpected failure for Chan002(normal) ---------------------------------------------------------------- And waiting for something forever. Does anyone understand what happened? Note that I can build GHC HEAD by typing "gmake" (v3.82 installed by the ports system) twice. This is a serious problem for us since we want to merge our code to GHC HEAD. "validate" against GHC with our code on Linux and Mac passed so far. But "validate" against even vanilla GHC freezes. P.S. On FreeBSD, I applied the following patch for validate since unused-but-set-variable is not available. diff --git a/mk/validate-settings.mk b/mk/validate-settings.mk index 399bf0e..378a3e6 100644 --- a/mk/validate-settings.mk +++ b/mk/validate-settings.mk @@ -13,7 +13,7 @@ HADDOCK_DOCS = YES # Debian doesn't turn -Werror=unused-but-set-variable on by default, so # we turn it on explicitly for consistency with other users ifeq "$(GccLT46)" "NO" -SRC_CC_WARNING_OPTS += -Werror=unused-but-set-variable +#SRC_CC_WARNING_OPTS += -Werror=unused-but-set-variable # gcc 4.6 gives 3 warning for giveCapabilityToTask not being inlined SRC_CC_WARNING_OPTS += -Wno-error=inline endif --Kazu

2 9

GHC compilation error (re-post).
by Caitlin 03 Feb '13

03 Feb '13

Hi all. I wrote the following test program: bar x = x * x on a Win32 (SP3) machine using the Haskell Platform and GHC-7.6.1 (standalone) and I have noticed the same frustrating errors. Any suggestions would be most appreciated. Thanks, ~Caitlin C:\>ghci GHCi, version 7.4.2: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. Loading package base ... linking ... done. Prelude> Prelude> :l bar [1 of 1] Compiling Main ( bar.hs, interpreted ) *** Exception: CreateDirectory ".": permission denied (Access is denied.) > > :l bar.hs [1 of 1] Compiling Main ( bar.hs, interpreted ) *** Exception: CreateDirectory ".": permission denied (Access is denied.) > > :l "C:\\bar.hs" [1 of 1] Compiling Main ( C:\bar.hs, interpreted ) *** Exception: CreateDirectory "C:\\": permission denied (Access is denied.) > >

5 8

ANNOUNCE: GHC version 7.6.2
by Ian Lynagh 02 Feb '13

02 Feb '13

============================================================= The (Interactive) Glasgow Haskell Compiler -- version 7.6.2 ============================================================= The GHC Team is pleased to announce a new patchlevel release of GHC, 7.6.2. This release fixes a number of bugs relative to 7.6.1, so we recommend upgrading. Full release notes are here: http://www.haskell.org/ghc/docs/7.6.2/html/users_guide/release-7-6-2.html How to get it ~~~~~~~~~~~~~ The easy way is to go to the web page, which should be self-explanatory: http://www.haskell.org/ghc/ We supply binary builds in the native package format for many platforms, and the source distribution is available from the same place. Packages will appear as they are built - if the package for your system isn't available yet, please try again later. Background ~~~~~~~~~~ Haskell is a standard lazy functional programming language. GHC is a state-of-the-art programming suite for Haskell. Included is an optimising compiler generating good code for a variety of platforms, together with an interactive system for convenient, quick development. The distribution includes space and time profiling facilities, a large collection of libraries, and support for various language extensions, including concurrency, exceptions, and foreign language interfaces (C, whatever). GHC is distributed under a BSD-style open source license. A wide variety of Haskell related resources (tutorials, libraries, specifications, documentation, compilers, interpreters, references, contact information, links to research groups) are available from the Haskell home page (see below). On-line GHC-related resources ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Relevant URLs on the World-Wide Web: GHC home page http://www.haskell.org/ghc/ GHC developers' home page http://hackage.haskell.org/trac/ghc/ Haskell home page http://www.haskell.org/ Supported Platforms ~~~~~~~~~~~~~~~~~~~ The list of platforms we support, and the people responsible for them, is here: http://hackage.haskell.org/trac/ghc/wiki/Contributors Ports to other platforms are possible with varying degrees of difficulty. The Building Guide describes how to go about porting to a new platform: http://hackage.haskell.org/trac/ghc/wiki/Building Developers ~~~~~~~~~~ We welcome new contributors. Instructions on accessing our source code repository, and getting started with hacking on GHC, are available from the GHC's developer's site run by Trac: http://hackage.haskell.org/trac/ghc/ Mailing lists ~~~~~~~~~~~~~ We run mailing lists for GHC users and bug reports; to subscribe, use the web interfaces at http://www.haskell.org/mailman/listinfo/glasgow-haskell-users http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs There are several other haskell and ghc-related mailing lists on www.haskell.org; for the full list, see http://www.haskell.org/mailman/listinfo/ Some GHC developers hang out on #haskell on IRC, too: http://www.haskell.org/haskellwiki/IRC_channel Please report bugs using our bug tracking system. Instructions on reporting bugs can be found here: http://www.haskell.org/ghc/reportabug

2 1

Proposal to extend FieldPat in Template Haskell
by Iavor Diatchki 30 Jan '13

30 Jan '13

Hello, (sorry for the repost, I forgot to add a subject.) I was just doing some work with Template Haskell and I noticed that the AST does not have support for record puns and wild-cards. I know that these could be desugared into ordinary record patterns but I think that it would be more convenient for users (and also more consistent with the rest of the AST) if we provided direct support for them. So I propose to change: type FieldPat = (Name, Pat) to data FieldPat = RecordFileldP Name Pat -- x = P | RecordPunP Name -- x | RecordWildP -- .. Would there be any objections to doing so? If not, I'd be happy to have a go at making the change. -Iavor

2 1

(no subject)
by Iavor Diatchki 29 Jan '13

29 Jan '13

Hello, I was just doing some work with Template Haskell and I noticed that the AST does not have support for record puns and wild-cards. I know that these could be desugared into ordinary record patterns but I think that it would be more convenient for users (and also more consistent with the rest of the AST) if we provided direct support for them. So I propose to change: type FieldPat = (Name, Pat) to data FieldPat = RecordFileldP Name Pat -- x = P | RecordPunP Name -- x | RecordWildP -- .. Would there be any objections to doing so? If not, I'd be happy to have a go at making the change. -Iavor

1 0

Extended periods of "waking up thread %d on cap %d"
by Ben Gamari 29 Jan '13

29 Jan '13

Recently I've been benchmarking my concurrent Gibbs sampler[1] on a largish multicore machine. I've been using GHC HEAD due to various GC-related fixes that are present. One thing that I've noticed in looking over the event logs is that there are large durations (tens of milliseconds) when HECs appear to be constantly bombarded with wake-ups from other capabilities. In these periods, the eventlog will be filled with blocks of messages such as this snippet from one benchmark run[2] (long repeated blocks marked with ellipses, a few irrelevant messages have been omitted yet not marked, see eventlog for full log), 28.320958s HEC 7: running thread 293 ... 28.391802s HEC 6: running thread 209 28.392070s HEC 6: waking up thread 284 on cap 7 28.392302s HEC 6: waking up thread 284 on cap 7 28.392579s HEC 6: waking up thread 284 on cap 7 28.392808s HEC 6: waking up thread 284 on cap 7 . . . 28.405971s HEC 16: waking up thread 284 on cap 7 28.406026s HEC 15: waking up thread 284 on cap 7 28.406080s HEC 12: waking up thread 284 on cap 7 28.406091s HEC 23: waking up thread 284 on cap 7 28.406095s HEC 6: waking up thread 284 on cap 7 28.406095s HEC 23: waking up thread 284 on cap 7 28.406225s HEC 16: waking up thread 284 on cap 7 . . . 28.490449s HEC 7: stopping thread 293 (thread yielding) 28.490454s HEC 7: waking up thread 284 on cap 7 28.490454s HEC 7: waking up thread 284 on cap 7 28.490455s HEC 7: waking up thread 284 on cap 7 28.490456s HEC 7: waking up thread 284 on cap 7 28.490456s HEC 7: waking up thread 284 on cap 7 28.490457s HEC 7: waking up thread 284 on cap 7 28.490458s HEC 7: waking up thread 284 on cap 7 . . . 28.491841s HEC 7: waking up thread 284 on cap 7 28.491850s HEC 7: migrating thread 284 to cap 0 28.491968s HEC 7: running thread 293 . . . In other words, it appears that HEC 7 took a vacation of more than a millisecond as it tried (ultimately unsuccessfully) to wake up thread 284. These blocks are easy to spot in this event log and quite difficult to explain. In this case I was being silly and spawned a few too many capabilities (30 capabilities whereas the machine has 24 real cores, 2 threads per core due to hyperthreading; I was running 24 threads). That being said, even under more reasonable conditions[3] (where I was running 24 capabilities with 20 threads on the same 24-core machine) I still see problems waking up. For example, from 32.293455s to 32.327349s see numerous attempts by many HECs to wake-up thread 517 on cap 12. In this period, cap 12 briefly runs thread 537 (32.326781s) but while running HEC 17 attempts to wake up 517 again. All-in-all, something seems a bit strange. Any ideas what might be going on here? I've CC'd Edward Yang (who I understand has recently been doing a rework on the scheduler) and Simon Marlow. Thanks, - Ben [1] https://github.com/bgamari/bayes-stack [2] http://goldnerlab.physics.umass.edu/~bgamari/Benchmark-wakeup.eventlog [3] http://goldnerlab.physics.umass.edu/~bgamari/Benchmark-wakeup-smaller.event…

2 3