No its fine for now but I may drop them myself later.
Cheers,
David
On 18 October 2011 15:34, Erik de Castro Lopo wrote:
> David Terei wrote:
>
>> Looks good. Why did you keep the Show instances at all? You say for
>> debugging, where is the debugging being done?
>
> The show instances were usef
David Terei wrote:
> Looks good. Why did you keep the Show instances at all? You say for
> debugging, where is the debugging being done?
The show instances were useful for the DDC backend. I haven't used
them in any of my GHC work.
Would you like me to rejig the patch to drop them?
Cheers,
Erik
Looks good. Why did you keep the Show instances at all? You say for
debugging, where is the debugging being done?
On 16 October 2011 01:57, Erik de Castro Lopo wrote:
> David Terei wrote:
>
>> Hmmm I wasn't expecting a huge speedup but was hoping for a few
>> percentage points at least. Can you f
David Terei wrote:
> Hmmm I wasn't expecting a huge speedup but was hoping for a few
> percentage points at least. Can you fork GHC on github and put your
> patch up on there and then send me a link please? This is just a far
> easier workflow for me to review and merge patches than email.
As req
On 14 October 2011 16:33, Erik de Castro Lopo wrote:
> David Terei wrote:
>
>> Can you fork GHC on github and put your
>> patch up on there and then send me a link please? This is just a far
>> easier workflow for me to review and merge patches than email.
>
> Sure, will do.
>
>> Hmmm I wasn't exp
David Terei wrote:
> Can you fork GHC on github and put your
> patch up on there and then send me a link please? This is just a far
> easier workflow for me to review and merge patches than email.
Sure, will do.
> Hmmm I wasn't expecting a huge speedup but was hoping for a few
> percentage point
Hmmm I wasn't expecting a huge speedup but was hoping for a few
percentage points at least. Can you fork GHC on github and put your
patch up on there and then send me a link please? This is just a far
easier workflow for me to review and merge patches than email.
Cheers,
David
On 13 October 2011
You can also use the fibon benchmarks to measure compilation time
(https://github.com/dmpots/fibon). It will only collect per-benchmark compile
times unlike nofib so it would probably be useful as a performance measurement,
but not a way to pinpoint inefficiencies.
Since you are only interested
On 04/10/2011 18:04, David Terei wrote:
On 4 October 2011 06:09, Erik de Castro Lopo wrote:
Ah, thats an idea. I should try to force the stage1 and stage2 compiler
to go via LLVM and then see how the time is:
- via NCG
- via LLVM before my changes
- via LLVM after my changes
Yes that
On 4 October 2011 06:09, Erik de Castro Lopo wrote:
> Ah, thats an idea. I should try to force the stage1 and stage2 compiler
> to go via LLVM and then see how the time is:
>
> - via NCG
> - via LLVM before my changes
> - via LLVM after my changes
>
Yes that will work and be a large scale test
Karel Gardas wrote:
> > Does anyone have a suggestion as an appropriate test for this?
>
> If you are successful in your hacking, then GHC bootstrap on ARM should
> be faster. I'm not able to give you a login on my pandaboard dedicated
> to ARM/GHC hacking, but in about two weeks my board shoul
On 10/ 4/11 02:53 PM, Erik de Castro Lopo wrote:
I'm working on some changes (suggested by David Terei) to the LLVM
backend that I hope will improve compile times when going via LLVM.
Something like that is more than welcome on slow hosts which are using
LLVM -- i.e. GHC/ARM combination comes
Hi all,
I'm working on some changes (suggested by David Terei) to the LLVM
backend that I hope will improve compile times when going via LLVM.
Does anyone have a suggestion as an appropriate test for this?
Cheers,
Erik
--
--
Er
13 matches
Mail list logo
