Re: [Haskell-cafe] Three Google Summer of Code project proposals
*** Build multiple Cabal packages in parallel *** http://hackage.haskell.org/trac/summer-of-code/ticket/1594 Many developers have multi-core machines but Cabal runs the build process in a single thread, only making use of one core. If the build process could be parallelized build times could be cut by perhaps a factor of 2-8, depending on the number of cores and opportunity of parallel execution available. Isn't the Cabal build process strictly I/O-limited rather than CPU-limited? *** Simpler support for isolated/sandboxed Cabal builds *** http://hackage.haskell.org/trac/summer-of-code/ticket/1590 cabal-dev and capri allow developers to build packages in their own sandboxes, using a separate package database for each. This allows for isolated builds and prevents breakages due e.g. package upgrades. Merging cabal-dev into Cabal allows us to share lots of code and makes the feature more accessible to developers. This would be very useful. PS. I also love the way that performing cabal build causes it to claim that it's also registering the package, when in fact it isn't. Not sure why that spurious message is there... ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Three Google Summer of Code project proposals
On Sun, Mar 27, 2011 at 1:03 PM, Andrew Coppin andrewcop...@btinternet.com wrote: *** Build multiple Cabal packages in parallel *** http://hackage.haskell.org/trac/summer-of-code/ticket/1594 Many developers have multi-core machines but Cabal runs the build process in a single thread, only making use of one core. If the build process could be parallelized build times could be cut by perhaps a factor of 2-8, depending on the number of cores and opportunity of parallel execution available. Isn't the Cabal build process strictly I/O-limited rather than CPU-limited? It's mostly CPU-limited due to spending most of its time in ghc --make (which is CPU limited). It would be nice to parallelize GHC itself at some point but that's a harder task I believe. Johan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Three Google Summer of Code project proposals
On 3/27/11 7:16 AM, Johan Tibell wrote: On Sun, Mar 27, 2011 at 1:03 PM, Andrew Coppin andrewcop...@btinternet.com wrote: *** Build multiple Cabal packages in parallel *** http://hackage.haskell.org/trac/summer-of-code/ticket/1594 Many developers have multi-core machines but Cabal runs the build process in a single thread, only making use of one core. If the build process could be parallelized build times could be cut by perhaps a factor of 2-8, depending on the number of cores and opportunity of parallel execution available. Isn't the Cabal build process strictly I/O-limited rather than CPU-limited? It's mostly CPU-limited due to spending most of its time in ghc --make (which is CPU limited). It would be nice to parallelize GHC itself at some point but that's a harder task I believe. I'm sure it is. But even if we had parallel-compiling GHC, having a parallel-building Cabal would make it easier to make the leap to distributed building--- which would be helpful for folks working on clusters and needing to install a whole lot of packages at once (e.g., bootstrapping or reinstalling). Haskell supercomputing ahoy! -- Live well, ~wren ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Three Google Summer of Code project proposals
Hi, I'd like to advertise three Google Summer of Code projects that I recently added to the list [1] of proposed projects: *** Build multiple Cabal packages in parallel *** http://hackage.haskell.org/trac/summer-of-code/ticket/1594 Many developers have multi-core machines but Cabal runs the build process in a single thread, only making use of one core. If the build process could be parallelized build times could be cut by perhaps a factor of 2-8, depending on the number of cores and opportunity of parallel execution available. *** Simpler support for isolated/sandboxed Cabal builds *** http://hackage.haskell.org/trac/summer-of-code/ticket/1590 cabal-dev and capri allow developers to build packages in their own sandboxes, using a separate package database for each. This allows for isolated builds and prevents breakages due e.g. package upgrades. Merging cabal-dev into Cabal allows us to share lots of code and makes the feature more accessible to developers. *** Convert the text package to use UTF-8 internally *** http://hackage.haskell.org/trac/summer-of-code/ticket/1595 When the text package was created, early benchmarks showed that using UTF-16 as the internal representation for Unicode code points was the fastest. The package still uses UTF-16 internally. The benchmarks might not have given a complete picture of the performance implications of using different internal encodings: all benchmarks were run on input data that used the same encoding as used internally, but most real world data uses UTF-8. If the benchmarks would also have taken the cost of decoding and encoding from and to UTF-8 the results might have been different. The goal of this project is to revisit the choice of internal encoding. I encourage any interested students to have a look at the three proposals (and the other proposals on the list), discuss them on this list, and sign up for GSoC (after March 28). 1. http://hackage.haskell.org/trac/summer-of-code/report/1 Cheers, Johan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
