Re: [Haskell-cafe] Climbing up the shootout...

Don Stewart ha scritto: [...] There is a lot of efforts to improve CPU time, but what about memory usage? http://shootout.alioth.debian.org/u64q/benchmark.php?test=all&lang=ghc&lang2=ghc No one is looking at memory at the moment, as the parallel/multicore profiler isn't working in 6.8.2. B

Re: [Haskell-cafe] Climbing up the shootout...

manlio_perillo: > Don Stewart ha scritto: > >Thanks to those guys who've submitted parallel programs to the language > >benchmarks game, we're climbing up the rankings, now in 3rd, and ahead > >of C :) > > > >http://shootout.alioth.debian.org/u64q/benchmark.php?test=all&lang=all > > > >Just one

Re: [Haskell-cafe] Climbing up the shootout...

Don Stewart ha scritto: Thanks to those guys who've submitted parallel programs to the language benchmarks game, we're climbing up the rankings, now in 3rd, and ahead of C :) http://shootout.alioth.debian.org/u64q/benchmark.php?test=all&lang=all Just one or two more parallel programs requir

Re[2]: [Haskell-cafe] Climbing up the shootout...

Hello Ketil, Thursday, September 25, 2008, 8:57:05 PM, you wrote: > "John Van Enk" <[EMAIL PROTECTED]> writes: >> 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

Re: [Haskell-cafe] Climbing up the shootout...

"John Van Enk" <[EMAIL PROTECTED]> writes: > 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? Or they could just FFI to the Haskell libraries

Re[16]: [Haskell-cafe] Climbing up the shootout...

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

Re: [Haskell-cafe] Climbing up the shootout...

Hallo, John Van Enk wrote: > 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? > Maybe they don't care

Re: Re[14]: [Haskell-cafe] Climbing up the shootout...

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 <[EMAIL PROTECTE

Re[14]: [Haskell-cafe] Climbing up the shootout...

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

Re: Re[12]: [Haskell-cafe] Climbing up the shootout...

On Wed, Sep 24, 2008 at 11:20 PM, Bulat Ziganshin <[EMAIL PROTECTED]> 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 won

Re[12]: [Haskell-cafe] Climbing up the shootout...

Hello Brandon, Thursday, September 25, 2008, 12:43:55 AM, you wrote: >> as i said, eddorts to optimize Haskell code is several times larger >> while the result is several times slower > ...and we're back to "dons demonstrated otherwise, so you have to > invent reasons to disqualify him". If a

Re[12]: [Haskell-cafe] Climbing up the shootout...

Hello Brandon, Thursday, September 25, 2008, 12:43:55 AM, you wrote: >> as i said, eddorts to optimize Haskell code is several times larger >> while the result is several times slower > ...and we're back to "dons demonstrated otherwise, so you have to please show me example that you mean and

Re: Re[10]: [Haskell-cafe] Climbing up the shootout...

On Sep 24, 2008, at 15:20 , Bulat Ziganshin wrote: Wednesday, September 24, 2008, 11:13:14 PM, you wrote: can come up with, including amorphous and vacuous ones" (you can almost always write something faster, but with how much effort?) as i said, eddorts to optimize Haskell code is several tim

Re[10]: [Haskell-cafe] Climbing up the shootout...

Hello Brandon, Wednesday, September 24, 2008, 11:13:14 PM, you wrote: > can come up with, including amorphous and vacuous ones" (you can > almost always write something faster, but with how much effort?) as i said, eddorts to optimize Haskell code is several times larger while the result is seve

Re: Re[8]: [Haskell-cafe] Climbing up the shootout...

On Sep 24, 2008, at 13:44 , Bulat Ziganshin wrote: (note how he keeps trying to run dons out of the discussion because he has proof to the contrary). Don os free to present such examples. unfortunately all examples i've seen was due to use of slow C code which easily can be made faster. in pa

Re[8]: [Haskell-cafe] Climbing up the shootout...

Hello Brandon, Wednesday, September 24, 2008, 9:36:56 PM, you wrote: > Because he's convinced himself it's pointless because Haskell will > never be able to run faster than C taking into account that C compilers are very close to maximum speed possible, and this required many years of developemn

Re: Re[6]: [Haskell-cafe] Climbing up the shootout...

On Sep 22, 2008, at 18:53 , Donnie Jones wrote: I'm fairly new to Haskell and the Haskell community, but I can say from my experience of hacking on GHC, the GHC team of developers are very interested in performance improvements, e.g. this thread is about performance! So Bulat, why don't you

Re: Re[2]: [Haskell-cafe] Climbing up the shootout...

On Sep 22, 2008, at 20:16 , Bulat Ziganshin wrote: Ok. So I'll just say: high level, efficient code is an overriding theme of many individuals working on Haskell. Things are better and better each year. We do not stand still. yes. when we say that things are greatly improving each year, this

Re: Re[8]: [Haskell-cafe] Climbing up the shootout...

On Tue, Sep 23, 2008 at 2:52 PM, Bulat Ziganshin <[EMAIL PROTECTED]>wrote: > Hello John, > > Tuesday, September 23, 2008, 5:39:17 PM, you wrote: > > > Probably not, but I think you completely missed my point. Perhaps I > > should have originally written "my original C equivalents" rather > > than

Re[10]: [Haskell-cafe] Climbing up the shootout...

Hello Donnie, Tuesday, September 23, 2008, 7:16:04 PM, you wrote: > I don't understand why you are willing to criticize GHC, but > unwilling to help improve GHC.  Personally, I think it is a waste of > everyone's time for you to just complain about GHC without offering > suggestions on how to imp

Re[8]: [Haskell-cafe] Climbing up the shootout...

Hello John, Tuesday, September 23, 2008, 5:39:17 PM, you wrote: > Probably not, but I think you completely missed my point. Perhaps I > should have originally written "my original C equivalents" rather > than "the". You're probably just a better C programmer than me. well, i don't say about me p

Re: Re[6]: [Haskell-cafe] Climbing up the shootout...

Probably not, but I think you completely missed my point. Perhaps I should have originally written "my original C equivalents" rather than "the". You're probably just a better C programmer than me. On Tue, Sep 23, 2008 at 9:25 AM, Bulat Ziganshin <[EMAIL PROTECTED]>wrote: > Hello John, > > Tuesda

Re[6]: [Haskell-cafe] Climbing up the shootout...

Hello John, Tuesday, September 23, 2008, 4:27:05 PM, you wrote: >> amount of work required to do this is much much more than amount of work >> required to write optimal C/asm code > I'm sorry, but no it's not. I've been using Haskell for a little > under two years now, and I'm already able to p

Re: Re[4]: [Haskell-cafe] Climbing up the shootout...

> amount of work required to do this is much much more than amount of work required to write optimal C/asm code I'm sorry, but no it's not. I've been using Haskell for a little under two years now, and I'm already able to produce programs with significantly less pain which outperform the C equival

Re[2]: [Haskell-cafe] Climbing up the shootout...

Hello Manlio, Tuesday, September 23, 2008, 3:43:03 PM, you wrote: >>> Maybe improve GHC to make Haskell suitable to write high reliable >>> internet servers is not of interest? >> >> well if it's interesting - do it :) > Unfortunately, I no more have the time for "do it your self", unless >

Re: [Haskell-cafe] Climbing up the shootout...

Bulat Ziganshin ha scritto: Hello Manlio, Tuesday, September 23, 2008, 3:14:58 PM, you wrote: Maybe improve GHC to make Haskell suitable to write high reliable internet servers is not of interest? well if it's interesting - do it :) Unfortunately, I no more have the time for "do it your

Re[2]: [Haskell-cafe] Climbing up the shootout...

Hello Manlio, Tuesday, September 23, 2008, 3:14:58 PM, you wrote: > Maybe improve GHC to make Haskell suitable to write high reliable > internet servers is not of interest? well if it's interesting - do it :) various people do that they find most exciting/important. actually, alt-network packag

Re: [Haskell-cafe] Climbing up the shootout...

Bulat Ziganshin ha scritto: Hello Manlio, Tuesday, September 23, 2008, 1:36:16 PM, you wrote: Any roadmap for improve support in intensive IO multiplexing? Or, at least, some papers about how this is implemented in GHC? Af far as I understand, select is used in two separate places. How much

Re[2]: [Haskell-cafe] Climbing up the shootout...

Hello Jules, Tuesday, September 23, 2008, 2:21:34 PM, you wrote: >> performance. what we have on prcatice is 10-20% speedup of ghc 6.8 and >> several libs which may improve speed in some usages > If you understand performance as well as you claim to - and from your > previous postings, I believ

Re: [Haskell-cafe] Climbing up the shootout...

Bulat Ziganshin wrote: and this work obviously doesn't speed up every Haskell program. so that we have in Haskell world now is heroic efforts to speed up shootout test which doesn't say anything about real Haskell performance. what we have on prcatice is 10-20% speedup of ghc 6.8 and several libs

Re[2]: [Haskell-cafe] Climbing up the shootout...

Hello Manlio, Tuesday, September 23, 2008, 1:36:16 PM, you wrote: > Any roadmap for improve support in intensive IO multiplexing? > Or, at least, some papers about how this is implemented in GHC? > Af far as I understand, select is used in two separate places. > How much effort it takes to imple

Re[4]: [Haskell-cafe] Climbing up the shootout...

Hello Sterling, Tuesday, September 23, 2008, 5:13:57 AM, you wrote: > Oh, and it "simply and naively" loops with the following: > while (fgets_unlocked (line, MAXLINELEN, stdin)) > If Bulat's point is that the shootout has inspired work on Haskell > performance, and in the stdlibs no less, then

Re: [Haskell-cafe] Climbing up the shootout...

Don Stewart ha scritto: [...] Ok. So I'll just say: high level, efficient code is an overriding theme of many individuals working on Haskell. Things are better and better each year. We do not stand still. Any roadmap for improve support in intensive IO multiplexing? Or, at least, some papers a

Re: Re[2]: [Haskell-cafe] Climbing up the shootout...

At the risk of getting sucked into a silly discussion, I'd like to point out that the c code uses the following "really simple and naive" function: http://sourceware.org/cgi-bin/cvsweb.cgi/libc/stdlib/strtol.c?rev=1.42.2.2&content-type=text/x-cvsweb-markup&cvsroot=glibc http://sourceware.org/cgi

Re[4]: [Haskell-cafe] Climbing up the shootout...

Hello Chaddaï, Tuesday, September 23, 2008, 4:39:18 AM, you wrote: >> it isn't the same as readInt which was added specifically for this >> test. it doesn't support arbitrary-size streams and doesn't return >> rest of stream > I think we should write all the entries in Haskell98 and disable any

Re[2]: [Haskell-cafe] Climbing up the shootout...

Hello Don, Tuesday, September 23, 2008, 4:36:55 AM, you wrote: >> it isn't the same as readInt which was added specifically for this >> test. it doesn't support arbitrary-size streams and doesn't return >> rest of stream >> > Hmm? That is wrong. These functions explicitly work on arbitrarily lo

Re: Re[2]: [Haskell-cafe] Climbing up the shootout...

2008/9/23 Bulat Ziganshin <[EMAIL PROTECTED]>: > Hello Don, > > Tuesday, September 23, 2008, 4:22:19 AM, you wrote: > >> bulat.ziganshin: >>> when gcc developers will start to add to C libraries functions >>> performing shootout benchmarks we will continue this discussion :D > >> atoi(3). > > it is

Re: [Haskell-cafe] Climbing up the shootout...

bulat.ziganshin: > Hello Don, > > Tuesday, September 23, 2008, 4:22:19 AM, you wrote: > > > bulat.ziganshin: > >> when gcc developers will start to add to C libraries functions > >> performing shootout benchmarks we will continue this discussion :D > > > atoi(3). > > it isn't the same as readIn

Re[2]: [Haskell-cafe] Climbing up the shootout...

Hello Don, Tuesday, September 23, 2008, 4:22:19 AM, you wrote: > bulat.ziganshin: >> when gcc developers will start to add to C libraries functions >> performing shootout benchmarks we will continue this discussion :D > atoi(3). it isn't the same as readInt which was added specifically for this

Re: [Haskell-cafe] Climbing up the shootout...

bulat.ziganshin: > when gcc developers will start to add to C libraries functions > performing shootout benchmarks we will continue this discussion :D atoi(3). -- Don ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/

Re: Re[2]: [Haskell-cafe] Climbing up the shootout...

2008/9/23 Bulat Ziganshin <[EMAIL PROTECTED]>: >> seems to do fine; you'll notice >> it drops "lines" after the first version. > > actually it counts lines using built-in function. you may find that > naive C is 6x fatser than naive Haskell and difference is so s

Re[2]: [Haskell-cafe] Climbing up the shootout...

Hello Don, Tuesday, September 23, 2008, 3:12:37 AM, you wrote: >> for the same reason i don't feed 5000 men with 7 breads - it's not my >> business ;) > Ok. So I'll just say: high level, efficient code is an overriding theme > of many individuals working on Haskell. Things are better and better

Re[2]: [Haskell-cafe] Climbing up the shootout...

Hello Gwern, Tuesday, September 23, 2008, 3:33:02 AM, you wrote: >> high-performance code in *most* cases. just for example, try to write wc >> without using "words" > seems to do fine; you'll notice > it drops "lines" after the first version. actually it cou

Re: [Haskell-cafe] Climbing up the shootout...

On 2008.09.22 21:12:06 +0400, Bulat Ziganshin <[EMAIL PROTECTED]> scribbled 0.5K characters: > Hello Simon, > > Monday, September 22, 2008, 9:03:52 PM, you wrote: > > > With bytestrings, unboxed arrays, light-weight threads and other > > tricks, we can usually replace all those ugly low-level prog

Re: [Haskell-cafe] Climbing up the shootout...

bulat.ziganshin: > Hello Donnie, > > Tuesday, September 23, 2008, 2:53:17 AM, you wrote: > > > i mean that naive haskell code is very slow and 3 or 5 or twelve libs > > can't solve the problem of ghc generating slow code > > > I'm fairly new to Haskell and the Haskell community, but I can say >

Re[8]: [Haskell-cafe] Climbing up the shootout...

Hello Donnie, Tuesday, September 23, 2008, 2:53:17 AM, you wrote: > i mean that naive haskell code is very slow and 3 or 5 or twelve libs > can't solve the problem of ghc generating slow code > I'm fairly new to Haskell and the Haskell community, but I can say > from my experience of hacking on

Re: Re[6]: [Haskell-cafe] Climbing up the shootout...

Hello Bulat, On Mon, Sep 22, 2008 at 3:09 PM, Bulat Ziganshin <[EMAIL PROTECTED]>wrote: > Hello Graham, > > >> i don't think that these 3 libs allows to write high-level > >> high-performance code in *most* cases. just for example, try to write wc > >> without using "words". > > > To a newbie, th

Re: Re[10]: [Haskell-cafe] Climbing up the shootout...

On Tue, 2008-09-23 at 00:46 +0400, Bulat Ziganshin wrote: > Hello Jonathan, > > Tuesday, September 23, 2008, 12:30:19 AM, you wrote: > > >> yes, in asm number of instructions executed more or less define > >> number of CPU cycles used. > > > > well, i more or less know all this stuff. but

Re[10]: [Haskell-cafe] Climbing up the shootout...

Hello Jonathan, Tuesday, September 23, 2008, 12:30:19 AM, you wrote: >> yes, in asm number of instructions executed more or less define >> number of CPU cycles used. well, i more or less know all this stuff. but are you really compare to Haskell??? does Haskell programs typically written i

Re: Re[8]: [Haskell-cafe] Climbing up the shootout...

On Tue, 2008-09-23 at 00:20 +0400, Bulat Ziganshin wrote: > Hello Isaac, > > Monday, September 22, 2008, 11:49:30 PM, you wrote: > > >> i mean that naive haskell code is very slow and 3 or 5 or twelve libs > >> can't solve the problem of ghc generating slow code > > > Is there something particul

Re[8]: [Haskell-cafe] Climbing up the shootout...

Hello Isaac, Monday, September 22, 2008, 11:49:30 PM, you wrote: >> i mean that naive haskell code is very slow and 3 or 5 or twelve libs >> can't solve the problem of ghc generating slow code > Is there something particularly fascinating about naive code written in > any language? yes, in asm

Re: [Haskell-cafe] Climbing up the shootout...

Don Stewart ha scritto: [...] I've now submitted a Text.Regex.PCRE parallelised entry written by Tim Newsham. It is by far the fastest haskell regex entry so far (down to 9s on quad core, from 100+ seconds on single core for the old entry), http://alioth.debian.org/tracker/index.php?func=de

Re: Re[6]: [Haskell-cafe] Climbing up the shootout...

--- Bulat Ziganshin <[EMAIL PROTECTED]> wrote: > Hello Graham, > > >> i don't think that these 3 libs allows to write high-level > >> high-performance code in *most* cases. just for example, try to > write wc > >> without using "words". > > > To a newbie, that's a cryptic statement. Are you say

Re: Re[2]: [Haskell-cafe] Climbing up the shootout...

igouy2: > > --- Simon Brenner <[EMAIL PROTECTED]> wrote: > > > On Mon, Sep 22, 2008 at 2:07 PM, Bulat Ziganshin > > <[EMAIL PROTECTED]> wrote: > > > this overall test is uselles for speed comparison. afair, there are > > > only 2-3 programs whose speed isn't heavily depend on libraries. in > > >

Re[6]: [Haskell-cafe] Climbing up the shootout...

Hello Graham, >> i don't think that these 3 libs allows to write high-level >> high-performance code in *most* cases. just for example, try to write wc >> without using "words". > To a newbie, that's a cryptic statement. Are you saying that these > libs aren't needed to make a high-performance "w

Re: Re[4]: [Haskell-cafe] Climbing up the shootout...

On Mon, Sep 22, 2008 at 1:12 PM, Bulat Ziganshin <[EMAIL PROTECTED]> wrote: > Hello Simon, > > Monday, September 22, 2008, 9:03:52 PM, you wrote: > >> With bytestrings, unboxed arrays, light-weight threads and other >> tricks, we can usually replace all those ugly low-level programs with >> nice hi

Re: Re[2]: [Haskell-cafe] Climbing up the shootout...

igouy2: > > --- Simon Brenner <[EMAIL PROTECTED]> wrote: > > > On Mon, Sep 22, 2008 at 2:07 PM, Bulat Ziganshin > > <[EMAIL PROTECTED]> wrote: > > > this overall test is uselles for speed comparison. afair, there are > > > only 2-3 programs whose speed isn't heavily depend on libraries. in > > >

Re: Re[2]: [Haskell-cafe] Climbing up the shootout...

--- Simon Brenner <[EMAIL PROTECTED]> wrote: > On Mon, Sep 22, 2008 at 2:07 PM, Bulat Ziganshin > <[EMAIL PROTECTED]> wrote: > > this overall test is uselles for speed comparison. afair, there are > > only 2-3 programs whose speed isn't heavily depend on libraries. in > > DNA test, for example, T

Re[4]: [Haskell-cafe] Climbing up the shootout...

Hello Simon, Monday, September 22, 2008, 9:03:52 PM, you wrote: > With bytestrings, unboxed arrays, light-weight threads and other > tricks, we can usually replace all those ugly low-level programs with > nice high-level haskell ones i don't think that these 3 libs allows to write high-level hig

Re: Re[2]: [Haskell-cafe] Climbing up the shootout...

On Mon, Sep 22, 2008 at 2:07 PM, Bulat Ziganshin <[EMAIL PROTECTED]> wrote: > this overall test is uselles for speed comparison. afair, there are > only 2-3 programs whose speed isn't heavily depend on libraries. in > DNA test, for example, Tcl (or PHP?) was leader just because it has > better rege

Re[2]: [Haskell-cafe] Climbing up the shootout...

Hello Manlio, Monday, September 22, 2008, 1:46:55 PM, you wrote: > This is cheating, IMHO. > Some test comparisons are unfair. this overall test is uselles for speed comparison. afair, there are only 2-3 programs whose speed isn't heavily depend on libraries. in DNA test, for example, Tcl (or PH

Re: [Haskell-cafe] Climbing up the shootout...

On 22 Sep 2008, at 11:46, Manlio Perillo wrote: Don Stewart ha scritto: Thanks to those guys who've submitted parallel programs to the language benchmarks game, we're climbing up the rankings, now in 3rd, and ahead of C :) This is cheating, IMHO. Some test comparisons are unfair. The fi

Re: [Haskell-cafe] Climbing up the shootout...

Don Stewart ha scritto: Thanks to those guys who've submitted parallel programs to the language benchmarks game, we're climbing up the rankings, now in 3rd, and ahead of C :) This is cheating, IMHO. Some test comparisons are unfair. The first problem is with the thread-ring benchmark. Haskell

Re: [Haskell-cafe] Climbing up the shootout...

Don Stewart wrote: Thanks to those guys who've submitted parallel programs to the language benchmarks game, we're climbing up the rankings, now in 3rd, and ahead of C :) http://shootout.alioth.debian.org/u64q/benchmark.php?test=all&lang=all Yay! This makes me very happy. ;-) __

[Haskell-cafe] Climbing up the shootout...

Thanks to those guys who've submitted parallel programs to the language benchmarks game, we're climbing up the rankings, now in 3rd, and ahead of C :) http://shootout.alioth.debian.org/u64q/benchmark.php?test=all&lang=all Just one or two more parallel programs required... Submit them here, a