- Haskell-Cafe - Haskell.org

Re[2]: Joels Time Leak
by Bulat Ziganshin 06 Jan '06

06 Jan '06

Hello Simon, Wednesday, January 04, 2006, 7:33:22 PM, you wrote: >>>>The minimum time between context switches is 20 milliseconds. >> SM> Sure, there's no reason why we couldn't do this. Of course, even >> SM> idle Haskell processes will be ticking away in the background, so >> SM> there's a reason not to make the interval too short. What do >> SM> you think is reasonable? >> >> Simon, the talk is about changing GHC _tick_, which is a _minimal_ >> possible context switch interval SM> Yes, I know. in this case, why you say that idle processes will be ticking in background? it's entirely up to program writers/users if they wants to decrease this interval. by default switches will occur in the same 20 ms, lesser tick will have no impact on ordinary programs as long as default switching time will be not changed -- Best regards, Bulat mailto:bulatz@HotPOP.com

2 2

RE: [Haskell-cafe] RE: Haskell vs. Clean
by Scherrer, Chad 06 Jan '06

06 Jan '06

Interesting. Have there been any performance comparisons vs GHC et al? Chad Scherrer Computational Mathematics Group Pacific Northwest National Laboratory "Time flies like an arrow; fruit flies like a banana." -- Groucho Marx > -----Original Message----- > From: Neil Mitchell [mailto:ndmitchell@gmail.com] > Sent: Thursday, January 05, 2006 1:58 PM > To: Scherrer, Chad > Cc: daniel.carrera(a)zmsl.com; haskell-cafe(a)haskell.org > Subject: Re: [Haskell-cafe] RE: Haskell vs. Clean > > Hi > > > My knowledge of Clean is fairly limited > Mine too, but one of the biggest differences is that Clean > has uniqueness types instead of Monads. > > They are in fact so similar that you can convert between them, using > Hacle: http://www-users.cs.york.ac.uk/~mfn/hacle/ > > I believe also that Clean has a lot more facilities for > strictness annotations, which may help with the speed. > > Thanks > > Neil >

2 1

RE: Haskell vs. Clean
by Scherrer, Chad 06 Jan '06

06 Jan '06

Daniel, My knowledge of Clean is fairly limited (even more so than my knowledge of Haskell), but no one seems to be responding to this, so I'll take a crack at it. Here is why I've stuck with Haskell instead of Clean: 1. It runs well on Linux 2. The license is more open 3. There is a (comparatively) large, active research community 4. Mailing list support is very good (haven't looked at Clean's for this) 5. It strikes me as more elegant Clean does seem to have a claim to speed. But given (3) and the fact that the languages are, after all, fairly similar, I wonder if (and hope that) Haskell may be able to make similar claims before long. Actually, this makes me wonder... Is Clean's claim to speed due to raw performance being a very high priority for its implementers, or is there something inherent in its semantics that will always give it an edge? Will Haskell be able to catch up? Chad ---------------------------------------------------- Daniel Carrera daniel.carrera at zmsl.com wrote: 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. ----------------------------------------------------

2 1

Re: [Haskell-cafe] Shootout favoring imperative code
by Chris Kuklewicz 06 Jan '06

06 Jan '06

This uses getLine instead of getContents and is 3.8 times slower. {-# OPTIONS -fglasgow-exts -O2 #-} -- -- The Computer Language Shootout -- http://shootout.alioth.debian.org/ -- -- compile with : ghc -O2 -o SumF SumF.hs -- To get better performance set default heap size to 10MB -- i.e. invoke as : ./SumF +RTS -H10M <input_file.txt -- contributed by Greg Buchholz -- modified by Mirko Rahn -- modified by Chris Kuklewicz, 5 Jan 2006 -- import Data.Char(ord) import GHC.Base {-# INLINE d2i #-} d2i :: Char -> Int# d2i c = let (I# x) = ord c (I# z) = ord '0' in x -# z main :: IO () main = do let next rt = do line <- catch getLine (\_ -> return []) if (null line) then return (I# rt) else next (rt +# aLine line) aLine ('-':rest) = nLine rest 0# where nLine [] soFar = (-1#) *# soFar nLine ( x :rest) soFar = nLine rest (d2i x +# (10# *# soFar)) aLine (x:rest) = pLine rest (d2i x) where pLine [] soFar = soFar pLine ( x :rest) soFar = pLine rest (d2i x +# (10# *# soFar)) total <- next 0# print total Sebastian Sylvan wrote: > On 1/5/06, Chris Kuklewicz <haskell(a)list.mightyreason.com> wrote: > >>I did manage to tweak SumFile to use unboxed Int# and go 10% faster. >> >>http://haskell.org/hawiki/SumFile > > > Interestingly, it's actually faster to do it this way than to call the > C functions fgets and atoi... > > However, I'm not sure it's "legal" since it's not using built-in > line-based IO functions (which the spec states, for no apparent reason > other than to favor languages whose IO convenience functions are > low-level :-)) > > /S > > -- > Sebastian Sylvan > +46(0)736-818655 > UIN: 44640862 >

1 0

Re: [Haskell-cafe] Frag/OSX
by Joel Reymont 06 Jan '06

06 Jan '06

On Jan 5, 2006, at 7:50 PM, Jason Dagit wrote: > I'm pretty sure I was on OSX when I tried it out a couple weeks > ago. There was at least one bot. I was able to kill it. > > Game play was buggy and awkward, bots didn't seem to have any > intelligence. Well, I would like to make extremely intelligent monsters (within my abilities of course) but I'm stumped at the moment. (gdb) r leveleg Starting program: /Users/joelr/Haskell/frag/a.out leveleg Reading symbols for shared libraries ... +.............................................................. done Program received signal EXC_BAD_ACCESS, Could not access memory. Reason: KERN_PROTECTION_FAILURE at address: 0x00000ab0 0x90ece5e8 in glDrawBuffer () (gdb) where #0 0x90ece5e8 in glDrawBuffer () #1 0x00011f5c in s1Iym_info () #2 0x0017e4a0 in schedule (mainThread=0x11c1748, initialCapability=0x9093000c) at Schedule.c:932 #3 0x0017f448 in waitThread_ (m=0x6066f0, initialCapability=0x0) at Schedule.c:2156 #4 0x0017f32c in scheduleWaitThread (tso=0x11c0000, ret=0x0, initialCapability=0x0) at Schedule.c:2050 #5 0x0019a120 in rts_evalLazyIO (p=0x22b874, ret=0x0) at RtsAPI.c:459 #6 0x0016929c in main (argc=1029, argv=0x9093000c) at Main.c:104 -- http://wagerlabs.com/

1 0

Frag/OSX
by Joel Reymont 06 Jan '06

06 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 05 Jan '06

05 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