[Haskell-cafe] Haskell Speed Myth
Lo guys, I thought you'd like to know about this result. I've been playing with the debian language shootout programs under OS X, looking at how fast Haskell code is compared to C on OS X, rather than linux. Interestingly, Haskell comes out rather better on OS X than it did on Linux. Here's my results (times in seconds): C Haskell Relative speed Inverse Binary Trees6.842 1.228 0.179479684302835 5.57166123778502 Fannkuch5.683 15.73 2.767904275910610.361284170375079 Mandelbrot 1.183 2.287 1.933220625528320.517271534761697 nbody 10.275 16.219 1.578491484184910.633516246377705 nsieve 0.167 0.253 1.514970059880240.660079051383399 nsieve-bits 0.471 0.713 1.513800424628450.660589060308555 partial sums1.047 1.313 1.254059216809930.797410510281797 pidigits1.238 1.4 1.130856219709210.884285714285714 recursive 1.554 3.594 2.312741312741310.432387312186978 spectral-norm 27.939 19.165 0.685958695729983 1.45781372293243 threadring 91.284 1.389 0.0152162481924543 65.719222462203 - Averages1.353336204328930.738914688605306 Some notes: Hardware: 2Ghz Core2Duo, enough ram to not worry about paging Some programs are not included, this is because the C code produced compile errors. The Haskell code appears to be portable in *all* cases. The average slowdown for running Haskell is only 1.3 times on OS X! That's pretty damn good. I'm sure some people will say yeh, but you have to optimise your code pretty heavily to get that kind of result. Interestingly, the programs that have the biggest speed advantage over C here are also the most naïvely written ones. The thing that seems to make C slower is the implementation of malloc in OS X. This has a couple of implications, first, if apple replaced the malloc library, it would probably push the result back to the 1.7 times slower we see under Linux. Second, Fannkuch can probably be optimised differently for Haskell to look even better -- at the moment, the haskell code actually uses malloc! Finally, that threading example... WOW! 65 times faster, and the code is *really* simple. The C on the other hand is a massive mess. Bob ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: [Haskell] Another First course in Haskell
Piyush P Kurur wrote: ( http://article.gmane.org/gmane.comp.lang.haskell.general/16390 ) I am planing a haskell based functional programming course. It is supposed to be a first course and I intend to show how real world applications can be built quite easily in haskell. Any feed back is really welcome. Is it a first course in programming, or in functional programming? Either way, I recommend focus on data and then class/instance, i.e. have the students use algebraic data types right from the beginning (*). Another idea for teaching is to introduce the language by having the students use standard libraries (e.g. Data.Map), also right from the start. So they are forced to read type signatures etc. (**) (*) that's the main problem I see with Hutton's book http://www.cs.nott.ac.uk/~gmh/book.html : it has Declaring types and classes as chapter 10 (of 13 total). I think that's way off - and it leaves readers (students) with the impression that declarative programming basically deals with (functions on) lists. This may have been true in the 70s/80s (LISP, Prolog), but it certainly shouldn't be true today. Recall the proverb Get your data structures correct first, and the rest of the program will write itself. (David Jones, cited in John Bentley: More Programming Pearls) I think this is independent of language and paradigm. (**) again, Hutton's book does not contain a single import declaration in the programming examples (did not check fully, but got this impression while browsing). Yes , Data.* is not Standard Haskell(98) and that's probably why he avoided it but the result diametrically contradicts everyday programming experience where the typical application program (in any language) is just some glue between library functions that do 90 percent of the actual work. Sure, a student programmer must be able to write a stand-alone bubble/quick/mergesort but it is equally (if not more) important that he knows how to (1) find and (2) call a sorting routine in any given programming environment. (So, have your students use http://www.haskell.org/hoogle/ ) Best regards, J.W. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Real World Haskell hits a milestone
On Fri, Aug 22, 2008 at 1:46 PM, Daryoush Mehrtash [EMAIL PROTECTED] wrote: Are the book's sample code available for download? Not yet. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Type family fun
Hey all, I was playing around with type families, and I have a strange problem. Suppose we have an alternative to an Either datatype: data (:|:) a b = Inl a | Inr b and a class Ix: class Ix i where type IxMap i :: * - * empty :: IxMap i [Int] Now I want to give an instance for (a :|: b): instance (Ix l, Ix r) = Ix (l :|: r) where type IxMap (l :|: r) = BiApp (IxMap l) (IxMap r) empty = BiApp empty empty BiApp is defined as following: data BiApp a b c = BiApp (a c) (b c) However, it looks like the recursive calls to empty can't be unified, I get the following error message: Couldn't match expected type `IxMap l' against inferred type `IxMap i' Expected type: IxMap (l :|: r) [Int] Inferred type: BiApp (IxMap i) (IxMap i1) [Int] In the expression: BiApp empty empty In the definition of `empty': empty = BiApp empty empty In the inferred type, there should be IxMap l instead of IxMap i, does anybody know what I'm doing wrong? Thanks, -chris ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Haskell Speed Myth
2008/8/23 Thomas Davie [EMAIL PROTECTED]: Finally, that threading example... WOW! 65 times faster, and the code is *really* simple. The C on the other hand is a massive mess. I've been wondering about this, but I can't check because I don't have a multi core cpu. I've heard GHC's single threaded runtime is very very good. What are the results for the threading example when compiled with -threaded and run with at least +RTS -N2? Luke ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Type family fun
On Sat, Aug 23, 2008 at 7:55 AM, Chris Eidhof [EMAIL PROTECTED] wrote: Hey all, I was playing around with type families, and I have a strange problem. Suppose we have an alternative to an Either datatype: data (:|:) a b = Inl a | Inr b and a class Ix: class Ix i where type IxMap i :: * - * empty :: IxMap i [Int] Now I want to give an instance for (a :|: b): instance (Ix l, Ix r) = Ix (l :|: r) where type IxMap (l :|: r) = BiApp (IxMap l) (IxMap r) empty = BiApp empty empty BiApp is defined as following: data BiApp a b c = BiApp (a c) (b c) However, it looks like the recursive calls to empty can't be unified, I get the following error message: Couldn't match expected type `IxMap l' against inferred type `IxMap i' Expected type: IxMap (l :|: r) [Int] Inferred type: BiApp (IxMap i) (IxMap i1) [Int] In the expression: BiApp empty empty In the definition of `empty': empty = BiApp empty empty In the inferred type, there should be IxMap l instead of IxMap i, does anybody know what I'm doing wrong? Thanks, -chris ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe Hi, I'm not very familiar with type families, but shouldn't BiApp be defined as data BiApp a b c = BiApp (a b) (a c) since you're applying it as BiApp (IxMap l) (IxMap r)? Alex ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Haskell Speed Myth
On 23 Aug 2008, at 20:01, Luke Palmer wrote: 2008/8/23 Thomas Davie [EMAIL PROTECTED]: Finally, that threading example... WOW! 65 times faster, and the code is *really* simple. The C on the other hand is a massive mess. I've been wondering about this, but I can't check because I don't have a multi core cpu. I've heard GHC's single threaded runtime is very very good. What are the results for the threading example when compiled with -threaded and run with at least +RTS -N2? That's really interesting -- I just tried this. Compiling not using -threaded: 1.289 seconds Compiling using -threaded, but not running with -N2: 3.403 seconds Compiling using -threaded, and using -N2: 55.072 seconds Wow! Haskell's runtime really is a *lot* better than trying to use operating system threads. I wonder if there's a point at which it becomes better to use both CPUs, or if the overhead of using OS threads for that problem is just too high. Bob ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Haskell Propeganda
Today I made an interesting discovery. We all know the benefits of a strong type system, and often tout it as a major advantage of using Haskell. The discovery I made, was that C programmer don't realise the implications of that, as this comment highlights: http://games.slashdot.org/comments.pl?sid=654821cid=24716845 Apparently, no one realises that a SEGFAULT is a type error, just not a very helpful one. Bob ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: [Haskell] Another First course in Haskell
It seems to me we should condense this thread into a series of new entires on the Haskell in Education page? People seem to be doing new courses, and new kinds of courses, in Haskell, so reflecting that online is a good idea. http://haskell.org/haskellwiki/Haskell_in_education waldmann: Piyush P Kurur wrote: ( http://article.gmane.org/gmane.comp.lang.haskell.general/16390 ) I am planing a haskell based functional programming course. It is supposed to be a first course and I intend to show how real world applications can be built quite easily in haskell. Any feed back is really welcome. Is it a first course in programming, or in functional programming? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Haskell Propeganda
On So, 2008-08-23 at 22:16 +0200, Thomas Davie wrote: Today I made an interesting discovery. We all know the benefits of a strong type system, and often tout it as a major advantage of using Haskell. The discovery I made, was that C programmer don't realise the implications of that, as this comment highlights: http://games.slashdot.org/comments.pl?sid=654821cid=24716845 Apparently, no one realises that a SEGFAULT is a type error, just not a very helpful one. Bob Type errors are useful because they emerge at compile time and prevent you from compiling (and running) a broken program. A segfault is a runtime error and as such provides no such guide -- it may or may not arise and you don't know something's wrong until sigsegv kills your app, screws all your data, crashes the airplane etc. (without the possibility to tell whether/when it will happen). Matus ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Haskell Propeganda
On 23 Aug 2008, at 22:36, Matus Tejiscak wrote: On So, 2008-08-23 at 22:16 +0200, Thomas Davie wrote: Today I made an interesting discovery. We all know the benefits of a strong type system, and often tout it as a major advantage of using Haskell. The discovery I made, was that C programmer don't realise the implications of that, as this comment highlights: http://games.slashdot.org/comments.pl?sid=654821cid=24716845 Apparently, no one realises that a SEGFAULT is a type error, just not a very helpful one. Bob Type errors are useful because they emerge at compile time and prevent you from compiling (and running) a broken program. A segfault is a runtime error and as such provides no such guide -- it may or may not arise and you don't know something's wrong until sigsegv kills your app, screws all your data, crashes the airplane etc. (without the possibility to tell whether/when it will happen). I guess I didn't express my point very clearly... That C programmers apparently don't realise that a type system that's sound will give them something -- i.e. their programmer won't ever segfault. I wonder when we try to advertise Haskell if we should be saying we can give you programs that never segfault, instead of we have a strong type system. Bob ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Haskell Propeganda
I guess I didn't express my point very clearly... That C programmers apparently don't realise that a type system that's sound will give them something -- i.e. their programmer won't ever segfault. I wonder when we try to advertise Haskell if we should be saying we can give you programs that never segfault, instead of we have a strong type system. That would be overpromissing. You can definitely get segfaults in Haskell. The obvious example being http://codepad.org/Q8cgS6x8 but many less contrived and more unexpected examples arise naturally (unfortunately). By the way, the Java camp has (correctly) been touting this argument for quite a while. Bob Tim Newsham http://www.thenewsh.com/~newsham/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Haskell Propeganda
newsham: I guess I didn't express my point very clearly... That C programmers apparently don't realise that a type system that's sound will give them something -- i.e. their programmer won't ever segfault. I wonder when we try to advertise Haskell if we should be saying we can give you programs that never segfault, instead of we have a strong type system. That would be overpromissing. You can definitely get segfaults in Haskell. The obvious example being http://codepad.org/Q8cgS6x8 but many less contrived and more unexpected examples arise naturally (unfortunately). By the way, the Java camp has (correctly) been touting this argument for quite a while. And it is just a property of strong typing, not static typing. The Pythonists would happily make the same remark. We promise both safety and efficiency. -- Don ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Haskell Propeganda
On 23 Aug 2008, at 23:10, Tim Newsham wrote: I guess I didn't express my point very clearly... That C programmers apparently don't realise that a type system that's sound will give them something -- i.e. their programmer won't ever segfault. I wonder when we try to advertise Haskell if we should be saying we can give you programs that never segfault, instead of we have a strong type system. That would be overpromissing. You can definitely get segfaults in Haskell. The obvious example being http://codepad.org/Q8cgS6x8 but many less contrived and more unexpected examples arise naturally (unfortunately). By the way, the Java camp has (correctly) been touting this argument for quite a while. I'd be interested to see your other examples -- because that error is not happening in Haskell! You can't argue that Haskell doesn't give you no segfaults, because you can embed a C segfault within Haskell. Bob ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Haskell Propeganda
On 23 Aug 2008, at 23:10, Tim Newsham wrote: I guess I didn't express my point very clearly... That C programmers apparently don't realise that a type system that's sound will give them something -- i.e. their programmer won't ever segfault. I wonder when we try to advertise Haskell if we should be saying we can give you programs that never segfault, instead of we have a strong type system. By the way, the Java camp has (correctly) been touting this argument for quite a while. As a day-time java programmer, I can say from experience that sometimes (100% pure) Java programs DO segfault. I've had it happen to me, and while you can justifiably say it's an error in the JVM somehow triggered by your program behaviour/timing, that doesn't help you very much at the time. Maarten Hazewinkel ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Haskell Propeganda
I guess I didn't express my point very clearly... That C programmers apparently don't realise that a type system that's sound will give them something -- i.e. their programmer won't ever segfault. I wonder when we try to advertise Haskell if we should be saying we can give you programs that never segfault, instead of we have a strong type system. I'm sure this point is already made somewhere. But I certainly agree that it's a useful point to make to C programmers who are interested in Haskell. I wonder whether seg faults are the true analogue to errors such as error: head empty list. or pattern match errors. Not that I'm saying we should be encouraging such errors in our Haskell programs. Chris. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Haskell Propeganda
As a day-time java programmer, I can say from experience that sometimes (100% pure) Java programs DO segfault. I've had it happen to me, and while you can justifiably say it's an error in the JVM somehow triggered by your program behaviour/timing, that doesn't help you very much at the time. Sure, and just as java has its runtime, so does Haskell. Runtimes are software and prone to being buggy. Runtimes are often written in languages like C where bugs can lead to memory corruption, crashes and arbitrary malicious code execution. Here's a small example that I unfortunately ran across today: ghc -c wxdirect/src/CompileClassTypes.hs -o dist/wxdirect/CompileClassTypes.o -idist/wxdirect -odir dist/wxdirect -hidir dist/wxdirect -package parsec -cpp -package time Segmentation fault (core dumped) :( Maarten Hazewinkel The point being that Haskell, while having a theorem checker that helps programmers find and avoid bugs and while being based on semi-formal concepts that can be used to avoid some pitfalls, is still no silver bullet against any and all crashes. Promising would-be converts that it is will only lead to disappointment. Tim Newsham http://www.thenewsh.com/~newsham/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Haskell Speed Myth
On 2008 Aug 23, at 18:34, Krzysztof Skrzętnicki wrote: Recently I wrote computation intensive program that could easily utilize both cores. However, there was overhead just from compiling with -threaded and making some forkIO's. Still, the overhead was not larger than 50% and with 4 cores I would probably still get the results faster - I didn't experience an order of magnitude slowdown. Perhaps it's the issue with OS X. All that's needed for multicore to be a *lot* slower is doing it wrong. Make sure you're forcing the right things in the right places, or you could quietly be building up thunks on both cores that will cause lots of cross-core signaling or locking. And, well, make sure the generated code isn't stupid. Quite possibly the PPC code is an order of magnitude worse than the better-tested Intel code. -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] [EMAIL PROTECTED] system administrator [openafs,heimdal,too many hats] [EMAIL PROTECTED] electrical and computer engineering, carnegie mellon universityKF8NH ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Haskell Propeganda
Thomas Davie wrote: http://games.slashdot.org/comments.pl?sid=654821cid=24716845 Apparently, no one realises that a SEGFAULT is a type error, just not a very helpful one. Right, so here's an action plan for a clueless C-programmer: - Recompile program in debug mode. - Start application in debugger. - See where error happens, check out call-stack, check out local variables and possibly some heap. - Fix problem, repeat action plan if needed. Here's an error the Haskell run-time system might throw: *** Exception: Prelude.head: empty list (or whatever) So now what? Action plan = []. Perhaps Hat could help here? Or the new GHCi debugger? As a professional C++ programmer and a free-time fan of Haskell I'm not sure e.g. Visual Studio and the Haskell debugging tools I've just mentioned are on the same level of usability. Be careful with your propaganda before you have the real-world tools to back it up. Regards, Niels, devil's advocate, never idealistic. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Haskell Propeganda
On 2008 Aug 23, at 17:29, C.M.Brown wrote: I wonder whether seg faults are the true analogue to errors such as error: head empty list. or pattern match errors. Not really; while laziness does introduce a certain amount of spooky action at a difference to such errors, it's not nearly as bad as the memory corruption (due to effective type mismatches) that often leads to the segfault. -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] [EMAIL PROTECTED] system administrator [openafs,heimdal,too many hats] [EMAIL PROTECTED] electrical and computer engineering, carnegie mellon universityKF8NH ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] parsec, hGetContents
I'm writing an NNTP client API. When I connect with connectTo, I get a Handle 'h'. I immediately hGetContents h to get a string 'c' that I hope contains all the data the server will ever send. I put h and c in a data Connection and pass it to the functions that send or receive. I send a command and receive a response. The response might look like 200 OK\r\n. Parsec parses c. No problem. But if I send another command and receive another response, parsec parses the same string because (I think) I haven't trimmed the part I parsed on the previous command. Maybe c looks like 200 OK\r\n200 second thing\r\n. So I was thinking I need to parse and return the unparsed part so that the next parse will work. Parsec has a getInput that returns the unparsed part, but it blocks if there is no more to parse. That is, after I parse 200 OK\r\n, if I ask parsec for the rest, it blocks because there isn't any rest yet. How should I be doing this? Before people suggest I hGetLine and parse that, I don't like hGetLine for this because 1) it assumes '\n' signifies the end of a line, whereas in my case the protocol specifies \r\n and 2) if the line doesn't have an ending, I can't tell it from what hGetLine returns. That is, hGetLine on a handle having abc\n returns the same thing as on a handle having abc. Also, if I can parse c directly, I can write parsers (especially those for multiline respones) much more naturally than I can if I have to get lines separately. Thanks very much for any help. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Haskell Propeganda
brian wrote: Here's an error the Haskell run-time system might throw: *** Exception: Prelude.head: empty list (or whatever) So now what? Action plan = []. http://cgi.cse.unsw.edu.au/~dons/blog/2007/11/14 Thank you for the URL, but I'm aware of the work in GHC(i). As I've mentioned in my previous e-mail the tooling is definitely not on-par with something like Visual Studio, or perhaps Eclipse for Java. And by not on-par I mean it's miles away from the same level. Microsoft engineers have surely done a good job in the Visual Studio 2005 debugger and unfortunately Microsoft Research doesn't have the same resources to work on the Haskell debugger. Referring to the OP: if Haskell is ever to become a mainstream language (and I certainly hope it will!) an IDE and integrated visual debugger is a must. Until then, perhaps is better to be conservative when kicking on the C language, it has survived worse storms (and not because it's the better language). Regards, Niels ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Haskell Propeganda
wrt head [], Niels said: So now what? Action plan = [] Oh come now. Between ghci, hpc, and manual analysis I've never hit a Haskell error and thrown my hands up, I can't go any further, I'm at a complete loss! Also it helps that I run into this extremely rarely - I have a larger habit of hidding black holes :-( Niels said: Thank you for the URL, but I'm aware of the work in GHC(i). It might interest you to know some people actually use hpc for debugging with reasonble success - it colors the unevaluated sections and this can be very helpful in determining where a program stopped and threw an exception. If you have your eyes on the future you should see Dana Xu's work on static contract checking (check out her Cambridge page). Cheers, Tom ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Haskell Propeganda
G'day all. Quoting Don Stewart [EMAIL PROTECTED]: We promise both safety and efficiency. We also provide (though don't promise) modularity, robustness and correctness, which is not something that Java gives you out of the box. Cheers, Andrew Bromage ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Haskell Speed Myth
That's really interesting -- I just tried this. Compiling not using -threaded: 1.289 seconds Compiling using -threaded, but not running with -N2: 3.403 seconds Compiling using -threaded, and using -N2: 55.072 seconds I was hoping to see a relative improvement when introducting an opportunity parallelism in the program, so I made a version with two MVars filled at the start. This didn't work out though - perhaps some performance stands to be gained by improving the GHC scheduler wrt cpu / OS thread affinity for the Haskell threads? For the curious: -O2: 7.3 seconds (CPU: 99.7% user) -O2 -threaded: 11.5 seconds (CPU: 95% user, 5% system) -O2 -threaded ... +RTS -N2: killed after 3 minutes (CPUs: 15% user, 20% system) Thats quite a lot of CPU time going to the system. Specs: Linux 2.6.26 (Arch) x86_64 Intel Core 2 Duo 2.5GHz SOURCE Notice the threads still exist when a value of 0 is seen - this is OK as the other value will be terminating ringsize threads earlier and this thread will never be needed again. import Control.Monad import Control.Concurrent import System.Environment ring = 503 new l i = do r - newEmptyMVar forkIO (thread i l r) return r thread :: Int - MVar Int - MVar Int - IO () thread i l r = go where go = do m - takeMVar l when (m == 1) (print i) putMVar r $! m - 1 when (m 0) go main = do val - return . read . head = getArgs a - newMVar val b - newMVar val y - foldM new a [2..ring] forkIO $ thread (ring+1) y b z - foldM new b [(ring + 2)..(ring + ring)] thread 1 z a ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] multi-core programming in Haskell
Thank you Murray. My post was not so clear I was referring to automatic parellelization vs manual parallelization. By automatic I mean the programmer doesn't have to indicate where to parallelize ... instead the compiler decides how to parallize! Vasili On Sat, Aug 23, 2008 at 12:58 AM, Murray Gross [EMAIL PROTECTED] wrote: Vasili: Each par sparks a new thread, which is then queued for execution. At appropriate points, the threads are distributed to available (free) processors (cores). The result is that parallelization scales automatically with the number of available processors. Take a look at the GPH site for papers that will provide more information on how parallel (and distributed) Haskell does things. Best, Murray Gross, Brooklyn College On Fri, 22 Aug 2008, Galchin, Vasili wrote: Hello, With pure side of the Haskell house, there is hope that the generated code could automagically scale as more cores are added yes? It seems that it is on the stateful monadic side of the house in an appplication that it is the programmer responsibility to design the software so that it scales across increasing cores? (I am assuming that things like par construct are monadic). On Monday, I am starting a several month project with a company. Alledgely some of the code will be written in Python. I would like engage the manager in a discussion about multi-core enabling the code now when we design and implement not later as an afterthought. Seems like a gnarly subject given current state-of-the-art software tools. Ideas?! Regards, Vasili ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Haskell Propeganda
On 2008.08.24 01:29:18 +0200, Niels Aan de Brugh [EMAIL PROTECTED] scribbled 1.0K characters: Thomas Davie wrote: http://games.slashdot.org/comments.pl?sid=654821cid=24716845 Apparently, no one realises that a SEGFAULT is a type error, just not a very helpful one. Right, so here's an action plan for a clueless C-programmer: - Recompile program in debug mode. - Start application in debugger. - See where error happens, check out call-stack, check out local variables and possibly some heap. - Fix problem, repeat action plan if needed. Here's an error the Haskell run-time system might throw: *** Exception: Prelude.head: empty list (or whatever) So now what? Action plan = []. Perhaps Hat could help here? Or the new GHCi debugger? As a professional C++ programmer and a free-time fan of Haskell I'm not sure e.g. Visual Studio and the Haskell debugging tools I've just mentioned are on the same level of usability. Be careful with your propaganda before you have the real-world tools to back it up. Regards, Niels, devil's advocate, never idealistic. What do I do? In the very rare case that it isn't immediately obvious where the head is coming from, I pull out the interlude library: http://hackage.haskell.org/cgi-bin/hackage-scripts/package/interlude. 2 or 3 lines later, I run the binary and find out the answer. -- gwern CESID Security Delta d DUVDEVAN SRI composition data-haven SONANGOL World signature.asc Description: Digital signature ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
