
Hello John, Thursday, September 25, 2008, 1:55:18 AM, you wrote: ask benchmark authors or just examine code before making any conclusions. for example, in sumfile behcnmark, C entries use fgets+atoi or C++ streams to read input numbers so C works 2x slower than Clean and 4x slower than low-level Haskell code (which wasn't accepted for the same reasons). so we have "fight of invalids" where Haskell invalid was made much faster (on this test) by adding special function to ghc libs
I'm going to have to agree with David... even if you ignore the multi-threaded projects, why couldn't the C programs just implement very specific version of the third party library inside their code? Is there anything stopping them?
On Wed, Sep 24, 2008 at 5:50 PM, Bulat Ziganshin
wrote: Hello david48,
Thursday, September 25, 2008, 1:38:55 AM, you wrote:
please show me example that you mean and i will show exact reasons why this Haskell code wasn't compared to the best C code
The shootout seems pretty popular, and there's still a lot of C programmers around, so I wonder why the C code on the shootout would be of poor quality.
1. speed of most shootout examples heavily depends on availability and quality of libraries bundled with the compiler. shootout authors doesn't allow to use 3rd-party libs nor rewrite this functionality from scratch. for example C lays down in multithreading tests because C compilers doesn't include green thread libs
2. unlike Don, C authors can't modify libs bundled to their compilers to reach out maximum speed on these benchmarks. for example, using of readInt instead of generic read allowed to make program tens times faster and even outperform a bit C version that uses standard library functions
-- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com
_______________________________________________
Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
-- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com