Hello Khudyakov,
Sunday, February 22, 2009, 12:58:59 AM, you wrote:
>> you could even pass it in a test data set to which it must be optimized;
>> after the program is compiled, the compiler runs and profiles it, measures
>> the results, and does another pass to make it faster.
it supported in g
Oh I've again sent mail to wrong address
-- Forwarded Message --
On Saturday 21 February 2009 02:42:11 you wrote:
> On Sat, Feb 21, 2009 at 12:22 AM, Bulat Ziganshin
>
> > wrote:
> >
> > Hello Khudyakov,
> >
> > Saturday, February 21, 2009, 2:07:39 AM, you wrote:
> > > I have an
bulat.ziganshin:
> Hello John,
>
> Saturday, February 21, 2009, 3:42:24 AM, you wrote:
>
> >> this is true for *application* code, but for codec you may have lots of
> >> code that just compute, compute, compute
>
> > Yes indeed. If there is code like this out there for haskell, I would
> > love
Hello John,
Saturday, February 21, 2009, 3:42:24 AM, you wrote:
>> this is true for *application* code, but for codec you may have lots of
>> code that just compute, compute, compute
> Yes indeed. If there is code like this out there for haskell, I would
> love to add it as a test case for jhc.
But it is very misleading. It would be nice to have a log or
something similar to inform about the current state
://repetae.net/computer/jhc/jhc.shtml
> That is just there for historical reasons as my initial announcement.
>
> more up to date info is
>
> in the manual: http://repetae.net/computer
On Sat, Feb 21, 2009 at 01:20:14AM +0100, Alberto G. Corona wrote:
> John,
> please update the section "All is not well in jhc-land" because now
> things are better isn´t?
Ah, are you refering to this page?
http://repetae.net/computer/jhc/jhc.shtml
That is just there for historical reasons as my
On Sat, Feb 21, 2009 at 03:21:03AM +0300, Bulat Ziganshin wrote:
> >> what is "substantial size"? can jhc be used for video codec, i.e.
> >> probably no extensions - just raw computations, and thousands or tens
> >> of thousands LOCs?
>
> > Perhaps. A bigger issue in practice is that the larger a
Hello Xiao-Yong,
Saturday, February 21, 2009, 3:16:28 AM, you wrote:
>> some C++ compilers can already do this (profile based optimization).
>>
> Rumor says firefox needs profile based optimization to run
> faster. Or it is not a rumor at all.
why it's rumor? PGO is natural optimization techniq
Hello John,
Saturday, February 21, 2009, 2:49:25 AM, you wrote:
>> what is "substantial size"? can jhc be used for video codec, i.e.
>> probably no extensions - just raw computations, and thousands or tens
>> of thousands LOCs?
> Perhaps. A bigger issue in practice is that the larger a program i
John,
please update the section "All is not well in jhc-land" because now
things are better isn´t?
2009/2/21 John Meacham
>
> On Sat, Feb 21, 2009 at 02:24:59AM +0300, Bulat Ziganshin wrote:
> > Hello John,
> >
> > Saturday, February 21, 2009, 2:14:25 AM, you wrote:
> >
> > > Heh. He probably me
I think that a higuer level language has better opportunities to optimize,
specially if the compiler is coded in its own language. for example I guess
that a good type dependent implementation would evaluate
the sum[1..10^9::Int] at compilation time.
I reality haskell is much much faster than c in
Peter Verswyvelen writes:
> you could even pass it in a test data set to which it must be optimized;
> after the program is compiled,
> the compiler runs and profiles it, measures the results, and does another
> pass to make it faster.
>
> some C++ compilers can already do this (profile based o
On Sat, Feb 21, 2009 at 02:24:59AM +0300, Bulat Ziganshin wrote:
> Hello John,
>
> Saturday, February 21, 2009, 2:14:25 AM, you wrote:
>
> > Heh. He probably meant something more like "jhc is not a production
> > compiler" which is true for a lot of projects. For projects of
> > substantial size
On Sat, Feb 21, 2009 at 12:22 AM, Bulat Ziganshin wrote:
> Hello Khudyakov,
>
> Saturday, February 21, 2009, 2:07:39 AM, you wrote:
>
> > I have another question. Why shouldn't compiler realize that `sum
> [1..10^9]'
> > is constant and thus evaluate it at compile time?
>
> since we expect that c
Hello John,
Saturday, February 21, 2009, 2:14:25 AM, you wrote:
> Heh. He probably meant something more like "jhc is not a production
> compiler" which is true for a lot of projects. For projects of
> substantial size or that require many extensions, jhc falls somewhat
> short. It is getting bett
Hello Khudyakov,
Saturday, February 21, 2009, 2:07:39 AM, you wrote:
> I have another question. Why shouldn't compiler realize that `sum [1..10^9]'
> is constant and thus evaluate it at compile time?
since we expect that compilation will be done in reasonable amount of
time. you cannot guarante
On Fri, Feb 20, 2009 at 11:52:27PM +0100, Thomas Davie wrote:
>
> On 20 Feb 2009, at 23:44, Bulat Ziganshin wrote:
>
>> Hello John,
>>
>> Saturday, February 21, 2009, 1:33:12 AM, you wrote:
>>
>>> Don't forget jhc:
>>
>> i was pretty sure that jhc will be as fast as gcc :) unfortunately,
>> jhc isn
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 $ sum[1..10^9::Int]
>
> ... skipped ...
The discussion is mo
Bulat Ziganshin writes:
>> Don't forget jhc:
> i was pretty sure that jhc will be as fast as gcc :) unfortunately,
> jhc isn't our production compiler
Neither is GCC :-)
-k
--
If I haven't seen further, it is by standing in the footprints of giants
On 21 Feb 2009, at 00:01, Bulat Ziganshin wrote:
Hello Thomas,
Saturday, February 21, 2009, 1:52:27 AM, you wrote:
i was pretty sure that jhc will be as fast as gcc :) unfortunately,
jhc isn't our production compiler
Why not? There's nothing stopping you from choosing any Haskell
compile
Hello Thomas,
Saturday, February 21, 2009, 1:52:27 AM, you wrote:
>> i was pretty sure that jhc will be as fast as gcc :) unfortunately,
>> jhc isn't our production compiler
> Why not? There's nothing stopping you from choosing any Haskell
> compiler you like. If jhc gives you the performanc
On 20 Feb 2009, at 23:44, Bulat Ziganshin wrote:
Hello John,
Saturday, February 21, 2009, 1:33:12 AM, you wrote:
Don't forget jhc:
i was pretty sure that jhc will be as fast as gcc :) unfortunately,
jhc isn't our production compiler
Why not? There's nothing stopping you from choosing an
Hello John,
Saturday, February 21, 2009, 1:33:12 AM, you wrote:
> Don't forget jhc:
i was pretty sure that jhc will be as fast as gcc :) unfortunately,
jhc isn't our production compiler
--
Best regards,
Bulatmailto:bulat.zigans...@gmail.com
__
Don't forget jhc:
on my machine (with 'print' equivalent added to C one to be fair, and
10^9 changed to 1000*1000*1000 just like the C one)
ghc: (-O2)
time ./foo
./foo 2.26s user 0.00s system 99% cpu 2.273 total
gcc:
time ./a.out
./a.out 0.34s user 0.00s system 99% cpu 0.341 total
jhc:
time
Am Freitag, 20. Februar 2009 18:10 schrieb Bulat Ziganshin:
> Hello Don,
>
> Friday, February 20, 2009, 7:41:33 PM, you wrote:
> >> main = print $ sum[1..10^9::Int]
> >
> > This won't be comparable to your loop below, as 'sum' is a left fold
> > (which doesn't fuse under build/foldr).
> >
> > You s
bulat.ziganshin:
> Friday, February 20, 2009, 7:41:33 PM, you wrote:
>
> >> main = print $ sum[1..10^9::Int]
>
> > This won't be comparable to your loop below, as 'sum' is a left fold
> > (which doesn't fuse under build/foldr).
>
> > You should use the list implementation from the stream-fusion
On 20 Feb 2009, at 18:37, Bulat Ziganshin wrote:
Hello Thomas,
Friday, February 20, 2009, 8:22:33 PM, you wrote:
doesn't matter for testing speed
okay then, I wrote a faster Haskell version:
main = print "Hello world"
for you, any language will be fast enough :D
No C was very slow,
Hello Thomas,
Friday, February 20, 2009, 8:22:33 PM, you wrote:
>> doesn't matter for testing speed
> okay then, I wrote a faster Haskell version:
> main = print "Hello world"
for you, any language will be fast enough :D
--
Best regards,
Bulatmailto:bulat.zigans.
On 20 Feb 2009, at 18:10, Bulat Ziganshin wrote:
Well, that's a bit different. It doesn't print the result, and it
returns a different
results on 64 bit
doesn't matter for testing speed
okay then, I wrote a faster Haskell version:
main = print "Hello world"
Remember – being the sam
Hello Don,
Friday, February 20, 2009, 7:41:33 PM, you wrote:
>> main = print $ sum[1..10^9::Int]
> This won't be comparable to your loop below, as 'sum' is a left fold
> (which doesn't fuse under build/foldr).
> You should use the list implementation from the stream-fusion package (or
> uvector
bulat.ziganshin:
> 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:
Wonderful. Thank you!
> main = print $ sum[1..10^9::Int]
This won't be comparable to your loop below, as 'sum' is
Hey guys, what about the LLVM bindings? They seem nice for tight loops this one.
--
Felipe.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Hello David,
Friday, February 20, 2009, 6:52:03 PM, you wrote:
> In Haskell you're printing it... why not print it in C++?
in order to omit #include line
--
Best regards,
Bulatmailto:bulat.zigans...@gmail.com
___
Haske
On Friday 20 February 2009 10:52:03 am David Leimbach wrote:
> The GCC optimizer must know that you can't return a value to user space of
> that large as a return result.
>
> In Haskell you're printing it... why not print it in C++?
I actually changed my local copy to print out the result (since I
On Fri, Feb 20, 2009 at 6:39 AM, Dan Doel wrote:
> Sorry for replying to myself, but I got suspicious about the 6ms runtime of
> the 64-bit C++ code on my machine. So I looked at the assembly and found
> this:
>
>.LCFI1:
>movabsq $45, %rsi
>movl$_ZS
Hello Dan,
Friday, February 20, 2009, 5:39:25 PM, you wrote:
> Not that I'd be sad if GHC could reduce that whole constant at compile time,
> but GCC isn't doing 1 billion adds in 6 (or even 60) milliseconds.
yes, that's what was done actually:
22 0020 8D44D01C leal28(%eax,%e
Sorry for replying to myself, but I got suspicious about the 6ms runtime of
the 64-bit C++ code on my machine. So I looked at the assembly and found this:
.LCFI1:
movabsq
Test.hs
import Prelude hiding (sum, enumFromTo)
import Data.List.Stream (sum, unfoldr)
enumFromTo m n = unfoldr f m
where f k | k <= n= Just (k,k+1)
| otherwise = Nothing
main = print . sum $ enumFromTo 1 (10^9 :: Int)
snip
do...@zeke % time ./Test
Hello Miguel,
Friday, February 20, 2009, 4:48:15 PM, you wrote:
> Ahem. Seems like you've included time spent on the runtime loading.
for C, i've used additional 100x loop
> sys 0m0.002s
> sys 0m0.017s
> While 3.201 vs. 0.066 seem to be a huge difference, 0.017 vs. 0.002 is
> not that
Forget it, my bad.
On 20 Feb 2009, at 16:48, Miguel Mitrofanov wrote:
Ahem. Seems like you've included time spent on the runtime loading.
My results:
MigMit:~ MigMit$ gcc -o test -O3 -funroll-loops test.c && time ./test
-1243309312
real0m0.066s
user0m0.063s
sys 0m0.002s
MigMit:~ M
Ahem. Seems like you've included time spent on the runtime loading.
My results:
MigMit:~ MigMit$ gcc -o test -O3 -funroll-loops test.c && time ./test
-1243309312
real0m0.066s
user0m0.063s
sys 0m0.002s
MigMit:~ MigMit$ rm test; ghc -O2 --make test.hs && time ./test
Linking test ...
-2
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 $ sum[1..10^9::Int]
main = print $ sum0 (10^9) 0
sum0 :: Int -> Int -> Int
sum0 0 !acc = acc
sum0 !x !acc = sum0 (x-1) (acc+x)
42 matches
Mail list logo
