On 23/05/12 21:11, Ryan Newton wrote:
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 files.) His work might benef
>
> 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, mmap still offered bette
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 whole-packa
On 26/04/2012 23:32, Johan Tibell wrote:
On Thu, Apr 26, 2012 at 2:34 PM, Mikhail Glushenkov
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
On Thu, Apr 26, 2012 at 2:34 PM, Mikhail Glushenkov
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.
-- Johan
Hello Simon,
On Wed, Apr 25, 2012 at 9:57 AM, Simon Marlow 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 loading by
>
> 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 sing
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 Marlow wrote:
Questions:
Would implementing this optimisation be a worthwhile/realistic GSoC
project?
What are other potential wa
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 Marlow wrote:
Questions:
Would implementing this optimisation be a worthwhile/realistic GSoC
project?
What are other potential ways to bring 'ghc -c' performance up to pa
> 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
> c
Hello Simon,
Sorry for the delay.
On Tue, Apr 10, 2012 at 1:03 PM, Simon Marlow 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 gue
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 paralle
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
> 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 t
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 sig
15 matches
Mail list logo
