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 PHP?) was leader just because it has better regexp library to make things even funnier, this test allows to use libs bundled to compiler, but not 3rd-arty ones. so ghc (not Haskell!) what includes more built-in libs than gcc looks like a leader. of course, noone uses bare ghc or gcc in real world even benchamrks that test pure speed of compiled code are useless because 1) they are imited by RAM speed, not speed of code itself 2) there uis a fashion in Haskell world to write for shootout in the very low-level style, which isn't actually used in real programming and actually understood only by a few "wizards" developing high-performance haskell code so actually that this shootout shows is that 1) in real world, program speed more depends on libs that on compilers. if you go to compare weak language plus lot of libs with a strong language with a few libs first variant will win (unless you go to reimplement all these libs at your own) 2) highly-optimized Haskell code is only 2-3 times slower than real C code produces by average C programmer. taken into account that such Haskell code is written many times slower than C one and need much more knowledge, Haskell hardly can be compared to C 3) if you need to compare real-world Haskell code with C one, you may look at these papers: An approach to fast arrays in Haskell http://www.cse.unsw.edu.au/~chak/papers/afp-arrays.ps.gz Rewriting Haskell Strings http://www.cse.unsw.edu.au/~dons/papers/fusion.pdf that they call "naive approach" is real Haskell programs not speeded up by special libs -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com

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 high-performance code in *most* cases. just for example, try to write wc without using "words" -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com

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 "wc", and that the Prelude functions are sufficient? (I note too that there is Data.ByteString.Char8.words, but I assume you are talking about the Prelude function.)

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 -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com

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 number of instructions executed more or less define number of CPU cycles used. C known as portable asm. Haskell was developed with goal to hide implementation details from egg-headed scientists and this obviously should have some drawbacks -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com

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 in account of cache misses and CPU ticks? i suggest you to look into two papers i mentioned - they state hundreds times slower naive Haskell vs naive C. it's a reality, against all your arguments -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com

Hello Bulat, On Mon, Sep 22, 2008 at 3:09 PM, Bulat Ziganshin 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 saying that these libs aren't needed to make a high-performance "wc", and that the Prelude functions are sufficient? (I note too that there is Data.ByteString.Char8.words, but I assume you are talking about the Prelude function.)

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 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 hack on GHC yourself and help improve the compiler? Or suggest detailed improvements since you seem capable of citing specific examples? Thank you. __ Donnie

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 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 hack on GHC yourself and help improve the compiler?  Or suggest detailed improvements since you seem capable of citing specific examples?

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 each year. We do not stand still. For example, Bulat cites a paper talking about naive list code from 2002, however, by 2008 we know how to do fusion on lists, so it runs in the same time as low level loops, the technique is implemented and you can download it from hackage, http://hackage.haskell.org/cgi-bin/hackage-scripts/package/stream-fusion Simon Marlow is busy adding more efficient GC and parallelism to GHC, and there's a summer project to rewrite the native code generator. GHC gained pointer tagging in the last release cycle, dramatically reducing the cost of algebraic data types. At the same time, we're writing books about how to program "naively" in Haskell, such that your code doesn't suck. That is: training. Teaching people how to write Haskell. We can see it paying off, where naive code performs very very well, http://shootout.alioth.debian.org/gp4/benchmark.php?test=sumcol&lang=all And lots and lots more people able to write good code for Hackage. I find Bulat's outlook rather bleak, and I think it is time to update expectations. Progress is beautiful. -- Don

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

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 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 long lazy bytestrings, and return the rest of the stream in a pair: readInt :: ByteString -> Maybe (Int, ByteString) readInteger :: ByteString -> Maybe (Integer, ByteString) These are the initial parts of a bytestring lexing library, more of which is appareing in the bytestring-lex package on Hackage. -- Don

2008/9/23 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 readInt which was added specifically for this test. it doesn't support arbitrary-size streams and doesn't return rest of stream

Yeah, readInt has a more useful type than atoi() in most circumstances so obviously it's a default which somehow disqualify this function... (I wasn't aware that this function was only useful in the shoutout context, I should probably scrap it from my other programs now) I think we should write all the entries in Haskell98 and disable any optimisation in GHC too, that would gives us a much fairer vision of Haskell current performances. -- Jedaï

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-bin/cvsweb.cgi/libc/stdlib/strtol_l.c?rev=1.4.2.3&content-type=text/x-cvsweb-markup&cvsroot=glibc 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 lovely, and that's all to the good. Below every high level interface is lots of low level pain. If his point is anything else, this is getting absurd. --S On Mon, Sep 22, 2008 at 8:16 PM, Bulat Ziganshin wrote:

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 each year. We do not stand still.

yes. when we say that things are greatly improving each year, this means that they was bad previously ;)

...

For example, Bulat cites a paper talking about naive list code from 2002, however, by 2008 we know how to do fusion on lists, so it runs in the same time as low level loops, the technique is implemented and you can download it from hackage,

...

http://hackage.haskell.org/cgi-bin/hackage-scripts/package/stream-fusion

someone can ask why this great code isn't used in ghc by default. probably it is just work in progress which isn't yet ready to replace old slow code. then we can see tha fusion isn't magic wand which improves speed of every haskell code that's slower than C one. it just makes C-speed code sometimes

...

Simon Marlow is busy adding more efficient GC and parallelism to GHC, and there's a summer project to rewrite the native code generator.

well, i'm sais about *current* real situation. if you consider this as attack against Haskell developers, it's your mistake. the problem is that i many years wrote about slowness of ghc code, every time you cosider this as attack and write that in future Haskell will become much faster. we still wait for this future, however

...

GHC gained pointer tagging in the last release cycle, dramatically reducing the cost of algebraic data types.

10-20% speed improvement, on average. it's the only real improvement (for my own program) i know. i think that ByteString-related libs gived more improvements but their use isn't automatic and they doesn't help in any situation. they just provide fast library code for solving some concrete (although very frequent) situations, such as counting lines

...

At the same time, we're writing books about how to program "naively" in Haskell, such that your code doesn't suck. That is: training. Teaching people how to write Haskell.

it is what i say - if naive code was effective and automagically optimized by ghc, we don't need all those tutorials. anyone looked into your tutorial on writing efficient Haskell code, will never say that it's easier than in C. so we can conclude that optimized haskell programs are several times slower than C ones and need several times more to write

...

We can see it paying off, where naive code performs very very well,

...

http://shootout.alioth.debian.org/gp4/benchmark.php?test=sumcol&lang=all

yes! it's my beloved example of "elegant" haskell code entirely based on the readInt function added to ghc libs specifically to win in this test. it's implementation is really simple and naive:

-- --------------------------------------------------------------------- -- Reading from ByteStrings

-- | readInt reads an Int from the beginning of the ByteString. If there is no -- integer at the beginning of the string, it returns Nothing, otherwise -- it just returns the int read, and the rest of the string. readInt :: ByteString -> Maybe (Int, ByteString) readInt as | null as = Nothing | otherwise = case unsafeHead as of '-' -> loop True 0 0 (unsafeTail as) '+' -> loop False 0 0 (unsafeTail as) _ -> loop False 0 0 as

where loop :: Bool -> Int -> Int -> ByteString -> Maybe (Int, ByteString) STRICT4(loop) loop neg i n ps | null ps = end neg i n ps | otherwise = case B.unsafeHead ps of w | w >= 0x30 && w <= 0x39 -> loop neg (i+1) (n * 10 + (fromIntegral w - 0x30)) (unsafeTail ps) | otherwise -> end neg i n ps

end _ 0 _ _ = Nothing end True _ n ps = Just (negate n, ps) end _ _ n ps = Just (n, ps)

when gcc developers will start to add to C libraries functions performing shootout benchmarks we will continue this discussion :D

...

And lots and lots more people able to write good code for Hackage.

...

I find Bulat's outlook rather bleak, and I think it is time to update expectations.

...

Progress is beautiful.

:)

-- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

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 which may improve speed in some usages

If you understand performance as well as you claim to - and from your previous postings, I believe you *do* understand performance well - then you will know that "10-20% speedup" is almost entirely meaningless in isolation. Any given particular program has a bottleneck; this bottleneck may be different depending on the OS/hardware configuration, although normally it won't be. Improvements which touch that bottleneck can have staggering benefits in the 40-500% range; improvements which are elsewhere have tiny <5% or non-measurale effects. In fact, various improvements made to GHC in the 6.4-6.10 timeline have had enormous, order-of-magnitude improvements to particular code patterns which had particular bottlenecks. Meanwhile they may well have had no effect at all on other code patterns which had different bottlenecks. You may ask, what are the common code patterns? What are the common bottlenecks? I'm not aware of good studies to answer these questions although they probably exist; I don't read widely the research in this area. [Naive C programs tend to IO bottleneck or Memory bottleneck; I strongly suspect naive haskell programs tend to GC bottleneck; but I don't think either of these observations is particularly profound or useful] What matters to a particular programmer of course it not actually common patterns and common bottlenecks. It is the bottleneck in his particular program. However: The Shootout is a *game*. It even says that in its name. It's a game which many of us enjoy playing; if you don't enjoy, please feel free not to play. Many of us find that, by playing the game, we learn a lot of interesting things about the low-level performance of GHC in interesting edge-cases. The quad-core machine recently added to the benchmark has enabled us to learn interesting things about `par` and Control.Parallel. Learning these things, and sharing them, may help us write better programs, help us teach other people to write better programs, and help the GHC team write a better compiler. Jules

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 equivalents. Sure, if I pour a lot more time and head scratching into my C, then I can probably beat my Haskell, but I just don't have the time (or the need) to introduce pointer tagging, lazy evaluation, and referential transparency transparency to my C code. Any way, this thread has lost any usefulness. On Tue, Sep 23, 2008 at 5:32 AM, Bulat Ziganshin wrote:

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 lovely, and that's all to the good. Below every high level interface is lots of low level pain.

functions used to make C code faster is obviously worse than those used for Haskell code. just look - Clean gets 2x better performance than C

...

If his point is anything else, this is getting absurd.

my point is very simple - these tests says nothing about real performance since these tests was hardly optimized including adding special functions to ghc libs. amount of work required to do this is much much more than amount of work required to write optimal C/asm code

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 which may improve speed in some usages

-- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

-- /jve

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 wrote:

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 produce programs with significantly less pain which outperform the C equivalents. Sure, if

can you write program which sums hexadecimal numbers which is both significantly less than C 10-liner and work faster? :)

-- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com

-- /jve

On Tue, Sep 23, 2008 at 2:52 PM, Bulat Ziganshin 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 "the". You're probably just a better C programmer than me.

well, i don't say about me personnaly or someone else. my points is that

1) modern C compilers allows to get close-to-asm performance. Haskell don't 2) fastest Haskell code is very hard to write, much harder than C one

This is only true for tiny toy benchmarks, not for real applications. For real applications you're going to have bottle necks in small parts of the code. So what if that 5-20% of the code has to be written using specialized techniques to get speed, when you get several times more productivity/correctness/maintainability in the 80-95% of the code which is not the bottle neck? If you're involved in a game where everyone tries to show off how their programming language deals with the bottle necks then obviously you'd use these "ugly" techniques to optimize things. It may be that it's more convenient to write this low level code in C (though I wouldn't say it's "much" more convenient, slightly more for some cases, less for others), but the price you pay is that you have to use this low level style for *everything*. Most of the inconvenience, IMO, is due to syntax not semantics (specifically having to do "<-" on separate lines in order to read mutable memory rather than being able to extract the value at the usage site - though I do believe some syntactic sugar was on the way for that?) So I think you're wrong to criticize people for showing that Haskell can be fast. Yes it takes effort (though you can increasingly avoid most of it by using libraries like ByteString), but nobody is saying that it doesn't. You're arguing against a straw man. The point is that you *can* get good performance in Haskell for the parts of your programs which is a bottle neck. The shootout only tests these parts, which is why the Haskell code in those submissions is sometimes a bit obscure (though not nearly to the extent you make out). But that's not how *real* applications look! In real applications that kind of code would be only a fraction of the total code base, most of it would be perfectly ordinary Haskell! (whereas in C everything would be, well C) Cheers, -- Sebastian Sylvan +44(0)7857-300802 UIN: 44640862

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 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 implement a pluggable "reactor" (select, poll, epoll, kqueue, /dev/poll, and so)?

[...]

Thanks Manlio Perillo

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 effort it takes to implement a pluggable "reactor" (select, poll, epoll, kqueue, /dev/poll, and so)?

look at alt-network package

improving existing ghc i/o library may be a bad idea since it is a large monolithic code which is aklready hard to maintain. there was several efforts to provide new i/o library. of those, my Streams library was the largest. unfortunately, all who done those libs stopped their work. so the most probable scenario now is what we eventually will get ByteString-based modular I/O library from FPS/Binary developers

Maybe improve GHC to make Haskell suitable to write high reliable internet servers is not of interest?

Thanks Manlio Perillo

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 self", unless there is *really* no other solution (and, in this case, the solution is to use Erlang).

various people do that they find most exciting/important. actually, alt-network package is just about fast network i/o

Where can I find alt-network? Thanks Manlio Perillo

Manlio Perillo wrote:

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 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 implement a pluggable "reactor" (select, poll, epoll, kqueue, /dev/poll, and so)?

We'd certainly support any efforts to add support for a more modern I/O multiplexing or asynchronous I/O back-end to the IO library. It's not too difficult, because the interface between the low-level I/O supplier and the rest of the IO library is rather small - just a few functions that read and write blocks of data in a blocking or non-blocking way. The blocking variants currently communicate with the I/O manager thread which does select() on behalf of the clients. Before doing this, though, I'd urge you to check that your application really does have scaling issues with the current system. If it doesn't, then great, and if it does then you have a good benchmark to evaluate the replacement. Cheers, Simon

manlio_perillo:

However I'm looking for a good environment for implementing generic internet servers, or web applications with special needs. As an example one of my "maybe future" tasks is to write a simple BitTorrent tracker + seeder.

You could look at conjure, the bitorrent client that uses STM for network multiplexing, http://darcs.haskell.org/~lemmih/conjure/

Twisted (a Python asynchronous framework) is a confortable environment, but I feel concurrent Haskell is superior.

Should be a lot faster, given there's compiled native code, and no global locks. Actually, the very kind of thing we see on the shootout now :)

It surely will work using just select, but since I have experience (including indirect experience) with both Twisted and Nginx, I know that using select is asking for troubles (but the solution used by Haskell is very new for me).

Yes, you'd use probably STM's `orElse` to multiplex IO from different sources, and GHCs lightweight threads for concurrency. We've used solutions like this at Galois to build servers that are both high level and efficient. -- Don

Don Stewart ha scritto:

manlio_perillo:

...

However I'm looking for a good environment for implementing generic internet servers, or web applications with special needs. As an example one of my "maybe future" tasks is to write a simple BitTorrent tracker + seeder.

You could look at conjure, the bitorrent client that uses STM for network multiplexing,

http://darcs.haskell.org/~lemmih/conjure/

Its unfortunate that the project seems to be dead.

...

Twisted (a Python asynchronous framework) is a confortable environment, but I feel concurrent Haskell is superior.

Should be a lot faster, given there's compiled native code, and no global locks.

With Twisted you usually don't use threads.

[...]

Manlio Perillo

Simon Marlow ha scritto:

Manlio Perillo wrote:

...

Simon Marlow ha scritto:

...

Manlio Perillo wrote: [...] We'd certainly support any efforts to add support for a more modern I/O multiplexing or asynchronous I/O back-end to the IO library. It's not too difficult, because the interface between the low-level I/O supplier and the rest of the IO library is rather small - just a few functions that read and write blocks of data in a blocking or non-blocking way. The blocking variants currently communicate with the I/O manager thread which does select() on behalf of the clients.

There is some documentation that summarize the current status, and how all fits together?

Sadly no, but the code is mostly restricted to a couple of modules (GHC.Handle and GHC.Conc).

Ok. I' I'm also reading the "unify" paper. What I would like to do is to write a library for high efficient IO, using the code from Nginx (that is well written and reusable). What Nginx give us is: 1) Several modules for efficient event handling on all platform. There is also Windows support with IOCP, but the code is not public (but lately someone is porting Nginx to Windows, and I can always ask the author of Nginx to make his code public). 2) Support for SSL. 3) There is support for timeouts, using a red black tree. In Haskell timeouts are handled spwawing a thread with forkIO, but is this efficient? 4) Support for async DNS resolver. 5) Support for "sending" buffer chains. A buffer chain is "sent" with writev. In Haskell a ByteString has several chunks, so it can be efficiently "sent" using writev. 6) Support for file buffers. A file buffer is "sent" with sendfile, if available. There is no equivalent in Haskell. Since I have started to work with Nginx, I had the interest of reusing the Nginx code as a library/framework, but all the languages I knew did not have native support for microthreads (Python has greenlets, but it also already hase Twisted, so it is of little interest to implement yet another async framework). GHC seems the best platform to use, since it has microthreads, and Haskell language allow a "safe" use of OS threads.

...

There are some benchmarks that tell you the use of a separate I/O manager thread is a good solution?

Compared to what? I did measure the difference between doing this in Haskell code in the IO library (as with -threaded) against doing it in the RTS (without -threaded),

Yes, this is what I meant.

and the Haskell version won hands down, mainly because it only re-initiates the select() when it has to change the file handles in the set. Using epoll() instead of select() should be even better.

Ok, thanks. In GHC there is only one IO manager thread? And forkIO can execute code in a separate OS thread, if necessary?

Cheers, Simon

Regards Manlio

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 hack on GHC yourself and help improve the compiler? Or suggest detailed improvements since you seem capable of citing specific examples?

Because he's convinced himself it's pointless because Haskell will never be able to run faster than C (note how he keeps trying to run dons out of the discussion because he has proof to the contrary). -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH

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 particular, shootout can't be considered as representative benchmark

"I reserve the right to disallow any actual evidence for any reason I can come up with, including amorphous and vacuous ones" (you can almost always write something faster, but with how much effort?) Thanks, I get enough of that from the government here. -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH

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 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 all you can do is get in the way of people doing what you claim is impossible, please stop. -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH

On Wed, Sep 24, 2008 at 11:20 PM, Bulat Ziganshin 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.

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

-- /jve

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

Hello Ketil, Thursday, September 25, 2008, 8:57:05 PM, you wrote:

"John Van Enk" 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 :-)

there are lots of green thread libs for C, they are just not bundled with gcc -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com

On 2008.09.22 21:12:06 +0400, Bulat Ziganshin 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 programs with nice high-level haskell ones

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"

-- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com

http://haskell.org/haskellwiki/Wc seems to do fine; you'll notice it drops "lines" after the first version. -- gwern class ASPIC Duress BNC WWSV of intelligence retrieval Al PRF

2008/9/23 Bulat Ziganshin :

...

http://haskell.org/haskellwiki/Wc 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 small only because C version is bound by memory speed

So what ? Strings represented as lists of character are slow ? What an incredible discovery ! The ByteString versions are fast, ByteString was invented especially for IO intensive situation, it's a library you can use pretty naively and mostly get excellent performances, what exactly isn't Haskelly enough for you in this solution ? The guts of ByteString aren't idiomatic Haskell ? And ? The guts of the JVM aren't written in Java either... At least ByteString was built over GHC which means it can be done. Besides a part of the performances of ByteString comes from stream fusion and that's specifically something that is hard to achieve outside of Haskell... What exactly is your point ? - Haskell is slow, we can't make it faster ? That's obviously false as demonstrated by the progress in the latest years. - Haskell is slower than C ? Well that's probably true, because C can touch the hardware directly and can always optimize every single aspects of a computation... On the other hand that kind of uber optimization has a cost that I am unwilling to pay, I would rather write high level Haskell and pay a little hit on execution time. - We shouldn't center ourselves around performance to promote Haskell (or should we even promote Haskell) ? Well there you may have a point, but maybe it would be better to just make it and avoid denying other peoples efforts to make Haskell faster ? -- Jedaï

igouy2:

--- Simon Brenner wrote:

...

On Mon, Sep 22, 2008 at 2:07 PM, Bulat Ziganshin 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 regexp library

On the regex-dna benchmark, I'll have to agree. It's unfortunate to have a benchmark so dependent on the set of libraries included in the distribution, and e.g. Text.Regex.PCRE kicks Text.Regex.Posix's behind in this benchmark - but we probably can't use it only because one's bundled and the other isn't. Maybe we could roll our own regexp engine for this specific benchmark though (for example, Text.Regex.TDFA is within 10% or something of PCRE and AFAIK pure Haskell - a customized and downsized version of that could probably be made quite competitive).

You could always suggest use of Text.Regex.PCRE, provide a program and instructions on how to install Text.Regex.PCRE on Ubuntu.

-snip-

...

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 ...

Go do!

All is in hand. Tim Newsham's uploaded a regex-pcre and regex-posix entry to the wiki, and I'm testing now on quad core. If it survives testing, we'll submit it to Isaac. -- Don

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=detail&aid=311132&group_id=30402&atid=411646

It does require the regex-pcre library, which if it isn't in your package system on Ubuntu, you can certainly build,

What performance gain do you obtain using regex-pcre-builtin against a native Haskell regex library?

[...]

Thanks Manlio Perillo

ChrisK wrote:

And, though I had never seen it before, the current winner for speed is "ATS" ( http://www.ats-lang.org/ ) which is dependently-typed functional language.

And as discussed on Reddit recently[1] it uses a good deal of embedded C/C++ and so is subject to the same non-idiomatic complaints. While the non-idiomatic complaint is a valid one, I think it's also overrated. Back in the day people said that an automatic compiler would never be able to out-perform hand-written assembly; and today gcc produces better assembly code than any mere mortal. Yet occasionally C/C++ programmers still feel the need to do the compiler's job. Similarly, if ATS or Haskell lets one write better C/C++ than any mere mortal, then it has won-- even if programmers feel the need to do the compiler's job from time to time. Compilers for any language will never be omniscient, but they're far more consistent about applying known optimization patterns globally. While some tasks do require absolute performance, high-level languages seek to optimize programmer time which is far more valuable than cpu time for the great majority of tasks. The optimization techniques for Haskell are quite different than for C, but I wouldn't say they are inherently "harder" in any real sense. Optimizing Haskell requires a deep understanding of the runtime internals of ghc (or other compiler of choice); optimizing C requires a deep understanding of the runtime internals of C's memory 'runtime'. The only difference I see is that C's view of the world is taught as canon and has been a target of research for longer. [1] http://www.reddit.com/r/programming/comments/72hmw/language_shootout_ats_is_... -- Live well, ~wren

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 or two more parallel programs required...

Submit them here, and we can test on quad core,

http://haskell.org/haskellwiki/Shootout/Parallel

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. -- Don