Many thanks all for replies, yes, that's what I assumed/wrote. C compiler does compile-time evaluation, while ghc does another transformation. And, well, yes, declaring upper bound in loop in extra file breaks the optimization for C compiler and, thus, both evaluation times for C and Haskell binaries are the same thus.
Thank you once, again,
Dušan
P.S.
If anyone can point me to resource, where examples on demonstration of Haskell optimization are, I'll be very glad.
D.
On úterý 27. února 2018 23:06:38 CET Richard O'Keefe wrote:
> In order to optimise array indexing and to automatically vectorise
> your code, high performance compilers for imperative languages
> like C and Fortran analyse counted loops like you wouldn't believe.
> You can find out what the C compiler does with your code by using
> the -S command line option. gcc 7.2 optimised the whole loop away.
>
> Split your C program into two files.
> One contains
> long bound = 100000000L, incr = 1L;
> The other is a version of your existing code with
> extern long bound, incr;
> ...
> for (i = 1L; i <= bound; i += incr) { ... }
> ...
> gcc 7.2 isn't quite smart enough to optimise this away. Yet.
>
> The polyhedral optimisations going on are described in the
> open literature and are valuable for imperative array-
> crunching code. You are not likely to see them in GHC any
> time soon, just as you're not likely to see deforestation
> in gcc any time soon.
>
> On 28 February 2018 at 04:06, Dušan Kolář <kolar@fit.vut.cz> wrote:
> > Dear Café,
> >
> >
> >
> > I'm trying to do very small, but impressive example about optimizations
> > possible during Haskell compilation. So far, I can demonstrate that the
> > following two programs (if compiled) perform computation in the same time:
> >
> >
> >
> > 1)
> >
> >
> >
> > main =
> >
> > putStrLn $ show $ sum $ map (*(2::Int)) [(1::Int)..(100000000::Int)]
> >
> >
> >
> >
> >
> > 2)
> >
> >
> >
> > main =
> >
> > putStrLn $! show $! sumup 1 0
> >
> >
> >
> > sumup :: Int -> Int -> Int
> >
> > sumup n total =
> >
> > if n<=(100000000::Int) then sumup (n+1) $! total+(2*n)
> >
> > else total
> >
> >
> >
> >
> >
> > Nevertheless, I expect a question on comparison with C:
> >
> >
> >
> > 3)
> >
> >
> >
> > #include <stdio.h>
> >
> >
> >
> > int main(void) {
> >
> > long sum, i;
> >
> > sum = 0;
> >
> > for (i=1; i <= 100000000L; ++i) {
> >
> > sum += 2*i;
> >
> > }
> >
> > printf("%ld\n",sum);
> >
> > return 0;
> >
> > }
> >
> >
> >
> >
> >
> > Unfortunately, in this case the C is much more faster (it prints the
> > result immediately), at least on my machine. Is it due to a fact that C
> > compiler does a brutal optimization leading to compile-time evaluation,
> > while ghc is not able to do that?
> >
> >
> >
> > I'm using -O2 -dynamic --make ghc compiler flags. For gcc for C
> > compilation just -O2, running Arch Linux.
> >
> >
> >
> > Is there any option, how to force compile time evaluation? The reason, why
> > I think it works this way is the fact, that when running out of long type
> > values in C a code is generated that computes the values regularly
> > (providing misleading value as a result) taking its time.
> >
> >
> >
> > Best regards,
> >
> >
> >
> > Dušan
> >
> >
> >
> >
> >
> >
> >
> > _______________________________________________
> > Haskell-Cafe mailing list
> > To (un)subscribe, modify options or view archives go to:
> > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
> > Only members subscribed via the mailman list are allowed to post.
--
Dusan Kolar tel: +420 54 114 1238
UIFS FIT VUT Brno fax: +420 54 114 1270
Bozetechova 2 e-mail: kolar@fit.vutbr.cz
Brno 612 66
Czech Republic
--