1. 06 Apr, 2006 5 commits
  2. 05 Apr, 2006 3 commits
  3. 30 Mar, 2006 3 commits
  4. 29 Mar, 2006 3 commits
  5. 23 Mar, 2006 1 commit
  6. 28 Mar, 2006 1 commit
  7. 27 Mar, 2006 3 commits
    • Simon Marlow's avatar
      Add a new primitive forkOn#, for forking a thread on a specific Capability · c520a3a2
      Simon Marlow authored
      This gives some control over affinity, while we figure out the best
      way to automatically schedule threads to make best use of the
      available parallelism.
      In addition to the primitive, there is also:
        GHC.Conc.forkOnIO :: Int -> IO () -> IO ThreadId
      where 'forkOnIO i m' creates a thread on Capability (i `rem` N), where
      N is the number of available Capabilities set by +RTS -N.
      Threads forked by forkOnIO do not automatically migrate when there are
      free Capabilities, like normal threads do.  Still, if you're using
      forkOnIO exclusively, it's a good idea to do +RTS -qm to disable work
      pushing anyway (work pushing takes too much time when the run queues
      are large, this is something we need to fix).
    • Simon Marlow's avatar
      eliminate a warning · 5ed93b10
      Simon Marlow authored
    • Simon Marlow's avatar
      elimiante a couple of warnings · 24fd303c
      Simon Marlow authored
  8. 24 Mar, 2006 3 commits
    • Simon Marlow's avatar
      fix a warning · a1b4e3b8
      Simon Marlow authored
    • Simon Marlow's avatar
      Add some more flexibility to the multiproc scheduler · 4368121d
      Simon Marlow authored
      There are two new options in the -threaded RTS:
        -qm       Don't automatically migrate threads between CPUs
        -qw       Migrate a thread to the current CPU when it is woken up
      previously both of these were effectively off, i.e. threads were
      migrated between CPUs willy-milly, and threads were always migrated to
      the current CPU when woken up.  This is the first step in tweaking the
      scheduling for more effective work balancing, there will no doubt be
      more to come.
    • duncan.coutts@worc.ox.ac.uk's avatar
      mkDerivedConstants.c depends on ghcplatform.h · 354cefe7
      duncan.coutts@worc.ox.ac.uk authored
      I think this missing dep is what broke my parallel build
      I used make -j2 with ghc- and got:
      ==fptools== make boot -wr --jobserver-fds=3,11 -j;
      in /var/tmp/portage/ghc-6.4.2_pre20060323/work/ghc-
      Creating ghcplatform.h...
      gcc -O -O2 -march=k8 -pipe -Wa,--noexecstack    -c mkDerivedConstants.c -o mkDerivedConstants.o
      In file included from ghcconfig.h:5,
                       from Stg.h:42,
                       from Rts.h:19,
                       from mkDerivedConstants.c:20:
      ghcplatform.h:1:1: unterminated #ifndef
      With this patch applied I can no longer repoduce this build bug.
      So I think this patch should be applied to the cvs ghc-6-4-branch too.
  9. 27 Mar, 2006 2 commits
  10. 25 Mar, 2006 1 commit
  11. 08 Mar, 2006 1 commit
  12. 24 Mar, 2006 3 commits
  13. 23 Mar, 2006 2 commits
    • Volker Stolz's avatar
      Accept amd64-*-freebsd architecture · 1eff6846
      Volker Stolz authored
    • Simon Marlow's avatar
      gcc is getting smarter, so we need to hit it with a bigger stick · 7aede9b1
      Simon Marlow authored
      On x86_64 we are using C argument registers for global registers in
      the STG machine.  This is always going to be problematic when it comes
      to making C calls from STG and compiling via C.  Prior to GCC 4.1.0
      (approx) it was possible to just assign the argument expressions to
      temporaries to avoid a clash.  Now, we need to add an extra dummy
      function call as a barrier between the temporary assignments and the
      actual call.  The dummy call is removed by the mangler.
  14. 18 Mar, 2006 3 commits
  15. 22 Mar, 2006 2 commits
  16. 21 Mar, 2006 4 commits