RE: Optimisation of unpackCString#

2008-04-30 Thread Simon Peyton-Jones
| One of my ideas was some RULES that expand: | | test x | neil `isPrefixOf` x = ... | | ned `isPrefixOf` x = ... You might want to be careful about this, because you could really get a *lot* of code this way. | Simon: I will email you in a couple of weeks to discuss it. Great,

RE: Optimisation of unpackCString#

2008-04-29 Thread Simon Peyton-Jones
| I could imagine adding two rules to the simplifier: | | case unpackCString# of == case [] of | case unpackCString# xyz of == case (C# 'x': unpackCString# yz) of ... | This goes back to an old gripe of mine actually -- we can't get | at the length of a C string literal at compile time either,

Re: Optimisation of unpackCString#

2008-04-29 Thread Neil Mitchell
Hi what is general purpose stuff. I don't think there is anything wrong with magic for primitive types, but if there is a useful general-purpose mechanism trying to get out, let's liberate it. I think the tension comes from representing String's as CString's, not actual lists of Char and

Re: Optimisation of unpackCString#

2008-04-29 Thread Neil Mitchell
Hi PROPOSAL 1: Add the following rules to the simplifier: case unpackCString# of == case [] of case unpackCString# xyz of == case (C# 'x': unpackCString# yz) of I've been wanting to have a go at hacking GHC for a while, and this seems like a good candidate to start with. If there is no

Re: Optimisation of unpackCString#

2008-04-29 Thread Don Stewart
ndmitchell: Hi what is general purpose stuff. I don't think there is anything wrong with magic for primitive types, but if there is a useful general-purpose mechanism trying to get out, let's liberate it. I think the tension comes from representing String's as CString's, not

RE: Optimisation of unpackCString#

2008-04-29 Thread Simon Peyton-Jones
| PROPOSAL 1: Add the following rules to the simplifier: | |case unpackCString# of == case [] of |case unpackCString# xyz of == case (C# 'x': unpackCString# yz) of | | I've been wanting to have a go at hacking GHC for a while, and this | seems like a good candidate to start with. If

Re: Optimisation of unpackCString#

2008-04-29 Thread Neil Mitchell
Hi Cons: Makes the simplifier slightly more complex - but I hope not by much! And it doesn't work for my case -- I'd really want length as a compile time constant. Could you elaborate on what kind of rules you think we could write with the ability to get the head? One of my ideas was

Re: Optimisation of unpackCString#

2008-04-29 Thread Don Stewart
ndmitchell: Hi Cons: Makes the simplifier slightly more complex - but I hope not by much! And it doesn't work for my case -- I'd really want length as a compile time constant. Could you elaborate on what kind of rules you think we could write with the ability to get the

Re: Optimisation of unpackCString#

2008-04-29 Thread Johan Tibell
On Tue, Apr 29, 2008 at 8:44 PM, Don Stewart [EMAIL PROTECTED] wrote: ndmitchell: That requires Proposal 2, so needs to have an API defined -- including length# and some others. Out of curiosity, how much performance boost would this give in ByteString? It matters for programs with

Re: Optimisation of unpackCString#

2008-04-29 Thread Ian Lynagh
On Mon, Apr 28, 2008 at 02:00:38PM -0700, Donald Bruce Stewart wrote: This goes back to an old gripe of mine actually -- we can't get at the length of a C string literal at compile time either, which would be super useful in rules. I think that this is easy to do by, instead of desugaring

Re: Optimisation of unpackCString#

2008-04-29 Thread Don Stewart
igloo: On Mon, Apr 28, 2008 at 02:00:38PM -0700, Donald Bruce Stewart wrote: This goes back to an old gripe of mine actually -- we can't get at the length of a C string literal at compile time either, which would be super useful in rules. I think that this is easy to do by, instead of

Optimisation of unpackCString#

2008-04-28 Thread Neil Mitchell
Hi (All these results are from GHC 6.9.20071226, but suspect they hold for 6.9.* and 6.8) The following code: test = head neil Produces (with -O2): Text.HTML.TagSoup.Development.Sample.test = case GHC.Base.unpackCString# neil of wild_aaU { [] - GHC.List.badHead @ GHC.Base.Char; : x_aaY

Re: Optimisation of unpackCString#

2008-04-28 Thread Don Stewart
ndmitchell: Hi (All these results are from GHC 6.9.20071226, but suspect they hold for 6.9.* and 6.8) The following code: test = head neil Produces (with -O2): Text.HTML.TagSoup.Development.Sample.test = case GHC.Base.unpackCString# neil of wild_aaU { [] - GHC.List.badHead

Re: Optimisation of unpackCString#

2008-04-28 Thread Don Stewart
dons: ndmitchell: Hi (All these results are from GHC 6.9.20071226, but suspect they hold for 6.9.* and 6.8) The following code: test = head neil Produces (with -O2): Text.HTML.TagSoup.Development.Sample.test = case GHC.Base.unpackCString# neil of wild_aaU {

Re: Optimisation of unpackCString#

2008-04-28 Thread Neil Mitchell
Hi The first case makes sense, and is just a RULE. Though it seems GHC already does this? g = head goes to: M.g = badHead @ Char without prompting. Nope, as far as I can tell gets translated to [], not unpackCString# - hence the unpack never gets in the way. If you had

Re: Optimisation of unpackCString#

2008-04-28 Thread Don Stewart
ndmitchell: Hi The first case makes sense, and is just a RULE. Though it seems GHC already does this? g = head goes to: M.g = badHead @ Char without prompting. Nope, as far as I can tell gets translated to [], not unpackCString# - hence the unpack never

Re: Optimisation of unpackCString#

2008-04-28 Thread Neil Mitchell
Hi This goes back to an old gripe of mine actually -- we can't get at the length of a C string literal at compile time either, which would be super useful in rules. I was about to complain about this next, as soon as I got the previous part working :-) If we had some light primitives for

Re: Optimisation of unpackCString#

2008-04-28 Thread Neil Mitchell
Hi That would work on GHC, but not on Hugs. Optimisation and Hugs don't go together anyway. I want the code to work on Hugs, and perform fast on GHC. As it turns out, for this particular application, Hugs is faster than GHCi by about 25%. Thanks Neil

Re: Optimisation of unpackCString#

2008-04-28 Thread Don Stewart
ndmitchell: Hi That would work on GHC, but not on Hugs. Optimisation and Hugs don't go together anyway. I want the code to work on Hugs, and perform fast on GHC. As it turns out, for this particular application, Hugs is faster than GHCi by about 25%. Optimisation and ghci don't

Re: Optimisation of unpackCString#

2008-04-28 Thread Neil Mitchell
Hi Optimisation and ghci don't go together, so I don't know what your point is there. It's very worth having the application work in both Hugs and GHCi, and its not always GHC=faster, only if you compile it - so you trade your compile time for your run time. A delicate balance, with more than

Re: Optimisation of unpackCString#

2008-04-28 Thread Don Stewart
ndmitchell: Hi Optimisation and ghci don't go together, so I don't know what your point is there. It's very worth having the application work in both Hugs and GHCi, and its not always GHC=faster, only if you compile it - so you trade your compile time for your run time. A delicate

Re: Optimisation of unpackCString#

2008-04-28 Thread Neil Mitchell
Hi You'd have to conditionally use overloaded strings in GHC only. I'm not sure it would work ( can you quantify the cost of not being able to take head at compile time? ) The cost of not having this is probably ~10x slower for the tagsoup library :-( - i.e. pretty huge. I'm looking at