Bulat Ziganshin ha scritto:
[...]
but problem - not mine, but for haskellers, is that some people said
that ghc can generate code that is as fast as gcc one. it will be
stupid if someone will start to write say mpeg4 codec and after year
of work will find that it need 100 Ghz cpu to work.
Most people in the games industry that I knew don't even know haskell. they
are trained imperative hackers.
However tim sweeney studies haskell, so it cetainly has influenced at least
one well known game developer.
But I wasn't saying that Haskell *is* used, I said one could use it for
nothing should stop you from writing video games in Haskell since
video codec isn't video game :)))
ouch, mea culpa, I misread your message.
but I've worked with people that wrote physics engines in C/C++,
and they also had to hand optimize specifically for a certain compiler to
get
Hello Louis,
Saturday, February 21, 2009, 4:16:10 AM, you wrote:
In the meantime, a brief summary:
a minor correction: the best gcc result shown in the thread was 50x
faster than Don's one, so you need to miltiple all ratios by a factor
of 50
Straightforward and simple Haskell code, written
Observation:
The best gcc result shown in the thread, if I recall, precomputed the result
of the full computation at compiletime and simply outputted it, when we
looked at the assembly.
While I will accept that this could be seen as an optimization GHC should
have made, I do not accept that this
Am Sonntag, 22. Februar 2009 00:21 schrieb Bulat Ziganshin:
Hello Louis,
Saturday, February 21, 2009, 4:16:10 AM, you wrote:
In the meantime, a brief summary:
a minor correction: the best gcc result shown in the thread was 50x
faster than Don's one, so you need to miltiple all ratios by a
Hello Louis,
Sunday, February 22, 2009, 2:30:23 AM, you wrote:
yes, you are right. Don also compared results of 64x-reduced
computation with full one. are you think that these results are more
fair?
Observation:
The best gcc result shown in the thread, if I recall, precomputed
the result of
Hello Daniel,
Sunday, February 22, 2009, 2:36:57 AM, you wrote:
You're referring to the freak result of Dan Doel?
Come on, be serious, please. I have a Haskell result that runs in 7ms, too.
Just use a rewrite rule and hey presto :)
Dan, why you have not said the same about test where ghc
I said nothing about fairness, and *never at any point said I thought Don's
results were more useful or fair.* What makes you think that's what I meant
to imply?
You have not responded to my separate concern that
For code that actively requires computation at runtime, I have seen
no examples
On Sat, Feb 21, 2009 at 11:35 PM, Bulat Ziganshin bulat.zigans...@gmail.com
wrote:
Hello Louis,
Sunday, February 22, 2009, 2:30:23 AM, you wrote:
yes, you are right. Don also compared results of 64x-reduced
computation with full one. are you think that these results are more
fair?
Yes.
Sebastian, that's not Bulat's point. He's saying that if we make that
optimization in Haskell, we should at least make the same optimization in
GCC for fair comparison. (Though I'm not entirely sure that that
optimization would be of any use to GCC, but that's a linguistic concern, no
more.)
No, he asked if comparing the D64 version with the straight gcc one was
more fair then comparing a version that precomputes the result with one
that doesn't. That's what I responded to.
On Sat, Feb 21, 2009 at 11:59 PM, Louis Wasserman wasserman.lo...@gmail.com
wrote:
Sebastian, that's not
Am Sonntag, 22. Februar 2009 00:50 schrieb Bulat Ziganshin:
Hello Daniel,
Sunday, February 22, 2009, 2:36:57 AM, you wrote:
You're referring to the freak result of Dan Doel?
Come on, be serious, please. I have a Haskell result that runs in 7ms,
too. Just use a rewrite rule and hey presto
Hello Sebastian,
Sunday, February 22, 2009, 2:55:38 AM, you wrote:
yes, you are right. Don also compared results of 64x-reduced
computation with full one. are you think that these results are more
fair?
Yes. Clearly so.
It still computes the result from scratch - it just uses a trick
On Sun, Feb 22, 2009 at 12:10 AM, Bulat Ziganshin bulat.zigans...@gmail.com
wrote:
Hello Sebastian,
Sunday, February 22, 2009, 2:55:38 AM, you wrote:
yes, you are right. Don also compared results of 64x-reduced
computation with full one. are you think that these results are more
Hello Louis,
Sunday, February 22, 2009, 2:59:05 AM, you wrote:
Sebastian, that's not Bulat's point. He's saying that if we make
that optimization in Haskell, we should at least make the same
optimization in GCC for fair comparison. (Though I'm not entirely
sure that that optimization would
Bulat, you've some serious lessons to learn on how to interact with
online communities. First,
1. Stop posting replies to every post on this thread
2. Read some of the fine literature on how to be a productive,
contributing member of a mailing list community,
Bulat,
Thank you for being productive. =)
of course these results are useful! my own goal was just to make fair
comparison. i'm bothered when people said that ghc should be used
for something like video codecs based on those let's optimize only
for haskell pseudo-benchmarks. if Don was omitted
It's not practical at all. It's monstrously more complicated than C.
It would be much simpler to do it in C and use FFI.
Regards,
John A. De Goes
N-BRAIN, Inc.
The Evolution of Collaboration
http://www.n-brain.net|877-376-2724 x 101
On Feb 21, 2009, at 4:55 PM, Sebastian Sylvan
I think this thread has stopped being useful and started going round in
circles, so I've blocked all messages to it and...
On Sat, Feb 21, 2009 at 04:28:21PM -0800, Donald Bruce Stewart wrote:
I'm setting your moderation bit now
...reverted this.
Thanks
Ian
Bulat Ziganshin bulat.zigans...@gmail.com wrote:
execution times:
sum:
ghc 6.6.1 -O2 : 12.433 secs
ghc 6.10.1 -O2 : 12.792 secs
sum-fast:
ghc 6.6.1 -O2 : 1.919 secs
ghc 6.10.1 -O2 : 1.856 secs
ghc 6.10.1 -O2 -fvia-C
On a G4:
s.hs (which does not need bang patterns) is:
main = seq (sum0 (10^9) 0) (return ())
sum0 :: Int - Int - Int
sum0 0 acc = acc
sum0 x acc = sum0 (x-1) $! (acc+x)
And s.c is (actually including 10^9, which Bulat's did not):
main()
{
int sum=0;
for(int i=1000*1000*1000; i0; i--)
When I change the C++ program into:
int n;
scanf(%d, n);
for(i=0; in;i++)
{
sum += i;
}
GCC need 100 milliseconds on my 3.0GHz new Xeon with loop unrolling
enabled.
Without loop unrolling GCC needs about 635ms
Visual C++ does it in 577 ms, generating the following code:
loop: add
Hello Achim,
Friday, February 20, 2009, 5:44:44 PM, you wrote:
Nice! Now we know that gcc can calculate faster than Haskell can
calculate and print. Next time, use exitWith, please.
it was done in order to simplify sources. are you really believe that
ghc needs more than 1 millisecond to
Peter == Peter Verswyvelen bugf...@gmail.com writes:
Peter So GHC is about 3 to 4 times slower as Visual C++ / GCC
Peter without loop unrolling, which is not too bad since GHC does
Peter not perform register optimization and loop unrolling yet
Peter no?
I would call it rather
Hello Peter,
Friday, February 20, 2009, 6:18:50 PM, you wrote:
So GHC is about 3 to 4 times slower as Visual C++ / GCC without
loop unrolling
why stop on disabling loop unrolling? there are lot of options we can
use if we want to make gcc slower :D
--
Best regards,
Bulat
Bulat Ziganshin bulat.zigans...@gmail.com wrote:
Hello Achim,
Friday, February 20, 2009, 5:44:44 PM, you wrote:
Nice! Now we know that gcc can calculate faster than Haskell can
calculate and print. Next time, use exitWith, please.
it was done in order to simplify sources. are you
Well C# does it with a for loop in 2300ms, and when using a IEnumerable
sequence it needs 19936ms. Very much like the Haskell code. But of course
the Haskell code could optimize the sum I guess, I assume it is using the
lazy version of sum by default.
Anyway it was more of a question. Does GHC
Hello Achim,
Friday, February 20, 2009, 6:25:31 PM, you wrote:
it was done in order to simplify sources. are you really believe that
ghc needs more than 1 millisecond to print one number? :)
Well, I know that (Show a) is about as slow as you can get.
yes, but it's printed only once against
Hello Peter,
Friday, February 20, 2009, 6:34:04 PM, you wrote:
Well C# does it with a for loop in 2300ms, and when using a
IEnumerable sequence it needs 19936ms. Very much like the Haskell
code. But of course the Haskell code could optimize the sum I guess,
I assume it is using the lazy
Bulat Ziganshin bulat.zigans...@gmail.com wrote:
Hello Peter,
Friday, February 20, 2009, 6:34:04 PM, you wrote:
Well C# does it with a for loop in 2300ms, and when using a
IEnumerable sequence it needs__19936ms. Very much like the Haskell
code. But of course the Haskell code could
Don Stewart d...@galois.com wrote:
No! This is not how open source works! You *should submit bug
reports* and *analysis*. It is so so much more useful than
complaining and throwing stones.
Exactly. I don't know where, but I read that the vast majorities of
Linux bugs are reported, nailed, and
barsoap:
Don Stewart d...@galois.com wrote:
No! This is not how open source works! You *should submit bug
reports* and *analysis*. It is so so much more useful than
complaining and throwing stones.
Exactly. I don't know where, but I read that the vast majorities of
Linux bugs are
Concrete examples always help, thanks.
Turning this into a ticket with associated test will:
- enable others to find and repeat the test when this thread is long gone,
to see whether any other ghc changes have helped in any way
- enable documentation of what exactly the issue is (why is it
Hello Claus,
Friday, February 20, 2009, 11:15:59 PM, you wrote:
Turning this into a ticket with associated test will:
but why you think that this is untypical and needs a ticket? ;)
--
Best regards,
Bulatmailto:bulat.zigans...@gmail.com
Don Stewart d...@galois.com wrote:
(The bang patterns aren't needed). Note how he counts backwards from
10^9. Was there a reason for that, Bulat?
Tests against zero are faster, as you don't need a second operand... by
now, some platforms might be smart enough, but down-counting in loops
is
Bulat Ziganshin bulat.zigans...@gmail.com wrote:
Hello Claus,
Friday, February 20, 2009, 11:15:59 PM, you wrote:
Turning this into a ticket with associated test will:
but why you think that this is untypical and needs a ticket? ;)
Bulat, you are right in every aspect. You never did
claus.reinke:
Concrete examples always help, thanks.
In simple enough situations, one can roll one's own loop unrolling;),
somewhat like shown below (worker/wrapper split to bring the function
parameter representing the loop body into scope, then template haskell
to unroll its applications
Hello Achim,
Friday, February 20, 2009, 11:44:49 PM, you wrote:
Turning this into a ticket with associated test will:
but why you think that this is untypical and needs a ticket? ;)
Bulat, you are right in every aspect. You never did anything wrong.
Achim, this is simplest code one can
bulat.ziganshin:
Hello Achim,
Friday, February 20, 2009, 11:44:49 PM, you wrote:
Turning this into a ticket with associated test will:
but why you think that this is untypical and needs a ticket? ;)
Bulat, you are right in every aspect. You never did anything wrong.
Achim,
dons:
bulat.ziganshin:
Hello Achim,
Friday, February 20, 2009, 11:44:49 PM, you wrote:
Turning this into a ticket with associated test will:
but why you think that this is untypical and needs a ticket? ;)
Bulat, you are right in every aspect. You never did anything
On Fri, Feb 20, 2009 at 12:44 PM, Achim Schneider bars...@web.de wrote:
Bulat, you are right in every aspect. You never did anything wrong.
Back when you debugged your code all night long, you were only
dreaming.
Achim, this doesn't seem like a constructive way to respond. Bulat's already
Don Stewart ha scritto:
dons:
bulat.ziganshin:
Hello Achim,
Friday, February 20, 2009, 11:44:49 PM, you wrote:
Turning this into a ticket with associated test will:
but why you think that this is untypical and needs a ticket? ;)
Bulat, you are right in every aspect. You never did
Bulat Ziganshin bulat.zigans...@gmail.com wrote:
so - why YOU think that ghc
generates fast code and this example is something unusual?
I think ghc has decent performance, and that there's room for
improvement. I don't care whether you compare it to gcc,
malbolge, or hand-written assembly,
Hello Manlio,
Saturday, February 21, 2009, 12:54:00 AM, you wrote:
ghc -O2 naive left fold15.680
As a full comparison I would like to see time for
ghc -O0 naive left fold
he is still waiting :))) but that's really has only theoretical
interest, comparing ghc -O2 on
Bryan O'Sullivan b...@serpentine.com wrote:
On Fri, Feb 20, 2009 at 12:44 PM, Achim Schneider bars...@web.de
wrote:
Bulat, you are right in every aspect. You never did anything wrong.
Back when you debugged your code all night long, you were only
dreaming.
Achim, this doesn't
On 20 Feb 2009, at 22:57, Bulat Ziganshin wrote:
Hello Don,
Saturday, February 21, 2009, 12:43:46 AM, you wrote:
gcc -O3 -funroll-loops 0.318
ghc -funroll-loops -D64 0.088
So what did we learn here?
nothing new: what you are not interested
Bulat Ziganshin bulat.zigans...@gmail.com wrote:
Hello Don,
Saturday, February 21, 2009, 12:43:46 AM, you wrote:
gcc -O3 -funroll-loops 0.318
ghc -funroll-loops -D64 0.088
So what did we learn here?
nothing new: what you are not
Hello Achim,
Saturday, February 21, 2009, 12:54:33 AM, you wrote:
so - why YOU think that ghc
generates fast code and this example is something unusual?
I think ghc has decent performance, and that there's room for
improvement. I don't care whether you compare it to gcc,
i'm asking
Hello Achim,
Saturday, February 21, 2009, 1:17:08 AM, you wrote:
nothing new: what you are not interested in real compilers comparison,
preferring to demonstrate artificial results
...that we have a path to get better results than gcc -O3
-funroll-loops, and it's within reach... we even can
On 20 Feb 2009, at 23:33, Bulat Ziganshin wrote:
Hello Achim,
Saturday, February 21, 2009, 1:17:08 AM, you wrote:
nothing new: what you are not interested in real compilers
comparison,
preferring to demonstrate artificial results
...that we have a path to get better results than gcc -O3
Hello Thomas,
Saturday, February 21, 2009, 1:19:47 AM, you wrote:
I'm not sure what you're getting at Bulat √ it's been demonstrated
that ghc is slower than gcc for most cases at the moment (many
benchmarks will back this up), *however*, it's also easily verified
that ghc has had
On 20 Feb 2009, at 23:41, Bulat Ziganshin wrote:
Hello Thomas,
Saturday, February 21, 2009, 1:19:47 AM, you wrote:
I'm not sure what you're getting at Bulat √ it's been demonstrated
that ghc is slower than gcc for most cases at the moment (many
benchmarks will back this up), *however*, it's
Hello Thomas,
Saturday, February 21, 2009, 1:41:24 AM, you wrote:
You need look no further than the debian language shootout that things
really aren't as bad as you're making out √ Haskell comes in in
general less than 3x slower than gcc compiled C.
you should look inside these tests, as i
2009/2/20 Bulat Ziganshin bulat.zigans...@gmail.com:
Hello Thomas,
Saturday, February 21, 2009, 1:19:47 AM, you wrote:
I'm not sure what you're getting at Bulat √ it's been demonstrated
that ghc is slower than gcc for most cases at the moment (many
benchmarks will back this up), *however*,
On 20 Feb 2009, at 23:52, Bulat Ziganshin wrote:
Hello Thomas,
Saturday, February 21, 2009, 1:41:24 AM, you wrote:
You need look no further than the debian language shootout that
things
really aren't as bad as you're making out √ Haskell comes in in
general less than 3x slower than gcc
Hello Thomas,
Saturday, February 21, 2009, 1:41:24 AM, you wrote:
so, again: this confirms that Don is always build artificial
comparisons, optimizing Haskell code by hand and ignoring obvious ways
You need look no further than the debian language shootout that things
and yes - this is the
bulat.ziganshin:
Hello Achim,
Saturday, February 21, 2009, 1:17:08 AM, you wrote:
nothing new: what you are not interested in real compilers comparison,
preferring to demonstrate artificial results
...that we have a path to get better results than gcc -O3
-funroll-loops, and it's
Thomas Davie wrote:
You need look no further than the debian language shootout that things
really aren't as bad as you're making out – Haskell comes in in general
less than 3x slower than gcc compiled C.
Of note, of all the managed languages, this is about the fastest – none
of the other
On 21 Feb 2009, at 00:10, Ahn, Ki Yung wrote:
Thomas Davie wrote:
You need look no further than the debian language shootout that
things really aren't as bad as you're making out – Haskell comes in
in general less than 3x slower than gcc compiled C.
Of note, of all the managed languages,
Hello Thomas,
Saturday, February 21, 2009, 1:55:33 AM, you wrote:
most of these tests depends on libraries speed. in one test, PHP is
1st. from 2 or 3 tests that depends on compiler speed, one was fooled
by adding special function readInt to ghc libs and the rest are
written in low-level
Hello Don,
Saturday, February 21, 2009, 1:55:19 AM, you wrote:
This is extremely depressing to read after the good results and lessons of
this thread.
you misunderstand, it is not personal! We just want something to
sarcasm on. Something specific.
--
Best regards,
Bulat
Bulat Ziganshin bulat.zigans...@gmail.com wrote:
but problem - not mine, but for haskellers, is that some people said
that ghc can generate code that is as fast as gcc one. it will be
stupid if someone will start to write say mpeg4 codec and after year
of work will find that it need 100 Ghz
nothing should stop you from writing video games in Haskell since the
control logic of many video games is written in e.g. a scripting language
like LUA :-)
sure if you want to write a physics engine in Haskell, that's something
else.
but I've worked with people that wrote physics engines in
Khudyakov Alexey alexey.sklad...@gmail.com wrote:
On Friday 20 February 2009 16:29:29 Bulat Ziganshin wrote:
Hello haskell-cafe,
since there are no objective tests comparing ghc to gcc, i made my
own one. these are 3 programs, calculating sum in c++ and haskell:
main = print $
On Fri, Feb 20, 2009 at 10:33 PM, Bulat Ziganshin bulat.zigans...@gmail.com
wrote:
Hello Achim,
Saturday, February 21, 2009, 1:17:08 AM, you wrote:
nothing new: what you are not interested in real compilers comparison,
preferring to demonstrate artificial results
...that we have a
Hello Peter,
Saturday, February 21, 2009, 2:36:15 AM, you wrote:
nothing should stop you from writing video games in Haskell since
video codec isn't video game :)))
but I've worked with people that wrote physics engines in C/C++,
and they also had to hand optimize specifically for a certain
Turning this into a ticket with associated test will:
but why you think that this is untypical and needs a ticket? ;)
Because generally ghc is doing a good-enough job. And it is doing
that because long ago, ghc hq's war cry was if ghc generates code
that is slower than any other haskell
Now perhaps I'll be stepping into some lines of fire as it seems like
this thread is full of them. If I get in anyone's way please kindly
hold your shot ;-)
That said, video codecs are the kinds of things that usually benefit
greatly from vectorization and parallelization right? These are
On Fri, Feb 20, 2009 at 11:51:43PM +0100, Thomas Davie wrote:
of course. what fool will say that ghc cannot be optimized the same
way as gcc? if we spent the same amount of time for improving ghc
back-end as was spent for gcc (tens or hundreds man-years?), then
*low-level* Haskell code will
Peter Verswyvelen bugf...@gmail.com wrote:
nothing should stop you from writing video games in Haskell
Show me a studio that uses Haskell and I'd even accept dollars or pounds
as payment.
--
(c) this sig last receiving data processing entity. Inspect headers
for copyright history. All rights
Hello Sebastian,
Saturday, February 21, 2009, 2:42:33 AM, you wrote:
Bulat, please, you're missing the point.
actually you are missing the point. i mirror Don's
non-attacking style of comments on my person. are you mentioned
those Don letter? sure - no
Nobody is saying that the
Hello Achim,
Saturday, February 21, 2009, 2:37:55 AM, you wrote:
not having enough weight in the shootout. For now, you can just use TH
to force things getting evaluated. (Try to do that in C)
they have Templates axe too :)
--
Best regards,
Bulat
--- On Fri, 2/20/09, Bulat Ziganshin bulat.zigans...@gmail.com wrote:
-snip-
You need look no further than the debian language
shootout that things
really aren't as bad as you're making out √
Haskell comes in in
general less than 3x slower than gcc compiled C.
you should look
Hello Isaac,
Saturday, February 21, 2009, 3:28:31 AM, you wrote:
When did you look - six months ago? a year ago? 3 years ago?
ah, again this argument. two weeks ago Don said that ghc changed a lot
in 2 years, now when we see that there is no difference, he says that
those loop optimizer is
On Sat, Feb 21, 2009 at 12:16 AM, Bulat Ziganshin bulat.zigans...@gmail.com
wrote:
Hello Sebastian,
Saturday, February 21, 2009, 2:42:33 AM, you wrote:
Bulat, please, you're missing the point.
actually you are missing the point. i mirror Don's
non-attacking style of comments on my
I was intending to send this privately but clicked the wrong button.
Apologies for adding even more noise to this discussion.
On Sat, Feb 21, 2009 at 12:47 AM, Sebastian Sylvan
syl...@student.chalmers.se wrote:
On Sat, Feb 21, 2009 at 12:16 AM, Bulat Ziganshin
bulat.zigans...@gmail.com
I am no longer sure that this conversation is producing useful information
or a learning experience for any involved party, and suggest it ends.
In the meantime, a brief summary:
- Straightforward and simple Haskell code, written by an individual aware
of issues with tail recursion and
--- On Fri, 2/20/09, Bulat Ziganshin bulat.zigans...@gmail.com wrote:
From: Bulat Ziganshin bulat.zigans...@gmail.com
Subject: Re[4]: [Haskell-cafe] Re: speed: ghc vs gcc
To: Isaac Gouy igo...@yahoo.com
Cc: haskell-cafe@haskell.org
Date: Friday, February 20, 2009, 4:43 PM
Hello Isaac
Don Stewart wrote:
If we take what I usually see as the best loops GHC can do for this kind
of thing:
import Data.Array.Vector
main = print (sumU (enumFromToU 1 (10^9 :: Int)))
And compile it:
$ ghc-core A.hs -O2 -fvia-C -optc-O3
We get ideal core, all data structures
bertram.felgenhauer:
This is odd, but it doesn't hurt the inner loop, which only involves
$wsum01_XPd, and is identical to $wfold_s15t above.
Checking the asm:
$ ghc -O2 -fasm
sQ3_info:
.LcRt:
cmpq 8(%rbp),%rsi
jg .LcRw
leaq 1(%rsi),%rax
81 matches
Mail list logo
