Difference between revisions of "Talk:Questions and answers"
(...and now the code snippet actually makes sense!) |
|||
| (One intermediate revision by the same user not shown) | |||
| Line 5: | Line 5: | ||
:not yet at least. try the #haskell irc channel on freenode which is usually manned by at least a few very helpfull people. alternatively try the [http://haskell.org/pipermail/haskell-cafe/ haskell-cafe] mailing list --[[User:JohannesAhlmann|Johannes Ahlmann]] 12:29, 22 January 2007 (UTC) |
:not yet at least. try the #haskell irc channel on freenode which is usually manned by at least a few very helpfull people. alternatively try the [http://haskell.org/pipermail/haskell-cafe/ haskell-cafe] mailing list --[[User:JohannesAhlmann|Johannes Ahlmann]] 12:29, 22 January 2007 (UTC) |
||
| + | == A question of speed == |
||
| − | :: I tried the IRC channel. 300+ people and nobody speaking. Not very helpful. [[User:MathematicalOrchid|MathematicalOrchid]] 13:23, 22 January 2007 (UTC) |
||
| + | I have just performed a benchmark regarding the speed of <hask>(++)</hask> vs <hask>putStr</hask>, and received an extremely puzzling and counter-intuitive result. Perhaps somebody can explain? |
||
| − | ::: Try again. The channel is quite active, so active it's even distracting. If you don't believe me, check the [http://tunes.org/~nef/logs/haskell/ channel logs] for yourself. Besides, maybe now with conferences over, you'll have better luck. -- [[User:EricKow|kowey]] 19:12, 22 January 2007 (UTC) |
||
| − | === |
+ | === Test #1 === |
| + | <haskell> |
||
| − | Not wishing to belabour the point, but I did spend over an hour in that channel. Several people came in and asked perfectly reasonably questions, but were greeted only by absolute silence... (Search the logs. My name is in there... somewhere.) [[User:MathematicalOrchid|MathematicalOrchid]] 22:10, 22 January 2007 (UTC) |
||
| + | writeFile "Test1.txt" $ concat $ replicate n "test" |
||
| + | </haskell> |
||
| + | For n = 10,000,000, that takes about 35 seconds wall-clock time and about 17 seconds CPU time on my test machine. (It also uses about 1.4 MB RAM.) |
||
| − | :When was this? -- [[User:EricKow|kowey]] 23:56, 22 January 2007 (UTC) |
||
| + | === Test #2 === |
||
| − | :: Much to my irritation, it appears that ChatZilla doesn't keep track of such information. I know it was probably in November 2006 sometime... but that's a lot of searching to do. I did check my diary, but apparently I didn't write it down there either. Oh well. [[User:MathematicalOrchid|MathematicalOrchid]] 15:48, 23 January 2007 (UTC) |
||
| + | <haskell> |
||
| − | :: Drop by [http://www.cse.unsw.edu.au/~dons/irc/ the channel]. You must have visited during a quiet period. The mailing list is also a better place for this kind of discussion that the wiki. There's maybe 5 people reading this page, but several thousand on the mailing list... [[User:Dons|Dons]] 10:49, 23 January 2007 (UTC) |
||
| + | writeFile "Test2.txt" $ concatMap (\x -> "test") [1..n] |
||
| + | </haskell> |
||
| + | For the same value of n, that takes about 43 seconds wall-clock time and about 20 seconds CPU time. (Uses 2.4 MB RAM for some reason...) |
||
| − | ::: I'm not keen on mailing lists. Too many people talking across each other about totally unrelated topics. It's too difficult to untangle all the threads. I prefer NNTP or web forums... |
||
| + | === Test #3 === |
||
| − | :::: You might like the [http://news.gmane.org/gmane.comp.lang.haskell.cafe gmane interface to Haskell Cafe], in that case. It even works with news readers: <tt>nntp://news.gmane.org/gmane.comp.lang.haskell.cafe</tt> |
||
| + | <haskell> |
||
| − | :::: Can't offer much else in the way of help. You seem quite invested in the idea that the channel will be useless to you, despite all claims and evidence to the contrary. Too bad. Despite your single experience, it is quite a wonderful resource. -- [[User:EricKow|kowey]] 16:17, 23 January 2007 (UTC) |
||
| + | writeFile "Test3.txt" $ build n "" |
||
| + | |||
| + | build 0 x = x |
||
| + | build n x = build (n-1) (x ++ "test") |
||
| + | </haskell> |
||
| + | |||
| + | This test does not finish. It simply consumes memory without limit, never writing anything to disk. (At 90 MB, Windoze warned me that 'the system is getting dangerously low on virtual memory'.) |
||
| + | |||
| + | I added a couple of calls to <hask>seq</hask> in there - but this made no noticeable difference to anything. |
||
| + | |||
| + | === Test #4 === |
||
| + | |||
| + | And now the really interesting test: |
||
| + | |||
| + | <haskell> |
||
| + | do h <- openFile "Test4.txt" WriteMode ; mapM_ (\x -> hPutStr h "help") [1..n] |
||
| + | </haskell> |
||
| + | |||
| + | This takes 80 seconds wall-time and 70 seconds CPU time. (Memory usage appears to be 2.4 MB or less.) |
||
| + | |||
| + | === Summary === |
||
| + | |||
| + | I'm supprised that <hask>concatMap</hask> should be slower than <hask>concat</hask> and <hask>replicate</hask>. But then we're not talking about a huge speed difference. |
||
| + | |||
| + | I am absolutely astonished that <hask>(++)</hask> should be ''50% faster'' than the much more efficient I/O calls. Does anybody have the slightest clue how this can be? Currently the only think I can think of is that each I/O call has some kind of constant overhead, and so the ''number'' of I/O calls affects speed more than the amount of data processed. But even so... 50%?? |
||
| + | |||
| + | All this is with code compiled by GHC 6.6 - as if that makes any difference. |
||
Latest revision as of 13:23, 5 February 2007
IRC
Is this a good place to ask questions? MathematicalOrchid 15:30, 18 January 2007 (UTC)
- not yet at least. try the #haskell irc channel on freenode which is usually manned by at least a few very helpfull people. alternatively try the haskell-cafe mailing list --Johannes Ahlmann 12:29, 22 January 2007 (UTC)
A question of speed
I have just performed a benchmark regarding the speed of (++) vs putStr, and received an extremely puzzling and counter-intuitive result. Perhaps somebody can explain?
Test #1
writeFile "Test1.txt" $ concat $ replicate n "test"
For n = 10,000,000, that takes about 35 seconds wall-clock time and about 17 seconds CPU time on my test machine. (It also uses about 1.4 MB RAM.)
Test #2
writeFile "Test2.txt" $ concatMap (\x -> "test") [1..n]
For the same value of n, that takes about 43 seconds wall-clock time and about 20 seconds CPU time. (Uses 2.4 MB RAM for some reason...)
Test #3
writeFile "Test3.txt" $ build n ""
build 0 x = x
build n x = build (n-1) (x ++ "test")
This test does not finish. It simply consumes memory without limit, never writing anything to disk. (At 90 MB, Windoze warned me that 'the system is getting dangerously low on virtual memory'.)
I added a couple of calls to seq in there - but this made no noticeable difference to anything.
Test #4
And now the really interesting test:
do h <- openFile "Test4.txt" WriteMode ; mapM_ (\x -> hPutStr h "help") [1..n]
This takes 80 seconds wall-time and 70 seconds CPU time. (Memory usage appears to be 2.4 MB or less.)
Summary
I'm supprised that concatMap should be slower than concat and replicate. But then we're not talking about a huge speed difference.
I am absolutely astonished that (++) should be 50% faster than the much more efficient I/O calls. Does anybody have the slightest clue how this can be? Currently the only think I can think of is that each I/O call has some kind of constant overhead, and so the number of I/O calls affects speed more than the amount of data processed. But even so... 50%??
All this is with code compiled by GHC 6.6 - as if that makes any difference.