Hi D.R Plotkin,
There are some nice mailing lists in haskell.org, include HUGS
--- On Sat, 2/21/09, haskell-cafe-request@haskell.org <haskell-cafe-request@haskell.org> wrote:
From: haskell-cafe-request@haskell.org <haskell-cafe-request@haskell.org>
Subject: Haskell-Cafe Digest, Vol 66, Issue 71
To: haskell-cafe@haskell.org
Date: Saturday, February 21, 2009, 7:01 PM
Send Haskell-Cafe mailing list submissions to
haskell-cafe@haskell.org
To subscribe or unsubscribe via the World Wide Web, visit
http://www.haskell.org/mailman/listinfo/haskell-cafe
or, via email, send a message with subject or body 'help' to
haskell-cafe-request@haskell.org
You can reach the person managing the list at
haskell-cafe-owner@haskell.org
When replying, please edit your Subject line so it is more specific
than "Re: Contents of Haskell-Cafe digest..."
Today's Topics:
1. controlling timeout for Network.Socket.connect - how? (Belka)
2. Stacking StateTs (Luis O'Shea)
3. Haskellers on Twitter! (Daniel Peebles)
4. Fwd: Re: [Haskell-cafe] speed: ghc vs gcc (Khudyakov Alexey)
5. Re: Fwd: Re: [Haskell-cafe] speed: ghc vs gcc (Bulat Ziganshin)
6. Re[3]: [Haskell-cafe] Re: speed: ghc vs gcc (Bulat Ziganshin)
7. Re: Re[3]: [Haskell-cafe] Re: speed: ghc vs gcc (Louis Wasserman)
8. Re: Re: speed: ghc vs gcc (Daniel Fischer)
9. Re[5]: [Haskell-cafe] Re: speed: ghc vs gcc (Bulat Ziganshin)
10. Re: Stacking StateTs (David Menendez)
11. Re[2]: [Haskell-cafe] Re: speed: ghc vs gcc (Bulat Ziganshin)
12. Re: Re[5]: [Haskell-cafe] Re: speed: ghc vs gcc (Louis Wasserman)
13. Re: Re[5]: [Haskell-cafe] Re: speed: ghc vs gcc (Sebastian Sylvan)
14. Re: Help using catch in 6.10 (John Meacham)
15. Re: Re[5]: [Haskell-cafe] Re: speed: ghc vs gcc (Louis Wasserman)
16. The community is more important than the product (Don Stewart)
17. Re: Re[5]: [Haskell-cafe] Re: speed: ghc vs gcc (Sebastian Sylvan)
18. Re: Re: speed: ghc vs gcc (Daniel Fischer)
19. Re[7]: [Haskell-cafe] Re: speed: ghc vs gcc (Bulat Ziganshin)
20. Template Haskell compilation error on Windows (was Re: speed:
ghc vs gcc) (Peter Verswyvelen)
----------------------------------------------------------------------
Message: 1
Date: Sat, 21 Feb 2009 11:26:51 -0800 (PST)
From: Belka <lambda-belka@yandex.ru>
Subject: [Haskell-cafe] controlling timeout for Network.Socket.connect
- how?
To: haskell-cafe@haskell.org
Message-ID: <22139581.post@talk.nabble.com>
Content-Type: text/plain; charset=us-ascii
Hello, communion people!
I have a problem and ask for an advice.
I'm dealing with sockets on *Linux* platform (Network.Socket). The problem
is that I can't fully control timeout for (connect :: Socket -> SockAddr
->
IO ()) operation.
On my system the timeout is - 3 seconds - I want to be able to change that
in run-time. Well I managed to find out how to make it LESS THAN 3 seconds -
using System.Timeout. But how to make timeout bigger (for example 9 seconds)
is a mystery.
(Notice: in order to achieve 9 seconds timeout - just repeating *connect* 3
times won't be effective for long-slow-way-connections. So it's not a
solution.)
The source code of Network.Socket.connect, taken from darcs:
---------------------------------
-- Connecting a socket
--
-- Make a connection to an already opened socket on a given machine
-- and port. assumes that we have already called createSocket,
-- otherwise it will fail.
--
-- This is the dual to $bindSocket$. The {\em server} process will
-- usually bind to a port number, the {\em client} will then connect
-- to the same port number. Port numbers of user applications are
-- normally agreed in advance, otherwise we must rely on some meta
-- protocol for telling the other side what port number we have been
-- allocated.
connect :: Socket -- Unconnected Socket
-> SockAddr -- Socket address stuff
-> IO ()
connect sock@(MkSocket s _family _stype _protocol socketStatus) addr = do
modifyMVar_ socketStatus $ \currentStatus -> do
if currentStatus /= NotConnected
then
ioError (userError ("connect: can't peform connect on socket in
status "
++
show currentStatus))
else do
withSockAddr addr $ \p_addr sz -> do
let connectLoop = do
r <- c_connect s p_addr (fromIntegral sz)
if r == -1
then do
rc <- c_getLastError
case rc of
10093 -> do -- WSANOTINITIALISED
withSocketsDo (return ())
r <- c_connect s p_addr (fromIntegral sz)
if r == -1
then (c_getLastError >>= throwSocketError "connect")
else return r
_ -> throwSocketError "connect" rc
else return r
connectBlocked = do
#if !defined(__HUGS__)
threadWaitWrite (fromIntegral s)
#endif
err <- getSocketOption sock SoError
if (err == 0)
then return 0
else do ioError (errnoToIOError "connect"
(Errno (fromIntegral err))
Nothing Nothing)
connectLoop
return Connected
---------------------------------
I know that controlling timeout is somehow connected to select(2) (I'm
currently investigating this matter...), but it's not in the Network or
Network.Socket libs (but in the libs that they FFI with).
Hope I won't have to rewrite these low-level functions.... >__<
Could anybody, please share some experience on how to adjust timeout for
*connect*?
Thanks in advance,
Best regards,
Belka
--
View this message in context:
http://www.nabble.com/controlling-timeout-for-Network.Socket.connect---how--tp22139581p22139581.html
Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com.
------------------------------
Message: 2
Date: Sat, 21 Feb 2009 15:33:28 -0500
From: Luis O'Shea <loshea@gmail.com>
Subject: [Haskell-cafe] Stacking StateTs
To: haskell-cafe@haskell.org
Message-ID: <3636FA2B-5BB1-47CC-B20F-85491A55E4F7@gmail.com>
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
I've been experimenting with the state monad and with StateT, and
have some questions about how to combine one state with another.
This email is literate Haskell tested on GHCi, version 6.10.1. Also,
sigfpe's post on monad transformers (http://blog.sigfpe.com/2006/05/
grok-haskell-monad-transformers.html) was very helpful.
> import Control.Monad.State
My question is basically whether the function modifyT (below) makes
sense, whether some form of it already exists in a standard library,
and (most importantly) whether it actually indicates that I'm
thinking about StateT all wrong.
> modifyT :: Monad m =>
> (s -> StateT t m s)
> -> StateT t (StateT s m) ()
> modifyT f = do
> x <- get
> y <- lift get
> (y',x') <- lift $ lift $ runStateT (f y) x
> lift $ put y'
> put x'
Some context may be useful, so here is how I ended up thinking I
needed modifyT.
The state monad makes it easy to write stateful computations. For
example here is a computation that has an Integer as its state and
returns a String:
> test1 :: State Integer String
> test1 = do
> modify (+ 1)
> a <- get
> return $ "foobar" ++ (show a)
If the computation wants to do some IO then it makes sense to start
with the IO monad and then apply the StateT transformer to it:
> test2 :: StateT Integer IO String
> test2 = do
> modify (+ 1)
> a <- get
> lift $ print a
> return $ "foobar" ++ (show a)
So from now on I won't actually do any IO and will replace IO with an
arbitrary monad m. Also instead of the fixed string "foobar"
I'll
have it take a String as a parameter:
> test3 :: Monad m => String -> StateT Integer m String
> test3 s = do
> modify (+ 1)
> a <- get
> return $ s ++ (show a)
A nice feature of all this is that it is easy to combine these
computations:
> test4 :: Monad m => StateT Integer m (String,String)
> test4 = do
> s1 <- test3 "foo"
> s2 <- test3 "bar"
> return $ (s1,s2)
Now seeing as test3 takes a String and returns another String you can
imagine using it to transform a String state. (I'm also going to
assume that test3 is in another library so we don't want to alter how
it's written.) So here is how you could use test3 in a computation
that has (String,Integer) as its state:
> test5 :: (Monad m) => m Integer
> test5 = do
> (s1,x1) <- runStateT (test3 "") 0
> (s2,x2) <- runStateT (test3 s1) (2*x1 + 1)
> (s3,x3) <- runStateT (test3 s2) (x2*x2)
> return x3
Then running test5 >>= print gives 17. The problem with test5, of
course, is that we have manually threaded the state, with all the
problems that implies. For example nothing prevents you from
erroneously misthreading the state:
> test5bad :: (Monad m) => m Integer
> test5bad = do
> (s1,x1) <- runStateT (test3 "") 0
> (s2,x2) <- runStateT (test3 s1) (2*x1 + 1)
> (s3,x3) <- runStateT (test3 s1) (x2*x1)
> return x3
Running test5bad >>= print gives 5. Obviously we want operate in a
State monad with more state. One way to do this is to stack two
StateTs on top of m. This is, finally, where I need the modifyT that
we defined above -- it lets us "lift" test3 to a function that
modifies the state of the top *two* StateTs. Now let's use it to
rewrite test5:
> test6 :: (Monad m) => StateT Integer (StateT String m) Integer
> test6 = do
> modifyT test3
> modify $ \x -> 2*x + 1
> modifyT test3
> modify $ \x -> x*x
> modifyT test3
> x <- get
> return x
>
> test7 :: (Monad m) => m Integer
> test7 = evalStateT (evalStateT test6 0) ""
As expected, running test7 >>= print gives 17.
So, given that modifyT seems to be useful, does it, or something like
it, already exists in the standard libraries? More likely, am I
making a mountain of a molehill and is there a better way to
structure all this?
Thanks,
Luis
> main = do
> test5 >>= print
> test5bad >>= print
> test7 >>= print
------------------------------
Message: 3
Date: Sat, 21 Feb 2009 16:14:15 -0500
From: Daniel Peebles <pumpkingod@gmail.com>
Subject: [Haskell-cafe] Haskellers on Twitter!
To: haskell-cafe@haskell.org
Message-ID:
<b1a8a5050902211314y74edbf39h97dcfa3188f80a60@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
Hi all,
I liked Brian O'Sullivan's blog post on twitter
(http://www.serpentine.com/blog/2008/12/05/functional-programmers-on-twitter/),
so I moved the Haskell subset of his list (along with a couple of
additions) onto the haskell wiki, to make it easier for people to
update. You can find the page at
http://haskell.org/haskellwiki/Twitter. Please update with yourself or
any other Haskellers we may have missed.
Cheers,
Dan
------------------------------
Message: 4
Date: Sun, 22 Feb 2009 00:58:59 +0300
From: Khudyakov Alexey <alexey.skladnoy@gmail.com>
Subject: Fwd: Re: [Haskell-cafe] speed: ghc vs gcc
To: haskell-cafe@haskell.org
Message-ID: <200902220058.59198.alexey.skladnoy@gmail.com>
Content-Type: Text/Plain; charset="iso-8859-1"
Oh I've again sent mail to wrong address
---------- Forwarded Message ----------
On Saturday 21 February 2009 02:42:11 you wrote:
> On Sat, Feb 21, 2009 at 12:22 AM, Bulat Ziganshin
> <bulat.ziganshin@gmail.com
>
> > wrote:
> >
> > Hello Khudyakov,
> >
> > Saturday, February 21, 2009, 2:07:39 AM, you wrote:
> > > I have another question. Why shouldn't compiler realize that
`sum
> >
> > [1..10^9]'
> >
> > > is constant and thus evaluate it at compile time?
> >
> > since we expect that compilation will be done in reasonable amount of
> > time. you cannot guarantee this for list-involving computation
>
> it would be nice to have a compiler that can run forever, incrementally
> generating faster and faster versions of the same program, until you press
> a key or a timeout is reached.
>
> then you just let it run before you get to bed ;-)
>
> you could even pass it in a test data set to which it must be optimized;
> after the program is compiled, the compiler runs and profiles it, measures
> the results, and does another pass to make it faster.
>
I've just remembered another but related approach to optimization. It uses
genetic algorithm to determine close to the best set of optimization options.
Alternatively it could be used to find badly interacting options,
pessimizations.
Implementation for gcc is here:
http://www.coyotegulch.com/products/acovea/
In fact I didn't tried it but I liked the idea.
--
Khudaykov Alexey
------------------------------
Message: 5
Date: Sun, 22 Feb 2009 01:09:23 +0300
From: Bulat Ziganshin <bulat.ziganshin@gmail.com>
Subject: Re: Fwd: Re: [Haskell-cafe] speed: ghc vs gcc
To: Khudyakov Alexey <alexey.skladnoy@gmail.com>
Cc: haskell-cafe@haskell.org
Message-ID: <528706754.20090222010923@gmail.com>
Content-Type: text/plain; charset=us-ascii
Hello Khudyakov,
Sunday, February 22, 2009, 12:58:59 AM, you wrote:
>> you could even pass it in a test data set to which it must be
optimized;
>> after the program is compiled, the compiler runs and profiles it,
measures
>> the results, and does another pass to make it faster.
it supported in gcc4 and icl at least
> I've just remembered another but related approach to optimization. It
uses
> genetic algorithm to determine close to the best set of optimization
options.
afaik it used widely for tuning parameters of compression algorithms
--
Best regards,
Bulat mailto:Bulat.Ziganshin@gmail.com
------------------------------
Message: 6
Date: Sun, 22 Feb 2009 02:21:09 +0300
From: Bulat Ziganshin <bulat.ziganshin@gmail.com>
Subject: Re[3]: [Haskell-cafe] Re: speed: ghc vs gcc
To: Louis Wasserman <wasserman.louis@gmail.com>
Cc: haskell-cafe@haskell.org
Message-ID: <989437740.20090222022109@gmail.com>
Content-Type: text/plain; charset=us-ascii
Hello Louis,
Saturday, February 21, 2009, 4:16:10 AM, you wrote:
> In the meantime, a brief summary:
a minor correction: the best gcc result shown in the thread was 50x
faster than Don's one, so you need to miltiple all ratios by a factor
of 50
> Straightforward and simple Haskell code, written by an individual
> aware of issues with tail recursion and stream fusion, is frequently
> within 3x the speed of GCC code when compiled with appropriate
> optimizations in GHC.
yes, within 150x margin
> When performance is an absolute necessity,
> Haskell code can sometimes be manually modified (e.g. with manual
> loop unrolls) to equal GCC in performance.
yes, to make it only 50x slower while being only 7 times larger (i
mean source lines)
> Can we move on?
yes, we can! :)
--
Best regards,
Bulat mailto:Bulat.Ziganshin@gmail.com
------------------------------
Message: 7
Date: Sat, 21 Feb 2009 17:30:23 -0600
From: Louis Wasserman <wasserman.louis@gmail.com>
Subject: Re: Re[3]: [Haskell-cafe] Re: speed: ghc vs gcc
To: Bulat Ziganshin <Bulat.Ziganshin@gmail.com>
Cc: haskell-cafe@haskell.org
Message-ID:
<ab4284220902211530k1690103ay1a31f437a2c521f4@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
Observation:
The best gcc result shown in the thread, if I recall, precomputed the result
of the full computation at compiletime and simply outputted it, when we
looked at the assembly.
While I will accept that this could be seen as an optimization GHC should
have made, I do not accept that this will be the case with most everyday
code a programmer writes, as most code is not used to simply compute
arithmetic constants.
For code that actively requires computation at runtime, I have seen no
examples of an instance where well-optimized GHC is actually dozens or
hundreds of times slower than GCC output.
Louis Wasserman
wasserman.louis@gmail.com
On Sat, Feb 21, 2009 at 5:21 PM, Bulat Ziganshin
<bulat.ziganshin@gmail.com>wrote:
> Hello Louis,
>
> Saturday, February 21, 2009, 4:16:10 AM, you wrote:
>
> > In the meantime, a brief summary:
>
> a minor correction: the best gcc result shown in the thread was 50x
> faster than Don's one, so you need to miltiple all ratios by a factor
> of 50
>
> > Straightforward and simple Haskell code, written by an individual
> > aware of issues with tail recursion and stream fusion, is frequently
> > within 3x the speed of GCC code when compiled with appropriate
> > optimizations in GHC.
>
> yes, within 150x margin
>
> > When performance is an absolute necessity,
> > Haskell code can sometimes be manually modified (e.g. with manual
> > loop unrolls) to equal GCC in performance.
>
> yes, to make it only 50x slower while being only 7 times larger (i
> mean source lines)
>
> > Can we move on?
>
> yes, we can! :)
>
>
> --
> Best regards,
> Bulat mailto:Bulat.Ziganshin@gmail.com
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://www.haskell.org/pipermail/haskell-cafe/attachments/20090221/3aef994b/attachment-0001.htm
------------------------------
Message: 8
Date: Sun, 22 Feb 2009 00:36:57 +0100
From: Daniel Fischer <daniel.is.fischer@web.de>
Subject: Re: [Haskell-cafe] Re: speed: ghc vs gcc
To: Bulat Ziganshin <Bulat.Ziganshin@gmail.com>, Louis Wasserman
<wasserman.louis@gmail.com>
Cc: haskell-cafe@haskell.org
Message-ID: <200902220036.57182.daniel.is.fischer@web.de>
Content-Type: text/plain; charset="iso-8859-1"
Am Sonntag, 22. Februar 2009 00:21 schrieb Bulat Ziganshin:
> Hello Louis,
>
> Saturday, February 21, 2009, 4:16:10 AM, you wrote:
> > In the meantime, a brief summary:
>
> a minor correction: the best gcc result shown in the thread was 50x
> faster than Don's one, so you need to miltiple all ratios by a factor
> of 50
You're referring to the freak result of Dan Doel?
Come on, be serious, please. I have a Haskell result that runs in 7ms, too.
Just use a rewrite rule and hey presto :)
>
> > Straightforward and simple Haskell code, written by an individual
> > aware of issues with tail recursion and stream fusion, is frequently
> > within 3x the speed of GCC code when compiled with appropriate
> > optimizations in GHC.
>
> yes, within 150x margin
Bulat, your obsession has become obnoxious and ridiculous.
>
> > When performance is an absolute necessity,
> > Haskell code can sometimes be manually modified (e.g. with manual
> > loop unrolls) to equal GCC in performance.
>
> yes, to make it only 50x slower while being only 7 times larger (i
> mean source lines)
>
> > Can we move on?
>
> yes, we can! :)
Apparently not :(
------------------------------
Message: 9
Date: Sun, 22 Feb 2009 02:35:29 +0300
From: Bulat Ziganshin <bulat.ziganshin@gmail.com>
Subject: Re[5]: [Haskell-cafe] Re: speed: ghc vs gcc
To: Louis Wasserman <wasserman.louis@gmail.com>
Cc: Bulat Ziganshin <Bulat.Ziganshin@gmail.com>,
haskell-cafe@haskell.org
Message-ID: <136796235.20090222023529@gmail.com>
Content-Type: text/plain; charset=iso-8859-1
Hello Louis,
Sunday, February 22, 2009, 2:30:23 AM, you wrote:
yes, you are right. Don also compared results of 64x-reduced
computation with full one. are you think that these results are more
fair?
> Observation:
> The best gcc result shown in the thread, if I recall, precomputed
> the result of the full computation at compiletime and simply
> outputted it, when we looked at the assembly.
> While I will accept that this could be seen as an optimization GHC
> should have made, I do not accept that this will be the case with
> most everyday code a programmer writes, as most code is not used to
> simply compute arithmetic constants.
>
> For code that actively requires computation at runtime, I have seen
> no examples of an instance where well-optimized GHC is actually
> dozens or hundreds of times slower than GCC output.
> Louis Wasserman
> wasserman.louis@gmail.com
>
> On Sat, Feb 21, 2009 at 5:21 PM, Bulat Ziganshin
> <bulat.ziganshin@gmail.com> wrote:
> Hello Louis,
>
> Saturday, February 21, 2009, 4:16:10 AM, you wrote:
>
>> In the meantime, a brief summary:
>
>
> a minor correction: the best gcc result shown in the thread was 50x
> faster than Don's one, so you need to miltiple all ratios by a factor
> of 50
>
>> Straightforward and simple Haskell code, written by an individual
>> aware of issues with tail recursion and stream fusion, is frequently
>> within 3x the speed of GCC code when compiled with appropriate
>> optimizations in GHC.
>
>
> yes, within 150x margin
>
>> When performance is an absolute necessity,
>> Haskell code can sometimes be manually modified (e.g. with manual
>> loop unrolls) to equal GCC in performance.
>
>
> yes, to make it only 50x slower while being only 7 times larger (i
> mean source lines)
>
>> Can we move on?
>
> yes, we can! :)
>
>
> --
> Best regards,
> Bulat
mailto:Bulat.Ziganshin@gmail.com
>
>
>
--
Best regards,
Bulat mailto:Bulat.Ziganshin@gmail.com
------------------------------
Message: 10
Date: Sat, 21 Feb 2009 18:37:36 -0500
From: David Menendez <dave@zednenem.com>
Subject: Re: [Haskell-cafe] Stacking StateTs
To: "Luis O'Shea" <loshea@gmail.com>
Cc: haskell-cafe@haskell.org
Message-ID:
<49a77b7a0902211537s78bc7f8cq8ab5a50962c98cc8@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
On Sat, Feb 21, 2009 at 3:33 PM, Luis O'Shea <loshea@gmail.com>
wrote:
> I've been experimenting with the state monad and with StateT, and have
some
> questions about how to combine one state with another.
<snip>
>> test3 :: Monad m => String -> StateT Integer m String
>> test3 s = do
>> modify (+ 1)
>> a <- get
>> return $ s ++ (show a)
A style point: It's often better to specify what operations test3
uses, rather than requiring a specific family of monads.
test3 :: MonadState Integer m => String -> m String
> Now seeing as test3 takes a String and returns another String you can
> imagine using it to transform a String state. (I'm also going to
assume
> that test3 is in another library so we don't want to alter how
it's
> written.) So here is how you could use test3 in a computation that has
> (String,Integer) as its state:
>
>> test5 :: (Monad m) => m Integer
>> test5 = do
>> (s1,x1) <- runStateT (test3 "") 0
>> (s2,x2) <- runStateT (test3 s1) (2*x1 + 1)
>> (s3,x3) <- runStateT (test3 s2) (x2*x2)
>> return x3
You don't really need to jump all the way out of the state
transformer. Something like this would work just as well:
test5a = flip execStateT 0 $ do
s1 <- test3 ""
modify $ \x -> 2 * x + 1
s2 <- test3 s1
modify $ \x -> x * x
test3 s2
Contrast this with your test6.
Now, if you want to avoid passing the strings around explicitly, you
could add another state transformer. For example, we could layer a
String transformer on top of the underlying monad with this fairly
general combinator:
modifyM :: (Monad m) => (s -> m s) -> StateT s m ()
modifyM f = StateT $ \s -> f s >>= \s' -> return
((),s')
test5b = flip execStateT 0 . flip evalStateT "" $ do
modifyM test3
lift $ modify $ \x -> 2 * x + 1
modifyM test3
lift $ modify $ \x -> x * x
modifyM test3
Note that modifyM works on the top-level state, whereas lift . modify
works on the inner state.
Or, you can put the state transformer on the bottom by taking
advantage of the fact that test3 is polymorphic in any underlying
monad.
test3' = lift get >>= test3 >>= lift . put -- this is
essentially
modifyT test3
test5c = flip evalState "" . flip execStateT 0 $ do
test3'
modify $ \x -> 2*x+1
test3'
modify $ \x -> x * x
test3'
But this only really makes sense if you expect the String state to
last at least as long as the Integer state.
Of my three alternatives, test5a actually seems the most idiomatic to
me, followed by test5b and then test5c. It's possible to write test5a
in a way that avoids explicitly passing the strings around, but the
result doesn't end up looking much better.
PS. Here are two functions that I ended up not using in my examples,
but which may come in handy when dealing with nested applications of
StateT:
curryStateT :: (Monad m) => StateT (s,t) m a -> StateT s (StateT t m) a
curryStateT m = StateT $ \s -> StateT $ \t ->
runStateT m (s,t) >>= \ ~(a,(s,t)) -> return ((a,s),t)
uncurryStateT :: (Monad m) => StateT s (StateT t m) a -> StateT (s,t) m a
uncurryStateT m = StateT $ \ ~(s,t) ->
runStateT (runStateT m s) t >>= \ ~((a,s),t) -> return (a,(s,t))
--
Dave Menendez <dave@zednenem.com>
<http://www.eyrie.org/~zednenem/>
------------------------------
Message: 11
Date: Sun, 22 Feb 2009 02:50:39 +0300
From: Bulat Ziganshin <bulat.ziganshin@gmail.com>
Subject: Re[2]: [Haskell-cafe] Re: speed: ghc vs gcc
To: Daniel Fischer <daniel.is.fischer@web.de>
Cc: Bulat Ziganshin <Bulat.Ziganshin@gmail.com>,
haskell-cafe@haskell.org, Louis Wasserman <wasserman.louis@gmail.com>
Message-ID: <715268448.20090222025039@gmail.com>
Content-Type: text/plain; charset=us-ascii
Hello Daniel,
Sunday, February 22, 2009, 2:36:57 AM, you wrote:
> You're referring to the freak result of Dan Doel?
> Come on, be serious, please. I have a Haskell result that runs in 7ms,
too.
> Just use a rewrite rule and hey presto :)
Dan, why you have not said the same about test where ghc becomes 4x
faster than gcc?
> Bulat, your obsession has become obnoxious and ridiculous.
i really, really wonder why cheating on gcc side is "obsession that
become obnoxious and ridiculous" while cheating on ghc side is ok for
you. can you explain?
--
Best regards,
Bulat mailto:Bulat.Ziganshin@gmail.com
------------------------------
Message: 12
Date: Sat, 21 Feb 2009 17:54:53 -0600
From: Louis Wasserman <wasserman.louis@gmail.com>
Subject: Re: Re[5]: [Haskell-cafe] Re: speed: ghc vs gcc
To: Bulat Ziganshin <Bulat.Ziganshin@gmail.com>
Cc: haskell-cafe@haskell.org
Message-ID:
<ab4284220902211554r6c1cc2f5x114dde89d3ed7210@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
I said nothing about fairness, and *never at any point said I thought Don's
results were more useful or fair.* What makes you think that's what I
meant
to imply?
You have not responded to my separate concern that
> For code that actively requires computation at runtime, I have seen
> no examples of an instance where well-optimized GHC is actually
> dozens or hundreds of times slower than GCC output.
Rather than accusing me of taking sides, if you'd take an actual
apples-to-apples comparison, citing the best Haskell results and best GCC
results -- without using examples from either language which performed
computation at compile-time that would not be possible in everyday programs
-- my original claims were true: that GHC code is frequently within 3x the
speed of GCC code, and hacked-up GHC code can reach and match GCC
performance -- though I agree those hacks require an impractical blowup in
code size. (Depending on your individual interpretation of what an average
Haskell program looks like, I concede that 3x might be off by a factor of 2
or so -- but not the factor of 50 you claimed.)
Don's "-D64" results, while *not* a useful gcc-vs-ghc comparison,
are
relevant if really determined Haskellers are interested in learning how to
obtain the absolute optimal perfection from their code. Don's results
*are*
useful, but not in the way you say we're claiming.
Louis Wasserman
wasserman.louis@gmail.com
On Sat, Feb 21, 2009 at 5:35 PM, Bulat Ziganshin
<bulat.ziganshin@gmail.com>wrote:
> Hello Louis,
>
> Sunday, February 22, 2009, 2:30:23 AM, you wrote:
>
> yes, you are right. Don also compared results of 64x-reduced
> computation with full one. are you think that these results are more
> fair?
>
> > Observation:
>
> > The best gcc result shown in the thread, if I recall, precomputed
> > the result of the full computation at compiletime and simply
> > outputted it, when we looked at the assembly.
>
> > While I will accept that this could be seen as an optimization GHC
> > should have made, I do not accept that this will be the case with
> > most everyday code a programmer writes, as most code is not used to
> > simply compute arithmetic constants.
> >
> > For code that actively requires computation at runtime, I have seen
> > no examples of an instance where well-optimized GHC is actually
> > dozens or hundreds of times slower than GCC output.
>
> > Louis Wasserman
> > wasserman.louis@gmail.com
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://www.haskell.org/pipermail/haskell-cafe/attachments/20090221/91ab0294/attachment-0001.htm
------------------------------
Message: 13
Date: Sat, 21 Feb 2009 23:55:38 +0000
From: Sebastian Sylvan <sylvan@student.chalmers.se>
Subject: Re: Re[5]: [Haskell-cafe] Re: speed: ghc vs gcc
To: Bulat Ziganshin <Bulat.Ziganshin@gmail.com>
Cc: Louis Wasserman <wasserman.louis@gmail.com>,
haskell-cafe@haskell.org
Message-ID:
<3d96ac180902211555w12b7730cqfa6b6966fc185d44@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
On Sat, Feb 21, 2009 at 11:35 PM, Bulat Ziganshin <bulat.ziganshin@gmail.com
> wrote:
> Hello Louis,
>
> Sunday, February 22, 2009, 2:30:23 AM, you wrote:
>
> yes, you are right. Don also compared results of 64x-reduced
> computation with full one. are you think that these results are more
> fair?
Yes. Clearly so.
It still computes the result from scratch - it just uses a trick which
generates better code. This is clearly a useful and worthwhile exercise as
it shows A) A neat trick with TH, B) A reasonably practical way to produce
fast code for the critical parts of a Haskell app, C) a motivating example
for implementing a compiler optimization to do it automatically.
Just outputting the precomputed result means nothing.
--
Sebastian Sylvan
+44(0)7857-300802
UIN: 44640862
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://www.haskell.org/pipermail/haskell-cafe/attachments/20090221/8861a70f/attachment-0001.htm
------------------------------
Message: 14
Date: Sat, 21 Feb 2009 15:59:04 -0800
From: John Meacham <john@repetae.net>
Subject: Re: [Haskell-cafe] Help using catch in 6.10
To: haskell-cafe@haskell.org
Message-ID: <20090221235904.GU22261@sliver.repetae.net>
Content-Type: text/plain; charset=utf-8
On Sat, Feb 21, 2009 at 01:54:52PM +0000, Ian Lynagh wrote:
> On Sat, Feb 21, 2009 at 01:18:35AM +0100, Martijn van Steenbergen wrote:
> >
> > You now need to specify the exact type of the exception you wish to
> > catch. For example, to catch any exception:
> >
> > action `catch` (\(e :: SomeException) -> handler)
> >
> > For more information, see:
> >
> > http://www.haskell.org/~simonmar/papers/ext-exceptions.pdf
>
> See also
>
> "Catching all exceptions"
>
http://www.haskell.org/ghc/dist/stable/docs/libraries/base/Control-Exception.html#4
It is too bad we didn't name SomeException to just be Exception, then it
would be quite straightforward to write code that cleanly compiles on
6.8 and 6.10. As it is,
#if __GLASGOW_HASKELL__ < 610
type SomeException = Exception
#endif
does the trick, but no one likes CPP...
John
--
John Meacham - ⑆repetae.net⑆john⑈
------------------------------
Message: 15
Date: Sat, 21 Feb 2009 17:59:05 -0600
From: Louis Wasserman <wasserman.louis@gmail.com>
Subject: Re: Re[5]: [Haskell-cafe] Re: speed: ghc vs gcc
To: Sebastian Sylvan <sylvan@student.chalmers.se>
Cc: Bulat Ziganshin <Bulat.Ziganshin@gmail.com>,
haskell-cafe@haskell.org
Message-ID:
<ab4284220902211559i62648cabi697317bb33a5def5@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
Sebastian, that's not Bulat's point. He's saying that if we make
that
optimization in Haskell, we should at least make the same optimization in
GCC for fair comparison. (Though I'm not entirely sure that that
optimization would be of any use to GCC, but that's a linguistic concern,
no
more.)
His point is valid. But Don's results *not* obtained by optimizing in this
fashion are valid comparisons, and the results obtained with this
optimization are useful for other reasons.
Louis Wasserman
wasserman.louis@gmail.com
On Sat, Feb 21, 2009 at 5:55 PM, Sebastian Sylvan <
sylvan@student.chalmers.se> wrote:
>
>
> On Sat, Feb 21, 2009 at 11:35 PM, Bulat Ziganshin <
> bulat.ziganshin@gmail.com> wrote:
>
>> Hello Louis,
>>
>> Sunday, February 22, 2009, 2:30:23 AM, you wrote:
>>
>> yes, you are right. Don also compared results of 64x-reduced
>> computation with full one. are you think that these results are more
>> fair?
>>
>
> Yes. Clearly so.
> It still computes the result from scratch - it just uses a trick which
> generates better code. This is clearly a useful and worthwhile exercise as
> it shows A) A neat trick with TH, B) A reasonably practical way to produce
> fast code for the critical parts of a Haskell app, C) a motivating example
> for implementing a compiler optimization to do it automatically.
>
> Just outputting the precomputed result means nothing.
>
>
>
> --
> Sebastian Sylvan
> +44(0)7857-300802
> UIN: 44640862
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://www.haskell.org/pipermail/haskell-cafe/attachments/20090221/d81c03fc/attachment-0001.htm
------------------------------
Message: 16
Date: Sat, 21 Feb 2009 15:59:54 -0800
From: Don Stewart <dons@galois.com>
Subject: [Haskell-cafe] The community is more important than the
product
To: haskell-cafe@haskell.org
Message-ID: <20090221235954.GZ19753@whirlpool.galois.com>
Content-Type: text/plain; charset=us-ascii
http://haskell.org/haskellwiki/Protect_the_community
Random notes on how to maintain tone, focus and productivity in an
online community I took a few years ago.
Might be some material there if anyone's seeking to help ensure
we remain a constructive, effective community.
-- Don
P.S. release some code on hackage.haskell.org.
------------------------------
Message: 17
Date: Sun, 22 Feb 2009 00:02:05 +0000
From: Sebastian Sylvan <sylvan@student.chalmers.se>
Subject: Re: Re[5]: [Haskell-cafe] Re: speed: ghc vs gcc
To: Louis Wasserman <wasserman.louis@gmail.com>
Cc: Bulat Ziganshin <Bulat.Ziganshin@gmail.com>,
haskell-cafe@haskell.org
Message-ID:
<3d96ac180902211602p5516d7aeh59dd27abbb90c6c4@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
No, he asked if comparing the D64 version with the straight gcc one was
"more fair" then comparing a version that precomputes the result with
one
that doesn't. That's what I responded to.
On Sat, Feb 21, 2009 at 11:59 PM, Louis Wasserman <wasserman.louis@gmail.com
> wrote:
> Sebastian, that's not Bulat's point. He's saying that if we
make that
> optimization in Haskell, we should at least make the same optimization in
> GCC for fair comparison. (Though I'm not entirely sure that that
> optimization would be of any use to GCC, but that's a linguistic
concern, no
> more.)
>
> His point is valid. But Don's results *not* obtained by optimizing in
this
> fashion are valid comparisons, and the results obtained with this
> optimization are useful for other reasons.
>
> Louis Wasserman
> wasserman.louis@gmail.com
>
>
> On Sat, Feb 21, 2009 at 5:55 PM, Sebastian Sylvan <
> sylvan@student.chalmers.se> wrote:
>
>>
>>
>> On Sat, Feb 21, 2009 at 11:35 PM, Bulat Ziganshin <
>> bulat.ziganshin@gmail.com> wrote:
>>
>>> Hello Louis,
>>>
>>> Sunday, February 22, 2009, 2:30:23 AM, you wrote:
>>>
>>> yes, you are right. Don also compared results of 64x-reduced
>>> computation with full one. are you think that these results are
more
>>> fair?
>>>
>>
>> Yes. Clearly so.
>> It still computes the result from scratch - it just uses a trick which
>> generates better code. This is clearly a useful and worthwhile
exercise as
>> it shows A) A neat trick with TH, B) A reasonably practical way to
produce
>> fast code for the critical parts of a Haskell app, C) a motivating
example
>> for implementing a compiler optimization to do it automatically.
>>
>> Just outputting the precomputed result means nothing.
>>
>>
>>
>> --
>> Sebastian Sylvan
>> +44(0)7857-300802
>> UIN: 44640862
>>
>
>
--
Sebastian Sylvan
+44(0)7857-300802
UIN: 44640862
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://www.haskell.org/pipermail/haskell-cafe/attachments/20090222/65ad0a79/attachment-0001.htm
------------------------------
Message: 18
Date: Sun, 22 Feb 2009 01:11:19 +0100
From: Daniel Fischer <daniel.is.fischer@web.de>
Subject: Re: [Haskell-cafe] Re: speed: ghc vs gcc
To: Bulat Ziganshin <Bulat.Ziganshin@gmail.com>
Cc: Bulat Ziganshin <Bulat.Ziganshin@gmail.com>,
haskell-cafe@haskell.org, Louis Wasserman <wasserman.louis@gmail.com>
Message-ID: <200902220111.19929.daniel.is.fischer@web.de>
Content-Type: text/plain; charset="iso-8859-1"
Am Sonntag, 22. Februar 2009 00:50 schrieb Bulat Ziganshin:
> Hello Daniel,
>
> Sunday, February 22, 2009, 2:36:57 AM, you wrote:
> > You're referring to the freak result of Dan Doel?
> > Come on, be serious, please. I have a Haskell result that runs in
7ms,
> > too. Just use a rewrite rule and hey presto :)
>
> Dan, why you have not said the same about test where ghc becomes 4x
> faster than gcc?
Because, as has been explained several times to you, it was not a test of
ghc's code generation vs. gcc's, and it was NOT meant to be. It was
explicitely an investigation of how effective an improvement loop-unrolling
could be.
>
> > Bulat, your obsession has become obnoxious and ridiculous.
>
> i really, really wonder why cheating on gcc side is "obsession that
> become obnoxious and ridiculous" while cheating on ghc side is ok for
> you. can you explain?
Seriously????
You have one case where gcc calculated the result for an extremely simple
programme during the compilation and you use that to say that gcc's code is
routinely 50-150 times faster than ghc's. Very convincing.
------------------------------
Message: 19
Date: Sun, 22 Feb 2009 03:10:31 +0300
From: Bulat Ziganshin <bulat.ziganshin@gmail.com>
Subject: Re[7]: [Haskell-cafe] Re: speed: ghc vs gcc
To: Sebastian Sylvan <sylvan@student.chalmers.se>
Cc: Bulat Ziganshin <Bulat.Ziganshin@gmail.com>,
haskell-cafe@haskell.org, Louis Wasserman <wasserman.louis@gmail.com>
Message-ID: <561497165.20090222031031@gmail.com>
Content-Type: text/plain; charset=us-ascii
Hello Sebastian,
Sunday, February 22, 2009, 2:55:38 AM, you wrote:
> yes, you are right. Don also compared results of 64x-reduced
> computation with full one. are you think that these results are more
> fair?
> Yes. Clearly so.
> It still computes the result from scratch - it just uses a trick
> which generates better code. This is clearly a useful and worthwhile
> exercise as it shows A) A neat trick with TH, B) A reasonably
> practical way to produce fast code for the critical parts of a
> Haskell app, C) a motivating example for implementing a compiler
> optimization to do it automatically.
yes, but does you know why his last program is 64x faster than simple
code? it's because *gcc* optimize it this way. the first program i
published there does it by mistake, then i fixed it by using 'xor'
instead of (+) and published here that i've considered most fair
comparison
OTOH Don used this gcc optimization to generate faster code for
haskell. he doesn't used this trick for C++ and doesn't omitted
unoptimized gcc results from the chart. as a result people who don't
analyzed details made conclusion that ghc outperformed gcc here
so i have made experiment with cheating the same way, but in more
obvious manner. and i got 3 angry answers in 5 minutes. so what are
the difference? you don't catched details of Don comparison or you
bothered only by gcc-related cheating?
--
Best regards,
Bulat mailto:Bulat.Ziganshin@gmail.com
------------------------------
Message: 20
Date: Sun, 22 Feb 2009 01:12:13 +0100
From: Peter Verswyvelen <bugfact@gmail.com>
Subject: [Haskell-cafe] Template Haskell compilation error on Windows
(was Re: speed: ghc vs gcc)
To: Don Stewart <dons@galois.com>
Cc: Claus Reinke <claus.reinke@talk21.com>, haskell-cafe@haskell.org,
Bulat Ziganshin <Bulat.Ziganshin@gmail.com>
Message-ID:
<a88790d10902211612m52ff9145lb522577611b76779@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
I tried to compile the template Haskell loop unrolling trick from Claus
Reinke on my machine which is running Windows and GHC 6.10.1, and I got
linker errors.
(note that compiling *without* -fvia-C works fine)
Compiling under Cygwin did not solve it. Any ideas how I could get this
working? I have no experience with TH yet so I might be missing something
essential...
Thanks,
Peter
c:\temp>ghc -O2 -fvia-C -optc-O3 -fforce-recomp Apply.hs
Apply.o:ghc6140_0.hc:(.text+0x7d): undefined reference to
`templatezmhaskell_LanguageziHaskellziTHziSyntax_VarP_con_info'
Apply.o:ghc6140_0.hc:(.text+0x10d): undefined reference to
`templatezmhaskell_LanguageziHaskellziTHziSyntax_VarE_con_info'
Apply.o:ghc6140_0.hc:(.text+0x19d): undefined reference to
`templatezmhaskell_LanguageziHaskellziTHziSyntax_VarP_con_info'
Apply.o:ghc6140_0.hc:(.text+0x571): undefined reference to
`templatezmhaskell_LanguageziHaskellziTHziSyntax_VarP_con_info'
Apply.o:ghc6140_0.hc:(.text+0x609): undefined reference to
`templatezmhaskell_LanguageziHaskellziTHziSyntax_VarE_con_info'
Apply.o:ghc6140_0.hc:(.text+0x6c9): undefined reference to
`templatezmhaskell_LanguageziHaskellziTHziSyntax_VarE_con_info'
Apply.o:ghc6140_0.hc:(.text+0x789): undefined reference to
`templatezmhaskell_LanguageziHaskellziTHziSyntax_VarE_con_info'
Apply.o:ghc6140_0.hc:(.text+0x82c): undefined reference to
`templatezmhaskell_LanguageziHaskellziTHziLib_a23_closure'
Apply.o:ghc6140_0.hc:(.text+0x868): undefined reference to
`templatezmhaskell_LanguageziHaskellziTHziLib_a23_closure'
Apply.o:ghc6140_0.hc:(.text+0x891): undefined reference to
`templatezmhaskell_LanguageziHaskellziTHziSyntax_VarP_con_info'
Apply.o:ghc6140_0.hc:(.text+0xd81): undefined reference to
`templatezmhaskell_LanguageziHaskellziTHziSyntax_VarP_con_info'
Apply.o:ghc6140_0.hc:(.text+0xe19): undefined reference to
`templatezmhaskell_LanguageziHaskellziTHziSyntax_VarE_con_info'
Apply.o:ghc6140_0.hc:(.text+0xed9): undefined reference to
`templatezmhaskell_LanguageziHaskellziTHziSyntax_VarE_con_info'
Apply.o:ghc6140_0.hc:(.text+0xf99): undefined reference to
`templatezmhaskell_LanguageziHaskellziTHziSyntax_VarE_con_info'
Apply.o:ghc6140_0.hc:(.text+0x103c): undefined reference to
`templatezmhaskell_LanguageziHaskellziTHziLib_a23_closure'
Apply.o:ghc6140_0.hc:(.text+0x1078): undefined reference to
`templatezmhaskell_LanguageziHaskellziTHziLib_a23_closure'
Apply.o:ghc6140_0.hc:(.text+0x10a1): undefined reference to
`templatezmhaskell_LanguageziHaskellziTHziSyntax_VarP_con_info'
Apply.o:ghc6140_0.hc:(.text+0x14d0): undefined reference to
`__stginit_templatezmhaskell_LanguageziHaskellziTHziSyntax_'
Apply.o:ghc6140_0.hc:(.text+0x292): undefined reference to
`templatezmhaskell_LanguageziHaskellziTHziLib_lamE_info'
Apply.o:ghc6140_0.hc:(.text+0x6ab): undefined reference to
`templatezmhaskell_LanguageziHaskellziTHziLib_a23_info'
Apply.o:ghc6140_0.hc:(.text+0x76b): undefined reference to
`templatezmhaskell_LanguageziHaskellziTHziLib_a23_info'
Apply.o:ghc6140_0.hc:(.text+0x9bc): undefined reference to
`templatezmhaskell_LanguageziHaskellziTHziLib_lamE_info'
Apply.o:ghc6140_0.hc:(.text+0xebb): undefined reference to
`templatezmhaskell_LanguageziHaskellziTHziLib_a23_info'
Apply.o:ghc6140_0.hc:(.text+0xf7b): undefined reference to
`templatezmhaskell_LanguageziHaskellziTHziLib_a23_info'
Apply.o:ghc6140_0.hc:(.text+0x11cc): undefined reference to
`templatezmhaskell_LanguageziHaskellziTHziLib_lamE_info'
C:\app\ghc-6.10.1/libHSrts.a(Main.o):Main.c:(.text+0x7): undefined
reference
to `__stginit_ZCMain'
C:\app\ghc-6.10.1/libHSrts.a(Main.o):Main.c:(.text+0x36): undefined
reference to `ZCMain_main_closure'
collect2: ld returned 1 exit status
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://www.haskell.org/pipermail/haskell-cafe/attachments/20090222/bff4135e/attachment.htm
------------------------------
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
End of Haskell-Cafe Digest, Vol 66, Issue 71
********************************************
|