- Haskell-Cafe - Haskell.org

Frag/OSX
by Joel Reymont 05 Jan '06

05 Jan '06

Folks, Has anyone tried to run Frag on Mac OSX? Also, since I can't get it to run (glDrawBuffer crash), can someone tell me if it includes monsters? It looks to me like it's just a player with a gun running around. Thanks, Joel -- http://wagerlabs.com/

2 1

Re: Progress on shootout entries
by dons＠cse.unsw.edu.au 05 Jan '06

05 Jan '06

I've added an entry on the hawiki[1] for the regex-dna benchmark, and posted a smaller (down to 15 lines), faster entry for [2]reverse-complement, using string indexing from Alex. Cheers, Don [1] http://haskell.org/hawiki/ShootoutEntry [2] http://haskell.org/hawiki/ReverseComplementEntry

2 1

Re: Chaneneos
by Chris Kuklewicz 05 Jan '06

05 Jan '06

Josh Goldfoot wrote: > By the way, your version is already on the GP4 shootout, and has rated the fastest. > It also has the 3rd fewest lines of code, and uses a hell of a lot less memory than my version does. > Pretty cool! See the results here: > > http://shootout.alioth.debian.org/gp4/benchmark.php?test=chameneos&lang=all > > Thanks for the pointer, I had not seen the resuslts yet. Way cool. And thanks to Einar Karttunen for finind the Ch channel trick. Haskell is clearly good at their concurrency benchmark. Though there are many languages without entries, Haskell is the one to beat. -- Chris > > ----- Original Message ---- > From: Chris Kuklewicz <chris(a)mightyreason.com> > To: Josh Goldfoot <j_goldfoot(a)yahoo.com> > Sent: Wednesday, January 04, 2006 5:53:54 AM > Subject: Chaneneos > > > Hi, > > When I went to submit a Haskell entry for Chaneneos yesterday, I saw > yours for the first time but I did not know your address. I have copied > your entry's code to the wiki http://haskell.org/hawiki/ChameneosEntry. > The version Einar and I made has also been submitted to the shootout, > and should show up on the results list soon. > > Cheers, > Chris >

1 0

RE: [Haskell-cafe] Optimizing a high-traffic network architecture
by Simon Marlow 05 Jan '06

05 Jan '06

On 15 December 2005 10:21, Joel Reymont wrote: > Here are statistics that I gathered. I'm almost done modifying the > program to use 1 timer thread instead of 1 per bot as well as writing > to the socket from the writer thread. This should reduce the number > of threads from 6k (2k x 3) to 2k plus change. > > It appears that +RTS -k3k does make a difference. As per Simon, 2-4k > avoids the thread being garbage collected because each thread gets > its own block in the storage manager. Simon, did I get that right? The 3k threads are still GC'd, but they are not actually *copied* during GC. It'll increase the memory overhead per thread from 2k (1k * 2 for copying) to 4k (4k block, no overhead for copying). Cheers, Simon

3 4

RE: [Haskell-cafe] Re: [Haskell] Re: Boxing (Day) Question
by Simon Peyton-Jones 04 Jan '06

04 Jan '06

| > You'd still need several versions of the code for a polymorphic function, one | > for pointer values, one for 4-byte non-pointers, one for 8-byte non-pointers | > etc. | | Yes, but that's up to the user. A type variable always has a particular | kind, so for instance one might want an array over any 4-byte | non-pointer value: | | data Array4 (a :: #4) | | Functions on Array4 only need one version of code. This makes | polymorphism less useful, of course, but the goal here is to be closer | to the machine. Ah, now I see what you mean. I had not thought of doing that, but it'd make sense, esp if there were lots of 4-byte-non-pointer types. But there are only a couple (Int# and Word32#) so I'm not sure it's worth the effort. But (without thinking about it too hard) it looks like a very sensible idea. The trickiness is in the fact that some type constructors (notably (->)) are somewhat kind-polymorphic, which gives rise to some awkwardness in the type checker. So the details might not be entirely straightforward. Simon

2 1

Haskell vs Clean
by Daniel Carrera 04 Jan '06

04 Jan '06

Hi all, How would you compare Haskell and Clean? It looks like they are both pure functional languages with very similar syntax. It also appears that Clean is faster than Haskell, it appears to be fairly fast. I'm curious to learn about relative advantages and disadvantages of each. Thanks for the help! Daniel. -- /\/`) http://oooauthors.org /\/_/ http://opendocumentfellowship.org /\/_/ \/_/ I am not over-weight, I am under-tall. /

1 0

RE: [Haskell-cafe] Shootout favoring imperative code
by Scherrer, Chad 04 Jan '06

04 Jan '06

> --- Sebastian Sylvan <sebastian.sylvan(a)gmail.com> > wrote: > Some of the problems seem to be heavily geared towards an > imperative *implementation*, meaning that a Haskell version > is hardly idiomatic Haskell (and as such I , and I suspect > otehrs, really have no inclination to work on it). This may be correct, but it still doesn't address the question. Why does Clean fare so much better? Clean is purely functional, right? Chad Scherrer Computational Mathematics Group Pacific Northwest National Laboratory "Time flies like an arrow; fruit flies like a banana." -- Groucho Marx

2 1

RE: [Haskell-cafe] Re: Joels Time Leak
by Simon Marlow 04 Jan '06

04 Jan '06

On 03 January 2006 15:37, Sebastian Sylvan wrote: > On 1/3/06, Simon Marlow <simonmar(a)haskell.org> wrote: >> Tomasz Zielonka wrote: >>> On Thu, Dec 29, 2005 at 01:20:41PM +0000, Joel Reymont wrote: >>> >>>> Why does it take a fraction of a second for 1 thread to unpickle >>>> and several seconds per thread for several threads to do it at the >>>> same time? I think this is where the mistery lies. >>> >>> >>> Have you considered any of this: >>> >>> - too big memory pressure: more memory means more frequent and more >>> expensive GCs, 1000 threads using so much memory means bad cache >>> performance - a deficiency of GHC's thread scheduler - giving too >>> much time one thread steals it from others (Simons, don't get >>> angry at me - I am probably wrong here ;-) >> >> I don't think there's anything really strange going on here. >> >> The default context switch interval in GHC is 0.02 seconds, measured >> in CPU time by default. GHC's scheduler is stricly round-robin, so >> therefore with 100 threads in the system it can be 2 seconds between >> a thread being descheduled and scheduled again. > > According to this: > http://www.haskell.org/ghc/docs/latest/html/users_guide/sec-using-parallel.… > > The minimum time between context switches is 20 milliseconds. > > Is there any good reason why 0.02 seconds is the best that you can get > here? Couldn't GHC's internal timer tick at a _much_ faster rate (like > 50-100µs or so)? Sure, there's no reason why we couldn't do this. Of course, even idle Haskell processes will be ticking away in the background, so there's a reason not to make the interval too short. What do you think is reasonable? > Apart from meaning big trouble for applications with a large number of > threads (such as Joels) it'll also make life difficult for any sort of > real-time application. For instance if you want to use HOpenGL to > render a simulation engine and you split it up into tons of concurrent > processes (say one for each dynamic entity in the engine), the 20ms > granularity would make it quite hard to achieve 60 frames per second > in that case... The reason things are the way they are is that a large number of *running* threads is not a workload we've optimised for. In fact, Joel's program is the first one I've seen with a lot of running threads, apart from our testsuite. And I suspect that when Joel uses a better binary I/O implementation a lot of that CPU usage will disappear. Cheers, Simon

5 10

Progress on shootout entries
by Chris Kuklewicz 04 Jan '06

04 Jan '06

Hello, Where there were no entries to the http://shootout.alioth.debian.org/benchmark.php?test=chameneos&lang=all benchmark, there are now two. The one by Josh Goldfoot is already posted, the one Einar Karttunen and I optimized has been submitted and will run faster/smaller. Our code is at http://haskell.org/hawiki/ChameneosEntry Now for improving the fasta benchmark, http://shootout.alioth.debian.org/benchmark.php?test=fasta&lang=all , which currently has a space leak in the Haskell entry. A non-leaking version which has been optimized to run 3.5 times faster is now up at http://haskell.org/hawiki/FastaEntra (ooops..my spelling mistake). It could still be made to run about 3 times faster, if the other languages are any guide. Anyone want to help polish this one? Also, two other existing entries have space leaks, as can be seen at http://shootout.alioth.debian.org/benchmark.php?test=all&lang=ghc&lang2=ghc And finially, the haskel entry for http://shootout.alioth.debian.org/benchmark.php?test=fannkuch&lang=all is currently the *slowest* entry out of 28 languages. It is 813x slower than the c-code, 500x slower than OCaml. Should be easy to make it faster... Cheers, Chris Kuklewicz

9 17

RE: [Haskell-cafe] Re: Haskell Speed
by Simon Marlow 04 Jan '06

04 Jan '06

On 30 December 2005 01:23, Jan-Willem Maessen wrote: > Probably. The minimum table chunk size was rather large. I have > been experimenting (tests are running even as I type) with alternate > implementations of Data.HashTable. So far the winning implementation > is one based on multiplicative hashing and simple table doubling. > This seems to be consistently competitive with / faster than > Data.Map. At this point my inclination is to make the whole suite > available: > > Data.HashTable.Class > Data.HashTable.DataMap > Data.HashTable.Doubling > Data.HashTable.Flat > Data.HashTable.Freeze > Data.HashTable.Modulus > Data.HashTable.Multiplicative > Data.HashTable.Original > Data.HashTable.Test > Data.HashTable > > I've separated out the hashing technique (Modulus, Multiplicative) > from the hash table implementation. Note that a few of the above are > bogus, and this is only a fraction of the implementations tried thus > far. > > I need to get distribution clearance for a bunch of this code from my > employer, and figure out how to package it. The latter may be > tricky, as Data.Hashtable is currently rather intimately tied to a > bunch of rather tricky bits of GHC. I wonder if you could put together a drop-in replacement for Data.HashTable that we can incorporate? There's not much point in us still providing the inefficient version as standard after you've done all this work to figure out how to do it better. Cheers, Simon

2 1