On 23/05/12 21:11, Ryan Newton wrote:
the.dead.shall.r...@gmail.com
mailto:the.dead.shall.r...@gmail.com wrote:
Thanks. I'll look into how to optimise .hi loading by more
traditional
means, then.
Lennart is working on speeding up the binary package (which I
believe is used to decode the .hi
the.dead.shall.r...@gmail.com wrote:
Thanks. I'll look into how to optimise .hi loading by more traditional
means, then.
Lennart is working on speeding up the binary package (which I believe
is used to decode the .hi files.) His work might benefit this effort.
Last time I tested it,
Mikhail's original question was about loading interface files for entire
packages with mmap.
As a wild thought experiment, if GHC had a saved-heaps capability, I
believe that would avoid the Unique issues with mmap'ing individual data
structures that Simon mentioned. How about if each
On 26/04/2012 23:32, Johan Tibell wrote:
On Thu, Apr 26, 2012 at 2:34 PM, Mikhail Glushenkov
the.dead.shall.r...@gmail.com wrote:
Thanks. I'll look into how to optimise .hi loading by more traditional
means, then.
Lennart is working on speeding up the binary package (which I believe
is used
Hello Simon,
On Wed, Apr 25, 2012 at 9:57 AM, Simon Marlow marlo...@gmail.com wrote:
Is this a good idea? How hard it would be to implement this optimisation?
[...] Personally I think it's at
best very ambitious, and at worst not at all practical.
Thanks. I'll look into how to optimise .hi
On Thu, Apr 26, 2012 at 2:34 PM, Mikhail Glushenkov
the.dead.shall.r...@gmail.com wrote:
Thanks. I'll look into how to optimise .hi loading by more traditional
means, then.
Lennart is working on speeding up the binary package (which I believe
is used to decode the .hi files.) His work might
On 25/04/2012 03:17, Mikhail Glushenkov wrote:
Hello Simon,
Sorry for the delay.
On Tue, Apr 10, 2012 at 1:03 PM, Simon Marlowmarlo...@gmail.com wrote:
Questions:
Would implementing this optimisation be a worthwhile/realistic GSoC
project?
What are other potential ways to bring 'ghc -c'
On 25/04/2012 08:57, Simon Marlow wrote:
On 25/04/2012 03:17, Mikhail Glushenkov wrote:
Hello Simon,
Sorry for the delay.
On Tue, Apr 10, 2012 at 1:03 PM, Simon Marlowmarlo...@gmail.com wrote:
Questions:
Would implementing this optimisation be a worthwhile/realistic GSoC
project?
What are
The idea that I currently like the most is to make it possible to save
and load objects in the GHC heap format. That way, deserialisation
could be done with a simple fread() and a fast pointer fixup pass,
which would hopefully make running many 'ghc -c' processes as fast as
a single 'ghc
Hello Simon,
Sorry for the delay.
On Tue, Apr 10, 2012 at 1:03 PM, Simon Marlow marlo...@gmail.com wrote:
Questions:
Would implementing this optimisation be a worthwhile/realistic GSoC
project?
What are other potential ways to bring 'ghc -c' performance up to par
with 'ghc --make'?
My
Thank you for the answer.
I'll be working on another project during the summer, but I'm still
interested in making interface files load faster.
The idea that I currently like the most is to make it possible to save
and load objects in the GHC heap format. That way, deserialisation
could be
On 02/04/2012 07:37, Mikhail Glushenkov wrote:
Hi all,
[Hoping it's not too late.]
During my work on parallelising 'ghc --make' [1] I encountered a
stumbling block: running 'ghc --make' can be often much faster than
using separate compile ('ghc -c') and link stages, which means that
any
Hi all,
[Hoping it's not too late.]
During my work on parallelising 'ghc --make' [1] I encountered a
stumbling block: running 'ghc --make' can be often much faster than
using separate compile ('ghc -c') and link stages, which means that
any parallel build tool built on top of 'ghc -c' will be
Questions:
Would implementing this optimisation be a worthwhile/realistic GSoC project?
What are other potential ways to bring 'ghc -c' performance up to par
with 'ghc --make'?
I implemented a ghc server that runs several persistent ghcs, and
distributes compiles among them. It seemed to
I for one think this would make a good GSoC project. Make sure you get
your application in in time though.
-- Johan
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
15 matches
Mail list logo
