How to benckmark a Word64 -> Bool?

Hi, I have a Word64 -> Bool function called only012 that returns True iff the digits in base 10 are 0, 1 or 2. I wand to make sure that I'm competitive with C, so I wrote the following code: Haskell version: http://lpaste.net/100129 C version: http://lpaste.net/100128 $ ghc --make -O3 303only012.hs && time ./303only012 50000000 > /dev/null ./303only012 50000000 > /dev/null 21.44s user 0.41s system 91% cpu 23.754 total $ g++ -O3 303only012.cpp -o 303cpponly012 && time ./303cpponly012 50000000
/dev/null ./303cpponly012 50000000 > /dev/null 13.87s user 0.03s system 95% cpu 14.577 total
So there's a difference, but I'm not sure if it's related to my algorithm or related to IO/RTS. The core output of only012 looks quite tight: http://lpaste.net/100130 Am I doing the IO part right, that is fast IO that is not screwing my benckmark? I'm not so sure about that since I use a convoluted way to print the boolean result in Haskell. Cheers, -- Cp

Hi Charles,
Criterion might give you more precise results :
http://hackage.haskell.org/package/criterion
Cheers
On Feb 19, 2014 5:37 PM, "Charles-Pierre Astolfi"
Hi,
I have a Word64 -> Bool function called only012 that returns True iff the digits in base 10 are 0, 1 or 2. I wand to make sure that I'm competitive with C, so I wrote the following code:
Haskell version: http://lpaste.net/100129
C version: http://lpaste.net/100128
$ ghc --make -O3 303only012.hs && time ./303only012 50000000 > /dev/null ./303only012 50000000 > /dev/null 21.44s user 0.41s system 91% cpu 23.754 total
$ g++ -O3 303only012.cpp -o 303cpponly012 && time ./303cpponly012 50000000
/dev/null ./303cpponly012 50000000 > /dev/null 13.87s user 0.03s system 95% cpu 14.577 total
So there's a difference, but I'm not sure if it's related to my algorithm or related to IO/RTS.
The core output of only012 looks quite tight: http://lpaste.net/100130
Am I doing the IO part right, that is fast IO that is not screwing my benckmark? I'm not so sure about that since I use a convoluted way to print the boolean result in Haskell.
Cheers, -- Cp
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

Also, prefer quotRem over divMod as the former is faster. See here:
http://stackoverflow.com/questions/339719/when-is-the-difference-between-quo...
On Wed, Feb 19, 2014 at 10:19 AM, Gregory Collins
On Wed, Feb 19, 2014 at 9:36 AM, Charles-Pierre Astolfi
wrote: So there's a difference, but I'm not sure if it's related to my algorithm or related to IO/RTS.
Text.Printf is slower than the C version (and uses String). Use Data.ByteString.putStr instead.
-- Gregory Collins
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

Switching to quotRem gave no measurable improvements.
After switching to ByteString, the code now runs in 9 seconds, which
outperforms my C version. But honestly, I have no idea why.
New code:
http://lpaste.net/100136
$ ghc --make -O3 303only012.hs && time ./303only012 50000000 > /dev/null
./303only012 50000000 > /dev/null 9.72s user 0.21s system 90% cpu 10.961
total
@Alois, I'm not sure how criterion can help compare my code with the C
version, since in the C version I cannot measure the exec time of only012
only. What did you have in mind?
Thanks everyone!
--
Cp
On Wed, Feb 19, 2014 at 7:24 PM, Levent Erkok
Also, prefer quotRem over divMod as the former is faster. See here: http://stackoverflow.com/questions/339719/when-is-the-difference-between-quo...
On Wed, Feb 19, 2014 at 10:19 AM, Gregory Collins
wrote:
On Wed, Feb 19, 2014 at 9:36 AM, Charles-Pierre Astolfi
wrote: So there's a difference, but I'm not sure if it's related to my algorithm or related to IO/RTS.
Text.Printf is slower than the C version (and uses String). Use Data.ByteString.putStr instead.
-- Gregory Collins
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

Hi Charles,
I had in mind comparing with similar tool the C version, but it looks like
I was a bit naive at thinking that same tooling exist for C (after googling
a bit it sounds there is no lib like that).
OTOH, Bryan O'Sullivan mention in his original blog past about criterion
that it could be potentially used to benchmark C code as well.
The cost of putting that in place might outperform the benefit though.
Cheers
Alois
On 19 February 2014 18:49, Charles-Pierre Astolfi
Switching to quotRem gave no measurable improvements. After switching to ByteString, the code now runs in 9 seconds, which outperforms my C version. But honestly, I have no idea why.
New code: http://lpaste.net/100136
$ ghc --make -O3 303only012.hs && time ./303only012 50000000 > /dev/null ./303only012 50000000 > /dev/null 9.72s user 0.21s system 90% cpu 10.961 total
@Alois, I'm not sure how criterion can help compare my code with the C version, since in the C version I cannot measure the exec time of only012 only. What did you have in mind?
Thanks everyone!
-- Cp
On Wed, Feb 19, 2014 at 7:24 PM, Levent Erkok
wrote: Also, prefer quotRem over divMod as the former is faster. See here: http://stackoverflow.com/questions/339719/when-is-the-difference-between-quo...
On Wed, Feb 19, 2014 at 10:19 AM, Gregory Collins < greg@gregorycollins.net> wrote:
On Wed, Feb 19, 2014 at 9:36 AM, Charles-Pierre Astolfi
wrote: So there's a difference, but I'm not sure if it's related to my algorithm or related to IO/RTS.
Text.Printf is slower than the C version (and uses String). Use Data.ByteString.putStr instead.
-- Gregory Collins
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
-- *Alois Cochard* http://aloiscochard.blogspot.com http://twitter.com/aloiscochard http://github.com/aloiscochard
participants (4)
-
Alois Cochard
-
Charles-Pierre Astolfi
-
Gregory Collins
-
Levent Erkok