Re: default instance for IsString
Why are potentially partial literals scarier than the fact that every value in the language could lead to an exception when forced? On Tue, Apr 24, 2012 at 5:35 AM, Yitzchak Gale g...@sefer.org wrote: Markus Läll wrote: You do know, that you already *can* have safe Text and ByteString from an overloaded string literal. Yes, the IsString instances for Text and ByteString are safe (I hope). But in order to use them, I have to turn on OverloadedStrings. That could cause other string literals in the same module to throw exceptions at run time. -Yitz ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: default instance for IsString
I think my point was more along the lines that every *value*, regardless of whether it's a function or not, can be partial (ignoring primitive types and such). I can hand you a list where the third Int in it will cause you to crash if you force it. In that sense, whether every numeric literal expands to fromInteger ... or every string literal expands to fromString ... doesn't really make it any different from any other value. Is the concern that because it's polymorphic, that different uses of the same polymorphic value might or might not crash? That's the case for any polymorphic value: take e.g., read (), which will crash or not depending on where it's used. If it's just the case that the value itself could crash when forced, well, that's true of any value of any lifted type. So if every value, when forced, can crash your program, possibly depending on what type it's instantiated to, why are we so concerned about String literals behaving like everything else? Dan On Tue, Apr 24, 2012 at 1:23 PM, Evan Laforge qdun...@gmail.com wrote: From what I can see the core of the disagreement is that some people believe fromString will tempt misuse (i.e. using *easily* partial functions, like XML validation), while others don't think it's that likely. Indeed misusing IsString is worse than your average partial function because of the global nature of typeclasses and fromString being implicit. If that is indeed the core of the disagreement, then can we at least agree that writing a partial fromString is a bad idea? I'd say *easily* partial since someone pointed out the UTF8 fromString is partial, but it's pretty hard to type bad UTF8 accidentally so it doesn't seem so bad to me. If we agree that 'fromString :: String - XML' is a bad idea, then can we just say so don't do that then? Safety is good but there's a point where you have to trust people with the sharp tools. Suppose a library author adding a fromString for regexes that crashes on unbalanced parens. If it's a problem in practice I imagine people would complain to them to change their library, or use another library. On Tue, Apr 24, 2012 at 9:10 AM, Henrik Nilsson n...@cs.nott.ac.uk wrote: Hi, Yitzhack Gale wrote: Wouldn't it be ironic if the one thing that every language other than Haskell is able to check at compile time, namely the static syntax of string literals, could only be checked at run time in Haskell? I don't really see the irony, I'm afraid, as nothing really has changed, and as Simon M. that I don't see what the fuss is about. Presumably, the syntax of string literals as such is still going to be checked by the scanner, as it always was? And the issue, then, is whether an overloaded fromString is total in all its overloadings? Or did I miss something central, here? Well, Haskell is not a total language, so the fact that fromString might have non-total overloadings is not surprising. Yes, fromString would be implicitly inserted, just like e.g. fromInteger for overloaded integer literals, to create the effect of overloaded literals, but this is really just a convenience, albeit an important one. The benefit of an approach to overloading of string literals that is analogous to the existing method for overloading of numeric literals would seem to me to outweigh the benefits of additional static checking through an essentially new approach to overloading of literals for a specific case. Best, /Henrik -- Henrik Nilsson School of Computer Science The University of Nottingham n...@cs.nott.ac.uk ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: default instance for IsString
I think it'll be hard to do that without putting Text in base, which I'm not sure anyone wants to do. Dan On Sat, Apr 21, 2012 at 8:20 PM, Greg Weber g...@gregweber.info wrote: I would like to default IsString to use the Text instance to avoid ambiguous type errors. I see defaulting capability is available for Num. Is there any way to do this for IsString? Thanks, Greg Weber ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: behaviour change in getDirectoryContents in GHC 7.2?
Can't we just have the usual .Internal module convention, where people who want internals can get at them if they need to, and most people get a simpler interface? It's amazingly frustrating when you have a library that does 99% of what you need it to do, except for one tiny internal detail that the author didn't foresee anyone needing, so didn't export. 2011/11/6 John Lask jvl...@hotmail.com for what it is worth, I would like to see both System.IO and Directory export internal functions where the filepath is a Raw Byte representation. I have utilities that regularly scan 100,000 of files and hash the path the details of which are irrelevant to this discussion, the point being that the locale encoding/decoding is not relevant in this situation and adds unnecessary overhead that would affect the speed of the file-system scans. A denotation of a filepath as an uninterpreted sequence of bytes is the lowest common denominator for all systems that I know of and would be worthwhile to export from the system libraries upon which other abstractions can be built. I agree that for the general user the current behavior is sufficient, however exporting the raw interface would be beneficial for some users, for instance those that have responded to this thread. On 7/11/2011 2:42 AM, Max Bolingbroke wrote: On 6 November 2011 04:14, John Millikinjmilli...@gmail.com wrote: For what it's worth, on my Ubuntu system, Nautilus ignores the locale and just treats all paths as either UTF8 or invalid. To me, this seems like the most reasonable option; the concept of locale encoding is entirely vestigal, and should only be used in certain specialized cases. Unfortunately non-UTF8 locale encodings are seen in practice quite often. I'm not sure about Linux, but certainly lots of Windows systems are configured with a locale encoding like GBK or Big5. Paths as text is what *Windows* programmers expect. Paths as bytes is what's expected by programmers on non-Windows OSes, including Linux and OS X. IIRC paths on OS X are guaranteed to be valid UTF-8. The only platform that uses bytes for paths (that we care about) is Linux. I'm not saying one is inherently better than the other, but considering that various UNIX and UNIX-like operating systems have been using byte-based paths for near on forty years now, trying to abolish them by redefining the type is not a useful action. We have to: 1. Provide an API that makes sense on all our supported OSes 2. Have getArgs :: IO [String] 3. Have it such that if you go to your console and write (./MyHaskellProgram 你好) then getArgs tells you [你好] Given these constraints I don't see any alternative to PEP-383 behaviour. If you're going to make all the System.IO stuff use text, at least give us an escape hatch. The unix package is ideally suited, as it's already inherently OS-specific. Something like this would be perfect: You can already do this with the implemented design. We have: openFile :: FilePath - IO Handle The FilePath will be encoded in the fileSystemEncoding. On Unix this will have PEP383 roundtripping behaviour. So if you want openFile' :: [Byte] - IO Handle you can write something like this: escape = map (\b - if b 128 then chr b else chr (0xEF00 + b)) openFile = openFile' . escape The bytes that reach the API call will be exactly the ones you supply. (You can also implement escape by just encoding the [Byte] with the fileSystemEncoding). Likewise, if you have a String and want to get the [Byte] we decoded it from, you just need to encode the String again with the fileSystemEncoding. If this is not enough for you please let me know, but it seems to me that it covers all your use cases, without any need to reimplement the FFI bindings. Max ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: foldr oddity
Yeah, you should absolutely mind the order of the parameters (or more generally, when the operation isn't commutative), the strictness of the function's second parameter. In this case, both () and (||) are strict in their first parameter, but both short circuit if the first parameter is False/True, and don't evaluate their second parameter. The short-circuiting (via laziness) terminates foldr's traversal of the entire list structure and saves the program lots of work. By flipping the arguments, you're basically forcing testr' to traverse the entire list before saying what it knew from the beginning. On Tue, Oct 11, 2011 at 10:45 PM, Frodo Chao frodogr...@gmail.com wrote: Hi, I came upon this when playing with foldr and filter. Compare the two definitions: testr n = foldr (\x y - x y) True [t | (_, t) - zip [1 .. n] [True, True ..]] testr' n = foldr (\x y - y x) True [t | (_, t) - zip [1 .. n] [True, True ..]] I tried these functions on ghci (The Glorious Glasgow Haskell Compilation System, version 7.0.3), and get the following results (with :set +s): testr 100 = True (0.01 secs, 7920832 bytes) testr' 100 = True (8.72 secs, 446585344 bytes) This bizarre (at least to me) behavior also applies to ||. Should I mind the orderings of the parameters (especially the accumulator) in the function passed to foldr? Thak you for reading. Sincerely yours, Frodo Chao ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: [Haskell-cafe] How to install GhC on a Mac without registering?
Isn't gcc just used for its assembler and object file creation, these days, now that via-C is deprecated? Or are there other parts of it that are needed? On Mon, Jun 6, 2011 at 10:47 AM, Malcolm Wallace malcolm.wall...@me.comwrote: On 6 Jun 2011, at 13:49, Lyndon Maydwell wrote: I would be fantastic if XCode wasn't a dependency. ... Not to detract at all from the work of the wonderful GHC and Haskell Platform contributors in any way. For me it would just make it that much easier to convince mac-using friends to give Haskell a try. The ghc team already bundle a copy of gcc in their Windows distribution, precisely because it can be fiddly to get a working copy of gcc for that platform otherwise. I wonder if they would consider the possibility of shipping gcc on Mac too? (There may be good reasons not to do that, but let's have the discussion.) Regards, Malcolm ___ Haskell-Cafe mailing list haskell-c...@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: parsing types
I don't have an answer for you, but you might want to look at what :k does in ghci, since that needs to parse a type. On Sat, Apr 23, 2011 at 2:06 PM, Ranjit Jhala jh...@cs.ucsd.edu wrote: Hi all, can someone give me a hint as to the best way to parse a type from a string. Ideally, I'd like a function stringType :: String - Maybe Type or possibly, stringType :: (GhcMonad m) = String - m (Maybe Type) such that, stringType s == Just t if in the current GHC context the string s is the name of the type t. For example, I'd like: stringType Int to return a value equal to intTy (from TysWiredIn). My investigations have led me to parseType :: P (LHsType RdrName) and I suspect that with some work (mainly creating an appropriate PState, and mapping the name back, I can extract what I want, but I was wondering if there is some simpler route that I've overlooked. Thanks! Ranjit. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Injective type families?
I think what you want is closed type families, as do I and many others :) Unfortunately we don't have those. On Mon, Feb 14, 2011 at 10:02 PM, Conal Elliott co...@conal.net wrote: Yes, it's one things that data families do. Another is introducing *new* data types rather than reusing existing ones. - Conal On Mon, Feb 14, 2011 at 1:41 PM, John Meacham j...@repetae.net wrote: Isn't this what data families (as opposed to type families) do? John On Mon, Feb 14, 2011 at 1:28 PM, Conal Elliott co...@conal.net wrote: Is there a way to declare a type family to be injective? I have data Z data S n type family n :+: m type instance Z :+: m = m type instance S n :+: m = S (n :+: m) My intent is that (:+:) really is injective in each argument (holding the other as fixed), but I don't know how to persuade GHC, leading to some compilation errors like the following: Couldn't match expected type `m :+: n' against inferred type `m :+: n1' NB: `:+:' is a type function, and may not be injective I realize that someone could add more type instances for (:+:), breaking injectivity. Come to think of it, I don't know how GHC could even figure out that the two instances above do not overlap on the right-hand sides. Since this example is fairly common, I wonder: does anyone have a trick for avoiding the injectivity issue? Thanks, - Conal ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: building ghc-7.1.20110125 under Mac OS X
The -march=-i686 issue was fixed in the past couple of days, so I'd just grab a newer version. Not sure about the 64-bit question, though. -Dan On Tue, Feb 1, 2011 at 6:50 AM, Pavel Perikov peri...@gmail.com wrote: hi list. i have to build ghc-7.1.20110125 under mac os x, so i grabbed the stable snapshot. Everything builds fine but the resulting compiler has problems with ld. It passes gcc flags to ld like -march=-i686. Any ideas? BTW while still here. Are there any specific docs available on building 64-bit mac os x compiler? regards pavel ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: RFC: migrating to git
I fully support this (especially if it lived on github), but we should probably sort the top contributors to GHC in the past year or so and consider their opinions on the matter in that order :) I certainly would not be on that list. A git(hub)-based workflow would however facilitate any minor contributions I might make (and I'd imagine those of many others). Dan On Mon, Jan 10, 2011 at 6:19 AM, Simon Marlow marlo...@gmail.com wrote: It's time to consider again whether we should migrate GHC development from darcs to (probably) git. From our perspective at GHC HQ, the biggest problem that we would hope to solve by switching is that darcs makes branching and merging very difficult for us. We have a few branches of HEAD that are very painful to keep merged with HEAD, and we would almost certainly have more branches if the overhead were lower. In some sense the overhead is self-inflicted because we have the no-conflict policy in the mainline repository, but that is to avoid problems with darcs' merging algorithms (both performance and correctness). We are still using darcs v1 patches rather than v2, but there are known problems with v2 which are preventing us from upgrading. The darcs team have been making great strides with performance, but conflict handling remains a serious problem. The darcs roadmap doesn't show this being fixed in the near future http://wiki.darcs.net/Roadmap Rebase support is coming, and it does work, though the workflow is a bit laborious. Besides the branching/merging/conflict issue, switching to git would give us plenty of side benefits, notably via access to a wealth of tool support. Making contribution easy is important to us too, and there are a lot of people using git. The cost of switching is quite high, which is one reason we decided to stay with darcs last time. We have multiple repos that need to be converted, and for some of them, where the repo is being shared with other projects, we may have to mirror rather than convert in place. We're prepared to put in the effort if the gains would be worthwhile though (offers of help are more than welcome!). We're intrested in opinions from both active and potential GHC developers/contributors. Let us know what you think - would this make life harder or easier for you? Would it make you less likely or more likely to contribute? Cheers, Simon ___ Cvs-ghc mailing list cvs-...@haskell.org http://www.haskell.org/mailman/listinfo/cvs-ghc ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: RFC: migrating to git
So the basic point seems to be: if you know how to use a tool, you don't usually curse and swear when you use it. If you don't, you tend to swear a lot! :) On Mon, Jan 10, 2011 at 5:32 PM, Adam Wick aw...@galois.com wrote: On 01/10/2011 08:52 AM, Malcolm Wallace wrote: If I were considering contributing minor patches to a project, the use of git would probably not deter me too much - I can cope with the simple stuff. But if I wanted more major involvement, git would definitely cause me to think twice about whether to bother. And just to show that you can't make everyone happy ... I'll put in an equal-and-opposite vote from Malcolm. GHC's use of darcs is a blocker for me even thinking about doing any work on GHC or the related libraries; my limited experience with darcs has been terrible, and the swearing I've heard about darcs makes me think my experience was not unique. Switching to git would make the chance that I'd do work on GHC nonzero. - Adam ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Removing/deprecating -fvia-c
I thought GHC's own codegen didn't do any instruction reordering for the pipeline. I guess that ends up not being much of an issue in practice? On Sun, Feb 14, 2010 at 12:58 PM, Don Stewart d...@galois.com wrote: igloo: Hi all, We are planning to remove the -fvia-c way of compiling code (unregisterised compilers will continue to compile via C only, but registerised compilers will only use the native code generator). We'll probably deprecate -fvia-c in the 6.14 branch, and remove it in 6.16. Simon Marlow has recently fixed FP performance for modern x86 chips in the native code generator in the HEAD. That was the last reason we know of to prefer via-C to the native code generators. But before we start the removal process, does anyone know of any other problems with the native code generators that need to be fixed first? Do we have the blessing of the DPH team, wrt. tight, numeric inner loops? As recently as last year -fvia-C -optc-O3 was still useful for some microbenchmarks -- what's changed in that time, or is expected to change? -- Don ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Compiling to ANSI C
You can use -fvia-C and -keep-hc-files but the generated C code is pretty platform-dependent (at least in terms of word sizes and so on... it may be possible to port across platforms with the same word sizes?), and probably won't help you cross-compile. It also doesn't look much like any c code any human would have written, and I think there are plans to deprecate the via-C compilation pathway eventually. If you are looking to add cross-compilation to GHC, the first thing I'd look at is detaching the choice of native code generator from the preprocessor and hooking it up to a front-end command-line option instead :) Someone on IRC (his username is dumael, not sure what his real name is) has already been working on an ARM native code generator for GHC recently. The recent LLVM back-end development should also make it pretty simple to generate code for other platforms (especially if we have a nice way to pass front-end options to the code generators) Dan On Sat, Nov 7, 2009 at 12:08 PM, han e...@xtendo.org wrote: I am (in fact we are) working to make Haskell code to run on an ARM Linux machine called GP2X Wiz, the open-source based handheld game console. I wish to finally make a Haskell cross-compiler for ARM Linux, and for now I am trying to make main = putStrLn Hello, World! to run on the machine. At first I did $ ghc hello.hs -o hello -fvia-C -keep-hc-files and tried to use the generated hc file, but figured that the code is (or at least some code in the included headers is) x86-dependent. I heard that the GHC can compile to ANSI C, and I want to use it as an intermediate code to ARM Linux before we can actually port the GHC to it. Is there any specific option I have to give in order to generate an ANSI C code from a Haskell source code? ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: STM experiment
Hi Luca, Just in case you weren't aware of it, your example didn't actually contain any STM (beyond the import), just regular Haskell IO-based concurrency. But the answer to your question is that there's no synchronization on writing to a file descriptor, so both threads are simultaneously writing to stdout (hPutStr stdout ...\n === putStrLn ... by the way) and result in the interleaved results you see. One solution is to have a thread that effectively owns stdout, and instead of writing to stdout, you write to a Chan (Control.Concurrent.Chan) to talk to the stdout owner, who will then write out your messages. This approach will give you the Hello world or world Hello output that you were after. Hope this helps, Dan On Fri, Oct 2, 2009 at 12:16 PM, Luca Ciciriello luca_cicirie...@hotmail.com wrote: Hi All. I'm very new using Concurrency and STM in Haskell. I'm trying some basic example using STM like this one: module Main where import IO import Control.Concurrent import Control.Concurrent.STM main :: IO () main = do forkIO (hPutStr stdout Hello) hPutStr stdout world\n Loading this module in GHCi and running main, the result is: wHoerllldo On MacOs X 10.5.8 and on WindowsXp Compiling this module with: ghc --make Main.hs -o Main and launcing ./Main the result is just: Terminal world Am I doing something wrong? My expected result was Hello world (or world Hello) Thanks in advance for any answer. Luca. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Choosing implementation depending on class instances using rewriting rules
This isn't necessarily correct, is it? An equality-based (n^2) nub
works fine on infinite lists, whereas any O(n log n) sort-based nub
must necessarily evaluate the entire list before being able to return
the value. The original n^2 nub also returns the elements in the order
of their first appearance rather than sorted order.
Of course, you may not care about this and just be experimenting with
rewrite rules, in which case I can't help you :)
Dan
On Wed, Jun 3, 2009 at 5:58 AM, Milan Straka f...@ucw.cz wrote:
Hi,
I am interesting in writing a method nub in such a way, that it will
use O(N^2) trivial algorithm for types with equality only, and O(N log N)
algorithm for comparable types. I would like to say
class Nub where nub :: [a] - [a]
instance Ord a = Nub a where nub = nubOrd
instance Eq a = Nub a where nub = nubEq
which is of course not valid Haskell. I tried using GHC rewriting rules
to achieve this. My first try was
{-# NOINLINE nub #-}
nub :: Eq a = [a] - [a]
nub xs = ...
nubOrd :: Ord a = [a] - [a]
nubOrd xs = ...
{-# RULES nub/nubOrd nub = nubOrd #-}
which does not work either, because of missing an Ord a context. I was not
able to write the rule which would fire.
Is there a way to write such a rewriting rule or there is no way of acquiring
the Ord dictionary in rewrite rule? Or does anyone know any other way
of implementing such a nub without explicitly listing all Ord instances?
I wish you a nice day,
Milan Straka
PS: Listing {-# RULES nub/nubOrd Int nub = nubOrd :: [Int]-[Int] #-} for
all Ord instances would work, but ...
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: No last core parallel slowdown on OS X
That looks great! I wonder what about Mac OS leads to such good performance... Now if only we could get a nice x86_64-producing GHC for Mac OS too, I could use all my RAM and the extra registers my Mac Pro gives me :) On Sat, Apr 18, 2009 at 2:39 PM, Dave Bayer ba...@cpw.math.columbia.edu wrote: I'm a huge fan of the recent paper http://ghcmutterings.wordpress.com/2009/03/03/new-paper-runtime-support-for-multicore-haskell/ which put me over the top to get started writing parallel code in Haskell. Parallel code is now integral to my and my Ph.D. students' research. For example, we recently checked an assertion for the roughly 69 billion atomic lattices on six atoms, in a day rather than a week, using perhaps 6 lines of parallel code in otherwise sequential code. When you're anxiously waiting for the answer, a day is a lot better than a week. (The enumeration itself is down to two hours on 7 cores, which astounds me. I see no reason to ever use another language.) In that paper, they routinely benchmark N-1 cores on an N core Linux box, because of a noticeable falloff using the last core, which can do more harm than good. I had confirmed this on my four core Linux box, but was puzzled that my two core MacBook showed no such falloff. Hey, two cores isn't representative of many cores, cache issues yada yada, so I waited. I just got an EFi-X boot processor (efi-x.com) working on a nearly identical quad core box that I built, and I tested the same computations with OS X. For my test case, there's a mild cost to moving to parallel at all, but... Compared to 2 cores, using 3, 4 cores on a four core Linux box gives speedups of 1.37x, 1.38x Compared to 2 cores, using 3, 4 cores on an equivalent four core box running OS X gives speedups of 1.45x, 1.9x Here 1.5x, 2.0x is ideal, so I'm thrilled. If we can't shame Linux into fixing this, I'm never looking back. How true is this for other parallel languages? Haskell alone is perhaps too fringe to cause a Linux scandal over this, even if it should... The EFi-X boot processor itself is rather expensive ($240 now), and there's sticking to a specific hardware compatibility list, and I needed to update my motherboard BIOS and the EFi-X firmware, but no other fiddling for me. These boxes are just compute servers for me, I would have been ok returning to Linux, but not if it means giving up a core. People worry about compatibility, I sensed a softness in the surround sound in game X..., but for me the above numbers put all this in perspective. Another way to put this, especially for those who don't have a strong preference for building their own machines, and can't wait for Linux to get its act together: If you're serious about parallel Haskell, buy a Mac Pro. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
