Re: [GHC] #1741: Threaded RTS must use processor affinity and processor information
#1741: Threaded RTS must use processor affinity and processor information
-+--
Reporter: guest | Owner: simonmar
Type: task| Status: closed
Priority: high| Milestone: 7.0.1
Component: Runtime System |Version: 6.6.1
Resolution: fixed | Keywords:
Testcase: | Blockedby:
Difficulty: Unknown | Os: Unknown/Multiple
Blocking: | Architecture: Unknown/Multiple
Failure: None/Unknown|
-+--
Changes (by simonmar):
* status: new = closed
* resolution: = fixed
Comment:
I implemented affinity on Windows:
{{{
Tue Sep 14 16:58:44 BST 2010 Simon Marlow marlo...@gmail.com
* implement setThreadAffinity on Windows (#1741)
}}}
strangely it causes some parallel programs to go very slowly when using
all the cores, though I'm confident it's doing the right thing. I suspect
the Windows scheduler is trying to keep one of the cores free or
something.
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1741#comment:15
GHC http://www.haskell.org/ghc/
The Glasgow Haskell Compiler
___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #1741: Threaded RTS must use processor affinity and processor information
#1741: Threaded RTS must use processor affinity and processor information -+-- Reporter: guest |Owner: simonmar Type: task | Status: new Priority: high |Milestone: 6.14.1 Component: Runtime System| Version: 6.6.1 Keywords:| Testcase: Blockedby:| Difficulty: Unknown Os: Unknown/Multiple | Blocking: Architecture: Unknown/Multiple | Failure: None/Unknown -+-- Changes (by simonmar): * owner: = simonmar * failure: = None/Unknown * priority: low = high -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1741#comment:14 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #1741: Threaded RTS must use processor affinity and processor information
#1741: Threaded RTS must use processor affinity and processor information -+-- Reporter: guest |Owner: Type: task | Status: new Priority: normal|Milestone: 6.12 branch Component: Runtime System| Version: 6.6.1 Severity: normal| Resolution: Keywords:| Difficulty: Unknown Testcase:| Os: Unknown/Multiple Architecture: Unknown/Multiple | -+-- Changes (by igloo): * milestone: 6.10 branch = 6.12 branch -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1741#comment:11 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #1741: Threaded RTS must use processor affinity and processor information
#1741: Threaded RTS must use processor affinity and processor information +--- Reporter: guest | Owner: Type: task| Status: new Priority: normal | Milestone: 6.10 branch Component: Runtime System |Version: 6.6.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Multiple Os: Multiple| +--- Changes (by tibbe): * cc: [EMAIL PROTECTED] (added) Comment: Replying to [comment:2 simonmar]: One problem with setting `-N` to something other than 1 by default is that `System.Posix.forkProcess` only works with `-N1`, so if you use that function then you need to fix `-N1` somehow (probably with a hook). I'm not sure I want to contemplate making `forkProcess` work for larger values of N. I suspect `forkProcess` is rare, and we might want to deprecate it anyway. POSIX already puts pretty severe restrictions on what you can do in the child process after `fork()` in a threaded program, so it's not clear that we should be providing it at the Haskell level. I really need to be able to fork in the threaded RTS to daemonize my process. I imagine that other server programs need to do the same. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1741#comment:8 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #1741: Threaded RTS must use processor affinity and processor information
#1741: Threaded RTS must use processor affinity and processor information
+---
Reporter: guest | Owner:
Type: task| Status: new
Priority: normal | Milestone: 6.10 branch
Component: Runtime System |Version: 6.6.1
Severity: normal | Resolution:
Keywords: | Difficulty: Unknown
Testcase: | Architecture: Multiple
Os: Multiple|
+---
Comment (by simonmar):
You can do this via the `defaultsHook`; just define a C function
{{{
void defaultsHook (void) { ... your code here ... }
}}}
and it'll get run during the RTS startup, just before the command-line
flags are parsed. The idea is that you can modify `RtsFlags` to set
various options (see [[GhcFile(includes/RtsFlags.h)]]). The field
corresponding to `+RTS -N` is `RtsFlags.ParFlags.nNodes`.
I think it would be great if you (or someone else) could write some code
to automatically set `+RTS -N` using `defaultsHook`, and we can pick it up
at a later time.
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1741#comment:7
GHC http://www.haskell.org/ghc/
The Glasgow Haskell Compiler___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #1741: Threaded RTS must use processor affinity and processor information
#1741: Threaded RTS must use processor affinity and processor information +--- Reporter: guest | Owner: Type: task| Status: new Priority: normal | Milestone: 6.10 branch Component: Runtime System |Version: 6.6.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Multiple Os: Multiple| +--- Changes (by PHO): * cc: [EMAIL PROTECTED] (added) -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1741#comment:5 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #1741: Threaded RTS must use processor affinity and processor information
#1741: Threaded RTS must use processor affinity and processor information +--- Reporter: guest | Owner: Type: task| Status: new Priority: normal | Milestone: 6.10 branch Component: Runtime System |Version: 6.6.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Multiple Os: Multiple| +--- Comment (by bos): Having `forkProcess` be broken by default would be unfortunate, I agree. Perhaps a new link-phase option, say `-multicore`, could be added that would both use the threaded RTS and cause `-N/k/` to be set automatically. It could be explicitly documented as breaking `forkProcess`. Alternatively, if there were some documented means for people to add a little hunk of code that would set the number of capabilities and other RTS options to use before the RTS parses them, that would do the trick. That would also let an enterprising coder configure a system-appropriate maximum heap size, and other such goodness. I wonder if just adding a static initializer would be enough. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1741#comment:6 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #1741: Threaded RTS must use processor affinity and processor information
#1741: Threaded RTS must use processor affinity and processor information +--- Reporter: guest | Owner: Type: task| Status: new Priority: normal | Milestone: 6.10 branch Component: Runtime System |Version: 6.6.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Multiple Os: Multiple| +--- Changes (by simonmar): * milestone: 6.8 branch = 6.10 branch -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1741#comment:4 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #1741: Threaded RTS must use processor affinity and processor information
#1741: Threaded RTS must use processor affinity and processor information +--- Reporter: guest | Owner: Type: task| Status: new Priority: normal | Milestone: 6.8 branch Component: Runtime System |Version: 6.6.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Multiple Os: Multiple| +--- Comment (by guest): Replying to [comment:2 simonmar]: One problem with setting `-N` to something other than 1 by default is that `System.Posix.forkProcess` only works with `-N1`, so if you use that function then you need to fix `-N1` somehow (probably with a hook). I'm not sure I want to contemplate making `forkProcess` work for larger values of N. I suspect `forkProcess` is rare, and we might want to deprecate it anyway. Does anyone have opinion about it? I think that if someone want to use -threaded option, he want to use more than 2-core normally. So setting -N to 1 by default isn't good solution. I think that writing about this problem on Haddock System.Posix.forkProcess document, and then deprecating `forkProcess` is better solution. Because if someone can't find `forkProcess` problem in document, he cann't decide to use `forkProcess` or not. His program works well with default -N1, but he suddenly encounts problem when setting option -N to parallelize his program. That isn't good. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1741#comment:3 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
[GHC] #1741: Threaded RTS must use processor affinity and processor information
#1741: Threaded RTS must use processor affinity and processor information ---+ Reporter: guest | Owner: Type: task | Status: new Priority: normal| Milestone: Component: Compiler |Version: 6.6.1 Severity: normal| Keywords: Difficulty: Unknown | Os: Multiple Testcase:| Architecture: Multiple ---+ Threaded RTS must use processor affinity and processor information I think current GHC's SMP parallelism support has 2 problems. 1. We must specify -Nx option if we want to use multiple CPU or cores. 1. Threaded RTS doesn't set processor affinity even if OS API support that. 1 is bad. Because this is complex for Application user and developper. If user want to take full advantage of multiple core processor, user must know how many his computer's cpu cores, and specify RTS option in runtime. Or application developper must guess how many users' computer use cpu cores, and set guessed good enough RTS option. * http://www.haskell.org/ghc/docs/latest/html/users_guide/runtime- control.html#rts-hooks If OS doesn't provide CPU information, it's real solution. But we can get CPU information by OS's API, so it's just bad way. We can get number of processors (cores) by sysconf(_SC_NPROCESSORS_CONF) under unix (includes Mac OS X) platform, and by GetSystemInfo function under Windows platform. * http://developer.apple.com/documentation/Darwin/Reference/ManPages/man3/sysconf.3.html * http://msdn2.microsoft.com/en-us/library/ms724381.aspx So I think threaded RTS must specify -Nx's default x by using these API. 2 is related to good parallel program's behavior. Current mainstream OS scheduler assigns thread to CPU implicitly by default. And if two thread are assigned to same CPU, then a thead must wait when another thread is running, even if other CPU is idle. This is not good. * http://www.haskell.org/pipermail/cvs-ghc/2007-August/037534.html And RTS -Nx option specifies number of thread running simultaneously. * http://www.haskell.org/ghc/docs/latest/html/users_guide/sec-using- smp.html So I think threaded RTS must assigning thread to CPU instead of leaving work for OS scheduler. This is not difficult work on Linux and Windows. Because we just need to set processor affinity by OS's API. Linux has sched_setaffinity, so we must just set bitmask on Linux. * http://linux.die.net/man/2/sched_setaffinity * http://www-128.ibm.com/developerworks/linux/library/l-affinity.html Windows has many API, e.g. SetThreadAffinityMask and SetThreadIdealProcessor So we must just set bitmask by SetThreadAffinityMask, or set preferred processor by SetThreadIdealProcessor on Windows. * http://msdn2.microsoft.com/en-us/library/ms684251.aspx But I don't get other OS's API information soonly, and I think this is difficult point of this task. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1741 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #1741: Threaded RTS must use processor affinity and processor information
#1741: Threaded RTS must use processor affinity and processor information -+-- Reporter: guest |Owner: Type: task | Status: new Priority: normal|Milestone: Component: Compiler | Version: 6.6.1 Severity: normal| Resolution: Keywords:| Difficulty: Unknown Os: Multiple | Testcase: Architecture: Multiple | -+-- Changes (by guest): * cc: [EMAIL PROTECTED] (added) Comment: It would be nice if -N''k'' wasn't needed by default. SimonM, if you want, I can write a patch against 6.8 that sets the right value of ''k'' by default, letting -N''k'' override it. I'm not concerned about setting affinity. It's usually better to let the OS choose this by default, as it's almost impossible to get highly pertinent information out of the kernel, such as whether two cores are in the same physical package or not. If the OS is scheduling two runnable processes on a single core while another one lies idle, that's a kernel scheduler bug. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1741#comment:1 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
