Hi
I've talked to John a bit, and discussed test cases etc. I've tracked
this down a little way.
Given the attached file, compiling witih SHORT_EXPORT_LIST makes the
code go _slower_. By exporting the print_lines function the code
doubles in speed. This runs against everything I was expecting,
PROTECTED]
| Sent: 28 November 2008 09:48
| To: Simon Peyton-Jones
| Cc: John Lato; glasgow-haskell-users@haskell.org; Don Stewart
| Subject: Re: cross module optimization issues
|
| Hi
|
| I've talked to John a bit, and discussed test cases etc. I've tracked
| this down a little way
| To: Simon Peyton-Jones
| Cc: Neil Mitchell; glasgow-haskell-users@haskell.org; Don Stewart
| Subject: Re: cross module optimization issues
|
| Neil, thank you very much for taking the time to look at this; I
| greatly appreciate it.
|
| One thing I don't understand is why the specializations
On 28/11/2008, at 15:46, Simon Peyton-Jones wrote:
The $f2 comes from the instance Monad (IterateeGM ...).
print_lines uses a specialised version of that instance, namely
Monad (IterateeGM el IO)
The fact that print_lines uses it makes GHC generate a specialised
version of the
Yes, this does help, thank you. I didn't know you could generate
specialized instances. In fact, I was so sure that this was some
arcane feature I immediately went to the GHC User Guide because I
didn't believe it was documented.
I immediately stumbled upon Section 8.13.9.
Thanks to everyone
Hi
instance Monad m = Monad (IterateeGM el m) where
{-# SPECIALISE instance Monad (IterateeGM el IO) #-}
does that help?
Yes. With that specialise line in, we get identical performance
between the two results.
So, in summary:
The print_lines function uses the IterateeGM with IO as the
On Sat, Nov 22, 2008 at 6:55 PM, Don Stewart [EMAIL PROTECTED] wrote:
jwlato:
Is this , since it is in IO code, a -fno-state-hack scenario?
Simon wrote recently about when and why -fno-state-hack would be
needed, if you want to follow that up.
-- Don
Unfortunately, -fno-state-hack
jwlato:
On Wed, Nov 19, 2008 at 4:17 PM, Simon Peyton-Jones
[EMAIL PROTECTED] wrote:
| I'm compiling with -O2 -Wall. After looking at the Core output, I
| think I've found the key difference. A function that is bound in a
| where statement is different between the monolithic and split
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf
Of Simon Peyton-Jones
Sent: 21 November 2008 10:34 am
To: John Lato
Cc: glasgow-haskell-users@haskell.org; Don Stewart
Subject: RE: cross module optimization issues
| This project is based on Oleg's Iteratee
| This project is based on Oleg's Iteratee code; I started using his
| IterateeM.hs and Enumerator.hs files and added my own stuff to
| Enumerator.hs (thanks Oleg, great work as always). When I started
| cleaning up by moving my functions from Enumerator.hs to MyEnum.hs, my
| minimal test case
| I'm compiling with -O2 -Wall. After looking at the Core output, I
| think I've found the key difference. A function that is bound in a
| where statement is different between the monolithic and split
| sources. I have no idea why, though. I'll experiment with a few
| different things to see
On Sat, Nov 15, 2008 at 10:09 PM, Don Stewart [EMAIL PROTECTED] wrote:
jwlato:
Hello,
I have a problem with a package I'm working on, and I don't have any
idea how to sort out the current problem.
One part of my package is in one monolithic module, without an export
list, which works fine.
Hello,
I have a problem with a package I'm working on, and I don't have any
idea how to sort out the current problem.
One part of my package is in one monolithic module, without an export
list, which works fine. However, when I've started to separate out
certain functions into another module,
jwlato:
Hello,
I have a problem with a package I'm working on, and I don't have any
idea how to sort out the current problem.
One part of my package is in one monolithic module, without an export
list, which works fine. However, when I've started to separate out
certain functions into
14 matches
Mail list logo
