Re: -prof, -threaded, and -N
That's a leftover from when profiling didn't support -N, I'll fix it.
Thanks!
Simon
On 03/06/2015 07:03, Lars Kuhtz wrote:
From https://github.com/ghc/ghc/blob/master/rts/RtsFlags.c#L1238 it seems that
the behavior described in my email below is intended:
```
if (rts_argv[arg][2] == '\0') {
#if defined(PROFILING)
RtsFlags.ParFlags.nNodes = 1;
#else
RtsFlags.ParFlags.nNodes = getNumberOfProcessors();
#endif
```
So, my question is: what is the reason for this difference between the
profiling and the non-profiling case?
Lars
On Jun 2, 2015, at 10:20 PM, Lars Kuhtz hask...@kuhtz.eu wrote:
Hi,
The behavior of the -N flag (without argument) with the profiling runtime seems
inconsistent compared to the behavior without profiling. The following program
```
module Main where
import GHC.Conc
main :: IO ()
main = print numCapabilities
```
when compiled with `ghc -threaded -fforce-recomp Prof.hs` and run as `./Prof
+RTS -N` prints `2` on my machine. When the same program is compiled with `ghc
-threaded -fforce-recomp -prof Prof.hs` and executed as `./Prof +RTS -N` it
prints `1`.
When an argument is provided to `-N` (e.g. `./Prof +RTS -N2`) the profiling and
non-profiling versions behave the same.
I tested this with GHC-7.10.1 but I think that I already observed the same
behavior with GHC-7.8.
Is this inconsistency intended?
Lars
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
Re: -prof, -threaded, and -N
From https://github.com/ghc/ghc/blob/master/rts/RtsFlags.c#L1238 it seems that
the behavior described in my email below is intended:
```
if (rts_argv[arg][2] == '\0') {
#if defined(PROFILING)
RtsFlags.ParFlags.nNodes = 1;
#else
RtsFlags.ParFlags.nNodes = getNumberOfProcessors();
#endif
```
So, my question is: what is the reason for this difference between the
profiling and the non-profiling case?
Lars
On Jun 2, 2015, at 10:20 PM, Lars Kuhtz hask...@kuhtz.eu wrote:
Hi,
The behavior of the -N flag (without argument) with the profiling runtime
seems inconsistent compared to the behavior without profiling. The following
program
```
module Main where
import GHC.Conc
main :: IO ()
main = print numCapabilities
```
when compiled with `ghc -threaded -fforce-recomp Prof.hs` and run as `./Prof
+RTS -N` prints `2` on my machine. When the same program is compiled with
`ghc -threaded -fforce-recomp -prof Prof.hs` and executed as `./Prof +RTS -N`
it prints `1`.
When an argument is provided to `-N` (e.g. `./Prof +RTS -N2`) the profiling
and non-profiling versions behave the same.
I tested this with GHC-7.10.1 but I think that I already observed the same
behavior with GHC-7.8.
Is this inconsistency intended?
Lars
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
-prof, -threaded, and -N
Hi, The behavior of the -N flag (without argument) with the profiling runtime seems inconsistent compared to the behavior without profiling. The following program ``` module Main where import GHC.Conc main :: IO () main = print numCapabilities ``` when compiled with `ghc -threaded -fforce-recomp Prof.hs` and run as `./Prof +RTS -N` prints `2` on my machine. When the same program is compiled with `ghc -threaded -fforce-recomp -prof Prof.hs` and executed as `./Prof +RTS -N` it prints `1`. When an argument is provided to `-N` (e.g. `./Prof +RTS -N2`) the profiling and non-profiling versions behave the same. I tested this with GHC-7.10.1 but I think that I already observed the same behavior with GHC-7.8. Is this inconsistency intended? Lars ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
RE: Cloud Haskell and network latency issues with -threaded
Hey folks, The latency changes sound relevant to some work on the scheduler I'm doing; is there a place I can see the changes? Thanks, Edward Excerpts from Simon Peyton-Jones's message of Wed Feb 06 10:10:10 -0800 2013: 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-hask...@googlegroups.com [mailto:parallel-hask...@googlegroups.com] On Behalf Of Andreas Voellmy Sent: 06 February 2013 14:28 To: watson.timo...@gmail.com Cc: kosti...@gmail.com; parallel-haskell; glasgow-haskell-users@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.timo...@gmail.commailto:watson.timo...@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, kosti...@gmail.commailto:kosti...@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
Re: Cloud Haskell and network latency issues with -threaded
Hi Edward, I did two things to improve latency for my application: (1) rework the IO manager and (2) stabilize the work pushing. (1) seems like a big win and we are almost done with the work on that part. It is less clear whether (2) will generally help much. It helped me when I developed it against 7.4.1, but it doesn't seem to have much impact on HEAD on the few measurements I did. The idea of (2) was to keep running averages of the run queue length of each capability, then push work when these running averages get too out-of-balance. The desired effect (which seems to work on my particular application) is to avoid cases in which threads are pushed back and forth among cores, which may make cache usage worse. You can see my patch here: https://github.com/AndreasVoellmy/ghc-arv/commits/push-work-exchange-squashed . -Andi On Fri, Feb 8, 2013 at 12:10 AM, Edward Z. Yang ezy...@mit.edu wrote: Hey folks, The latency changes sound relevant to some work on the scheduler I'm doing; is there a place I can see the changes? Thanks, Edward Excerpts from Simon Peyton-Jones's message of Wed Feb 06 10:10:10 -0800 2013: 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-hask...@googlegroups.com [mailto: parallel-hask...@googlegroups.com] On Behalf Of Andreas Voellmy Sent: 06 February 2013 14:28 To: watson.timo...@gmail.com Cc: kosti...@gmail.com; parallel-haskell; glasgow-haskell-users@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.timo...@gmail.com mailto:watson.timo...@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, kosti...@gmail.commailto:kosti...@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
Re: Cloud Haskell and network latency issues with -threaded
OK. I think it is high priority for us to get some latency benchmarks into nofib so that GHC devs (including me) can start measuring changes off them. I know Edsko has some benchmarks here: http://www.edsko.net/2013/02/06/performance-problems-with-threaded/ but they depend on network which makes it a little difficult to move into nofib. I'm working on other scheduler changes that may help you guys out; we should keep each other updated. I noticed your patch also incorporates the make yield actually work patch; do you think the improvement in 7.4.1 was due to that specific change? (Have you instrumented the run queues and checked how your patch changes the distribution of jobs over your runtime?) Somewhat unrelatedly, if you have some good latency tests already, it may be worth a try compiling your copy of GHC -fno-omit-yields, so that forced context switches get serviced more predictably. Cheers, Edward Excerpts from Andreas Voellmy's message of Thu Feb 07 21:20:25 -0800 2013: Hi Edward, I did two things to improve latency for my application: (1) rework the IO manager and (2) stabilize the work pushing. (1) seems like a big win and we are almost done with the work on that part. It is less clear whether (2) will generally help much. It helped me when I developed it against 7.4.1, but it doesn't seem to have much impact on HEAD on the few measurements I did. The idea of (2) was to keep running averages of the run queue length of each capability, then push work when these running averages get too out-of-balance. The desired effect (which seems to work on my particular application) is to avoid cases in which threads are pushed back and forth among cores, which may make cache usage worse. You can see my patch here: https://github.com/AndreasVoellmy/ghc-arv/commits/push-work-exchange-squashed . -Andi On Fri, Feb 8, 2013 at 12:10 AM, Edward Z. Yang ezy...@mit.edu wrote: Hey folks, The latency changes sound relevant to some work on the scheduler I'm doing; is there a place I can see the changes? Thanks, Edward Excerpts from Simon Peyton-Jones's message of Wed Feb 06 10:10:10 -0800 2013: 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-hask...@googlegroups.com [mailto: parallel-hask...@googlegroups.com] On Behalf Of Andreas Voellmy Sent: 06 February 2013 14:28 To: watson.timo...@gmail.com Cc: kosti...@gmail.com; parallel-haskell; glasgow-haskell-users@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.timo...@gmail.com mailto:watson.timo...@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
Re: Cloud Haskell and network latency issues with -threaded
On Fri, Feb 8, 2013 at 12:30 AM, Edward Z. Yang ezy...@mit.edu wrote: OK. I think it is high priority for us to get some latency benchmarks into nofib so that GHC devs (including me) can start measuring changes off them. I know Edsko has some benchmarks here: http://www.edsko.net/2013/02/06/performance-problems-with-threaded/ but they depend on network which makes it a little difficult to move into nofib. I'm working on other scheduler changes that may help you guys out; we should keep each other updated. That would be great :) I noticed your patch also incorporates the make yield actually work patch; do you think the improvement in 7.4.1 was due to that specific change? Actually, I believe that patch is irrelevant to the scheduler change and probably should not be in there, strictly speaking. I actually needed that patch for the IO manager revisions to work properly. (Have you instrumented the run queues and checked how your patch changes the distribution of jobs over your runtime?) I didn't do this very rigorously, but I think I added some print statements in the scheduler and I looked at some eventlogs in threadscope to see that threads work pushing slows down after a while. I had planned to write a script to analyze an event log file to extract these stats, but I never got around to it. -Andi Somewhat unrelatedly, if you have some good latency tests already, it may be worth a try compiling your copy of GHC -fno-omit-yields, so that forced context switches get serviced more predictably. Cheers, Edward Excerpts from Andreas Voellmy's message of Thu Feb 07 21:20:25 -0800 2013: Hi Edward, I did two things to improve latency for my application: (1) rework the IO manager and (2) stabilize the work pushing. (1) seems like a big win and we are almost done with the work on that part. It is less clear whether (2) will generally help much. It helped me when I developed it against 7.4.1, but it doesn't seem to have much impact on HEAD on the few measurements I did. The idea of (2) was to keep running averages of the run queue length of each capability, then push work when these running averages get too out-of-balance. The desired effect (which seems to work on my particular application) is to avoid cases in which threads are pushed back and forth among cores, which may make cache usage worse. You can see my patch here: https://github.com/AndreasVoellmy/ghc-arv/commits/push-work-exchange-squashed . -Andi On Fri, Feb 8, 2013 at 12:10 AM, Edward Z. Yang ezy...@mit.edu wrote: Hey folks, The latency changes sound relevant to some work on the scheduler I'm doing; is there a place I can see the changes? Thanks, Edward Excerpts from Simon Peyton-Jones's message of Wed Feb 06 10:10:10 -0800 2013: 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-hask...@googlegroups.com [mailto: parallel-hask...@googlegroups.com] On Behalf Of Andreas Voellmy Sent: 06 February 2013 14:28 To: watson.timo...@gmail.com Cc: kosti...@gmail.com; parallel-haskell; glasgow-haskell-users@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.timo...@gmail.com mailto:watson.timo...@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
Re: Cloud Haskell and network latency issues with -threaded
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, kosti...@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 ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Cloud Haskell and network latency issues with -threaded
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 ed...@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.htmlhttp://haskell-distributed.github.com/wiki/networktransport.htmlfor 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-4https://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...@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.nethttps://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+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: Cloud Haskell and network latency issues with -threaded
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-hask...@googlegroups.com [mailto:parallel-hask...@googlegroups.com] On Behalf Of Andreas Voellmy Sent: 06 February 2013 14:28 To: watson.timo...@gmail.com Cc: kosti...@gmail.com; parallel-haskell; glasgow-haskell-users@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.timo...@gmail.commailto:watson.timo...@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, kosti...@gmail.commailto:kosti...@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
Re: Runtime performance degradation for multi-threaded C FFI callback
On 21/01/2012 15:35, Sanket Agrawal wrote: Hi Edward, I was just going to get back to you about it. I did find out that the issue was indeed one GHC thread dealing with 5 C threads for callback (1:5 mapping) - so, the C threads were blocking on callback waiting for the only GHC thread to be available. I updated the code to do 1:1 mapping - 5 GHC threads for 5 C threads. That proved to be almost linearly scalable. This is almost right, except that your callbacks are not waiting for a GHC *thread*, but what we call a capability, which is roughly speaking permission to execute Haskell code. The +RTS -N option chooses the number of capabilities. I expect that with -N1, your program is spending a lot of time just switching between the different OS threads. It's possible that we could make the runtime more flexible here. I recently made it possible to modify the number of capabilities at runtime, so it's conceivable that the runtime could automatically add capabilities if it is being called from multiple OS threads. John Latos suggested the above approach two days back, but I didn't get to test the idea until now. It doesn't seem to matter whether number of GHC threads are increased, if the mapping between GHC threads and C threads is not 1:1. I got 1:1 mapping by doing forkIO for each C thread. Is it really possible to do 7:5 mapping (that is 7 GHC threads to choose from, for 5 C threads during callback)? I can't think of a way to do it. Not that I need it. I am just curious if that is possible. Just think of +RTS -N7 as being 7 *locks*, not 7 threads. Then it makes perfect sense to have 7 locks available for 5 threads. Cheers, Simon Thanks, Sanket On Fri, Jan 20, 2012 at 11:16 PM, Edward Z. Yang ezy...@mit.edu mailto:ezy...@mit.edu wrote: Hello Sanket, What happens if you run this experiment with 5 threads in the C function, and have GHC run RTS with -N7? (e.g. five C threads + seven GHC threads = 12 threads on your 12-core box.) Edward Excerpts from Sanket Agrawal's message of Tue Jan 17 23:31:38 -0500 2012 tel:38%20-0500%202012: I posted this issue on StackOverflow today. A brief recap: In the case when C FFI calls back a Haskell function, I have observed sharp increase in total time when multi-threading is enabled in C code (even when total number of function calls to Haskell remain same). In my test, I called a Haskell function 5M times using two scenarios (GHC 7.0.4, RHEL5, 12-core box): - Single-threaded C function: call back Haskell function 5M times - Total time 1.32s - 5 threads in C function: each thread calls back the Haskell function 1M times - so, total is still 5M - Total time 7.79s - Verified that pthread didn't contribute much to the overhead by having the same code call a C function instead, and compared with single-threaded version. So, almost all of the increase in overhead seems to come from GHC runtime. What I want to ask is if this is a known issue for GHC runtime? If not, I will file a bug report for GHC team with code to reproduce it. I don't want to file a duplicate bug report if this is already known issue. I searched through GHC trac using some keywords but didn't see any bugs related to it. StackOverflow post link (has code and details on how to reproduce the issue): http://stackoverflow.com/questions/8902568/runtime-performance-degradation-for-c-ffi-callback-when-pthreads-are-enabled ___ 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: Runtime performance degradation for multi-threaded C FFI callback
Hi Simon, I'm not certain that your explanation matches what I observed. All of my tests were done on a 4-core machine, executing with +RTS -N, which should be the same as +RTS -N4 I believe. With 1 Haskell thread (the main thread) and 4 process threads (via pthreads), I saw a significant performance degradation compared to 5 Haskell threads (main + 4 via forkIO) and 4 process threads. As I understand your explanation, if C callbacks are scheduled according to available capabilities, there should be no difference between these situations. I observed this with GHC-7.2.1, however Daniel Fischer reported that, with ghc-7.2.2, he observed different behavior (which matches your explanation AFAICT). Is it possible that the scheduling of callbacks into Haskell changed between those versions? Thanks, John L. From: Simon Marlow marlo...@gmail.com Subject: Re: Runtime performance degradation for multi-threaded C FFI callback To: Sanket Agrawal sanket.agra...@gmail.com Cc: glasgow-haskell-users glasgow-haskell-users@haskell.org Message-ID: 4f1d2f4d.9050...@gmail.com Content-Type: text/plain; charset=ISO-8859-1; format=flowed On 21/01/2012 15:35, Sanket Agrawal wrote: Hi Edward, I was just going to get back to you about it. I did find out that the issue was indeed one GHC thread dealing with 5 C threads for callback (1:5 mapping) - so, the C threads were blocking on callback waiting for the only GHC thread to be available. I updated the code to do 1:1 mapping - 5 GHC threads for 5 C threads. That proved to be almost linearly scalable. This is almost right, except that your callbacks are not waiting for a GHC *thread*, but what we call a capability, which is roughly speaking permission to execute Haskell code. The +RTS -N option chooses the number of capabilities. I expect that with -N1, your program is spending a lot of time just switching between the different OS threads. It's possible that we could make the runtime more flexible here. I recently made it possible to modify the number of capabilities at runtime, so it's conceivable that the runtime could automatically add capabilities if it is being called from multiple OS threads. John Latos suggested the above approach two days back, but I didn't get to test the idea until now. It doesn't seem to matter whether number of GHC threads are increased, if the mapping between GHC threads and C threads is not 1:1. I got 1:1 mapping by doing forkIO for each C thread. Is it really possible to do 7:5 mapping (that is 7 GHC threads to choose from, for 5 C threads during callback)? I can't think of a way to do it. Not that I need it. I am just curious if that is possible. Just think of +RTS -N7 as being 7 *locks*, not 7 threads. Then it makes perfect sense to have 7 locks available for 5 threads. Cheers, Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Runtime performance degradation for multi-threaded C FFI callback
I'll need to analyse the program to see what's going on. There was a small change to the scheduler between 7.2.1 and 7.2.2 that could conceivably have made a difference in this scenario, but it was aimed at fixing a bug rather than improvement performance. Another possibility is a difference in OS scheduling behaviour between yours and Daniel Fischer's setup. In microbenchmarks like this, it's easy for a difference in OS scheduling behaviour to make a large difference in performance if it happens consistently. Cheers, Simon On 23/01/2012 12:49, John Lato wrote: Hi Simon, I'm not certain that your explanation matches what I observed. All of my tests were done on a 4-core machine, executing with +RTS -N, which should be the same as +RTS -N4 I believe. With 1 Haskell thread (the main thread) and 4 process threads (via pthreads), I saw a significant performance degradation compared to 5 Haskell threads (main + 4 via forkIO) and 4 process threads. As I understand your explanation, if C callbacks are scheduled according to available capabilities, there should be no difference between these situations. I observed this with GHC-7.2.1, however Daniel Fischer reported that, with ghc-7.2.2, he observed different behavior (which matches your explanation AFAICT). Is it possible that the scheduling of callbacks into Haskell changed between those versions? Thanks, John L. From: Simon Marlowmarlo...@gmail.com Subject: Re: Runtime performance degradation for multi-threaded C FFI callback To: Sanket Agrawalsanket.agra...@gmail.com Cc: glasgow-haskell-usersglasgow-haskell-users@haskell.org Message-ID:4f1d2f4d.9050...@gmail.com Content-Type: text/plain; charset=ISO-8859-1; format=flowed On 21/01/2012 15:35, Sanket Agrawal wrote: Hi Edward, I was just going to get back to you about it. I did find out that the issue was indeed one GHC thread dealing with 5 C threads for callback (1:5 mapping) - so, the C threads were blocking on callback waiting for the only GHC thread to be available. I updated the code to do 1:1 mapping - 5 GHC threads for 5 C threads. That proved to be almost linearly scalable. This is almost right, except that your callbacks are not waiting for a GHC *thread*, but what we call a capability, which is roughly speaking permission to execute Haskell code. The +RTS -N option chooses the number of capabilities. I expect that with -N1, your program is spending a lot of time just switching between the different OS threads. It's possible that we could make the runtime more flexible here. I recently made it possible to modify the number of capabilities at runtime, so it's conceivable that the runtime could automatically add capabilities if it is being called from multiple OS threads. John Latos suggested the above approach two days back, but I didn't get to test the idea until now. It doesn't seem to matter whether number of GHC threads are increased, if the mapping between GHC threads and C threads is not 1:1. I got 1:1 mapping by doing forkIO for each C thread. Is it really possible to do 7:5 mapping (that is 7 GHC threads to choose from, for 5 C threads during callback)? I can't think of a way to do it. Not that I need it. I am just curious if that is possible. Just think of +RTS -N7 as being 7 *locks*, not 7 threads. Then it makes perfect sense to have 7 locks available for 5 threads. Cheers, Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Runtime performance degradation for multi-threaded C FFI callback
I agree the OS scheduler is likely to contribute to our different observations. I'll try to test with ghc-7.4-rc1 tonight to see if I get similar results to 7.2.1. If you want to see some code I'll post it, although I doubt it's necessary. I would appreciate it if you (or someone else in the know) could answer a question for me: does the GHC runtime handle scheduling of code from Haskell threads (forkIO) and foreign callbacks (via FunPtr's) in the same way, or are there restrictions on which capability may handle one or the other (ignoring bound threads and the like)? Thank you, John L. On Mon, Jan 23, 2012 at 1:26 PM, Simon Marlow marlo...@gmail.com wrote: I'll need to analyse the program to see what's going on. There was a small change to the scheduler between 7.2.1 and 7.2.2 that could conceivably have made a difference in this scenario, but it was aimed at fixing a bug rather than improvement performance. Another possibility is a difference in OS scheduling behaviour between yours and Daniel Fischer's setup. In microbenchmarks like this, it's easy for a difference in OS scheduling behaviour to make a large difference in performance if it happens consistently. Cheers, Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Runtime performance degradation for multi-threaded C FFI callback
Hi Edward, I was just going to get back to you about it. I did find out that the issue was indeed one GHC thread dealing with 5 C threads for callback (1:5 mapping) - so, the C threads were blocking on callback waiting for the only GHC thread to be available. I updated the code to do 1:1 mapping - 5 GHC threads for 5 C threads. That proved to be almost linearly scalable. John Latos suggested the above approach two days back, but I didn't get to test the idea until now. It doesn't seem to matter whether number of GHC threads are increased, if the mapping between GHC threads and C threads is not 1:1. I got 1:1 mapping by doing forkIO for each C thread. Is it really possible to do 7:5 mapping (that is 7 GHC threads to choose from, for 5 C threads during callback)? I can't think of a way to do it. Not that I need it. I am just curious if that is possible. Thanks, Sanket On Fri, Jan 20, 2012 at 11:16 PM, Edward Z. Yang ezy...@mit.edu wrote: Hello Sanket, What happens if you run this experiment with 5 threads in the C function, and have GHC run RTS with -N7? (e.g. five C threads + seven GHC threads = 12 threads on your 12-core box.) Edward Excerpts from Sanket Agrawal's message of Tue Jan 17 23:31:38 -0500 2012: I posted this issue on StackOverflow today. A brief recap: In the case when C FFI calls back a Haskell function, I have observed sharp increase in total time when multi-threading is enabled in C code (even when total number of function calls to Haskell remain same). In my test, I called a Haskell function 5M times using two scenarios (GHC 7.0.4, RHEL5, 12-core box): - Single-threaded C function: call back Haskell function 5M times - Total time 1.32s - 5 threads in C function: each thread calls back the Haskell function 1M times - so, total is still 5M - Total time 7.79s - Verified that pthread didn't contribute much to the overhead by having the same code call a C function instead, and compared with single-threaded version. So, almost all of the increase in overhead seems to come from GHC runtime. What I want to ask is if this is a known issue for GHC runtime? If not, I will file a bug report for GHC team with code to reproduce it. I don't want to file a duplicate bug report if this is already known issue. I searched through GHC trac using some keywords but didn't see any bugs related to it. StackOverflow post link (has code and details on how to reproduce the issue): http://stackoverflow.com/questions/8902568/runtime-performance-degradation-for-c-ffi-callback-when-pthreads-are-enabled ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Runtime performance degradation for multi-threaded C FFI callback
Hello Sanket, What happens if you run this experiment with 5 threads in the C function, and have GHC run RTS with -N7? (e.g. five C threads + seven GHC threads = 12 threads on your 12-core box.) Edward Excerpts from Sanket Agrawal's message of Tue Jan 17 23:31:38 -0500 2012: I posted this issue on StackOverflow today. A brief recap: In the case when C FFI calls back a Haskell function, I have observed sharp increase in total time when multi-threading is enabled in C code (even when total number of function calls to Haskell remain same). In my test, I called a Haskell function 5M times using two scenarios (GHC 7.0.4, RHEL5, 12-core box): - Single-threaded C function: call back Haskell function 5M times - Total time 1.32s - 5 threads in C function: each thread calls back the Haskell function 1M times - so, total is still 5M - Total time 7.79s - Verified that pthread didn't contribute much to the overhead by having the same code call a C function instead, and compared with single-threaded version. So, almost all of the increase in overhead seems to come from GHC runtime. What I want to ask is if this is a known issue for GHC runtime? If not, I will file a bug report for GHC team with code to reproduce it. I don't want to file a duplicate bug report if this is already known issue. I searched through GHC trac using some keywords but didn't see any bugs related to it. StackOverflow post link (has code and details on how to reproduce the issue): http://stackoverflow.com/questions/8902568/runtime-performance-degradation-for-c-ffi-callback-when-pthreads-are-enabled ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Runtime performance degradation for multi-threaded C FFI callback
I posted this issue on StackOverflow today. A brief recap: In the case when C FFI calls back a Haskell function, I have observed sharp increase in total time when multi-threading is enabled in C code (even when total number of function calls to Haskell remain same). In my test, I called a Haskell function 5M times using two scenarios (GHC 7.0.4, RHEL5, 12-core box): - Single-threaded C function: call back Haskell function 5M times - Total time 1.32s - 5 threads in C function: each thread calls back the Haskell function 1M times - so, total is still 5M - Total time 7.79s - Verified that pthread didn't contribute much to the overhead by having the same code call a C function instead, and compared with single-threaded version. So, almost all of the increase in overhead seems to come from GHC runtime. What I want to ask is if this is a known issue for GHC runtime? If not, I will file a bug report for GHC team with code to reproduce it. I don't want to file a duplicate bug report if this is already known issue. I searched through GHC trac using some keywords but didn't see any bugs related to it. StackOverflow post link (has code and details on how to reproduce the issue): http://stackoverflow.com/questions/8902568/runtime-performance-degradation-for-c-ffi-callback-when-pthreads-are-enabled ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Runtime performance degradation for multi-threaded C FFI callback
Hmm, this kind of sounds like GHC is assuming that it has control over all of the threads, and when this assumption fails bad things happen. (We use lightweight threads, and use the operating system threads that map to pthreads sparingly.) I'm sure Simon Marlow could give a more accurate assessment, however. Edward Excerpts from Sanket Agrawal's message of Tue Jan 17 23:31:38 -0500 2012: I posted this issue on StackOverflow today. A brief recap: In the case when C FFI calls back a Haskell function, I have observed sharp increase in total time when multi-threading is enabled in C code (even when total number of function calls to Haskell remain same). In my test, I called a Haskell function 5M times using two scenarios (GHC 7.0.4, RHEL5, 12-core box): - Single-threaded C function: call back Haskell function 5M times - Total time 1.32s - 5 threads in C function: each thread calls back the Haskell function 1M times - so, total is still 5M - Total time 7.79s - Verified that pthread didn't contribute much to the overhead by having the same code call a C function instead, and compared with single-threaded version. So, almost all of the increase in overhead seems to come from GHC runtime. What I want to ask is if this is a known issue for GHC runtime? If not, I will file a bug report for GHC team with code to reproduce it. I don't want to file a duplicate bug report if this is already known issue. I searched through GHC trac using some keywords but didn't see any bugs related to it. StackOverflow post link (has code and details on how to reproduce the issue): http://stackoverflow.com/questions/8902568/runtime-performance-degradation-for-c-ffi-callback-when-pthreads-are-enabled ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Beware: Bad I/O performance on Windows without -threaded
I just noticed that I/O performane on Windows without -threaded is pretty terrible. The following program: main = getConetnts = putStr tested with a 1MB file: $ rm cat.exe; ghc-7.0.1 --make -rtsopts cat.hs $ ./cat 1M /dev/null +RTS -s snip Total time0.28s ( 0.49s elapsed) snip But if we add -threaded: $ rm cat.exe; ghc-7.0.1 --make -rtsopts cat.hs -threaded $ ./cat 1M /dev/null +RTS -s snip Total time0.05s ( 0.07s elapsed) snip Several times better. I just made a tweak in my working tree to increase the I/O buffer sizes, and this helps quite a lot: $ rm cat.exe; ../ghc-testing/inplace/bin/ghc-stage2.exe --make -rtsopts cat.hs $ ./cat 1M /dev/null +RTS -s snip Total time0.06s ( 0.05s elapsed) snip $ rm cat.exe; ../ghc-testing/inplace/bin/ghc-stage2.exe --make -rtsopts cat.hs -threaded $ ./cat 1M /dev/null +RTS -s snip Total time0.05s ( 0.05s elapsed) snip Why is this? I'm not entirely sure, but I suspect it is the implementation of asynchronous I/O in the RTS that is only used on Windows without -threaded (rts/win32/AsyncIO.c etc.). Every I/O operation in the non-threaded RTS on Windows involves a couple of OS-thread switches. I'll get the buffer size fixes into 7.0.2. Cheers, Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Problems with openFd and -threaded
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11/29/10 18:36 , Bryan O'Sullivan wrote: On Sat, Nov 27, 2010 at 9:05 PM, wren ng thornton w...@freegeek.org mailto:w...@freegeek.org wrote: So I've just started playing around with STM and -threaded programs and I've run into a bug. The bug is similar to [1] except that the file in question is a Posix FIFO instead of a Bluetooth device. Same behavior: always errors with -threaded, but expected behavior when not -threaded (i.e., blocks until another process opens the other end of the FIFO). GHC version is 6.12.1. Isn't that pretty normal? Just retry if you get EINTR, that's what throwErrnoIfMinus1 and friends are for: The problem is the interrupting signal is the timer interrupt used by the runtime system; this should not be visible to user programs, instead the runtime should *itself* restart the operation. - -- brandon s. allbery [linux,solaris,freebsd,perl] allb...@kf8nh.com system administrator [openafs,heimdal,too many hats] allb...@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.10 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkz5Uv4ACgkQIn7hlCsL25UOLACgz85SXrIH54c5zVZHot0FTzqW Z9cAoKa6ViYVrT4U5PaYwVF34oM6lahv =o2md -END PGP SIGNATURE- ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Problems with openFd and -threaded
On 30/11/10 05:49, wren ng thornton wrote: On 11/29/10 6:36 PM, Bryan O'Sullivan wrote: On Sat, Nov 27, 2010 at 9:05 PM, wren ng thorntonw...@freegeek.org wrote: So I've just started playing around with STM and -threaded programs and I've run into a bug. The bug is similar to [1] except that the file in question is a Posix FIFO instead of a Bluetooth device. Same behavior: always errors with -threaded, but expected behavior when not -threaded (i.e., blocks until another process opens the other end of the FIFO). GHC version is 6.12.1. Isn't that pretty normal? The blocking for someone to open the other end is perfectly normal. The fact that compiling with -threaded takes a perfectly working program and makes it consistently crash I wouldn't call normal. N.B., the call to openFd in question is from the main thread and before any STM or forkIO shenanigans. Just retry if you get EINTR, that's what throwErrnoIfMinus1 and friends are for: http://www.haskell.org/ghc/docs/6.12.2/html/libraries/base-4.2.0.1/Foreign-C-Error.html#v%3AthrowErrnoIfRetryMayBlock I'll see if I can make a workaround with that, but as I said: Simon's already confirmed that this is a bug, I'm just looking for a ticket number or a version where it's fixed. And fix it I did: Wed Jan 27 11:46:00 GMT 2010 Simon Marlow marlo...@gmail.com * check for EINTR in openFd M ./System/Posix/Error.hs -2 +26 M ./System/Posix/IO.hsc -1 +1 The fix is in unix-2.4.1.0, which comes with GHC 7.0.1. Cheers, Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Problems with openFd and -threaded
On 11/30/10 11:05 AM, Simon Marlow wrote: On 30/11/10 05:49, wren ng thornton wrote: I'll see if I can make a workaround with that, but as I said: Simon's already confirmed that this is a bug, I'm just looking for a ticket number or a version where it's fixed. And fix it I did: Wed Jan 27 11:46:00 GMT 2010 Simon Marlow marlo...@gmail.com * check for EINTR in openFd M ./System/Posix/Error.hs -2 +26 M ./System/Posix/IO.hsc -1 +1 The fix is in unix-2.4.1.0, which comes with GHC 7.0.1. Cool. Thanks. -- Live well, ~wren ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Problems with openFd and -threaded
On Sat, Nov 27, 2010 at 9:05 PM, wren ng thornton w...@freegeek.org wrote: So I've just started playing around with STM and -threaded programs and I've run into a bug. The bug is similar to [1] except that the file in question is a Posix FIFO instead of a Bluetooth device. Same behavior: always errors with -threaded, but expected behavior when not -threaded (i.e., blocks until another process opens the other end of the FIFO). GHC version is 6.12.1. Isn't that pretty normal? Just retry if you get EINTR, that's what throwErrnoIfMinus1 and friends are for: http://www.haskell.org/ghc/docs/6.12.2/html/libraries/base-4.2.0.1/Foreign-C-Error.html#v%3AthrowErrnoIfRetryMayBlock ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Problems with openFd and -threaded
On 11/29/10 6:36 PM, Bryan O'Sullivan wrote: On Sat, Nov 27, 2010 at 9:05 PM, wren ng thorntonw...@freegeek.org wrote: So I've just started playing around with STM and -threaded programs and I've run into a bug. The bug is similar to [1] except that the file in question is a Posix FIFO instead of a Bluetooth device. Same behavior: always errors with -threaded, but expected behavior when not -threaded (i.e., blocks until another process opens the other end of the FIFO). GHC version is 6.12.1. Isn't that pretty normal? The blocking for someone to open the other end is perfectly normal. The fact that compiling with -threaded takes a perfectly working program and makes it consistently crash I wouldn't call normal. N.B., the call to openFd in question is from the main thread and before any STM or forkIO shenanigans. Just retry if you get EINTR, that's what throwErrnoIfMinus1 and friends are for: http://www.haskell.org/ghc/docs/6.12.2/html/libraries/base-4.2.0.1/Foreign-C-Error.html#v%3AthrowErrnoIfRetryMayBlock I'll see if I can make a workaround with that, but as I said: Simon's already confirmed that this is a bug, I'm just looking for a ticket number or a version where it's fixed. -- Live well, ~wren ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Problems with openFd and -threaded
On Mon, Nov 29, 2010 at 9:49 PM, wren ng thornton w...@freegeek.org wrote: Isn't that pretty normal? The blocking for someone to open the other end is perfectly normal. The fact that compiling with -threaded takes a perfectly working program and makes it consistently crash I wouldn't call normal. Actually, this happens all the time if you're calling a system call that isn't already wrapped for you, and the behaviour is expected: you absolutely must expect, and deal with, EINTR. Here's an example: http://www.serpentine.com/blog/2010/09/04/dealing-with-fragile-c-libraries-e-g-mysql-from-haskell/ Are you using System.Posix.IO.openFD? The check for EINTR wasn't added to the unix package until January of this year, so perhaps the version of GHC or the unix package that you're using is too old to contain the fix? N.B., the call to openFd in question is from the main thread and before any STM or forkIO shenanigans. That doesn't matter. Once the threaded RTS starts, it's going to send your program SIGVTALRM. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Problems with openFd and -threaded
So I've just started playing around with STM and -threaded programs and I've run into a bug. The bug is similar to [1] except that the file in question is a Posix FIFO instead of a Bluetooth device. Same behavior: always errors with -threaded, but expected behavior when not -threaded (i.e., blocks until another process opens the other end of the FIFO). GHC version is 6.12.1. In the previous thread Simon confirmed that it's a bug and said he'd fix it, but I didn't see any ticket mentioned. Does anyone know if there's a ticket for it, or when it will be/has been fixed? [1] http://www.haskell.org/pipermail/glasgow-haskell-users/2009-December/018147.html -- Live well, ~wren ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Odd behavior of ncurses with -threaded
On 12/11/2010 17:25, Donn Cave wrote: Quoth Simon Marlowmarlo...@gmail.com, ... Is there anything that we could do in GHC to improve the situation? I suppose we could have a dedicated OS thread who's job it was to sit around and run the signal handler every Nth of a second. Since the -threaded RTS automatically spawns a couple of extra OS threads anyway, what's one more? I don't know - maybe it wouldn't be a problem. But we'd have to measure things to make sure the extra thread wasn't impacting performance somehow (e.g. by confusing the OS scheduler). Quoth Brian Sullivanb...@serpentine.com, or masking out RTS signals before calling potentially blocking foreign code (which is all my hack does) And unmasking on re-entry via callback, I suppose. Right - making a system call for every safe foreign call and return/callback probalby would make a difference. It's clear that a large number of C programmers know nothing about restarting system calls, and authors writing FFI code typically can't do anything about that except make sure those system calls don't get interrupted in the first place. Note that one of the reported victims was cabal, where I think it was a getContents that aborted with EINTR, on OpenSolaris. I have no idea what was going on there. Yes, we still don't know what the problem is there. Cheers, Simon Nor do I have any idea why my platform libraries are vulnerable to this signal - maybe it's just the usual system call, but I'm not on UNIX. In the present case, ncurses is probably as old as some of the parties to this discussion, and you'd have to wonder if after all this time it doesn't restart its select() on EINTR, if it isn't because that's actually how they want it to work! I'm not going to defend that proposition, but you're right, very low odds that the external world will be fixed to support timer signals. The SIGVTALRM fix solves the problem of an application that uses SIGALRM in its own timer. Donn Cave, d...@avvanta.com ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Signal handler scheduling on single-threaded RTS
Oh, there's quite a simple fix for this: don't have the FFI call handle the SIGINT; only handle a signal the RTS generates. I guess we should do a little more legwork to make sure interruptible(?) user threads don't see signals. Edward ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Odd behavior of ncurses with -threaded
On 11/11/2010 22:41, Bryan O'Sullivan wrote: On Thu, Nov 11, 2010 at 2:32 PM, Edward Z. Yang ezy...@mit.edu mailto:ezy...@mit.edu wrote: I was under the impression we fixed this: http://hackage.haskell.org/trac/ghc/ticket/850 That is, we should be using SIGVTALRM, not SIGALRM, these days, except under certain conditions when your operating system doesn't support the proper timer (which Linux most assuredly does). It's still a pretty common problem with all kinds of libraries. http://www.serpentine.com/blog/2010/09/04/dealing-with-fragile-c-libraries-e-g-mysql-from-haskell/ Is there anything that we could do in GHC to improve the situation? I suppose we could have a dedicated OS thread who's job it was to sit around and run the signal handler every Nth of a second. Cheers, Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Odd behavior of ncurses with -threaded
On Fri, Nov 12, 2010 at 8:07 AM, Simon Marlow marlo...@gmail.com wrote: Is there anything that we could do in GHC to improve the situation? I suppose we could have a dedicated OS thread who's job it was to sit around and run the signal handler every Nth of a second. Maybe that would work, or masking out RTS signals before calling potentially blocking foreign code (which is all my hack does). Another option would be to include my hack in the Foreign or GHC.* hierarchy somewhere in base. It's clear that a large number of C programmers know nothing about restarting system calls, and authors writing FFI code typically can't do anything about that except make sure those system calls don't get interrupted in the first place. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Odd behavior of ncurses with -threaded
Quoth Simon Marlow marlo...@gmail.com, ... Is there anything that we could do in GHC to improve the situation? I suppose we could have a dedicated OS thread who's job it was to sit around and run the signal handler every Nth of a second. Since the -threaded RTS automatically spawns a couple of extra OS threads anyway, what's one more? Quoth Brian Sullivan b...@serpentine.com, or masking out RTS signals before calling potentially blocking foreign code (which is all my hack does) And unmasking on re-entry via callback, I suppose. It's clear that a large number of C programmers know nothing about restarting system calls, and authors writing FFI code typically can't do anything about that except make sure those system calls don't get interrupted in the first place. Note that one of the reported victims was cabal, where I think it was a getContents that aborted with EINTR, on OpenSolaris. I have no idea what was going on there. Nor do I have any idea why my platform libraries are vulnerable to this signal - maybe it's just the usual system call, but I'm not on UNIX. In the present case, ncurses is probably as old as some of the parties to this discussion, and you'd have to wonder if after all this time it doesn't restart its select() on EINTR, if it isn't because that's actually how they want it to work! I'm not going to defend that proposition, but you're right, very low odds that the external world will be fixed to support timer signals. The SIGVTALRM fix solves the problem of an application that uses SIGALRM in its own timer. Donn Cave, d...@avvanta.com ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Signal handler scheduling on single-threaded RTS
Relatedly, it seems that it takes a nontrivial amount of time for the multithreaded RTS to realize that a thread has emitted a signal. I wonder if there's a more direct way an FFI call can say when I get back to Haskell, immediately start propagating an exception. Edward ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Odd behavior of ncurses with -threaded
Hello,
the following program should wait 3 seconds for user input before. If
now user input occurs within that time, it just prints -1.
{-# LANGUAGE ForeignFunctionInterface #-}
module Main where
import Foreign
import Foreign.C.String
import Foreign.C.Types
import Foreign.C.Error
foreign import ccall unsafe initscr :: IO (Ptr ())
foreign import ccall unsafe endwin :: IO CInt
foreign import ccall unsafe getch :: IO CInt
foreign import ccall unsafe timeout :: CInt - IO ()
main = do
initscr
timeout 3000
c - getch
endwin
print c
This works just fine if I do not use the threaded RTS, say:
ghc --make -lcurses Main.hs
However, with
ghc --make -threaded -lcurses Main.hs
it prints -1 immediately without awaiting the 3 seconds.
Is that considered a bug? Should I open a ticket?
ghc: 6.12.1
linux: 2.6.32
ncurses: 5.7
Cheers,
Simon
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Odd behavior of ncurses with -threaded
Quoth Simon Hengel simon.hen...@wiktory.org, ... This works just fine if I do not use the threaded RTS, say: ghc --make -lcurses Main.hs However, with ghc --make -threaded -lcurses Main.hs I bet, if you switch off the barrage of thread scheduling SIGALRMs, +RTS -V0 -RTS , it will work like it's supposed to. A very casual scrutiny of an ncurses source I have at hand shows no EINTR handling on select() in lib_getch.c. That could be the problem, or something like it - select() is interrupted by GHC's SIGALRM, aborting the timeout. Or they could both be using SIGALRM, and GHC's signal is mistaken for the application library's, but I don't see any sign of that and select() is a more obvious way to do the timeout anyway. it prints -1 immediately without awaiting the 3 seconds. Is that considered a bug? Should I open a ticket? ghc: 6.12.1 linux: 2.6.32 ncurses: 5.7 Someone probably should. It's tempting to conclude that the bug is in ncurses, and perhaps it is, and maybe there's nothing to be done about it anyway, but a language runtime that's spewing SIGALRMs is going to crash into this kind of thing a lot. I could comment a couple of other cases to the ticket that I've seen here or on Haskell-cafe. Donn Cave, d...@avvanta.com ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Odd behavior of ncurses with -threaded
ghc --make -threaded -lcurses Main.hs I bet, if you switch off the barrage of thread scheduling SIGALRMs, +RTS -V0 -RTS , it will work like it's supposed to. That helped, thanks! Cheers, Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Odd behavior of ncurses with -threaded
Excerpts from Donn Cave's message of Thu Nov 11 17:07:20 -0500 2010: ghc: 6.12.1 linux: 2.6.32 ncurses: 5.7 Someone probably should. It's tempting to conclude that the bug is in ncurses, and perhaps it is, and maybe there's nothing to be done about it anyway, but a language runtime that's spewing SIGALRMs is going to crash into this kind of thing a lot. I could comment a couple of other cases to the ticket that I've seen here or on Haskell-cafe. I was under the impression we fixed this: http://hackage.haskell.org/trac/ghc/ticket/850 That is, we should be using SIGVTALRM, not SIGALRM, these days, except under certain conditions when your operating system doesn't support the proper timer (which Linux most assuredly does). Edward ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Odd behavior of ncurses with -threaded
On Thu, Nov 11, 2010 at 2:32 PM, Edward Z. Yang ezy...@mit.edu wrote: I was under the impression we fixed this: http://hackage.haskell.org/trac/ghc/ticket/850 That is, we should be using SIGVTALRM, not SIGALRM, these days, except under certain conditions when your operating system doesn't support the proper timer (which Linux most assuredly does). It's still a pretty common problem with all kinds of libraries. http://www.serpentine.com/blog/2010/09/04/dealing-with-fragile-c-libraries-e-g-mysql-from-haskell/ ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Odd behavior of ncurses with -threaded
Quoth Simon Hengel simon.hen...@wiktory.org, ghc --make -threaded -lcurses Main.hs I bet, if you switch off the barrage of thread scheduling SIGALRMs, +RTS -V0 -RTS , it will work like it's supposed to. That helped, thanks! Great, but, beware - I am not fully informed on what it does, beyond the SIGALRM difference. I run my own application this way without apparent serious harm, but it could be failing to reclaim memory for example, due to missed garbage collections. Donn Cave, d...@avvanta.com ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Signal handler scheduling on single-threaded RTS
I've been poking the bad behavior Brian described here: http://blog.ezyang.com/2010/08/interrupting-ghc/comment-page-1/#comment-1334 and in the process noticed something kind of interesting about thread scheduling in non-multithreaded mode (i.e. without -threaded). When the single-threaded RTS receives a signal, it writes it to pending_handler_buf, and hopes that eventually startSignalHandlers creates the threads to handle the signal. This doesn't happen instantaneously, which is /really/ obvious if you're looping on an FFI call (like a program might use readline). Here's an example (with some extra debug statements from me): installing Haskell signal handler cap 0: thread 1 stopped (suspended while making a foreign call) ^Cstoring pending signal cap 0: running thread 1 (ThreadRunGHC) cap 0: thread 1 stopped (suspended while making a foreign call) cap 0: running thread 1 (ThreadRunGHC) Just cap 0: thread 1 stopped (suspended while making a foreign call) cap 0: running thread 1 (ThreadRunGHC) cap 0: thread 1 stopped (yielding) cap 0: thread 1 appended to run queue starting signal handlers scheduling a thread to handle signal (signo=2) cap 0: created thread 2 cap 0: thread 2 appended to run queue cap 0: running thread 1 (ThreadRunGHC) cap 0: thread 1 stopped (suspended while making a foreign call) cap 0: running thread 1 (ThreadRunGHC) As you can see, the signal is stored immediately, but thread 1 gets another crack at running the FFI call before it yields and we start signal handlers. Then, it turns out, thread 1 /never/ yields to anyone else, unless I add this following patch: hunk ./rts/posix/Signals.c 432 base_GHCziConcziSignal_runHandlers_closure, rts_mkPtr(cap, info)), rts_mkInt(cap, info-si_signo; +contextSwitchCapability(MainCapability); } unblockUserSignals(); In which case the program finally realizes that there's a signal and handles it about seven ENTER presses later. I wonder if we should make it so that contextSwitchCapability(..) works more instantly; possibly by checking for it before we start a safe FFI call and yielding before we go into the FFI. Cheers, Edward P.S. -threaded execution is broken in a different way: the ^C doesn't get handled until the FFI call returns to Haskell. But that's another issue entirely, and one in which readline is partially to blame. :-) ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHC-HEAD 19.Aug.2010, llvm, threaded [Memory Exhaustion]
On 20/08/2010 20:13, Christian Höner zu Siederdissen wrote: Hi, using: http://www.haskell.org/ghc/dist/current/dist/ghc-6.13.20100819-x86_64-unknown-linux.tar.bz2 parallel-3.1.0.0 and the most-common test program ... ever: module Main where import Control.Parallel.Strategies fib :: Int - Int fib n | n 1 = error n 1 | n == 1= 1 | n == 2= 1 | otherwise = fib (n-1) + fib(n-2) fibs = parMap rdeepseq fib $ [1..100] main = do mapM_ (putStrLn . show) $ zip [1..] fibs ghc -fllvm -threaded -rtsopts -O2 Prog.hs ./Prog -- runs slowly through 1..100 [OK] ./Prog +RTS -N2 -RTS -- requests all available memory [NOT OK] ghc -fllvm -threaded -rtsopts Prog.hs ./Prog +RTS -N2 -RTS -- slowly but [OK] Can anybody confirm this? Yes, and many thanks for reporting this. I was about to reply and say that I couldn't reproduce it, but then I noticed that it only happened sometimes and more often with larger -N values. I tracked it down to a bug where the RTS was looping allocating some objects when it should have been blocking the current thread. It was a simple missing test in some code that handles blocking on black hole objects. I'm testing the fix now. Thanks again for the report! Cheers, Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
GHC-HEAD 19.Aug.2010, llvm, threaded [Memory Exhaustion]
Hi, using: http://www.haskell.org/ghc/dist/current/dist/ghc-6.13.20100819-x86_64-unknown-linux.tar.bz2 parallel-3.1.0.0 and the most-common test program ... ever: module Main where import Control.Parallel.Strategies fib :: Int - Int fib n | n 1 = error n 1 | n == 1= 1 | n == 2= 1 | otherwise = fib (n-1) + fib(n-2) fibs = parMap rdeepseq fib $ [1..100] main = do mapM_ (putStrLn . show) $ zip [1..] fibs ghc -fllvm -threaded -rtsopts -O2 Prog.hs ./Prog -- runs slowly through 1..100 [OK] ./Prog +RTS -N2 -RTS -- requests all available memory [NOT OK] ghc -fllvm -threaded -rtsopts Prog.hs ./Prog +RTS -N2 -RTS -- slowly but [OK] Can anybody confirm this? Gruss, Christian pgpfof6FwbZjY.pgp Description: PGP signature ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: native threads vs. -threaded
On 13/03/2010 22:54, Donn Cave wrote: Quoth Simon Marlowmarlo...@gmail.com, ... So it was surprising when this turned out to be incompatible with the -threaded link option. With that option, I get one callback from a non-main thread, and then that native thread will die, shortly after return from the callback. You'll need to elaborate a little. When you say you get one callback from a non-main thread, are you saying that the external C++ code makes a call to a Haskell function? Yes. Was it Haskell that called C++ in the first place? Yes. What do you mean by a non-main thread? Why is the native thread dieing? By main thread I mean the original thread spawned by the process creation; the thread spawned by the foreign library window code is a non-main thread. I wish I knew why it dies! Without -threaded, I do get tracebacks from the various and sundry stack corruptions and whatever eventually occurs, but with -threaded, death is quick and silent. And, as far as I can tell, it happens in the foreign library code, not while executing a callback. The same type of callback works fine in the main thread (this API uses the same dispatch loop for the application itself, but it just doesn't spawn a new thread in that case.) It is expected that you'll get problems without -threaded, because -threaded is needed to handle callbacks from different OS threads. Are you using threads in your Haskell code at all? Do you know how bound threads work in GHC? (I'm only asking because if you're already familiar with this stuff I don't need to explain it :-). I suggest the next thing to do is to find out why the thread is dieing. You said a UI window gets its own thread - who creates that thread? If the app has more than one window, does each window get a different thread? Yes, each window runs its own thread. If it helps to have names, the BWindow::Show function spawns the thread, and from there its event loop calls virtual functions in the BWindow and BView classes that the application may override. That's where control goes back to the Haskell application, via foreign wrapper functions. But of course all that is perhaps unnecessary elaboration. The key points are, threads of foreign origin, with callbacks to Haskell foreign wrapper functions. Does the wrapper rts_lock() account for everything, or do threads need some initial setup I need to account for? Nope, as long as the RTS is initialised properly via hs_init() you should be able to make callbacks from any OS thread. Cheers, Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: native threads vs. -threaded
Quoth Simon Marlow marlo...@gmail.com, ... Does the wrapper rts_lock() account for everything, or do threads need some initial setup I need to account for? Nope, as long as the RTS is initialised properly via hs_init() you should be able to make callbacks from any OS thread. Thanks - I'm sorry to hear I'm doing everything right! Donn Cave, d...@avvanta.com ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: native threads vs. -threaded
On 12/03/10 16:38, Donn Cave wrote: I have been working on a Haskell interface to the platform API for Haiku (was BeOS.) It's C++, but the interesting thing at the moment is the use of threads - a UI window gets its own thread, and whatever Haskell code will be executed by callbacks from that thread. So it was surprising when this turned out to be incompatible with the -threaded link option. With that option, I get one callback from a non-main thread, and then that native thread will die, shortly after return from the callback. You'll need to elaborate a little. When you say you get one callback from a non-main thread, are you saying that the external C++ code makes a call to a Haskell function? Was it Haskell that called C++ in the first place? What do you mean by a non-main thread? Why is the native thread dieing? You said a UI window gets its own thread - who creates that thread? If the app has more than one window, does each window get a different thread? Cheers, Simon Results without -threaded are not really so good either (the application may run and work for a while, but inevitably fail with various errors that I suppose might be expected), so ... what do my threads need, to make -threaded work? The callbacks are `foreign wrapper' functions, which means rts_lock() is already getting called. It looks to me like that should work the same as if my thread had been invoked via forkOS, true? Is there anything else that I missed, that needs to be done to set the thread up for GHC? (I had been thinking this would not be a unique situation, rather there would be several other GUI toolkits out there that use threads in this obvious way, but after a brief review of the ones I usually hear about, not so sure. If there's another library that uses OS threads this way, with Haskell bindings already, that might be something I could steal a clue from.) ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: native threads vs. -threaded
Quoth Simon Marlow marlo...@gmail.com, ... So it was surprising when this turned out to be incompatible with the -threaded link option. With that option, I get one callback from a non-main thread, and then that native thread will die, shortly after return from the callback. You'll need to elaborate a little. When you say you get one callback from a non-main thread, are you saying that the external C++ code makes a call to a Haskell function? Yes. Was it Haskell that called C++ in the first place? Yes. What do you mean by a non-main thread? Why is the native thread dieing? By main thread I mean the original thread spawned by the process creation; the thread spawned by the foreign library window code is a non-main thread. I wish I knew why it dies! Without -threaded, I do get tracebacks from the various and sundry stack corruptions and whatever eventually occurs, but with -threaded, death is quick and silent. And, as far as I can tell, it happens in the foreign library code, not while executing a callback. The same type of callback works fine in the main thread (this API uses the same dispatch loop for the application itself, but it just doesn't spawn a new thread in that case.) You said a UI window gets its own thread - who creates that thread? If the app has more than one window, does each window get a different thread? Yes, each window runs its own thread. If it helps to have names, the BWindow::Show function spawns the thread, and from there its event loop calls virtual functions in the BWindow and BView classes that the application may override. That's where control goes back to the Haskell application, via foreign wrapper functions. But of course all that is perhaps unnecessary elaboration. The key points are, threads of foreign origin, with callbacks to Haskell foreign wrapper functions. Does the wrapper rts_lock() account for everything, or do threads need some initial setup I need to account for? Thanks! Donn Cave, d...@avvanta.com ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
native threads vs. -threaded
I have been working on a Haskell interface to the platform API for Haiku (was BeOS.) It's C++, but the interesting thing at the moment is the use of threads - a UI window gets its own thread, and whatever Haskell code will be executed by callbacks from that thread. So it was surprising when this turned out to be incompatible with the -threaded link option. With that option, I get one callback from a non-main thread, and then that native thread will die, shortly after return from the callback. Results without -threaded are not really so good either (the application may run and work for a while, but inevitably fail with various errors that I suppose might be expected), so ... what do my threads need, to make -threaded work? The callbacks are `foreign wrapper' functions, which means rts_lock() is already getting called. It looks to me like that should work the same as if my thread had been invoked via forkOS, true? Is there anything else that I missed, that needs to be done to set the thread up for GHC? (I had been thinking this would not be a unique situation, rather there would be several other GUI toolkits out there that use threads in this obvious way, but after a brief review of the ones I usually hear about, not so sure. If there's another library that uses OS threads this way, with Haskell bindings already, that might be something I could steal a clue from.) thanks! Donn Cave, d...@avvanta.com ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: openFd under -threaded gets interrupted
On 18/12/2009 17:40, Mitar wrote:
Hi!
I have written about this to Haskell cafe and they advised me to write it here.
I have a problem that I cannot open /dev/rfcomm0 device if I compile
my program with -threaded option. Like:
fd- openFd /dev/rfcomm0 ReadWrite Nothing OpenFileFlags { append =
False, noctty = True, exclusive = False, nonBlock = True, trunc =
False }
If I compile my program with -threaded option I always get such error:
interrupted (Interrupted system call)
But without -threaded it works flawlessly. I am using Linux 2.6.30
amd64, GHC 6.10.4. It was the same with 6.8. And I have tested it also
on 6.12.1.
It's a bug - openFd should be checking for EINTR. I'll fix it.
Cheers,
Simon
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
openFd under -threaded gets interrupted
Hi!
I have written about this to Haskell cafe and they advised me to write it here.
I have a problem that I cannot open /dev/rfcomm0 device if I compile
my program with -threaded option. Like:
fd - openFd /dev/rfcomm0 ReadWrite Nothing OpenFileFlags { append =
False, noctty = True, exclusive = False, nonBlock = True, trunc =
False }
If I compile my program with -threaded option I always get such error:
interrupted (Interrupted system call)
But without -threaded it works flawlessly. I am using Linux 2.6.30
amd64, GHC 6.10.4. It was the same with 6.8. And I have tested it also
on 6.12.1.
After some testing I have discovered that the problem is only with
/dev/rfcomm0 as a device, that is with Bluetooth serial connection.
The problem is that rfcomm Linux kernel code contains:
if (signal_pending(current)) {
err = -EINTR;
break;
}
So if during open call some signal comes it returns EINTR. As it has
to open a connection to a Bluetooth device opening a /dev/rfcomm0 file
requires some time and during that time obviously there is some signal
sent by GHC with -threaded option which is not sent without it.
So please tell me what is the difference between open with and without
-threaded option in GHC as I would like to make a simple C test case.
I am not really sure if this is a feature or a bug in Linux Bluetooth
kernel implementation. But in combination with threaded GHC it makes
not working.
Also is there any workaround possible in Haskell/GHC? For example
making time while openFd is in progress without interrupts?
I have found very similar bug reported here:
https://bugzilla.redhat.com/show_bug.cgi?id=161314
but code from the patch does not seem to be included in official
kernel source code (but it is also a long time ago so many things have
probably changed). But the workaround mentioned there is working also
here. If I open /dev/rfcomm0 with some other program (so that
Bluetooth connection is made) before I run Haskell program then it
works in both cases, with or without -threaded option. Of course this
is not really useful workaround in my case, I would like to make a
stand-alone Haskell program. So if it is similar to that bug then
maybe it is a bug in Linux kernel.
So please help me solve this problem.
Mitar
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: openFd under -threaded gets interrupted
Quoth Mitar mmi...@gmail.com, Also is there any workaround possible in Haskell/GHC? For example making time while openFd is in progress without interrupts? You might try something like this: import System.Posix.Signals ... setSignalMask fullSignalSet fd - openFd ... setSignalMask emptySignalSet I'm not in a position to try it in exactly the same situation, but I see that when I run with all signals blocked as above, after a while I have a SIGALRM pending (with -threaded or not), so I reckon that might be the signal used by the runtime thread manager. If it works, I would recommend blocking only that signal during the openFd, so for example you'll be able to abort normally with SIGINT if the device is stuck. Donn ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: openFd under -threaded gets interrupted
Hi! On Fri, Dec 18, 2009 at 7:15 PM, Donn Cave d...@avvanta.com wrote: setSignalMask fullSignalSet fd - openFd ... setSignalMask emptySignalSet Thanks! This did it. At the end it is enough to block just virtualTimerExpired signal and it works. Probably it is something RTS is using internally? Mitar ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ghci and ghc -threaded [slowdown]
It seems that the problem you have is that moving to the multithreaded runtime imposes an overhead on the communication between your two threads, when run on a *single CPU*. But performance on a single CPU is not what you're interested in - you said you wanted parallelism, and for that you need multiple CPUs, and hence multiple OS threads. Well, I'm interested in getting an absolute speedup. If the threaded performance on a single core is slightly slower than the non-threaded performance on a single core, that would be OK provided that the threaded performance using multiple cores was better than the same non-threaded baseline. However, it doesn't seem to work like that at all. In fact, threaded on multiple cores was _even_slower_ than threaded on a single core! Here are some figures: ghc-6.8.2 -O2 apply MVarstrict thr-N2 thr-N1 silicium 7.307.95 7.23 15.25 14.71 neghip4.254.43 4.186.67 6.48 hydrogen 11.75 10.8210.99 13.45 12.96 lobster 55.851.5 57.676.6 74.5 The first three columns are variations of the program using slightly different communications mechanisms, including threads/MVars with the non-threaded RTS. The final two columns are for the MVar mechanism with threaded RTS and either 1 or 2 cores. -N2 is slowest. I suspect the underlying problem in your program is that the communication is synchronous. To get good parallelism you'll need to use asynchronous communication, otherwise even on multiple CPUs you'll see little parallelism. I tried using Chans instead of MVars, to provide for different speeds of reader/writer, but the timings were even worse. (Add another 15-100%.) When I have time to look at this again (probably in the New Year), I will try some other strategies for communication that vary in their synchronous/asynchronous chunk size, to see if I can pin things down more closely. Regards, Malcolm ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ghci and ghc -threaded [slowdown]
Malcolm Wallace wrote: It seems that the problem you have is that moving to the multithreaded runtime imposes an overhead on the communication between your two threads, when run on a *single CPU*. But performance on a single CPU is not what you're interested in - you said you wanted parallelism, and for that you need multiple CPUs, and hence multiple OS threads. Well, I'm interested in getting an absolute speedup. If the threaded performance on a single core is slightly slower than the non-threaded performance on a single core, that would be OK provided that the threaded performance using multiple cores was better than the same non-threaded baseline. However, it doesn't seem to work like that at all. In fact, threaded on multiple cores was _even_slower_ than threaded on a single core! Entirely possible - unless there's any actual parallelism, running on multiple cores will probably slow things down due to thread migration. Here are some figures: ghc-6.8.2 -O2 apply MVarstrict thr-N2 thr-N1 silicium 7.307.95 7.23 15.25 14.71 neghip4.254.43 4.186.67 6.48 hydrogen 11.75 10.8210.99 13.45 12.96 lobster 55.851.5 57.676.6 74.5 The first three columns are variations of the program using slightly different communications mechanisms, including threads/MVars with the non-threaded RTS. The final two columns are for the MVar mechanism with threaded RTS and either 1 or 2 cores. -N2 is slowest. So you're not getting any parallelism at all, for some reason your program is sequentialised. There could be any number of reasons for this. I suspect the underlying problem in your program is that the communication is synchronous. To get good parallelism you'll need to use asynchronous communication, otherwise even on multiple CPUs you'll see little parallelism. I tried using Chans instead of MVars, to provide for different speeds of reader/writer, but the timings were even worse. (Add another 15-100%.) That would seem to indicate that your program is doing a lot of communication - I'd look at trying to reduce that, by increasing task size or whatever. However, the amount of communication is obviously not the only issue, there also seems to be some kind of dependency that sequentialises the program. Are you sure that you're not accidentally communicating thunks, and hence doing all the computation in one of the threads? That's a common pitfall that has caught me more than once. Do you know roughly the amount of parallelism you expect - i.e. the amount of work done by each thread? When I have time to look at this again (probably in the New Year), I will try some other strategies for communication that vary in their synchronous/asynchronous chunk size, to see if I can pin things down more closely. That would be good. At some point we hope to provide some kind of visualisation to let you see where the parallel performance bottlenecks in your program are; there are various ongoing efforts but nothing useable as yet. Cheers, Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ghci and ghc -threaded [slowdown]
Malcolm Wallace wrote: Simon Marlow marlo...@gmail.com wrote: Malcolm Wallace wrote: For the only application I tried, using the threaded RTS imposes a 100% performance penalty - i.e. computation time doubles, compared to the non-threaded RTS. This was with ghc-6.8.2, and maybe the overhead has improved since then? This is a guess, but I wonder if this program is concurrent, and does a lot of communication between the main thread and other threads? Exactly so - it hits the worst case behaviour. This was a naive attempt to parallelise an algorithm by shifting some work onto a spare processor. Unfortunately, there is a lot of communication to the main thread, because the work that was shifted elsewhere computes a large data structure in chunks, and passes those chunks back. The main thread then runs OpenGL calls using this data -- and I believe OpenGL calls must run in a bound thread. This all suggests that one consequence of ghc's RTS implementation choices is that it will never be cheap to compute visualization data in parallel with rendering it in OpenGL. That would be a shame. This was exactly the parallelism I was hoping for. I'm not sure how we could do any better here. To get parallelism you need to run the OpenGL thread and the worker thread on separate OS threads, which we do. So what aspect of the RTS design is preventing you from getting the parallelism you want? It seems that the problem you have is that moving to the multithreaded runtime imposes an overhead on the communication between your two threads, when run on a *single CPU*. But performance on a single CPU is not what you're interested in - you said you wanted parallelism, and for that you need multiple CPUs, and hence multiple OS threads. I suspect the underlying problem in your program is that the communication is synchronous. To get good parallelism you'll need to use asynchronous communication, otherwise even on multiple CPUs you'll see little parallelism. If you still do asynchronous communication and yet don't get good parallelism, then we should look into what's causing that. Cheers, Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ghci and ghc -threaded [slowdown]
Simon Marlow marlo...@gmail.com wrote: Malcolm Wallace wrote: For the only application I tried, using the threaded RTS imposes a 100% performance penalty - i.e. computation time doubles, compared to the non-threaded RTS. This was with ghc-6.8.2, and maybe the overhead has improved since then? This is a guess, but I wonder if this program is concurrent, and does a lot of communication between the main thread and other threads? Exactly so - it hits the worst case behaviour. This was a naive attempt to parallelise an algorithm by shifting some work onto a spare processor. Unfortunately, there is a lot of communication to the main thread, because the work that was shifted elsewhere computes a large data structure in chunks, and passes those chunks back. The main thread then runs OpenGL calls using this data -- and I believe OpenGL calls must run in a bound thread. This all suggests that one consequence of ghc's RTS implementation choices is that it will never be cheap to compute visualization data in parallel with rendering it in OpenGL. That would be a shame. This was exactly the parallelism I was hoping for. Regards, Malcolm ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ghci and ghc -threaded broken with pipes forking
Malcolm Wallace wrote: Had you deprecated the non-threaded RTS, we would probably have no problems described in ticket #2848 :-/ I think you'll have to deprecate it anyway, because it will be more and more difficult to maintain two versions of code, we may conduct small survey on amount of usage of old RTS (i mean ask this in haskell-cafe) For the only application I tried, using the threaded RTS imposes a 100% performance penalty - i.e. computation time doubles, compared to the non-threaded RTS. This was with ghc-6.8.2, and maybe the overhead has improved since then? This is a guess, but I wonder if this program is concurrent, and does a lot of communication between the main thread and other threads? The main thread is a bound thread, which means that communication between the main thread and any other thread is much more expensive than communication between unbound threads, because it involves full OS-level context switches. In a concurrent program, don't use the main thread to do any real work, do a forkIO and wait for the child to complete. Certainly a 2x performance overhead for the threaded RTS is not something we normally see. There will be an overhead for MVars and STM, but even then I'd consider 2x to be deeply suspicious. For most programs, the overhead should be close to zero. Cheers, Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ghci and ghc -threaded broken with pipes forking
Brian B wrote: Hi Bulat, My contribution to the survey: I've used forkProcess to daemonize a ghc program inside the haskell fuse bindings: http://hackage.haskell.org/cgi-bin/hackage-scripts/package/HFuse http://code.haskell.org/hfuse/System/Fuse.hsc If removing the non-threaded RTS would break forkProcess entirely, these bindings would have to do something different. The issue: users of the FUSE C api will get daemonized using daemon(2); it'd be nice if GHC fuse programs could behave similarly. forkProcess should work with the threaded RTS, as long as you don't enable multiple cores with +RTS -Nn. However, forking is a pretty tricky operation in a multi-threaded environment, and that's where the difficulty comes from. Cheers, Simon Thanks, Brian Bloniarz Hello Tomasz, Saturday, December 6, 2008, 10:52:39 PM, you wrote: Had you deprecated the non-threaded RTS, we would probably have no problems described in ticket #2848 :-/ I think you'll have to deprecate it anyway, because it will be more and more difficult to maintain two versions of code, especially if one of them will be much less used and tested. we may conduct small survey on amount of usage of old RTS (i mean ask this in haskell-cafe) -- Best regards, Bulat mailto:[EMAIL PROTECTED] ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users Connect to the next generation of MSN Messenger Get it now! http://imagine-msn.com/messenger/launch80/default.aspx?locale=en-ussource=wlmailtagline ___ 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: ghci and ghc -threaded broken with pipes forking
John Goerzen wrote: Brian B wrote: Hi Bulat, My contribution to the survey: I've used forkProcess to daemonize a ghc program inside the haskell fuse bindings: http://hackage.haskell.org/cgi-bin/hackage-scripts/package/HFuse http://code.haskell.org/hfuse/System/Fuse.hsc If removing the non-threaded RTS would break forkProcess entirely, these bindings would have to do something different. The issue: users of the FUSE C api will get daemonized using daemon(2); it'd be nice if GHC fuse programs could behave similarly. I also use forkProcess extensively: in HSH, for instance, which is used by hpodder, twidge, and a host of other tools. Removing the ability to use forkProcess removes the ability to write a Unix shell in Haskell, or to do anything shell-like, or anything even mildly advanced involving piping, file descriptors, and the like. I would see it as a significant regression. Have you tried those apps with the threaded RTS? I'd be interested to know whether they work as expected. I'm not suggesting we remove the non-threaded RTS, however perhaps there's an argument for making -threaded the default. After all, that's what you get with GHCi by default right now. Maintaining both versions of the RTS is certainly a burden, but I think it's one we have to carry, since there are still reasons to want both. The System.Process calls, last I checked (in 6.8.x) were both too buggy to use for complex tasks, and too inadequate for some (though the adequacy has been improving.) If there's bugginess we need to get it fixed - please report those bugs! Cheers, Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ghci and ghc -threaded broken with pipes forking
Simon Marlow wrote: John Goerzen wrote: Brian B wrote: Hi Bulat, My contribution to the survey: I've used forkProcess to daemonize a ghc program inside the haskell fuse bindings: http://hackage.haskell.org/cgi-bin/hackage-scripts/package/HFuse http://code.haskell.org/hfuse/System/Fuse.hsc If removing the non-threaded RTS would break forkProcess entirely, these bindings would have to do something different. The issue: users of the FUSE C api will get daemonized using daemon(2); it'd be nice if GHC fuse programs could behave similarly. I also use forkProcess extensively: in HSH, for instance, which is used by hpodder, twidge, and a host of other tools. Removing the ability to use forkProcess removes the ability to write a Unix shell in Haskell, or to do anything shell-like, or anything even mildly advanced involving piping, file descriptors, and the like. I would see it as a significant regression. Have you tried those apps with the threaded RTS? I'd be interested to know whether they work as expected. I have, and it didn't work well. But it's been awhile, and I can't tell you anymore what version of GHC or what exactly the problem was. I was most certainly 6.8 or older. Once 6.10 hits Debian, I could test again there. But see below... I'm not suggesting we remove the non-threaded RTS, however perhaps there's an argument for making -threaded the default. After all, that's what you get with GHCi by default right now. That's probably an OK solution. I would also add: does the threaded RTS support all platforms? For instance, GHC runs on my Alpha and on AIX, unregisterised. ghci doesn't run there, but GHC does. If you drop the non-threaded RTS, does that mean that GHC doesn't work there at all? The System.Process calls, last I checked (in 6.8.x) were both too buggy to use for complex tasks, and too inadequate for some (though the adequacy has been improving.) If there's bugginess we need to get it fixed - please report those bugs! Already done: http://hackage.haskell.org/trac/ghc/ticket/1780 (still open since Nov 2007) There was also a thread here regarding problems with the threaded RTS: http://www.mail-archive.com/glasgow-haskell-users@haskell.org/msg11573.html Not sure if that has been fixed, or was an error on my part, but see your reply at: http://www.mail-archive.com/glasgow-haskell-users@haskell.org/msg11585.html I admit I haven't had the chance to reread that whole thread, so my apologies if this is a red herring. -- John ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ghci and ghc -threaded broken with pipes forking
Simon Marlow wrote: I would also add: does the threaded RTS support all platforms? For instance, GHC runs on my Alpha and on AIX, unregisterised. ghci doesn't run there, but GHC does. If you drop the non-threaded RTS, does that mean that GHC doesn't work there at all? If those platforms support threads, there's no reason why the threaded RTS shouldn't work there. Also, GHCi should work on all platforms (even unregisterised) these days, including the FFI if there's support in libffi for that platform. That's very good to hear. http://hackage.haskell.org/trac/ghc/ticket/1780 (still open since Nov 2007) That one is closed - fixed in 6.8.3 I think. Oops, my mistake. I'll look into it again. http://www.mail-archive.com/glasgow-haskell-users@haskell.org/msg11585.html I did make a ticket for that: http://hackage.haskell.org/trac/ghc/ticket/1185 #1 way to tell you are a Haskell geek: * milestone changed from _|_ to 6.10.2. grin Thanks, Simon. -- John ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Re[2]: ghci and ghc -threaded broken with pipes forking
Had you deprecated the non-threaded RTS, we would probably have no problems described in ticket #2848 :-/ I think you'll have to deprecate it anyway, because it will be more and more difficult to maintain two versions of code, we may conduct small survey on amount of usage of old RTS (i mean ask this in haskell-cafe) For the only application I tried, using the threaded RTS imposes a 100% performance penalty - i.e. computation time doubles, compared to the non-threaded RTS. This was with ghc-6.8.2, and maybe the overhead has improved since then? Regards, Malcolm ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: Re[2]: ghci and ghc -threaded broken with pipes forking
Hi Bulat, My contribution to the survey: I've used forkProcess to daemonize a ghc program inside the haskell fuse bindings: http://hackage.haskell.org/cgi-bin/hackage-scripts/package/HFuse http://code.haskell.org/hfuse/System/Fuse.hsc If removing the non-threaded RTS would break forkProcess entirely, these bindings would have to do something different. The issue: users of the FUSE C api will get daemonized using daemon(2); it'd be nice if GHC fuse programs could behave similarly. Thanks, Brian Bloniarz Hello Tomasz, Saturday, December 6, 2008, 10:52:39 PM, you wrote: Had you deprecated the non-threaded RTS, we would probably have no problems described in ticket #2848 :-/ I think you'll have to deprecate it anyway, because it will be more and more difficult to maintain two versions of code, especially if one of them will be much less used and tested. we may conduct small survey on amount of usage of old RTS (i mean ask this in haskell-cafe) -- Best regards, Bulatmailto:[EMAIL PROTECTED] ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users _ Connect to the next generation of MSN Messenger http://imagine-msn.com/messenger/launch80/default.aspx?locale=en-ussource=wlmailtagline___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re[2]: ghci and ghc -threaded broken with pipes forking
Hello Tomasz, Saturday, December 6, 2008, 10:52:39 PM, you wrote: Had you deprecated the non-threaded RTS, we would probably have no problems described in ticket #2848 :-/ I think you'll have to deprecate it anyway, because it will be more and more difficult to maintain two versions of code, especially if one of them will be much less used and tested. we may conduct small survey on amount of usage of old RTS (i mean ask this in haskell-cafe) -- Best regards, Bulatmailto:[EMAIL PROTECTED] ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ghci and ghc -threaded broken with pipes forking
On Thu, Mar 1, 2007 at 5:21 PM, Simon Marlow [EMAIL PROTECTED] wrote: In fact you should think of the non-threaded RTS as deprecated. It isn't Haskell'-compliant, for one thing (assuming that Haskell' will probably require non-blocking foreign calls). I'm hesitant to actually deprecate it, for a few reasons: the threaded RTS is so much more complicated, it might have some adverse performance impliciations, and there are still people who want to run everything in a single OS thread, for whatever reason. But having multiple variants of the RTS is a maintenance and testing headache. Had you deprecated the non-threaded RTS, we would probably have no problems described in ticket #2848 :-/ I think you'll have to deprecate it anyway, because it will be more and more difficult to maintain two versions of code, especially if one of them will be much less used and tested. Best regards Tomasz ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Problems interrupting IO with -threaded
Yitzchak Gale wrote: Judah Jacobson wrote: I'm writing a program that reads input from the user but should also handle a ctrl-c... It works fine compiled without -threaded, but with -threaded it blocks forever after a ctrl-c. Simon Marlow wrote: Ah, this is a consequence of the change we made to stdin/stdout/stderr so that they no longer use O_NONBLOCK, but with -threaded they use blocking foreign calls instead... I don't see a good workaround... Unix semantics just isn't the right thing when it comes to non-blocking I/O. If only there were non-blocking read()/write() system calls, we'd be fine. I believe you that the Unix semantics may not be very pretty. But all modern high-level programming languages have a getChar that can be interrupted by ^C. Can't we just do what they all do? This is basic, essential functionality that we use every day. In my opinion, Judah should file a bug, and it should be marked high priority. You're right. I've created a ticket: http://hackage.haskell.org/trac/ghc/ticket/2363 Cheers, Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Problems interrupting IO with -threaded
Judah Jacobson wrote: Hi all, I'm writing a program that reads input from the user but should also handle a ctrl-c. My attempt is below; the program forks a thread to read one character of input, and kills that thread upon receiving a sigINT. It works fine compiled without -threaded, but with -threaded it blocks forever after a ctrl-c. I know that in general, foreign calls are not interruptible; but the documentation for Control.Concurrent and System.Timeout suggests that I/O operations are a special case. In particular, the documentation for System.Timeout.timeout says: Standard I/O functions like hGetBuf, hPutBuf, Network.Socket.accept, or hWaitForInput appear to be blocking, but they really don't because the runtime system uses scheduling mechanisms like select(2) to perform asynchronous I/O, so it is possible to interrupt standard socket I/O or file I/O using this combinator. So is the behavior that I'm seeing correct? If so, it seems odd to get better concurrency without the threaded runtime. If not, I can file a bug for this. I used ghc-6.8.2 and HEAD on OS X 10.5 (x86). Ah, this is a consequence of the change we made to stdin/stdout/stderr so that they no longer use O_NONBLOCK, but with -threaded they use blocking foreign calls instead. In your example, getChar is stuck in a blocking foreign call and can't be interrupted. I don't see a good workaround. One way is to add another thread: run the getChar in a subthread and the parent will be able to receive the signal. Or perhaps you could cause the read() that getChar has called to return EINTR, but that might not be enough because the I/O library executes mostly inside Control.Exception.block. Unix semantics just isn't the right thing when it comes to non-blocking I/O. If only there were non-blocking read()/write() system calls, we'd be fine. Cheers, Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Problems interrupting IO with -threaded
On 2008 Jun 11, at 0:43, Simon Marlow wrote: Unix semantics just isn't the right thing when it comes to non- blocking I/O. If only there were non-blocking read()/write() system calls, we'd be fine. Have you considered using aio_read() and company? -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] [EMAIL PROTECTED] system administrator [openafs,heimdal,too many hats] [EMAIL PROTECTED] electrical and computer engineering, carnegie mellon universityKF8NH ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Problems interrupting IO with -threaded
Brandon S. Allbery KF8NH wrote: On 2008 Jun 11, at 0:43, Simon Marlow wrote: Unix semantics just isn't the right thing when it comes to non-blocking I/O. If only there were non-blocking read()/write() system calls, we'd be fine. Have you considered using aio_read() and company? aio is not exactly the right API either. The IO manager would have to call aio_suspend(), and then in order to receive events from the RTS over the special pipe we have set up, the IO manager would have to issue its own aio_read() on this FD. And I'm not sure whether you can use aio_suspend() to wait for network accept(), but I suspect not. There ought to be a single way to wait for various different types of event on Unix. Cheers, Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Problems interrupting IO with -threaded
Judah Jacobson wrote: I'm writing a program that reads input from the user but should also handle a ctrl-c... It works fine compiled without -threaded, but with -threaded it blocks forever after a ctrl-c. Simon Marlow wrote: Ah, this is a consequence of the change we made to stdin/stdout/stderr so that they no longer use O_NONBLOCK, but with -threaded they use blocking foreign calls instead... I don't see a good workaround... Unix semantics just isn't the right thing when it comes to non-blocking I/O. If only there were non-blocking read()/write() system calls, we'd be fine. I believe you that the Unix semantics may not be very pretty. But all modern high-level programming languages have a getChar that can be interrupted by ^C. Can't we just do what they all do? This is basic, essential functionality that we use every day. In my opinion, Judah should file a bug, and it should be marked high priority. Thanks, Yitz ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Problems interrupting IO with -threaded
Hi all, I'm writing a program that reads input from the user but should also handle a ctrl-c. My attempt is below; the program forks a thread to read one character of input, and kills that thread upon receiving a sigINT. It works fine compiled without -threaded, but with -threaded it blocks forever after a ctrl-c. I know that in general, foreign calls are not interruptible; but the documentation for Control.Concurrent and System.Timeout suggests that I/O operations are a special case. In particular, the documentation for System.Timeout.timeout says: Standard I/O functions like hGetBuf, hPutBuf, Network.Socket.accept, or hWaitForInput appear to be blocking, but they really don't because the runtime system uses scheduling mechanisms like select(2) to perform asynchronous I/O, so it is possible to interrupt standard socket I/O or file I/O using this combinator. So is the behavior that I'm seeing correct? If so, it seems odd to get better concurrency without the threaded runtime. If not, I can file a bug for this. I used ghc-6.8.2 and HEAD on OS X 10.5 (x86). Thanks, -Judah -- module Main where import Control.Monad import System.Posix.Signals import Control.Concurrent import Control.Concurrent.MVar import System.IO main = do hSetBuffering stdin NoBuffering hSetEcho stdin False mv - newEmptyMVar let handler = putMVar mv Nothing installHandler sigINT (CatchOnce handler) Nothing tid - forkIO (myGetChar mv) c - takeMVar mv when (c==Nothing) $ do killThread tid putStrLn (Result: ++ show c) myGetChar mv = do c - getChar putMVar mv (Just c) ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Some problems writing a threaded program
John Vogel wrote: Thankyou both Don Stewart and Simon Marlow for your responses. By adding yield and threadDelay in certain spots I have at least prevented some of the threads from being starved of CPU time. The only issue now is that terminateProcess doesn't always terminate netstat.exe in the cmd.exe so I don't get an exit condition. Windows doesn't have the same concept of process groups that Unix has, so killing a shell doesn't necessarily kill its children. Have a look at the hoops Ian had to jump through to get this working for our timeout program in the GHC testsuite: http://darcs.haskell.org/testsuite/timeout/ Cheers, Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Some problems writing a threaded program
2008/2/11 John Vogel [EMAIL PROTECTED]: The only issue now is that terminateProcess doesn't always terminate netstat.exe in the cmd.exe so I don't get an exit condition. A simple way is to use runInteractiveProcess instead of runInteractiveCommand. The former doesn't start a new cmd.exe but starts netstat.exe directly. There isn't point of using runInteractiveCommand unless you want to execute some shell commands or batch files. Regards, Krasimir ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Some problems writing a threaded program
John Vogel wrote: I am running my program in WinXP with ghc 2.6.8 If you install netstat and change the parameters it should still work in linux. Why does thread # 3 dominate over the over threads int the output? Why does thread # 4 never seem to run? I can't use the sleep function in System.Process.Win32 since it puts all the threads asleep at the same time. Is there a way to put only one thread asleep? That would allow more of a chance for thread #4 to run. I haven't looked in detail at what happens in your program, but there is a matter of style here: you appear to be using busy-waiting and polling a lot. GHC's runtime shouldn't be considered fair in any sense other than the most basic: a thread will get to run eventually, but if it immediately blocks then it loses its timeslice. There's no guarantee that a thread will get a fair share of the CPU. So busy-waiting and polling will often suffer from a lack of fairness in the scheduler. Let me be a little more concrete: you're doing a lot of output to stdout. Now, stdout has a lock on it - only one thread can be holding stdout at any one time. Often, a thread will be preempted while holding the stdout lock, and since the other threads are all waiting to output to stdout too, none of them can make progress, so the original thread gets another timeslice (unfair!). This is why, if you try to write one of those ... concurrency tests using GHC, you'll probably get AA... GHC's scheduler is intentionally simple, because it is designed to cope with workloads that consist of mostly *blocked* threads, and a very few running threads. However, you might get more fairness using a couple of cores and running with +RTS -N2. Perhaps one day we'll have to consider questions of fairness and priority, hopefully in the context of a user-programmable scheduler. But for now, this is the way it is. Cheers, Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Some problems writing a threaded program
Thankyou both Don Stewart and Simon Marlow for your responses. By adding yield and threadDelay in certain spots I have at least prevented some of the threads from being starved of CPU time. The only issue now is that terminateProcess doesn't always terminate netstat.exe in the cmd.exe so I don't get an exit condition. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Some problems writing a threaded program
jpvogel1: I am running my program in WinXP with ghc 2.6.8 If you install netstat and change the parameters it should still work in linux. Why does thread # 3 dominate over the over threads int the output? Why does thread # 4 never seem to run? I can't use the sleep function in System.Process.Win32 since it puts all the threads asleep at the same time. Is there a way to put only one thread asleep? That would allow more of a chance for thread #4 to run. There is 'threadDelay' and 'yield' if you need to either sleep a thread, or explicitly trigger a scheduler event. http://haskell.org/ghc/docs/latest/html/libraries/base/Control-Concurrent.html#4 ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Some problems writing a threaded program
I am running my program in WinXP with ghc 2.6.8 If you install netstat and change the parameters it should still work in linux. Why does thread # 3 dominate over the over threads int the output? Why does thread # 4 never seem to run? I can't use the sleep function in System.Process.Win32 since it puts all the threads asleep at the same time. Is there a way to put only one thread asleep? That would allow more of a chance for thread #4 to run. The simplified program: --- module Main where import Data.IORef import Data.List import System.IO import System.Process import Control.Concurrent import Control.Concurrent.Chan data Connection = Null | Last | Active deriving (Eq) instance Show Connection where show Null = Null show Last = Last show Active = Active instance Read Connection where readsPrec _ s = case take 5 s of UDP - [(Active, )] TCP - [(Active, )] Last - [(Last,)] _ - [(Null,)] -- ptrints one 0 and 1 main = do stop - newIORef False cbuffer - newChan :: IO (Chan Connection) putStr 0 (_,output,_,ph) - runInteractiveCommand netstat -noa 5 sequence $ map forkIO $ [(processConnections ph output cbuffer), (stopNetstat ph stop False), (printChan cbuffer),(checkStop stop )] putStr 1 _ - waitForProcess ph --mapM killThread ts putStrLn \nDone -- thread # 2 processConnections :: ProcessHandle - Handle - (Chan Connection) - IO () processConnections ph hout chan = do h - hReady hout e - getProcessExitCode ph putStr 2 if (not h e /= Nothing) then do writeChan chan Last return () else do if h then do readConnection hout = writeChan chan else do processConnections ph hout chan readConnection :: Handle - IO Connection readConnection hout = do l - hGetLine hout let c = (read l :: Connection) if (c == Null) then do (readConnection hout) else do (return c) -- thread number 3 stopNetstat :: ProcessHandle - (IORef Bool) - Bool - IO () stopNetstat netstat _ True = terminateProcess netstat stopNetstat netstat gref False = putStr 3 yield readIORef gref = stopNetstat netstat gref --thread 4 printChan :: (Chan Connection) - IO () printChan chan = do putStr 4 c - readChan chan printConnection c printChan chan checkStop :: (IORef Bool) - String - IO () checkStop ref s = do if (take 4 s == stop) then do (writeIORef ref True) else do (getChar = (\x - checkStop ref ((tail s) ++ [x]))) printConnection :: Connection - IO () printConnection c = case c of Null - putStr N Last - putStr L _ - putStr A ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: combination not supported: Threaded/Profiling when building NDP library
Hello Ben, On Tue, 18 Sep 2007 18:21:35 +0900, Ben Gaster [EMAIL PROTECTED] wrote: Having read the papers on Nested Data Parallelism in the Haskell I wanted to play around with the de-sugared implementation in the GHC library NDP. I have built GHC from source, on RHE5, and then installed the NDP library from the tar ball. Following the build instructions in the README I got to building the library which resulted in the following error being reported: ghc-6-6.1: combination not supported: Threaded/Profiling This seems to be down to the fact that -prof and -threaded have been specified on a particular build line, although I emit not to be completely sure about this. If you want just testing ndp package, I think you can install with cabal instead of README file way. And you problem come from current rts' implemantion. Current rts' code cause the problem when using -prof and -threaded combination. So GHC's developper team omit this option to avoid problem by that in ghc 6.6.x release phase. http://hackage.haskell.org/trac/ghc/ticket/886 If you want to use their combination, please vote above Ticket #886 by adding your e-mail address to 'cc' field and commebt your problem, instead of just sending e-mail to this mailing-list. Because GHC's team decides task priority by using this field and comment. http://www.haskell.org/pipermail/glasgow-haskell-bugs/2007-July/008873.html Best Regards, -- shelarcy shelarcyhotmail.co.jp http://page.freett.com/shelarcy/ ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: combination not supported: Threaded/Profiling when building NDP library
H Shelarcy, Thanks for your reply. I have removed the -threaded when building the library and now everything builds correctly and the examples are all working. However, I would like to explore porting the library to use a small FFI library which will allow exporting flattened data parallel operations to a vector array processor that I'm working with. With this in mind I wanted to check that as this the library is not concerned with SMP and thus I will not expect the ported version of NDP to call GHC's SMP concurrency primitives, as I believe it does at the moment, then I need not be concerned with this option not being enabled, even at link time? Regards, Ben Benedict R. Gaster S/W Architecture Team Lead ClearSpeed Technology Plc 3110 Great Western Court Hunts Ground Road Stoke Gifford Bristol BS34 8HP Phone: + 44 117 3172016 Fax: + 44 117 3172002 [EMAIL PROTECTED] www.clearspeed.com -Original Message- From: shelarcy [mailto:[EMAIL PROTECTED] Sent: 20 September 2007 10:31 To: Ben Gaster Cc: glasgow-haskell-users@haskell.org Subject: Re: combination not supported: Threaded/Profiling when building NDP library Hello Ben, On Tue, 18 Sep 2007 18:21:35 +0900, Ben Gaster [EMAIL PROTECTED] wrote: Having read the papers on Nested Data Parallelism in the Haskell I wanted to play around with the de-sugared implementation in the GHC library NDP. I have built GHC from source, on RHE5, and then installed the NDP library from the tar ball. Following the build instructions in the README I got to building the library which resulted in the following error being reported: ghc-6-6.1: combination not supported: Threaded/Profiling This seems to be down to the fact that -prof and -threaded have been specified on a particular build line, although I emit not to be completely sure about this. If you want just testing ndp package, I think you can install with cabal instead of README file way. And you problem come from current rts' implemantion. Current rts' code cause the problem when using -prof and -threaded combination. So GHC's developper team omit this option to avoid problem by that in ghc 6.6.x release phase. http://hackage.haskell.org/trac/ghc/ticket/886 If you want to use their combination, please vote above Ticket #886 by adding your e-mail address to 'cc' field and commebt your problem, instead of just sending e-mail to this mailing-list. Because GHC's team decides task priority by using this field and comment. http://www.haskell.org/pipermail/glasgow-haskell-bugs/2007- July/008873.html Best Regards, -- shelarcy shelarcyhotmail.co.jp http://page.freett.com/shelarcy/ -- The contents of this email and any attachments are confidential and may be legally privileged. If you have received this email in error please notify the sender immediately and refrain from copying or disclosing the contents of the email to any third party. ClearSpeed accepts no liability for any viruses which may be transmitted by this email or its attachments. ClearSpeed Technology PLC is a company registered in England under company number 05159262 whose registered office is at 3110 Great Western Court, Hunts Ground Road, Bristol BS34 8HP, UK. ClearSpeed Technology INC is a wholly owned subsidiary of ClearSpeed Technology PLC and is incorporated in the United States of America, with its principle place of business at 3031 Tisch Way, Suite 200, San Jose, CA 95128, US. Additional Company information can be found at the following: http://www.clearspeed.com/aboutus/company/index.html ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
combination not supported: Threaded/Profiling when building NDP library
Hello Having read the papers on Nested Data Parallelism in the Haskell I wanted to play around with the de-sugared implementation in the GHC library NDP. I have built GHC from source, on RHE5, and then installed the NDP library from the tar ball. Following the build instructions in the README I got to building the library which resulted in the following error being reported: ghc-6-6.1: combination not supported: Threaded/Profiling This seems to be down to the fact that -prof and -threaded have been specified on a particular build line, although I emit not to be completely sure about this. Looking through the GHC page on its SMP support it seems to imply that the option -threaded is not needed when building code, rather when linking a parallel program, but it is unclear if this is the case when building a library such as NDP. Having scanned through the GHC source tree it seems that -prof is referenced in numerous places such that it would be a bit of a pain to have to remove these over removing the single reference to -threaded in the ndp.mk file. Thanks for any help that you can provide on this. Many Regards, Ben Benedict R. Gaster S/W Architecture Team Lead ClearSpeed Technology Plc 3110 Great Western Court Hunts Ground Road Stoke Gifford Bristol BS34 8HP -- The contents of this email and any attachments are confidential and may be legally privileged. If you have received this email in error please notify the sender immediately and refrain from copying or disclosing the contents of the email to any third party. ClearSpeed accepts no liability for any viruses which may be transmitted by this email or its attachments. ClearSpeed Technology PLC is a company registered in England under company number 05159262 whose registered office is at 3110 Great Western Court, Hunts Ground Road, Bristol BS34 8HP, UK. ClearSpeed Technology INC is a wholly owned subsidiary of ClearSpeed Technology PLC and is incorporated in the United States of America, with its principle place of business at 3031 Tisch Way, Suite 200, San Jose, CA 95128, US. Additional Company information can be found at the following: http://www.clearspeed.com/aboutus/company/index.html ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ForeignPtr and -threaded
On Mon, Jul 23, 2007 at 11:07:40AM +0900, PHO wrote: same. The documentations of both Foreign.ForeignPtr (*1) and Foreign.Concurrent (*2) say The only guarantee is that the finalizer runs before the program terminates. That's a documentation bug. In the HEAD it says: newForeignPtr :: FinalizerPtr a - Ptr a - IO (ForeignPtr a) -- ^Turns a plain memory reference into a foreign pointer, and -- associates a finaliser with the reference. The finaliser will be executed -- after the last reference to the foreign object is dropped. Note that there -- is no guarantee on how soon the finaliser is executed after the last -- reference was dropped; this depends on the details of the Haskell storage -- manager. Indeed, there is no guarantee that the finalizer is executed at -- all; a program may exit with finalizers outstanding. (This is true -- of GHC, other implementations may give stronger guarantees). Thanks Ian ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ForeignPtr and -threaded
From: Ian Lynagh [EMAIL PROTECTED] Subject: Re: ForeignPtr and -threaded Date: Mon, 23 Jul 2007 09:22:01 +0100 That's a documentation bug. In the HEAD it says: newForeignPtr :: FinalizerPtr a - Ptr a - IO (ForeignPtr a) -- ^Turns a plain memory reference into a foreign pointer, and -- associates a finaliser with the reference. The finaliser will be executed -- after the last reference to the foreign object is dropped. Note that there -- is no guarantee on how soon the finaliser is executed after the last -- reference was dropped; this depends on the details of the Haskell storage -- manager. Indeed, there is no guarantee that the finalizer is executed at -- all; a program may exit with finalizers outstanding. (This is true -- of GHC, other implementations may give stronger guarantees). Uh, ok... Thank you for your information. ___ - PHO - http://ccm.sherry.jp/ OpenPGP public key: 1024D/1A86EF72 Fpr: 5F3E 5B5F 535C CE27 8254 4D1A 14E7 9CA7 1A86 EF72 pgpsI6uFWa8TT.pgp Description: PGP signature ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
ForeignPtr and -threaded
Hi, I have encountered a weird behavior of ForeignPtr. I want to know how to work around this. I am using GHC 6.6.1 on Darwin. [1] Foreign.Concurrent The following code prints called when it is linked with -threaded RTS, but it prints nothing when it isn't. import Foreign.Marshal.Alloc import qualified Foreign.Concurrent as Conc main = do mem - mallocBytes 10 Conc.newForeignPtr mem $ print called [2] Foreign.ForeignPtr The following code prints nothing when it isn't linked with -threaded RTS, but when it is, it *sometimes* prints called but not always. import Foreign.Marshal.Alloc import Foreign.Ptr import Foreign.ForeignPtr foreign import ccall wrapper mkFinalizer :: (Ptr () - IO ()) - IO (FunPtr (Ptr () - IO ())) main = do mem - mallocBytes 10 fin - mkFinalizer $ \ _ - print called newForeignPtr fin mem ___ - PHO - http://ccm.sherry.jp/ OpenPGP public key: 1024D/1A86EF72 Fpr: 5F3E 5B5F 535C CE27 8254 4D1A 14E7 9CA7 1A86 EF72 pgp1tYdEE2v2q.pgp Description: PGP signature ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ForeignPtr and -threaded
Hello PHO, Sunday, July 22, 2007, 5:36:27 PM, you wrote: [2] Foreign.ForeignPtr The following code prints nothing when it isn't linked with -threaded RTS, but when it is, it *sometimes* prints called but not always. import Foreign.Marshal.Alloc import Foreign.Ptr import Foreign.ForeignPtr foreign import ccall wrapper mkFinalizer :: (Ptr () - IO ()) - IO (FunPtr (Ptr () - IO ())) main = do mem - mallocBytes 10 fin - mkFinalizer $ \ _ - print called newForeignPtr fin mem try to add performGC at end - this should force collecting garbage and therefore printing of string. otherwise, it's ok - there is no guarantee that GC will be performed and therefore that you finalizer will be performed. it's rather stanard behavior for GC languages - finalizers are almosr useless there -- Best regards, Bulatmailto:[EMAIL PROTECTED] ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ForeignPtr and -threaded
From: Bulat Ziganshin [EMAIL PROTECTED] Subject: Re: ForeignPtr and -threaded Date: Sun, 22 Jul 2007 17:48:05 +0400 try to add performGC at end - this should force collecting garbage and therefore printing of string. otherwise, it's ok - there is no guarantee that GC will be performed and therefore that you finalizer will be performed. it's rather stanard behavior for GC languages - finalizers are almosr useless there So I changed the code like this but the result was exactly the same. The documentations of both Foreign.ForeignPtr (*1) and Foreign.Concurrent (*2) say The only guarantee is that the finalizer runs before the program terminates. So I expected the finalizer to be called. import Foreign.Marshal.Alloc import Foreign.Ptr import Foreign.ForeignPtr import System.Mem import qualified Foreign.Concurrent as Conc main = work performGC where work = do mem - mallocBytes 10 Conc.newForeignPtr mem $ print called *1: http://haskell.org/ghc/docs/latest/html/libraries/base/Foreign-ForeignPtr.html *2: http://haskell.org/ghc/docs/latest/html/libraries/base/Foreign-Concurrent.html ___ - PHO - http://ccm.sherry.jp/ OpenPGP public key: 1024D/1A86EF72 Fpr: 5F3E 5B5F 535C CE27 8254 4D1A 14E7 9CA7 1A86 EF72 pgpr91nytJP5B.pgp Description: PGP signature ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Replacing select() in the non-threaded RTS?
Stefan O'Rear wrote: I don't beleive the GHC team would be interested in receiving any patches to the non-threaded RTS, since it is scheduled for removal in 6.8 IIRC (leaving only threaded). But the threaded RTS calls select, too, only from Haskell instead of C. So the problem remains, unless the plan to switch to the pluggable event model will mature earlier than seems to be expected. b ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Replacing select() in the non-threaded RTS?
I notice that select is a bit of a bottleneck in the non-threaded RTS once lots of sockets are in play. Between kernel and userspace, many a cycle are wasted once we go past a few hundred clients. On some operating systems, the fixed nature of fd_set imposes a surprisingly low ceiling on the maximum number of concurrently open file descriptors. I gather there's some kind of longish-term plan to build a more pluggable RTS, but it seems like a nearer-term solution could be implemented relatively cheaply, and wouldn't conflict with the ultimate goal. Would the GHC team be interested in receiving a patch that replaced select, where possible, with an operating system's native, and hopefully faster, event wait mechanism? b ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Replacing select() in the non-threaded RTS?
On Wed, May 30, 2007 at 09:21:36PM -0700, Bryan O'Sullivan wrote: I notice that select is a bit of a bottleneck in the non-threaded RTS once lots of sockets are in play. Between kernel and userspace, many a cycle are wasted once we go past a few hundred clients. On some operating systems, the fixed nature of fd_set imposes a surprisingly low ceiling on the maximum number of concurrently open file descriptors. I gather there's some kind of longish-term plan to build a more pluggable RTS, but it seems like a nearer-term solution could be implemented relatively cheaply, and wouldn't conflict with the ultimate goal. Would the GHC team be interested in receiving a patch that replaced select, where possible, with an operating system's native, and hopefully faster, event wait mechanism? I don't beleive the GHC team would be interested in receiving any patches to the non-threaded RTS, since it is scheduled for removal in 6.8 IIRC (leaving only threaded). Stefan ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ghci and ghc -threaded broken with pipes forking
John Goerzen wrote: On 2007-03-02, Simon Marlow [EMAIL PROTECTED] wrote: Regarding your shell: I would suggest trying forkIO for the Haskell processes (not forkOS unless for some reason you really need another OS thread). However, I can imagine that it might be hard to implement job control and signal handling in that system. You could also consider using System.Process.runInteractiveProcess, for portability. Thinking about forkIO seems that it could be fairly complex to just drop in. The problem lies around file descriptors. When you fork off a new process, and then close file descriptors in the parent, they stay open in the child, and vice versa. Proper management of file descriptors is a critical part of a shell, and it's vital to close the proper set of FDs at the proper time in the parent and the child, or else bad things like pipes never closing could easily lead to deadlock. Of course, it is possible to work around this, but I fear that it could make the program very complex. Admittedly I haven't completely thought this through, but my intuition was that you would be able to use forkIO at a higher level. That is, instead of just trying to replace forkProcess with forkIO, you replace forkProcess + pipes + FD handling with forkIO + lazy streams, for Haskell processes. So the way in which data is fed between processes depends on the process: Haskell processes talk to each other using lazy streams, external processes talk to each other over pipes, and at a boundary between the two you need a pipe with another Haskell thread to feed the pipe from a lazy stream, or vice-versa. Cheers, Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ghci and ghc -threaded broken with pipes forking
Bulat Ziganshin wrote: Hello Simon, Friday, March 2, 2007, 1:07:07 PM, you wrote: But let me add a voice to keeping the non-threaded RTS around. i want to mention that problem here is not the threaded RTS by itself, but standard i/o library that works via separate i/o manager thread that is built-in part of RTS. The I/O manager thread is hardly built-in to the RTS. It is all in a Haskell library; the only connection with the RTS is that the RTS feeds signals to the I/O manager thread down a pipe, and in fact we could move this signal-handling code out of the RTS and into the base package too. ? my Streams library [1] don't uses this thread at all. for threads created with forkOS it provides excellent overlapping of I/O and computations (thanks, Simon, situation was *greatly* improved in 6.6). of course, it should be not so great for forkIO'd threads I don't understand why forkOS should be any different from forkIO in this context. Could you explain? There seems to be a common misconception that forkOS is necessary to get certain kinds of concurrency, and forkIO won't do. I don't know where this comes from: the documentation does seem to be quite clear to me. The only reason to use forkOS is for interacting with foreign code that uses thread-local state; everytyhing else can be done with forkIO (and it is usually better to use forkIO). Cheers, Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ghci and ghc -threaded broken with pipes forking
On Mon, Mar 05, 2007 at 12:59:17PM +, Simon Marlow wrote: There seems to be a common misconception that forkOS is necessary to get certain kinds of concurrency, and forkIO won't do. I don't know where this comes from: the documentation does seem to be quite clear to me. The only reason to use forkOS is for interacting with foreign code that uses thread-local state; everytyhing else can be done with forkIO (and it is usually better to use forkIO). From reading the docs, it sounds like forkIO keeps everything in a single OS thread/process. Doesn't this mean that a program that uses forkIO instead of forkOS loses out on SMP machines? ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ghci and ghc -threaded broken with pipes forking
On Mon, Mar 05, 2007 at 08:36:29AM -0600, John Goerzen wrote: On Mon, Mar 05, 2007 at 12:59:17PM +, Simon Marlow wrote: There seems to be a common misconception that forkOS is necessary to get certain kinds of concurrency, and forkIO won't do. I don't know where this comes from: the documentation does seem to be quite clear to me. The only reason to use forkOS is for interacting with foreign code that uses thread-local state; everytyhing else can be done with forkIO (and it is usually better to use forkIO). From reading the docs, it sounds like forkIO keeps everything in a single OS thread/process. Doesn't this mean that a program that uses forkIO instead of forkOS loses out on SMP machines? You can use e.g. +RTS -N2 to use 2 OS threads. Thanks Ian ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ghci and ghc -threaded broken with pipes forking
Ian Lynagh wrote: On Mon, Mar 05, 2007 at 08:36:29AM -0600, John Goerzen wrote: On Mon, Mar 05, 2007 at 12:59:17PM +, Simon Marlow wrote: There seems to be a common misconception that forkOS is necessary to get certain kinds of concurrency, and forkIO won't do. I don't know where this comes from: the documentation does seem to be quite clear to me. The only reason to use forkOS is for interacting with foreign code that uses thread-local state; everytyhing else can be done with forkIO (and it is usually better to use forkIO). From reading the docs, it sounds like forkIO keeps everything in a single OS thread/process. Doesn't this mean that a program that uses forkIO instead of forkOS loses out on SMP machines? You can use e.g. +RTS -N2 to use 2 OS threads. I've added a sentence to the forkOS docs to say that you don't need forkOS to get parallelism. Cheers, Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ghci and ghc -threaded broken with pipes forking
On Mon, Mar 05, 2007 at 03:20:05PM +, Ian Lynagh wrote: From reading the docs, it sounds like forkIO keeps everything in a single OS thread/process. Doesn't this mean that a program that uses forkIO instead of forkOS loses out on SMP machines? You can use e.g. +RTS -N2 to use 2 OS threads. That's rather ugly though, and doesn't just work. With other languages, I could just use OS threads, and let the OS schedule, say, 15 threads across 2 CPUs, or 4 CPUs, or however I may have. -- John ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ghci and ghc -threaded broken with pipes forking
John Goerzen wrote: On Mon, Mar 05, 2007 at 03:20:05PM +, Ian Lynagh wrote: From reading the docs, it sounds like forkIO keeps everything in a single OS thread/process. Doesn't this mean that a program that uses forkIO instead of forkOS loses out on SMP machines? You can use e.g. +RTS -N2 to use 2 OS threads. That's rather ugly though, and doesn't just work. With other languages, I could just use OS threads, and let the OS schedule, say, 15 threads across 2 CPUs, or 4 CPUs, or however I may have. -- John Choice is good, but it does mean the default may need to be tweaked, such as with those options. The main difference in how lightweight or heavyweight the threads are. Lightweight forkIO threads allow for tremendous performance, see the benchmarks here: http://shootout.alioth.debian.org/gp4/benchmark.php?test=chameneoslang=all http://shootout.alioth.debian.org/gp4/benchmark.php?test=messagelang=all Those benchmarks are without using a +RTS -N2 style thread pool. -- Chris ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re[2]: ghci and ghc -threaded broken with pipes forking
Hello Simon, Friday, March 2, 2007, 1:07:07 PM, you wrote: But let me add a voice to keeping the non-threaded RTS around. i want to mention that problem here is not the threaded RTS by itself, but standard i/o library that works via separate i/o manager thread that is built-in part of RTS. my Streams library [1] don't uses this thread at all. for threads created with forkOS it provides excellent overlapping of I/O and computations (thanks, Simon, situation was *greatly* improved in 6.6). of course, it should be not so great for forkIO'd threads that i want to say is that future i/o lib may be written in the RTS-independent way. John Meacham once proposed to develop some common API for i/o managers that will allow to use various select variants with any i/o lib that works via this API -- Best regards, Bulatmailto:[EMAIL PROTECTED] ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ghci and ghc -threaded broken with pipes forking
On 2007-03-02, Simon Marlow [EMAIL PROTECTED] wrote: Regarding your shell: I would suggest trying forkIO for the Haskell processes (not forkOS unless for some reason you really need another OS thread). However, I can imagine that it might be hard to implement job control and signal handling in that system. You could also consider using System.Process.runInteractiveProcess, for portability. Thinking about forkIO seems that it could be fairly complex to just drop in. The problem lies around file descriptors. When you fork off a new process, and then close file descriptors in the parent, they stay open in the child, and vice versa. Proper management of file descriptors is a critical part of a shell, and it's vital to close the proper set of FDs at the proper time in the parent and the child, or else bad things like pipes never closing could easily lead to deadlock. Of course, it is possible to work around this, but I fear that it could make the program very complex. -- John ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ghci and ghc -threaded broken with pipes forking
Ok, what happens here is that in the forked process there is only a single thread, the runtime kills all the other threads (as advertised). Unfortunately this includes the I/O manager thread, so as soon as you do some I/O in the forked process, you block. It might be possible to fix this, but not easily I'm afraid, because the I/O manager doesn't currently have a way to restart after it's been killed. We could implement that, though. I'll create a bug report. On a more general note, forkProcess is known to be hairy - simply the fact that it kills all the other threads in the system in the forked process means that there's a good supply of means to shoot yourself in the foot, even accidentally. John - perhaps there's another way to achieve what you want? Cheers, Simon Jeremy Shaw wrote: Hello, Here is a simplified example that seems to exhibit the same behaviour, unless I screwed up: --- module Main where import System.Posix import System.IO import System.Exit main = do putStrLn running... (stdinr, stdinw) - createPipe (stdoutr, stdoutw) - createPipe pid - forkProcess $ do hw - fdToHandle stdoutw hr - fdToHandle stdinr closeFd stdinw hGetContents hr = hPutStr hw hClose hr hClose hw exitImmediately ExitSuccess closeFd stdoutw closeFd stdinw hr2 - fdToHandle stdoutr hGetContents hr2 = putStr getProcessStatus True False pid = print --- Compiling with: ghc --make -no-recomp test3.hs -o test3 ./test3 works. But compiling with: ghc --make -no-recomp -threaded test3.hs -o test3 ./test3 results in a hang. If you comment out the hGetContents hr = and change 'hPutStr hw' to 'hPutStr hw hi', then it seems to work ok. As you suggested, it seems that hGetContents is not ever seeing the EOF when -threaded is enabled. I think it gets 'Resource temporarily unavailable' instead. So, it keeps retrying. Assuming I have recreated the same bug, we at least have a simpiler test case now... j. At Wed, 28 Feb 2007 11:15:04 -0600, John Goerzen wrote: Hi, I've been hitting my head against a wall for the past couple of days trying to figure out why my shell-like pipeline code kept hanging. I found fd leakage (file descriptors not being closed), which disrupts EOF detection and can lead to deadlocks. I just couldn't find the problem. I finally tried compiling my test with ghc instead of running it in ghci. And poof, it worked fine the first time. I tried asking on #haskell, and got the suggestion that ghci uses -threaded. I tried compiling my test program with ghc -threaded, and again, same deadlock. My program never calls forkIO or forkOS or any other threading code. You can see my test case with: darcs get '--tag=glasgow ml' http://darcs.complete.org/hsh ghc -fglasgow-exts --make -o test2 test2.hs That'll run fine. If you add -threaded, it will hang. Ideas? Thanks, -- John ___ 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 ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ghci and ghc -threaded broken with pipes forking
On Thu, Mar 01, 2007 at 03:06:22PM +, Simon Marlow wrote: Ok, what happens here is that in the forked process there is only a single thread, the runtime kills all the other threads (as advertised). Unfortunately this includes the I/O manager thread, so as soon as you do some I/O in the forked process, you block. Could it just revert to the nonthreaded IO model, or is that not within the scope of what's easily achievable with the threaded RTS? On a more general note, forkProcess is known to be hairy - simply the fact that it kills all the other threads in the system in the forked process means that there's a good supply of means to shoot yourself in the foot, even accidentally. John - perhaps there's another way to achieve what you want? Right. Part of this problem may be one of documentation, and part of it rests with ghci. I have no need for threads in this program. And, in fact, as you said, threads are known to be hazardous when used in conjuntion with fork(). I have no interest in combining the to. The mechanics of signal propogation, file descriptor closing, etc. all get complicated. But it seems like there is not much choice with ghci. It appears to be built with the threaded RTS by default, and uses threads even though I never try to use threads with it. And there seems to be no way to turn it off. Between that and the lack of support for forkProcess in Hugs, this renders anything that needs to fork and then do I/O as being usable only in GHC-compiled code. Which is sub-optimal, but livable anyway. Also, why does hGetContents not work, but hPutStr does? If the IO manager is dead, how does some IO still work? -- John ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ghci and ghc -threaded broken with pipes forking
John Goerzen wrote: On Thu, Mar 01, 2007 at 03:06:22PM +, Simon Marlow wrote: Ok, what happens here is that in the forked process there is only a single thread, the runtime kills all the other threads (as advertised). Unfortunately this includes the I/O manager thread, so as soon as you do some I/O in the forked process, you block. Could it just revert to the nonthreaded IO model, or is that not within the scope of what's easily achievable with the threaded RTS? The non-threaded I/O system just isn't compiled into the threaded RTS at all. We used to use it in the threaded RTS before we switched to the I/O manager thread, but as I recall it was a rich source of bugs; the I/O manager thread is much simpler, being in Haskell. On a more general note, forkProcess is known to be hairy - simply the fact that it kills all the other threads in the system in the forked process means that there's a good supply of means to shoot yourself in the foot, even accidentally. John - perhaps there's another way to achieve what you want? Right. Part of this problem may be one of documentation, and part of it rests with ghci. I have no need for threads in this program. And, in fact, as you said, threads are known to be hazardous when used in conjuntion with fork(). I have no interest in combining the to. The mechanics of signal propogation, file descriptor closing, etc. all get complicated. But it seems like there is not much choice with ghci. It appears to be built with the threaded RTS by default, and uses threads even though I never try to use threads with it. And there seems to be no way to turn it off. The problem is that the choice between -threaded and non-threaded is made at link-time, so we have to make that choice when we link the GHCi binary. In fact you should think of the non-threaded RTS as deprecated. It isn't Haskell'-compliant, for one thing (assuming that Haskell' will probably require non-blocking foreign calls). I'm hesitant to actually deprecate it, for a few reasons: the threaded RTS is so much more complicated, it might have some adverse performance impliciations, and there are still people who want to run everything in a single OS thread, for whatever reason. But having multiple variants of the RTS is a maintenance and testing headache. Between that and the lack of support for forkProcess in Hugs, this renders anything that needs to fork and then do I/O as being usable only in GHC-compiled code. Which is sub-optimal, but livable anyway. I guess I'm really wondering why you need to fork and do I/O at all. Can you describe the problem at a higher level? Also, why does hGetContents not work, but hPutStr does? If the IO manager is dead, how does some IO still work? Ah well, only I/O that needs to block uses the I/O manager thread. I/O that doesn't block just proceeds directly. Cheers, Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ghci and ghc -threaded broken with pipes forking
On Thu, Mar 01, 2007 at 04:21:45PM +, Simon Marlow wrote: Between that and the lack of support for forkProcess in Hugs, this renders anything that needs to fork and then do I/O as being usable only in GHC-compiled code. Which is sub-optimal, but livable anyway. I guess I'm really wondering why you need to fork and do I/O at all. Can you describe the problem at a higher level? I am, for all intents and purposes, writing what amounts to a simple shell. The standard way of implemeting pipes between two external programs in Unix involves setting up pipes and forking, then duping things to stdin/stdout, and execing the final program. In this case, I am setting it up to let people pipe to Haskell functions as well, forking off a process that works with pipes to handle them. I know how all these things work in Unix, in C, in Python, etc. I have no idea how all of this will interact if I were to use forkOS. It is not clear to me what the semantics of forkProcess, executeFile, signal handling, etc. are under a Haskell thread instead of a forked process. This is, as far as I can tell, completely undocumented in System.Posix.* and the subject of differing advice on the WWW. But let me add a voice to keeping the non-threaded RTS around. I have learned the hard way that the threaded RTS is ported only to a very few platforms, a distinct minority of the platforms that Debian supports, for instance. (Just like ghci). Whereas the non-threaded RTS is supported much more broadly (such as Alpha support). My own program hpodder has failed to build in Debian on many platforms because I didn't realize this going in. Not only that, but it is apparent that the threaded RTS is simply inappropriate when a person is trying to do anything remotely low-level on the system. I would hate to have to become a Haskell refugee, going back to Python, because Haskell I/O has become incompatible with fork(). I do not find a language to be useful, in general, unless it lets me fork and exec when I have to. -- John ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ghci and ghc -threaded broken with pipes forking
At Thu, 1 Mar 2007 11:38:54 -0600, John Goerzen wrote: On Thu, Mar 01, 2007 at 04:21:45PM +, Simon Marlow wrote: Between that and the lack of support for forkProcess in Hugs, this renders anything that needs to fork and then do I/O as being usable only in GHC-compiled code. Which is sub-optimal, but livable anyway. I guess I'm really wondering why you need to fork and do I/O at all. Can you describe the problem at a higher level? I am, for all intents and purposes, writing what amounts to a simple shell. The neat thing about the library is that external commands and haskell code can be freely intermixed, and are uniformly handled. For example, in this pipeline, r - runS (ls -l -|- grep i -|- wcL ) wcL is a simple haskell function: wcL :: [String] - [String] wcL inp = [show $ genericLength inp] The HSH library just creates some pipes to hook the processes together, and then forks of ls, grep, and wcL as seperate processes. The advantage of this scheme is that once the pipeline is started, everything behaves the same way it would if you had run the bash command: $ ls -l | grep i | wcL So, you get very familiar behaviour/performance from a shell scripting point of view. But, you also get to easily stick haskell functions in your pipeline. Poking around with the full HSH code, I *think* I got pipelines that *only* called external commands working fine[1]. This seems logical, since the external commands do not care about the Haskell I/O manager at all. So, perhaps you can have an alternate version of 'instance ShellCommand (String - IO String)' that gets used for -threaded that uses forkOS instead of forkProcess. All of the external commands would still be forked into seperate processes, but all of the haskell commands would run in the same threaded process. Obviously, you would have to fake the return code, but it looks like that should be feasible. Some open questions are: a) how do you detect that you are running in the threaded RTS b) can you have the linker pick the correct version at link time, so that you do not have to have a compile-time check. Of course, a compile time check might only have to be done once, so the overhead would not be significant. j. [1] In fact, they may work fine out of the box, I haven't tested that. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
