My understanding was that the reason is that CSE can cause things to be
shared that take up a lot of space when normally they would be garbage
collected sooner.
On Feb 18, 2012 11:57 AM, Roman Cheplyaka r...@ro-che.info wrote:
It doesn't matter. Laziness would be affected if, for instance,
Different kinds of optimization. I expect you'd have different results even if
you use one type, but different -O flags.
On 18 Feb 2012, at 13:28, Heinrich Hördegen wrote:
Dear all,
I have a question about evaluation with respect to types and currying.
Consider this programm:
import
Hi,
this is true. The optimization only works with -O2. I'd like to have
more details about what's going on. How can I make sure, that this
optimization triggers?
Heinrich
On 18.02.2012 11:10, MigMit wrote:
Different kinds of optimization. I expect you'd have different results even if
Am 18.02.2012 um 11:56 schrieb Heinrich Hördegen:
Hi,
this is true. The optimization only works with -O2. I'd like to have more
details about what's going on. How can I make sure, that this optimization
triggers?
You cannot. Common subexpression elimination is done by GHC very
+ on Int is extremely cheap. It is always faster to add again rather
than store the value.
But Integer is a different story. Addition time on this type can grow to
several minutes.
18.02.2012 13:28, Heinrich Hördegen пишет:
Dear all,
I have a question about evaluation with respect to types
In case of +, the reason might be that it's cheap, but the function add
could do something else than + (It was just a small example).
Ok, thank you for your useful comments. I will read about cse.
Heinrich
On 18.02.2012 13:42, Victor Gorokgov wrote:
+ on Int is extremely cheap. It is always
* Holger Siegel holgersiege...@yahoo.de [2012-02-18 12:52:08+0100]
You cannot. Common subexpression elimination is done by GHC very
conservatively, because it can not only affect impure programs: it can
also affects strictness/lazyness and worsen memory usage of pure code.
Like the HaskellWiki
Am 18.02.2012 um 14:38 schrieb Roman Cheplyaka:
* Holger Siegel holgersiege...@yahoo.de [2012-02-18 12:52:08+0100]
You cannot. Common subexpression elimination is done by GHC very
conservatively, because it can not only affect impure programs: it can
also affects strictness/lazyness
example = a + b + a + b
exampleCSE = x + x
where x = a + b
With CSE we are introducing new thunk: x.
18.02.2012 17:38, Roman Cheplyaka пишет:
* Holger Siegelholgersiege...@yahoo.de [2012-02-18 12:52:08+0100]
You cannot. Common subexpression elimination is done by GHC very
conservatively,
I'm not sure you can. Why do you need it?
Отправлено с iPad
18.02.2012, в 14:56, Heinrich Hördegen hoerde...@funktional.info написал(а):
Hi,
this is true. The optimization only works with -O2. I'd like to have more
details about what's going on. How can I make sure, that this optimization
It doesn't matter. Laziness would be affected if, for instance,
something is not evaluated without CSE and is evaluated with it.
In your example either all or none of 'a' and 'b' get evaluated,
depending on whether the top-level expression is evaluated.
* Victor Gorokgov m...@rkit.pp.ru
11 matches
Mail list logo
