[Haskell-cafe] Is Haskell IO inherently slower than C?

[Jake]

It seems to me that BlockBuffering is the fastest. I checked and the
default buffering mode for stdout is BlockBuffering Nothing. So I went to
the C program and checked the value of BUFSIZ which was 8192. Then I set
the buffering mode for stdout to BlockBuffering (Just 8192) so they should
be buffering the same, right?
It didn't really change the performance at all. Is there something else
going on with the buffering I'm not changing?

On Wed, May 4, 2016 at 9:45 PM Mike Izbicki <mike at izbicki.me> wrote:

> That convinces me that your Haskell program is actually slower.  My
> guess is this is due to a buffering issue, and not due to anything
> haskell related.  Buffering is how the opeating system makes a
> tradeoff between performance and safety for io operations, and I'm
> guessing your two code fragments are (behind the scenes) making a
> different decision about how to do buffering.
>
> For a Haskell-related discussion about buffering, see:
> http://book.realworldhaskell.org/read/io.html#io.buffering
>
> BTW, a good rule of thumb for io performance in any language is to
> never write anything character by character, and instead write large
> chunks of characters at once.  The above link should make clear why
> this is the case.
>
> On Wed, May 4, 2016 at 6:22 PM, Jake <jake.waksbaum at gmail.com> wrote:
> > Thanks for the tip! I tried it again, this time using 100000000, and the
> > Haskell one runs at around 25 seconds. The C one is only 1.5 seconds. Can
> > that still be the run time system?
> >
> > On Wed, May 4, 2016 at 9:18 PM Mike Izbicki <mike at izbicki.me> wrote:
> >>
> >> You need to be doing tests that take much longer to accurately compare
> >> runtimes of executables.  Here's why:
> >>
> >> Haskell programs have a more complicated run time system than C
> >> programs, and the binaries output by GHC are much larger.  Therefore,
> >> there will be a small additional overhead that you have to pay once
> >> when the program starts.  For some machines, this could possibly be on
> >> the order of 0.3 seconds.
> >>
> >> I'd recommend you scale your test so that it takes at least 30 seconds
> >> for the slowest program.  This will give you more meaningful results.
> >>
> >> On Wed, May 4, 2016 at 6:07 PM, Jake <jake.waksbaum at gmail.com> wrote:
> >> > I also tried the more standard forM_ [0..100000] idiom and got similar
> >> > times. I hoped loop might be faster, but apparently not.
> >> >
> >> > On Wed, May 4, 2016 at 9:05 PM Jake <jake.waksbaum at gmail.com> wrote:
> >> >>
> >> >> I'm trying to write a program in Haskell that writes a large file at
> >> >> the
> >> >> end, and it seems like that output alone is taking way longer than it
> >> >> should. I don't understand why Haskell shouldn't be able to write
> data
> >> >> as
> >> >> quickly as C, so I wrote two test files:
> >> >>
> >> >> -- Test.hs
> >> >> import Control.Loop
> >> >> import Data.ByteString.Builder
> >> >> import System.IO
> >> >>
> >> >> main :: IO ()
> >> >> main =
> >> >>   numLoop 0 1000000 $ \_ ->
> >> >>     hPutBuilder stdout $ char7 ' '
> >> >>
> >> >> // test.c
> >> >> #include <stdio.h>
> >> >>
> >> >> int main() {
> >> >>   int i;
> >> >>   for (i = 0; i < 1000000; i++) {
> >> >>     fprintf(stdout, " ");
> >> >>   }
> >> >>   return 0;
> >> >> }
> >> >>
> >> >> I compiled them both with -O2, and ran them redirecting their outputs
> >> >> to
> >> >> /dev/null. For the Haskell version I got times aroudn 0.3 seconds,
> >> >> while the
> >> >> C version was around 0.03. Is there any reason why in simple IO the
> >> >> Haskell
> >> >> version would be slower by an order of magnitude?
> >> >
> >> >
> >> > _______________________________________________
> >> > Haskell-Cafe mailing list
> >> > Haskell-Cafe at haskell.org
> >> > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
> >> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20160505/c616a260/attachment-0001.html>