| Simon: there aren't really any patterns to combine in the test case,
| so I assume the reordering happens when "combining" a single
| pattern? Fill the fix you envisioned also cover the IsString variant?
yes it will.
S
___
Glasgow-haskell-users mailin
Ticket is http://hackage.haskell.org/trac/ghc/ticket/3126 .
Sorting by constructor tag is perfectly safe when done right.
You can read about how to do it in my 1985 FPCA paper or in Simon's book.
I did, long ago. I learned functional programming by implementing a
small functional language, us
Claus Reinke wrote:
You are right that this doesn't help my performance argument,
as performance issues are outside the language definition (not
observable in the language definition sense). It was merely an answer to
the vehement claims that pattern order is irrelevant.
The order of branches
Lennart Augustsson wrote:
Sorting by constructor tag is perfectly safe when done right.
You can read about how to do it in my 1985 FPCA paper or in Simon's book.
When pattern matching against against things that that are not
constructors (like literals etc) it's much trickier to reorder them
sin
| It would be nice if we could first reach a common understanding, so
| that I can actually report the right problem, not just isolated symptoms.
It's quite simple. The Reports specifies the semantics, not the operational
behaviour. Any implementation that behaves as the Report specifies is OK.
Sorting by constructor tag is perfectly safe when done right.
You can read about how to do it in my 1985 FPCA paper or in Simon's book.
When pattern matching against against things that that are not
constructors (like literals etc) it's much trickier to reorder them
since you have to prove harder
So a first comment on this. I spoke too soon, ghc clearly has a bug here.
It shouldn't reorder those matches against literals like that.
I suggest you report that bug, because, as you say, it violates the H98 report.
It would be nice if we could first reach a common understanding, so
that I can
So a first comment on this. I spoke too soon, ghc clearly has a bug here.
It shouldn't reorder those matches against literals like that.
I suggest you report that bug, because, as you say, it violates the H98 report.
But I don't think that bug at all affects the function you had in your
original
Sorry to be the odd man out - perhaps an example will help to
clarify my reading of the language definition.
I find this "reordering" discussion somewhat nonsensical.
Haskell specifies top-to-botton, left-to-right matching.
This specifies exactly which tests that have to be made and in what orde
Lennart Augustsson wrote:
I find this "reordering" discussion somewhat nonsensical.
Haskell specifies top-to-botton, left-to-right matching.
This specifies exactly which tests that have to be made and in what order,
and ghc does exactly those and in the correct order.
One can have a perception t
I find this "reordering" discussion somewhat nonsensical.
Haskell specifies top-to-botton, left-to-right matching.
This specifies exactly which tests that have to be made and in what order,
and ghc does exactly those and in the correct order.
One can have a perception that when there are multiple
Claus Reinke wrote:
Strange. I don't think it is my idea (older implementations
used to work that way, and iirc, it also matches what Prolog
systems used to do), and I didn't think it was anything but
straightforward to avoid case transformations unless there
is a clear benefit, so I doubt the
Lennart Augustsson wrote:
When you tried switching Nil and Cons, did you try it on many examples?
For a single example a 2-3% could be easily attributed to random
effects like different instruction cache hit patterns. If you get it
consistently over several programs then it seems likely to mean
On Wed, 2009-03-25 at 18:01 +, Claus Reinke wrote:
> With the hint about branch prediction, I also found this old ticket
> (which seems to have been waiting for the new backend, and
> indicates rather larger performance differences):
>
> Offer control over branch prediction
> http:/
On March 25, 2009 21:38:55 Claus Reinke wrote:
> If you don't have that kind of control, and generate code as if
> there were no hardware-level optimizations, the resulting
> mismatch will manifest in hard-to-predict variations in
> performance, making it difficult to see how much or why
> speed is
On Wed, 2009-03-25 at 09:18 +, Simon Peyton-Jones wrote:
> * More promising might be to say "this is the hot branch". That information
> about frequency could in principle be used by the back end to generate better
> code. However, I am unsure how
> a) to express this info in sourc
I don't find ordering of patterns appealing, I find it scary! I order
my patterns according to the semantics I desire, and then additionally
by what looks pretty. I'd like it if whatever cleverness GHC can work
is used rather than requiring me to think. If the order of patterns is
to become import
| very long list than the Cons-before-Nil order I wanted), but it is
| very frustrating if I'm not even given the chance because GHC
| sorts the alternatives, not even according to its own interpretation
| of branching performance, but completely arbitrarily!-)
All I'm saying is that GHC has neve
When you tried switching Nil and Cons, did you try it on many examples?
For a single example a 2-3% could be easily attributed to random
effects like different instruction cache hit patterns. If you get it
consistently over several programs then it seems likely to mean
something, but I'm not sure
On Mar 25, 2009, at 5:18 AM, Simon Peyton-Jones wrote:
Indeed GHC does not attempt to retain the order of alternatives,
although
a) it might be possible to do so by paying more attention in
numerous places
b) GHC may do so already, by accident, in certain cases
...
* Which plan performs be
Hi
> Your idea of simply ordering patterns is certainly appealing from the
> programming point of view. I don't yet see how to propagate that information
> through the pattern compilation algorithm, retain the resulting information
> in the optimizer, and exploit it in a code generator. But i
| >Indeed GHC does not attempt to retain the order of alternatives, although
| >a) it might be possible to do so by paying more attention in numerous places
| >b) GHC may do so already, by accident, in certain cases
|
| That adds even more unpredictability.
| very long list than the Cons-befor
When you tried switching Nil and Cons, did you try it on many examples?
For a single example a 2-3% could be easily attributed to random
effects like different instruction cache hit patterns. If you get it
consistently over several programs then it seems likely to mean
something, but I'm not sure
Indeed GHC does not attempt to retain the order of alternatives, although
a) it might be possible to do so by paying more attention in numerous places
b) GHC may do so already, by accident, in certain cases
That adds even more unpredictability. One thing that I don't want
whenever I have to car
Message-
| From: glasgow-haskell-users-boun...@haskell.org [mailto:glasgow-haskell-users-
| boun...@haskell.org] On Behalf Of Claus Reinke
| Sent: 23 March 2009 23:17
| To: glasgow-haskell-users@haskell.org
| Subject: compilation of pattern-matching?
|
| I just noticed that GHC (6.11.20090320
| You could imagine a pragma to say which branch is likely.
| f p1 = e1
| f p2 = {-# LIKELY #-} e2
| f p3 = e3
|
| Is there some way to propagate pragmas through core transformations?
Not robustly. We do have "Notes" attached to core, which are more or less
propagated though, but I make not prom
a
> Commentary page, and I'll check its veracity.
>
> Thanks
>
> Simon
>
>
> | -Original Message-
> | From: glasgow-haskell-users-boun...@haskell.org
> [mailto:glasgow-haskell-users-
> | boun...@haskell.org] On Behalf Of Claus Reinke
> | Sent: 23 March 2009 23:1
ll.org [mailto:glasgow-haskell-users-
| boun...@haskell.org] On Behalf Of Claus Reinke
| Sent: 23 March 2009 23:17
| To: glasgow-haskell-users@haskell.org
| Subject: compilation of pattern-matching?
|
| I just noticed that GHC (6.11.20090320) seems to compile both
|
| f (a:b:c) =
| f (a:[]) =
| f []
The only way to see the impact of very low level things like which way
branches go is to generate assembly code and the make simple
controlled changes of that.
But even doing that is very dodgy since you are subject to the whims
of cache misses etc.
As far as branching goes, conditional branches t
[commented cmm and asm elided - thanks, though! Some examples
like this would be helpful in the commentary (or are they there and
I've not yet seen them?)]
|I guess this is a long winded way of saying that the branches are being
|ordered such that the fall though case is not the one that you put
2009/3/23 Claus Reinke :
> I just noticed that GHC (6.11.20090320) seems to compile both
>
> f (a:b:c) =
> f (a:[]) = f [] =
> and
> f [] = f (a:[]) = f (a:b:c) =
>
> to something like (looking at Core, but writing source)
>
> f x = case x of { [] -> ..; (a:t) -> case t of { [] ->..; (b:c) ->..}}
On March 23, 2009 19:46:27 Claus Reinke wrote:
> My idea was that case branches correspond to conditional jumps
> (though the exact correspondence and optimization has been the
> subject of countless papers). If I loop through a very long list,
> most of the time the test for (:) will succeed, requ
How could you match the first case with less than two case constructs?
There are two (:) to check for, so I'm not sure what you are complaining about.
-- Lennart
The number of case constructs is needed, and since case in Core
also specifies strict contexts, perhaps there would be no difference
How could you match the first case with less than two case constructs?
There are two (:) to check for, so I'm not sure what you are complaining about.
-- Lennart
On Tue, Mar 24, 2009 at 12:16 AM, Claus Reinke wrote:
> I just noticed that GHC (6.11.20090320) seems to compile both
>
> f (a:b:c)
I just noticed that GHC (6.11.20090320) seems to compile both
f (a:b:c) =
f (a:[]) =
f [] =
and
f [] =
f (a:[]) =
f (a:b:c) =
to something like (looking at Core, but writing source)
f x = case x of { [] -> ..; (a:t) -> case t of { [] ->..; (b:c) ->..}}
That doesn't seem right to me: if
35 matches
Mail list logo
