Hi Bulat, On Monday 16 August 2010 07:35:44, Bulat Ziganshin wrote:
Hello Daniel,
Sunday, August 15, 2010, 10:39:24 PM, you wrote:
That's great. If that performance difference is a show stopper, one shouldn't go higher-level than C anyway :)
*all* speed measurements that find Haskell is as fast as C, was broken.
That's a pretty bold claim, considering that you probably don't know all such measurements ;) But let's get serious. Bryan posted measurements showing the text (HEAD) package's performance within a reasonable factor of wc's. (Okay, he didn't give a complete description of his test, so we can only assume that all participants did the same job. I'm bold enough to assume that.) Lazy text being 7% slower than wc, strict 30%. If you are claiming that his test was flawed (and since the numbers clearly showed Haskell slower thanC, just not much, I suspect you do, otherwise I don't see the point of your post), could you please elaborate why you think it's flawed?
Let's see:
D:\testing>read MsOffice.arc MsOffice.arc 317mb -- Done Time 0.407021 seconds (timer accuracy 0.000000 seconds) Speed 779.505632 mbytes/sec
I see nothing here, not knowing what `read' is. None of read (n), read (2), read (1p), read(3p) makes sense here, so it must be something else. Since it outputs a size in bytes, I doubt that it actually counts characters, like wc -m and, presumably, the text programmes Bryan benchmarked. Just counting bytes, wc and Data.ByteString[.Lazy] can do much faster than counting characters too.