Re: [Haskell-cafe] network 2.3.05 on windows 7 with ghc-7.2.1
Hi, If someone here managed to build network 2.3.05 on windows 7 with ghc-7.2.1 , could you kindly pass me the trick? The config step fails with missing header. I tried running it with mingw (tried with the latest one too - just in case : http://sourceforge.net/projects/mingw/files/Automated%20MinGW%20Installer/ ) I did not face any issue for the same thing on linux. Many thanks, Hemanth K I have done exactly this with the same versions. No problems. I used the MINGW that comes with ghc-7.2.1. I probably executed the configure under MSYS though, which probably makes the difference. Rene. _ Thanks! Your approach worked perfectly. All I had to do was to ensure that the msys uses ghc's mingw to configure and build successfully. thank you regards, Hemanth K ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] network 2.3.05 on windows 7 with ghc-7.2.1
Hi everybody, this evening (29th of September) there will be a meeting of people interested in Haskell or functional programming in general in Munich at Cafe Puck: http://www.cafepuck.de/ The meeting will start at 19h30 (german time). Sorry for being late with this announcement. Nevertheless, please feel free to join us. Have a nice day, Heinrich ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Munich Haskell Meeting Tonight
Sorry for the bad subject... Here comes my announcement again: Hi everybody, this evening (29th of September) there will be a meeting of people interested in Haskell or functional programming in general in Munich at Cafe Puck: http://www.cafepuck.de/ The meeting will start at 19h30 (german time). Sorry for being late with this announcement. Nevertheless, please feel free to join us. Have a nice day, Heinrich ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Munich Haskell Meeting Tonight
Eh, I was in munich last month for a week. If you announce future meetings here I might make it up there. It's a ~4 hour trip. Ciao! 2011/9/29 Dr. Heinrich Hördegen hoerde...@funktional.info: Sorry for the bad subject... Here comes my announcement again: Hi everybody, this evening (29th of September) there will be a meeting of people interested in Haskell or functional programming in general in Munich at Cafe Puck: http://www.cafepuck.de/ The meeting will start at 19h30 (german time). Sorry for being late with this announcement. Nevertheless, please feel free to join us. Have a nice day, Heinrich ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Turn GC off
To me this sounds like a problem where Erlang might be a better choice. On Wed, Sep 28, 2011 at 4:04 PM, Andreas Voellmy andreas.voel...@gmail.com wrote: On Sat, Sep 17, 2011 at 1:38 AM, Jesse Schalken jesseschal...@gmail.com wrote: There might be a way to do it, I don't know, but this sounds like an XY problem. Can I ask what you're trying to achieve by doing this, or is it just out of curiosity regarding how much garbage is created? (It's a lot, by the way. Since the only thing a purely functional program can do is create data and read data (as opposed to create, read and update in an impure program) I imagine a purely functional program without GC would hit OOM very, very quickly.) Sure. I'm writing a server that serves a number of long-lived TCP connections. The clients can be served mostly independently; there is a bit of shared state among the different connections. I'd like to use the concurrency available to scale the server to handle a large number of clients. Ideally I would just use more cores to handle a larger number of clients. It seems that GC is the biggest obstacle to doing this. The problem seems to be that the current GC stops all the processors before performing a GC. With a large number of processors this becomes expensive, and I find that a program that has really high mutator productivity with one processor can get terrible productivity at 12 or more processors. Of course, it helps to reduce the allocation rate of the program, but even after being very careful about how much memory is allocated, GC still takes up a significant amount of time. So I was looking for a way to turn off GC altogether just as an experiment to see how the program would perform without all the GC pauses. --Andreas On Thu, Sep 15, 2011 at 2:42 AM, Andreas Voellmy andreas.voel...@gmail.com wrote: Hi everyone, Is there a way to completely turn garbage collection off in the Haskell runtime system? I'm aware of the -A runtime option, but I'd like to completely turn it off, if possible. I'm OK with running the program until it runs out of memory, and I'm willing to recompile GHC if needed. Regards, Andreas ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] LLVM: function pointer in global struct
Hi everyone,
Using the LLVM bindings, I'm trying to create an initialized global
struct variable containing a pointer to a function.
{-# LANGUAGE ScopedTypeVariables #-}
import LLVM.Core
import Data.Word
import LLVM.Util.File(writeCodeGenModule)
sm_module = do
tick :: Function (Word32 - IO Word32) - createFunction
ExternalLinkage $ \x - ret x
info - createNamedGlobal False ExternalLinkage sm_info $
constStruct (tick ())
return info
I run into a complaint that this pointer isn't constant when it's part
of a global variable initializer.
No instance for (llvm-0.10.0.1:LLVM.Core.CodeGen.IsConstStruct
(Function (Word32 - IO Word32) : ()) a0)
arising from a use of `constStruct'
Possible fix:
add an instance declaration for
(llvm-0.10.0.1:LLVM.Core.CodeGen.IsConstStruct
(Function (Word32 - IO Word32) : ()) a0)
In the second argument of `($)', namely `constStruct (tick ())'
In a stmt of a 'do' expression:
info - createNamedGlobal False ExternalLinkage sm_info
$ constStruct (tick ())
In a stmt of a 'do' expression:
tick :: Function (Word32 - IO Word32) - createFunction
ExternalLinkage
$ \ x - ret x
I suppose this is because of
-- |A function is simply a pointer to the function.
type Function a = Value (Ptr a)
being a Value instead of ConstValue. Is there a way around this?
Cheers
Tom
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] ANNOUNCE: GA-1.0, a library for working with genetic algorithms
Hello, I'm proud to announce the v1.0 release of GA [1], my library for working with genetic algorithms in Haskell. Source repo is available on github. [2] This is a major version bump compared to the previous v0.2 release, because the library is pretty mature now in my view. Major features: * flexible user-friendly API for working with genetic algorithms * Entity type class to let user define entity definition, scoring, etc. * abstraction over monad, resulting in a powerful yet simple interface * support for scoring entire population at once * support for checkpointing each generation, and restoring from last checkpoint * convergence detection, as defined by user * also available: random searching, user-defined progress output * illustrative toy examples included I'm happy to take any questions or suggestions that you might have. [1] http://hackage.haskell.org/package/GA [2] https://github.com/boegel/GA ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] HackageDB User Account
Hi Jonathan, On 21 Sep 2011, at 22:41, Jonathan Frywater wrote: How does one go about getting an account? I sent an email to the address provided at http://hackage.haskell.org/packages/accounts.html but haven't received any response yet. Since it's been over 3 weeks, I decided to try my luck here. Ross is usually quite responsive. Try resending him your email, maybe he missed it for some reason. I got a password reset for Hackage a couple of weeks ago in a matter of hours. Kenneth___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Turn GC off
On Wed, Sep 28, 2011 at 6:04 AM, Andreas Voellmy andreas.voel...@gmail.comwrote: Sure. I'm writing a server that serves a number of long-lived TCP connections. How many are you looking at? (ROFLSCALEhttp://www.youtube.com/watch?v=majbJoD6fzo?) And how much activity? Do you need real-time responses? It seems that GC is the biggest obstacle to doing this. The problem seems to be that the current GC stops all the processors before performing a GC. Each OS thread gets its own bump-pointer nursery; minor collections of this nursery do not result in whole system pauses. This should be small enough to fit into a Core's cache (the default 512 kB is usually okay) so we can keep the entire nursery in cache while GC'ing it, keeping its cost close to that of stack. However, if you add an external pointer to large data or thunks in the nursery - e.g. by mutating a shared IORef - you can undermine the benefits of the nursery. It might be worth trying to do more work without mutations, and try to force evaluation of data before writing it to a variable. The idea is to keep the nursery busy so that the second-generation collectors don't need to be. Controlling memory is also important. Use iteratees to help make guarantees about memory consumption. Ideally, you can keep each TCP connection under some fixed live space cost - e.g. 2-4 MB. This keeps GCs small and cheap, and also allows the entire thread to fit into the CPU's larger caches, thus reducing scheduling and evaluation costs. Indeed, controlling memory is the most important thing you should do to reduce GC costs and improve performance. GC only touches live memory. Avoiding allocations is much less important than controlling amount of live memory. Regards, Dave ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Cabal rebuilding of the C++ code for wxHaskell
Hi all, I've been trying to resolve a compile time issue[1] with
wxHaskell, and I thought I'd throw it open to see if anyone on cafe
can help.
Here's the crux of the issue:
The Setup.hs for wxcore (the major component of wxHaskell) uses
simpleUserHooks, overriding only confHook.
However there is also cleanHook, which is defined by simpleUserHooks to be:
cleanHook = \p _ _ f - clean p f,
If you consult the source for clean[2] you'll see that it tries to
remove the whole dist/ directory rather than tracking exactly what
files we created in there. I presume that's why we have to do a full
re-build every time?
To try and circumvent this I modified the definition of main in
Setup.hs to this:
main = defaultMainWithHooks simpleUserHooks { confHook = myConfHook,
cleanHook = (\_ _ _ _ - return ())}
Unfortunately it still seems to re-build all the C++ on each 'install'
from cabal.
Not sure why?
Dave,
[1] http://sourceforge.net/mailarchive/message.php?msg_id=2807
[2] Taken from
http://www.haskell.org/ghc/docs/6.10.4/html/libraries/Cabal/src/Distribution-Simple.html#simpleUserHooks
-- Cleaning
clean :: PackageDescription - CleanFlags - IO ()
clean pkg_descr flags = do
let distPref = fromFlag $ cleanDistPref flags
notice verbosity cleaning...
maybeConfig - if fromFlag (cleanSaveConf flags)
then maybeGetPersistBuildConfig distPref
else return Nothing
-- remove the whole dist/ directory rather than tracking exactly what files
-- we created in there.
chattyTry removing dist/ $ do
exists - doesDirectoryExist distPref
when exists (removeDirectoryRecursive distPref)
-- these live in the top level dir so must be removed separately
removeRegScripts
-- Any extra files the user wants to remove
mapM_ removeFileOrDirectory (extraTmpFiles pkg_descr)
-- If the user wanted to save the config, write it back
maybe (return ()) (writePersistBuildConfig distPref) maybeConfig
where
removeFileOrDirectory :: FilePath - IO ()
removeFileOrDirectory fname = do
isDir - doesDirectoryExist fname
isFile - doesFileExist fname
if isDir then removeDirectoryRecursive fname
else if isFile then removeFile fname
else return ()
verbosity = fromFlag (cleanVerbosity flags)
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Programming with arrows, exercises
Hello. I am reading Programming with Arrows by John Hughes (very helpful and interesting!), the book has an exercises requiring a module called Circuits for checking the answer. There should be things like class ArrowCircuit and various functions related to digital logic circuits simulation. Does anybody know where can I find one? Thanks, Sergey ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] haskell i18n best practices
Hello list. I've been trying to figure a nice method to provide localisation. An application is deployed using a conventional installer. The end-user is not required to have the Haskell runtimes, compiler or platform. The application should bundle ready to use translation data. What I am after is simple; an intuitive way that an interested translator, with little knowledge of Haskell, can look at and create valid translation data. This is what I've been looking at lately. The first thing I noticed was the GNU gettext implementation for Haskell. The wiki page [1] has a nice explanation by Aufheben. The hgettext package is found here [2]. I don't know if this is a bad habit, but I had already separated the dialogue text in the code with variables holding the respective strings. At this time, I thought there could be some other way than gettext. Then I figured how to import localisation data, that the program loads, from external files. The data type is basically a tuple with variable-names associated with strings. This is bit like the file-embed package [3]. Still uncomfortable with i18n, I learned about the article I18N in Haskell in yesod blog [4]. I'd like to hear more about it. What is considered the best practice for localisation? -- [1] http://www.haskell.org/haskellwiki/Internationalization_of_Haskell_programs [2] http://hackage.haskell.org/packages/archive/hgettext/ [3] http://hackage.haskell.org/package/file-embed [4] http://www.yesodweb.com/blog/2011/01/i18n-in-haskell ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Cabal rebuilding all of the C++ code for wxHaskell
Hi all, I've been trying to resolve a compile time issue[1] with
wxHaskell, and I thought I'd throw it open to see if anyone on cafe
can help.
Here's the crux of the issue:
The Setup.hs for wxcore (the major component of wxHaskell) uses
simpleUserHooks, overriding only confHook.
However there is also cleanHook, which is defined by simpleUserHooks to
be:
cleanHook = \p _ _ f - clean p f,
If you consult the source for clean[2] you'll see that it tries to
remove the whole dist/ directory rather than tracking exactly what
files we created in there. I presume that's why we have to do a full
re-build every time?
To try and circumvent this I modified the definition of main in
Setup.hs to this:
main = defaultMainWithHooks simpleUserHooks { confHook = myConfHook,
cleanHook = (\_ _ _ _ - return ())}
Unfortunately it still seems to re-build all the C++ on each 'install'
from cabal.
Not sure why?
Dave,
[1] http://sourceforge.net/mailarchive/message.php?msg_id=2807
[2] Taken from
http://www.haskell.org/ghc/docs/6.10.4/html/libraries/Cabal/src/Distribution-Simple.html#simpleUserHooks
-- Cleaning
clean :: PackageDescription - CleanFlags - IO ()
clean pkg_descr flags = do
let distPref = fromFlag $ cleanDistPref flags
notice verbosity cleaning...
maybeConfig - if fromFlag (cleanSaveConf flags)
then maybeGetPersistBuildConfig distPref
else return Nothing
-- remove the whole dist/ directory rather than tracking exactly what
files
-- we created in there.
chattyTry removing dist/ $ do
exists - doesDirectoryExist distPref
when exists (removeDirectoryRecursive distPref)
-- these live in the top level dir so must be removed separately
removeRegScripts
-- Any extra files the user wants to remove
mapM_ removeFileOrDirectory (extraTmpFiles pkg_descr)
-- If the user wanted to save the config, write it back
maybe (return ()) (writePersistBuildConfig distPref) maybeConfig
where
removeFileOrDirectory :: FilePath - IO ()
removeFileOrDirectory fname = do
isDir - doesDirectoryExist fname
isFile - doesFileExist fname
if isDir then removeDirectoryRecursive fname
else if isFile then removeFile fname
else return ()
verbosity = fromFlag (cleanVerbosity flags)___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Cabal rebuilding all of the C++ code for wxHaskell
On Thu, Sep 29, 2011 at 7:15 PM, DukeDave duked...@gmail.com wrote: Hi all, I've been trying to resolve a compile time issue[1] with wxHaskell, and I thought I'd throw it open to see if anyone on cafe can help. Here's the crux of the issue: The Setup.hs for wxcore (the major component of wxHaskell) uses simpleUserHooks, overriding only confHook. However there is also cleanHook, which is defined by simpleUserHooks to be: cleanHook = \p _ _ f - clean p f, If you consult the source for clean[2] you'll see that it tries to remove the whole dist/ directory rather than tracking exactly what files we created in there. I presume that's why we have to do a full re-build every time? To try and circumvent this I modified the definition of main in Setup.hs to this: Why do you want to change the behavior of the 'clean' hook? Most users would expect it to clear out everything that 'configure', 'build' and such have done. I would be cautious about subverting user expectations like that. Antoine ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANNOUNCE: GA-1.0, a library for working with genetic algorithms
This is neat - thanks for putting in the time and effort (and
releasing the work to Hackage). A few questions:
* What GA-nerdy things does this do under the hood (I haven't looked
at the source)? It looks like it's a GA framework almost more than
the actual algorithm itself. I see crossover and mutation can be
defined by the user and understand there are limitations to what the
GA package can do (seeing as it is so polymorphic), but certainly it
could provide alternate fitness measures (adjusted, normalized,
standard), over-selection, elitism, automatically defined functions
(sometimes called encapsulation), and optimization (I think this is
referred to as editing by Koza).
* Have you considered using Binary or Serialize to make the
checkpointing? (I assume checkpointing is using the Show and Read
instances right now)
* Have you considered alternate random sources (Mersenne)? Perhaps
I'm being silly as most GAs are computationally dominated by the
fitness measurement.
* Is there a plan for parallel computations? Beyond what I can do
with scorePop?
* What does it mean if a score returns 'Nothing'?
On a related note, I've recently put some work into using the Typeable
and Dynamic modules to build a GA system in which the primitives could
hold heterogeneous types. I'll describe it below incase you are 1)
interested in doing it yourself, but actually completeing it (unlike
me) or 2) are already doing it so I won't be tempted to revisit the
work and duplicate effort. From the look of your package, this would
be just an special instance of your Entity class.
The basic idea was to allow the use of arbitrary Haskell types to be
lifted into a generic genetic algorithm:
{- BEGIN CODE -}
evolveSolution = do
let funcs = [mkPrim (:), mkPrim lookup, mkPrim delete, mkPrim
insert] ++ map mkPrim [0..100] ++ map mkPrim [(+),(*),(-)]
allFuncs = funcs ++ primsForContainersPackage -- my package
should have eventually provided such collections
fitness f = f 503 == 0
gaConf = mkGA funcs (mkPrim fitness) defaultConfig
in evolve gaConf
{- END CODE -}
In the system each individual is an operator and a list of arguments,
each contained in their own Dynamic type. All individuals include 1)
a mapping from type to sub-trees that are of that type and 2) a
mapping of types to functions that will construct the same individual
(that is: Map typ (typ - Individual)). The union of the domain of
these to mappings show what, if any, opportunities for crossover exist
between any two individuals.
The global configuration maintains all the primitives needed to
generate new individuals, which means sub-trees can also be generated
to allow mutation.
The main two issues that made me stop (read: I didn't recognize these
as the core issue till I'd already hacked around without thinking
about why what I'm doing wasn't quite right) were:
1) I didn't have a good way to dynamically safely coerce one type,
ty1, into another type, ty2. For example, when given t_1 - t_2 -
... - t_n - r and needed b_1 - b_2 - ... - b_m - r where m
n and there was a injective mapping between the b, t type variables I
still had bugs in the actual coercion.
A more concrete example of this point: given Int - Float - Float,
I wanted to coerce it into a function of type Float - Int - Float
or Float - Float or Int - Float. Usually my solution worked,
but I think a bug lingered (needs testing, which I don't have time
for now).
2) Generation of individuals in highly heterogenious configurations
was basically non-terminating without special effort. I was going to
make a routine to compute the minimum depth given any particular
primitive, then removed any primitive from consideration if the
minimum depth put me over the maximum depth for the individual.
So a bit long winded, but that was the effort in a nutshell. If
nothing else I hope it was entertaining. I'm sure it's doable but I
haven't the time of focus to do it properly, and won't for a while.
Cheers,
Thomas
On Thu, Sep 29, 2011 at 12:45 PM, Kenneth Hoste kenneth.ho...@gmail.com wrote:
Hello,
I'm proud to announce the v1.0 release of GA [1], my library for working with
genetic algorithms in Haskell.
Source repo is available on github. [2]
This is a major version bump compared to the previous v0.2 release, because
the library is pretty mature now in my view.
Major features:
* flexible user-friendly API for working with genetic algorithms
* Entity type class to let user define entity definition, scoring, etc.
* abstraction over monad, resulting in a powerful yet simple interface
* support for scoring entire population at once
* support for checkpointing each generation, and restoring from last
checkpoint
* convergence detection, as defined by user
* also available: random searching, user-defined progress output
* illustrative toy examples included
I'm happy to take any questions or suggestions that you might have.
[1]
Re: [Haskell-cafe] Cabal rebuilding all of the C++ code for wxHaskell
On Friday, 30 September 2011 01:42:00 UTC+1, Antoine Latter wrote: Why do you want to change the behavior of the 'clean' hook? Most users would expect it to clear out everything that 'configure', 'build' and such have done. I would be cautious about subverting user expectations like that. I'm only inquiring about changing the clean hook for this specific project, not cabal in general. And the reason I'm looking to change it is that building the C++ component takes a long time (over five minutes on my fairly average laptop), so cleaning everything every time is an extremely annoying inconvenience. My main questions are: 1. Is there some reason (other than 'safety') that cabal install cleans everything up? 2. Why does setting cleanHook to return () not have any effect? Thanks, ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Cabal rebuilding all of the C++ code for wxHaskell
On 30/09/11 02:45, DukeDave wrote: 1. Is there some reason (other than 'safety') that cabal install cleans everything up? As far as I've experienced and understand it, it doesn't - it's more that GHC can detect when Haskell modules don't need recompiling while the same is not true for C or C++ sources. For example, I change one module and see GHC report only that module and its dependents being recompiled, while the other compiled modules are reused from previous 'cabal install' runs. The C-sources: are recompiled every time even if unchanged, which I too find it somewhat annoying even with my small projects. 2. Why does setting cleanHook to return () not have any effect? I think becausae the clean hook is probably not called by 'cabal install', but by 'cabal clean'. Claude ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Turn GC off
On Thu, Sep 29, 2011 at 3:14 PM, David Barbour dmbarb...@gmail.com wrote: minor collections of this nursery do not result in whole system pauses. Yes, they do. GHC has a parallel garbage collector (so collection pauses the mutator threads, and collects garbage -in parallel- on multiple CPUs) but it in no way has a concurrent one. Every OS thread has its own young-gen heap space, and the old-generation heap space is shared amongst every CPU. But any young-gen GC will cause all mutator threads to pause no matter what the state of the others is. That said, Simon^2 has done research on this problem recently. They recently published a paper about 'local' garbage collection for individual OS threads, where every thread has its own, private nursery, that may be collected independently of all other CPUs, which promotes objects into the global heap when necessary for access from other threads. The design is reminiscent of older work on the same topic (thread-local heaps,) but adds a bunch of tasty work they did. You can find this branch of GHC with 'local heaps' here, in the local-gc branch of the git repository: https://github.com/ghc/ghc/tree/local-gc This new local collector branch is not, I repeat, not part of GHC and hasn't been merged. It's not certain if it ever will be, I think. The paper conclusion addresses the fact the scalability improvements as a result of this new collector are nowhere near as dramatic as they had hoped, and it's not certain the improvements they did get are worth the substantial complexity increase. It doesn't address the old-gen GC - any old-gen GCs still pause all mutator threads before continuing. They do note however that this local allocation strategy could be combined with a real concurrent/incremental GC for the old-generation, which would help control pause times more over the whole lifetime of an application. You can find all the juicy details in their paper Multicore garbage collection with thread local heaps, located near the top of Simon's webpage here: http://research.microsoft.com/en-us/people/simonpj/ -- Regards, Austin ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Turn GC off
Thank you for the clarification. I had read those papers, but I was under the impression that it was something already part of GHC 7. Regards, Dave On Thu, Sep 29, 2011 at 8:45 PM, austin seipp a...@hacks.yi.org wrote: On Thu, Sep 29, 2011 at 3:14 PM, David Barbour dmbarb...@gmail.com wrote: minor collections of this nursery do not result in whole system pauses. Yes, they do. GHC has a parallel garbage collector (so collection pauses the mutator threads, and collects garbage -in parallel- on multiple CPUs) but it in no way has a concurrent one. Every OS thread has its own young-gen heap space, and the old-generation heap space is shared amongst every CPU. But any young-gen GC will cause all mutator threads to pause no matter what the state of the others is. That said, Simon^2 has done research on this problem recently. They recently published a paper about 'local' garbage collection for individual OS threads, where every thread has its own, private nursery, that may be collected independently of all other CPUs, which promotes objects into the global heap when necessary for access from other threads. The design is reminiscent of older work on the same topic (thread-local heaps,) but adds a bunch of tasty work they did. You can find this branch of GHC with 'local heaps' here, in the local-gc branch of the git repository: https://github.com/ghc/ghc/tree/local-gc This new local collector branch is not, I repeat, not part of GHC and hasn't been merged. It's not certain if it ever will be, I think. The paper conclusion addresses the fact the scalability improvements as a result of this new collector are nowhere near as dramatic as they had hoped, and it's not certain the improvements they did get are worth the substantial complexity increase. It doesn't address the old-gen GC - any old-gen GCs still pause all mutator threads before continuing. They do note however that this local allocation strategy could be combined with a real concurrent/incremental GC for the old-generation, which would help control pause times more over the whole lifetime of an application. You can find all the juicy details in their paper Multicore garbage collection with thread local heaps, located near the top of Simon's webpage here: http://research.microsoft.com/en-us/people/simonpj/ -- Regards, Austin ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
