Re: [Haskell-cafe] darcs patch dependencies in dot format
On 5/12/12 8:52 AM, Sönke Hahn wrote: Any comments or suggestions? Cabalize it and release it on Hackage. But especially the cabalization part :) You should probably farm out the toDot rendering to one of the libraries that focuses on that[1], since they'll have focused on the efficiency issues--- or if they haven't, then you can contribute improvements there, helping everyone win. In particular, you're using Strings which is a notorious performance sink. Using Text or ByteStrings would be far better. Also, have you compared your transitive reduction to just outputting the whole graph and then using `tred`? The latter approach has the distinct downside of needing to serialize the whole graph; but it could still be a win unless you intend to implement similar algorithms yourself. The smart algorithms do *much* better than brute force. And of course it'd be nice to be able to pass arguments to the program in order to filter and otherwise manipulate the resulting graph. A lot of that can be done by special programs which only know about the Dot language (e.g., tred), so you should only focus on things which aren't captured by the Dot language or are otherwise only knowable by querying Darcs. [1] Like graphviz or language-dot: http://hackage.haskell.org/package/graphviz http://hackage.haskell.org/package/language-dot Though it doesn't look like those are used by the various other foo2dot programs on Hackage: http://hackage.haskell.org/package/hs2dot http://hackage.haskell.org/package/prof2dot http://hackage.haskell.org/package/scons2dot http://hackage.haskell.org/package/vacuum-cairo http://hackage.haskell.org/package/vacuum-opengl So perhaps there's some issue with those libraries... -- Live well, ~wren ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] darcs patch dependencies in dot format
On 16 May 2012 19:43, wren ng thornton w...@freegeek.org wrote: On 5/12/12 8:52 AM, Sönke Hahn wrote: Any comments or suggestions? Cabalize it and release it on Hackage. But especially the cabalization part :) You should probably farm out the toDot rendering to one of the libraries that focuses on that[1], since they'll have focused on the efficiency issues--- or if they haven't, then you can contribute improvements there, helping everyone win. In particular, you're using Strings which is a notorious performance sink. Using Text or ByteStrings would be far better. Also, have you compared your transitive reduction to just outputting the whole graph and then using `tred`? The latter approach has the distinct downside of needing to serialize the whole graph; but it could still be a win unless you intend to implement similar algorithms yourself. The smart algorithms do *much* better than brute force. I would like to point out that graphviz has a native implementation of tred (well, analogous rather than exact re-implementation). I also haven't joined this discussion before now, but some of the reduction algorithms in Graphalyze [1] (as used in SourceGraph [2]) might be applicable, though I admit they're not the best possible implementations [1]: http://hackage.haskell.org/package/Graphalyze [2]: http://hackage.haskell.org/package/SourceGraph And of course it'd be nice to be able to pass arguments to the program in order to filter and otherwise manipulate the resulting graph. A lot of that can be done by special programs which only know about the Dot language (e.g., tred), so you should only focus on things which aren't captured by the Dot language or are otherwise only knowable by querying Darcs. [1] Like graphviz or language-dot: http://hackage.haskell.org/package/graphviz http://hackage.haskell.org/package/language-dot Though it doesn't look like those are used by the various other foo2dot programs on Hackage: http://hackage.haskell.org/package/hs2dot http://hackage.haskell.org/package/prof2dot http://hackage.haskell.org/package/scons2dot http://hackage.haskell.org/package/vacuum-cairo http://hackage.haskell.org/package/vacuum-opengl So perhaps there's some issue with those libraries... -- Live well, ~wren ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe -- Ivan Lazar Miljenovic ivan.miljeno...@gmail.com http://IvanMiljenovic.wordpress.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Can Haskell outperform C++?
On 5/10/12 8:44 PM, Ryan Newton wrote: through the trouble of writing my algorithms in C/C++, but simple-minded people often have a desire to get the best performance possible, in which case you really want to use C, C++, Fortran or whatever high level assembler language you like. I think this is a bit of an unfair accusation (simple-minded). Well, yes and no. On the one hand, characterizing those who desire the best performance possible as simple-minded is, at best, a gross over-generalization. Like you, I work in a field where optimization is king (e.g., in machine translation, program runtimes are measured in days). But on the other hand, there are quite a lot of people who focus excessively on optimization when the actual differences for the code they're writing are either negligible (e.g., because of I/O bottlenecks) or uninteresting (e.g., a 2x slowdown is a nuisance rather than a crisis). For those who focus on optimization when the benefits are negligible or uninteresting, I think it's fair to characterize that focus as simple-minded. This focus seems especially common when people start talking about which language is faster--- as opposed to, say, which library is faster, or which implementation of a given algorithm is faster. In some cases the question of language speed is legitimate, but IME it's far more often used to prop up prejudices about which language is better--- i.e., which group of human beings (defined by their choice of programming language) is better. I agree that, as a community, we need to come to a realistic understanding of the performance characteristics of Haskell compared to C etc. I don't like prejudice and propaganda for Haskell any more than I like prejudice and propaganda for C etc. In some cases it's true that Haskell out-performs C (or C++, or Java); but in many cases it does not, and we need to acknowledge that. The real problem, I feel, is that it's not always clear which category any given program falls into. In some cases the idiomatic Haskell is the fast one, in some cases its the slow one; but in all cases, what is meant by idiomatic Haskell is a moving target with poorly specified meaning. The advent of ByteStrings was a major coup in figuring out exactly where and why Haskell is slow and how to fix it. Iteratees are another one, though the details are still being worked out. However, things like strictness annotations on (non-accumulator) function arguments, the choice whether to use ST or not, the choice whether to CPS-transform or not, etc, are still very much a black art. Even with a thorough understanding of the STG-machine and the GHC compilation pipeline, it's not always clear whether they will help or hurt. ST in particular is especially finicky, to the point where I wonder if it's ever a win (outside of in-place updates on arrays). So while I think most language performance comparisons are dubious to begin with, I don't think the comparison of Haskell to C++ (or C, or Java,...) can even be construed as something with a meaningful answer. Haskell is just too different, and its in-the-large cost model is too poorly understood. I'm not even aware of any helpful generalizations over comparing two specific programs. Even when restricting to things like parsing or compute-intensive numeric code, the comparison comes back with mixed answers. -- Live well, ~wren ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Can Haskell outperform C++?
On the one hand, characterizing those who desire the best performance possible as simple-minded is, at best, a gross over-generalization. Like you, I work in a field where optimization is king (e.g., in machine translation, program runtimes are measured in days). You misread the logical implication, Ertugrul said: simple-minded people often have a desire to get the best performance possible Which means: A is simple-minded == A will (most probably) want to get the best perf. You interpreted it as: A wants to get the best perf. == A is simple-minded I agree with you, the second implication is wrong, but that's not what was meant. (Moral: Should people use more logical operators and less words we would undertand better). 2012/5/16 wren ng thornton w...@freegeek.org On 5/10/12 8:44 PM, Ryan Newton wrote: through the trouble of writing my algorithms in C/C++, but simple-minded people often have a desire to get the best performance possible, in which case you really want to use C, C++, Fortran or whatever high level assembler language you like. I think this is a bit of an unfair accusation (simple-minded). Well, yes and no. On the one hand, characterizing those who desire the best performance possible as simple-minded is, at best, a gross over-generalization. Like you, I work in a field where optimization is king (e.g., in machine translation, program runtimes are measured in days). But on the other hand, there are quite a lot of people who focus excessively on optimization when the actual differences for the code they're writing are either negligible (e.g., because of I/O bottlenecks) or uninteresting (e.g., a 2x slowdown is a nuisance rather than a crisis). For those who focus on optimization when the benefits are negligible or uninteresting, I think it's fair to characterize that focus as simple-minded. This focus seems especially common when people start talking about which language is faster--- as opposed to, say, which library is faster, or which implementation of a given algorithm is faster. In some cases the question of language speed is legitimate, but IME it's far more often used to prop up prejudices about which language is better--- i.e., which group of human beings (defined by their choice of programming language) is better. I agree that, as a community, we need to come to a realistic understanding of the performance characteristics of Haskell compared to C etc. I don't like prejudice and propaganda for Haskell any more than I like prejudice and propaganda for C etc. In some cases it's true that Haskell out-performs C (or C++, or Java); but in many cases it does not, and we need to acknowledge that. The real problem, I feel, is that it's not always clear which category any given program falls into. In some cases the idiomatic Haskell is the fast one, in some cases its the slow one; but in all cases, what is meant by idiomatic Haskell is a moving target with poorly specified meaning. The advent of ByteStrings was a major coup in figuring out exactly where and why Haskell is slow and how to fix it. Iteratees are another one, though the details are still being worked out. However, things like strictness annotations on (non-accumulator) function arguments, the choice whether to use ST or not, the choice whether to CPS-transform or not, etc, are still very much a black art. Even with a thorough understanding of the STG-machine and the GHC compilation pipeline, it's not always clear whether they will help or hurt. ST in particular is especially finicky, to the point where I wonder if it's ever a win (outside of in-place updates on arrays). So while I think most language performance comparisons are dubious to begin with, I don't think the comparison of Haskell to C++ (or C, or Java,...) can even be construed as something with a meaningful answer. Haskell is just too different, and its in-the-large cost model is too poorly understood. I'm not even aware of any helpful generalizations over comparing two specific programs. Even when restricting to things like parsing or compute-intensive numeric code, the comparison comes back with mixed answers. -- Live well, ~wren __**_ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/**mailman/listinfo/haskell-cafehttp://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Can Haskell outperform C++?
Wren, I see at least three different issues being discussed here. I think it is important to delineate them: 1) Does Haskell and its libraries need performance improvements? Probably yes. Some of the performance issues seem to be related to the way the language is implemented and others by how it is defined. Developers really do run into performance issues with Haskell and either learn to work around the issue or try to fix the offending implementation. The wiki performance page gives insight into some of the performance issues and how address them. 2) Are language performance comparisons useful? They can be, if the comparison is focusing on what each language does best. They aren't useful if they focus on benchmarks that aren't relevant to the target domain of each language. I think the problem with current comparisons, is that they are designed to favor imperative languages. 3) Are the negative perceptions generated by popular performance comparisons important? Only if you care about the broader adoption of the language. If you don't care, then the point is moot. If you do care, then yes the comparisons are unfair and simple minded, but they do have an affect on the percepts of the language. It is not uncommon for management to raise roadblocks to the introduction of new technologies due to flawed reports that were published in popular magazines. If Haskell were a product and I was responsible for its success, then I would be using common marketing techniques to combat the negative perceptions. One is a technique called changing the playing field which means producing documents that reset the criteria for the evaluations and comparisons. This is not deception, but merely making sure that potential users understand where and how to make the proper comparisons, or more importantly that my champion was well armed with documentation to counter argue popular but flawed comparisons. On 5/16/2012 6:54 AM, wren ng thornton wrote: Haskell is just too different, and its in-the-large cost model is too poorly understood. I'm not even aware of any helpful generalizations over comparing two specific programs. Even when restricting to things like parsing or compute-intensive numeric code, the comparison comes back with mixed answers. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Can't prevent memoizing in simple code
The buffer http://hpaste.org/68595 presents a simple code I tried to profile. I spotted what I strongly think to be an abusive memoization. The problem is that I don't see how to (simply) get rid of it. Compiled with -O2, it consumes 130MB of memory, however lines A and B executed separately consume each only 1MB. The infinite list (l 1), whatever I do, keeps being shared between lines A and B. I tried to wrap it in a function, as you can see, I also tried to make it explicitely polymorphic (bypassing monomorphic restriction), nothing solves it, GHC is just to good at memoizing. NB: When compiled without optimisations, the sharing does not happen (side note: but then lack of strictness analysis -- which is what I was testing at the first place -- makes line A (call to suminit2) consume a lot of memory, but this is normal). ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Can't prevent memoizing in simple code
On May 16, 2012, at 12:08 PM, Yves Parès wrote:
The buffer http://hpaste.org/68595 presents a simple code I tried to profile.
I spotted what I strongly think to be an abusive memoization. The problem is
that I don't see how to (simply) get rid of it.
Compiled with -O2, it consumes 130MB of memory, however lines A and B
executed separately consume each only 1MB.
The infinite list (l 1), whatever I do, keeps being shared between lines A
and B.
I tried to wrap it in a function, as you can see, I also tried to make it
explicitely polymorphic (bypassing monomorphic restriction), nothing solves
it, GHC is just to good at memoizing.
Adding a {-# NOINLINE l #-} annotation helps here. Syntactically, it must be
located somewhere a type signature for l would also be valid.
Anthony
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Can't prevent memoizing in simple code
Thanks ^^
My other solution was a dirty trick:
Changing the second (l 1) by a (l (div 2 2)), which would only be good
until GHC knows how to statically analyse it (2-1 wasn't working for
instance).
I also noticed (while profiling to confirm that this was the source of the
memory leak) that adding manually cost centres forces the re-evaluation:
main = do
print $ suminit2 ({-# SCC list1 #-} l 1) 100 0
print $ fst $ suminit ({-# SCC list2 #-} l 1) 100 0
where
l n = enumFrom n
CAF:main5 Main 97 00.00.026.6
50.0
main Main118 00.00.026.6
50.0
list2Main119 00.00.026.6 *50.0
*
main.l Main120 1 26.6 50.026.6
50.0
[...]
CAF:main8 Main 95 00.00.030.4
50.0
main Main110 00.00.030.4
50.0
list1Main111 00.00.030.4
*50.0*
main.l Main112 1 30.4 50.030.4
50.0
We see here that allocations are shared between list1 and list2 (I expected
list1 to get 100% and list2 0%, due to sharing).
Strange...
2012/5/16 Anthony Cowley acow...@gmail.com
On May 16, 2012, at 12:08 PM, Yves Parès wrote:
The buffer http://hpaste.org/68595 presents a simple code I tried to
profile.
I spotted what I strongly think to be an abusive memoization. The problem
is that I don't see how to (simply) get rid of it.
Compiled with -O2, it consumes 130MB of memory, however lines A and B
executed separately consume each only 1MB.
The infinite list (l 1), whatever I do, keeps being shared between lines A
and B.
I tried to wrap it in a function, as you can see, I also tried to make it
explicitely polymorphic (bypassing monomorphic restriction), nothing solves
it, GHC is just to good at memoizing.
Adding a {-# NOINLINE l #-} annotation helps here. Syntactically, it must
be located somewhere a type signature for l would also be valid.
Anthony
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] How to use Plugins package?
Hi, I'm newbie and I've got a problem. I'm trying to get example programs from plugins-auto [1] or hotswap [2] to work. I think question on stackoverflow [3] somewhat related to my problem. They are compiled well, but in runtime I get either segfault or Prelude.undefined or internal error: PAP object entered! I use GHC 7.4.1. x86_64 Ubuntu I've read Plugging Haskell In and would like to make some fun with plugins, but alas... Maybe -dynamic flag is what I seek? Or maybe I need to know something else? Maybe I needn't use Plugins package like in gitit? Please, could you explain how to compile plugins in haskell correctly? Where should I start? [1] http://hackage.haskell.org/package/plugins-auto [2] http://hackage.haskell.org/package/hotswap [3] http://stackoverflow.com/questions/542/help-with-haskell-dynamic-plugin-load ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Can Haskell outperform C++?
Wed May 16 16:40:26 CEST 2012, Gregg Lebovitz wrote: 2) ... I think the problem with current comparisons, is that they are designed to favor imperative languages. Please be specific: - Which current comparisons? - How do you know what they are designed to favor? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] darcs patch dependencies in dot format
On 16 May 2012 19:43, wren ng thornton w...@freegeek.org wrote: You should probably farm out the toDot rendering to one of the libraries that focuses on that[1], since they'll have focused on the efficiency issues--- or if they haven't, then you can contribute improvements there, helping everyone win. In particular, you're using Strings which is a notorious performance sink. Using Text or ByteStrings would be far better. I'm not sure swapping to Text or ByteStrings make be much great shakes for this. If you are generating huge files, where it would count - then the files are going to be a real problem for Graphviz to render (unless Graphviz has seen some optimization recently...). That said, I would recommend Sönke uses a pretty print library rather than Printf as using the former makes for much more idiomatic for Haskell and generally performs well enough for generational activities even if it uses Strings internally. Best wishes Stephen ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Can Haskell outperform C++?
On Wed, May 16, 2012 at 8:40 AM, Gregg Lebovitz glebov...@gmail.com wrote: 1) Does Haskell and its libraries need performance improvements? Probably yes. Some of the performance issues seem to be related to the way the language is implemented and others by how it is defined. Developers really do run into performance issues with Haskell and either learn to work around the issue or try to fix the offending implementation. The wiki performance page gives insight into some of the performance issues and how address them. I think there is a closely-related issue: that you'll need to learn how to debug subtle performance problems *early* in your Haskell programming career. In particular - you will have space leaks and related performance problems in naively-written programs - you will consequently need to learn how to use strictness annotations and other related language features, and how to use the profiler to determine where they're needed For example, imagine you're new to the language, and as an exercise decide to write a program that counts the characters on standard input and writes the count to standard output. A naive program in, say, Python will probably use constant space and be fairly fast. A naive program in Haskell stands a good chance of having a space leak, building a long chain of thunks that isn't forced until it needs to write the final answer. On small inputs, you won't notice. The nasty surprise comes when your co-worker says cool, let's run it on this 100 MB log file! and your program dies a horrible death. If your friend is a sceptic, she'll arch an eyebrow and secretly think your program -- and Haskell -- are a bit lame. The example is contrived, but it's a very common task to consume some big stream of input and produce a much smaller summary of it. I think it's fair to say that you have to be a slightly sophisticated Haskell programmer to do those kinds of things correctly, at least compared to more mainstream languages. My experience is that this is perhaps the most important 'problem' with Haskell performance. Not so much that it's typically two or three or ten times slower than language X, but that it's easy to have a bad experience *early on*, one that seems inconsistent with the language shoot-out and other performance comparisons. Kevin -- Kevin Charter kevin.char...@acm.org ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Can Haskell outperform C++?
Isaac, I was looking at the debian coding contest benchmarks referenced by others in this discussion. All of the benchmarks algorithms, appear to be short computationally intensive programs with a fairly low level of abstraction. In almost all examples, the requirement says: you must implement the X functions as implemented in Java, or C#, or C++. The k-nucleotide even specifies a requirement to use an update a hash-table. I wonder if someone here could come up with a set of benchmarks that would out perform C++. Interesting that you would focus on this one comment in my post and not comment on one on countering the benchmarks with a new criteria for comparing languages. Gregg On 5/16/2012 12:59 PM, Isaac Gouy wrote: Wed May 16 16:40:26 CEST 2012, Gregg Lebovitz wrote: 2) ... I think the problem with current comparisons, is that they are designed to favor imperative languages. Please be specific: - Which current comparisons? - How do you know what they are designed to favor? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] ANN: variable-precision floating point
Hi all, I'm pleased to announce variable-precision-0.2: http://hackage.haskell.org/package/variable-precision There was no announcement for previous versions, as I quickly found their flaws to be too irritating in practice. --8-- excerpt from the hackage page Software floating point with type-tagged variable mantissa precision, implemented using a strict pair of Integer and Int scaled alike to decodeFloat. Instances of the usual numeric type classes are provided, along with additional operators (with carefully chosen fixities) to coerce, adjust and reify precisions. --8-- end excerpt Known shortcomings of this release: * no implementation of (inverse) (hyperbolic) trigonometric functions * no support for negative zero * no support for rounding modes * accuracy has not been extensively verified * termination of algorithms has not been proven The intention of this package is to be simple yet useable in the meantime until there is a version of hmpfr[1] or fixed-precision[2] that work without requiring a custom-compiled GHC. The design of variable-precision was inspired by the latter, and variable-precision is probably inferior, but the lifetime of the variable-precision package is hopefully going to be short. [1] http://hackage.haskell.org/package/hmpfr [2] http://hackage.haskell.org/package/fixed-precision I'm currently mainly using variable-precision for exploring the Mandelbrot Set, particularly in algorithms using Newton's method (for example, tracing external rays, where more precision is needed the closer you get to the boundary of the set). Thanks, Claude PS: --8-- excerpt from ghci session Prelude Numeric.VariablePrecision (pi :: F24) .@$ 200 $ show . (pi -) 1.5815072737072126433832795028841971693993751058209749096292229e-6 Prelude Numeric.VariablePrecision (pi :: F53) .@$ 200 $ show . (pi -) 4.1192675685652988632476805983544532308209749096292228904414057e-15 Prelude Numeric.VariablePrecision (2 :: F53) .@$ 200 $ show . log 0.69314718055994530941723212145817656807550013436025525413214402 Prelude Numeric.VariablePrecision log 2 0.6931471805599453 Prelude Numeric.VariablePrecision (2 :: F53) .@$ 200 $ show . exp 7.3890560989306502272304274605750078131803155705518473240869941 Prelude Numeric.VariablePrecision exp 2 7.38905609893065 --8-- end excerpt ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Can Haskell outperform C++?
Kevin, Interesting point. Over the past few weeks as part of my work, I have interviewed a large numbers of Haskell developers from many different industries and have been hearing the same points you are making. Space leaks that were address by learning how to use laziness and performance issues cleared up by using strictness. Also interesting is that in all my interviews, GHC performance was never raised. No one said "I have to drop into C to solve that performance problem." Gregg On 5/16/2012 1:44 PM, Kevin Charter wrote: On Wed, May 16, 2012 at 8:40 AM, Gregg Lebovitz glebov...@gmail.com wrote: 1) Does Haskell and its libraries need performance improvements? Probably yes. Some of the performance issues seem to be related to the way the language is implemented and others by how it is defined. Developers really do run into performance issues with Haskell and either learn to work around the issue or try to fix the offending implementation. The wiki performance page gives insight into some of the performance issues and how address them. I think there is a closely-related issue: that you'll need to learn how to debug subtle performance problems early in your Haskell programming career. In particular you will have space leaks and related performance problems in naively-written programs you will consequently need to learn how to use strictness annotations and other related language features, and how to use the profiler to determine where they're needed For example, imagine you're new to the language, and as an exercise decide to write a program that counts the characters on standard input and writes the count to standard output. A naive program in, say, Python will probably use constant space and be fairly fast. A naive program in Haskell stands a good chance of having a space leak, building a long chain of thunks that isn't forced until it needs to write the final answer. On small inputs, you won't notice. The nasty surprise comes when your co-worker says "cool, let's run it on this 100 MB log file!" and your program dies a horrible death. If your friend is a sceptic, she'll arch an eyebrow and secretly think your program -- and Haskell -- are a bit lame. The example is contrived, but it's a very common task to consume some big stream of input and produce a much smaller summary of it. I think it's fair to say that you have to be a slightly sophisticated Haskell programmer to do those kinds of things correctly, at least compared to more mainstream languages. My experience is that this is perhaps the most important 'problem' with Haskell performance. Not so much that it's typically two or three or ten times slower than language X, but that it's easy to have a bad experience early on, one that seems inconsistent with the language shoot-out and other performance comparisons. Kevin -- Kevin Charter kevin.char...@acm.org ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] import IO
Hi folks I need a little help. I had a hiccup upgrading my Ubuntu system, and eventually did a fresh install. Its mostly fixed to my old favourite ways but I cannot remember what's needed to install the stuff that the import IO statement uses! -- Andrew ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] import IO
On Wed, May 16, 2012 at 3:32 PM, A Smith asmith9...@gmail.com wrote: Hi folks I need a little help. I had a hiccup upgrading my Ubuntu system, and eventually did a fresh install. Its mostly fixed to my old favourite ways but I cannot remember what's needed to install the stuff that the import IO statement uses! import IO is obsolescent, and recent Ubuntu went with a GHC that deprecated it unless you ask for strict Haskell '98 compatibility. So you can do that (-package haskell98), or you can use the modern name (import System.IO). -- brandon s allbery allber...@gmail.com wandering unix systems administrator (available) (412) 475-9364 vm/sms ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Can Haskell outperform C++?
On 05/16/2012 09:02 PM, Gregg Lebovitz wrote: Isaac, I was looking at the debian coding contest benchmarks referenced by others in this discussion. All of the benchmarks algorithms, appear to be short computationally intensive programs with a fairly low level of abstraction. In almost all examples, the requirement says: you must implement the X functions as implemented in Java, or C#, or C++. The k-nucleotide even specifies a requirement to use an update a hash-table. I wonder if someone here could come up with a set of benchmarks that would out perform C++. That's easy: let ones = 1 : ones take 5 ones [1,1,1,1,1] I'm not sure how much C++ code you'd have to write to produce the correct answer without butchering the intent too much, but the naïve translation to C++ loops infinitely. Obviously Haskell is infintely better than C++!1oneone! Interesting that you would focus on this one comment in my post and not comment on one on countering the benchmarks with a new criteria for comparing languages. Comparing languages is a highly non-trivial matter involving various disciplines (including various squidgy ones) and rarely makes sense without a very specific context for comparison. So the short answer is: mu. Discovering the long answer requires a lifetime or more of research and may not actually result in an answer. Regards, ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Can Haskell outperform C++?
On Wed, May 16, 2012 at 1:17 PM, Gregg Lebovitz glebov...@gmail.com wrote: Also interesting is that in all my interviews, GHC performance was never raised. No one said I have to drop into C to solve that performance problem. That's been my experience too. I've so far been able to get acceptable performance with GHC when I've made good use of the tools for finding space and time leaks. And it hasn't been hard, just something I had to learn to do. Gregg Kevin -- Kevin Charter kevin.char...@acm.org ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Can Haskell outperform C++?
Kevin Charter kchar...@gmail.com writes: snip For example, imagine you're new to the language, and as an exercise decide to write a program that counts the characters on standard input and writes the count to standard output. A naive program in, say, Python will probably use constant space and be fairly fast. A naive program in Haskell stands a good chance of having a space leak, building a long chain of thunks that isn't forced until it needs to write the final answer. On small inputs, you won't notice. The nasty surprise comes when your co-worker says cool, let's run it on this 100 MB log file! and your program dies a horrible death. If your friend is a sceptic, she'll arch an eyebrow and secretly think your program -- and Haskell -- are a bit lame. I, for one, can say that my initial impressions of Haskell were quite scarred by exactly this issue. Being in experimental physics, I often find myself writing data analysis code doing relatively simple manipulations on large(ish) data sets. My first attempt at tackling a problem in Haskell took nearly three days to get running with reasonable performance. I can only thank the wonderful folks in #haskell profusely for all of their help getting through that period. That being said, it was quite frustrating at the time and I often wondered how I could tackle a reasonably large project if I couldn't solve even a simple problem with halfway decent performance. If it weren't for #haskell, I probably would have given up on Haskell right then and there, much to my deficit. While things have gotten easier, even now, nearly a year after writing my first line of Haskell, I still occassionally find a performance issue^H^H^H^H surprise. I'm honestly not really sure what technical measures could be taken to ease this learning curve. The amazing community helps quite a bit but I feel that this may not be a sustainable approach if Haskell gains greater acceptance. The profiler is certainly useful (and much better with GHC 7.4), but there are still cases where the performance hit incurred by the profiling instrumentation precludes this route of investigation without time consuming guessing at how to pare down my test case. It's certainly not an easy problem. Cheers, - Ben ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Can Haskell outperform C++?
Ben, This is precisely the kind of problem I am currently thinking about and why I asked for pointers to documents on best practices. The current model for gaining the necessary experience to use Haskell effectively does not scale well. Here are some ideas on how to address the knowledge issue: 1) Outstanding best practices documents that capture this knowledge and provides useful answers. Organizing this information in an online document that can be searched by keyword or index would be really helpful. The hard part will be maintaining it. As someone already pointed out the wiki entry on performance is already dated. 2) Training presentations derived from #1 that provides lots of examples. 3) Online Training Videos based on #2 above 4) Profiling tools that uses the captured knowledge above, highlights problem areas, and provides guidance on correcting them. As I mentioned in a previous email. I am willing to take on organization #1, but I will need help from people on this list. I can start with the performance wiki, but we will still need examples of where people get into trouble and the ways around them. Gregg On 5/16/2012 4:00 PM, Ben Gamari wrote: Kevin Charterkchar...@gmail.com writes: snip For example, imagine you're new to the language, and as an exercise decide to write a program that counts the characters on standard input and writes the count to standard output. A naive program in, say, Python will probably use constant space and be fairly fast. A naive program in Haskell stands a good chance of having a space leak, building a long chain of thunks that isn't forced until it needs to write the final answer. On small inputs, you won't notice. The nasty surprise comes when your co-worker says cool, let's run it on this 100 MB log file! and your program dies a horrible death. If your friend is a sceptic, she'll arch an eyebrow and secretly think your program -- and Haskell -- are a bit lame. I, for one, can say that my initial impressions of Haskell were quite scarred by exactly this issue. Being in experimental physics, I often find myself writing data analysis code doing relatively simple manipulations on large(ish) data sets. My first attempt at tackling a problem in Haskell took nearly three days to get running with reasonable performance. I can only thank the wonderful folks in #haskell profusely for all of their help getting through that period. That being said, it was quite frustrating at the time and I often wondered how I could tackle a reasonably large project if I couldn't solve even a simple problem with halfway decent performance. If it weren't for #haskell, I probably would have given up on Haskell right then and there, much to my deficit. While things have gotten easier, even now, nearly a year after writing my first line of Haskell, I still occassionally find a performance issue^H^H^H^H surprise. I'm honestly not really sure what technical measures could be taken to ease this learning curve. The amazing community helps quite a bit but I feel that this may not be a sustainable approach if Haskell gains greater acceptance. The profiler is certainly useful (and much better with GHC 7.4), but there are still cases where the performance hit incurred by the profiling instrumentation precludes this route of investigation without time consuming guessing at how to pare down my test case. It's certainly not an easy problem. Cheers, - Ben ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Can Haskell outperform C++?
The profiler is certainly useful (and much better with GHC 7.4) What are the improvements in that matter? (I just noticed that some GHC flags wrt profiling have been renamed) 2012/5/16 Ben Gamari bgamari.f...@gmail.com Kevin Charter kchar...@gmail.com writes: snip For example, imagine you're new to the language, and as an exercise decide to write a program that counts the characters on standard input and writes the count to standard output. A naive program in, say, Python will probably use constant space and be fairly fast. A naive program in Haskell stands a good chance of having a space leak, building a long chain of thunks that isn't forced until it needs to write the final answer. On small inputs, you won't notice. The nasty surprise comes when your co-worker says cool, let's run it on this 100 MB log file! and your program dies a horrible death. If your friend is a sceptic, she'll arch an eyebrow and secretly think your program -- and Haskell -- are a bit lame. I, for one, can say that my initial impressions of Haskell were quite scarred by exactly this issue. Being in experimental physics, I often find myself writing data analysis code doing relatively simple manipulations on large(ish) data sets. My first attempt at tackling a problem in Haskell took nearly three days to get running with reasonable performance. I can only thank the wonderful folks in #haskell profusely for all of their help getting through that period. That being said, it was quite frustrating at the time and I often wondered how I could tackle a reasonably large project if I couldn't solve even a simple problem with halfway decent performance. If it weren't for #haskell, I probably would have given up on Haskell right then and there, much to my deficit. While things have gotten easier, even now, nearly a year after writing my first line of Haskell, I still occassionally find a performance issue^H^H^H^H surprise. I'm honestly not really sure what technical measures could be taken to ease this learning curve. The amazing community helps quite a bit but I feel that this may not be a sustainable approach if Haskell gains greater acceptance. The profiler is certainly useful (and much better with GHC 7.4), but there are still cases where the performance hit incurred by the profiling instrumentation precludes this route of investigation without time consuming guessing at how to pare down my test case. It's certainly not an easy problem. Cheers, - Ben ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Can Haskell outperform C++?
Yves Parès yves.pa...@gmail.com writes: The profiler is certainly useful (and much better with GHC 7.4) What are the improvements in that matter? (I just noticed that some GHC flags wrt profiling have been renamed) The executive summary can be found in the release notes[1]. There was also a talk I remember watching a while ago which gave a pretty nice overview. I can't recall, but I might have been this[2]. Lastly, profiling now works with multiple capabilities[3]. Cheers, - Ben [1] http://www.haskell.org/ghc/docs/7.4.1/html/users_guide/release-7-4-1.html [2] http://www.youtube.com/watch?v=QBFtnkb2Erg [3] https://plus.google.com/107890464054636586545/posts/hdJAVufhKrD ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Can Haskell outperform C++?
On 5/16/2012 3:57 PM, Bardur Arantsson wrote: Comparing languages is a highly non-trivial matter involving various disciplines (including various squidgy ones) and rarely makes sense without a very specific context for comparison. So the short answer is: mu. Discovering the long answer requires a lifetime or more of research and may not actually result in an answer. Depends on your goal. From the discussion on the cafe, it appears that many believe performance is not the only criteria for evaluating languages. I agree with the comment made by Ertugrul Söylemez. Some people focus on getting the best performance because they don't know any better. If given better evaluation criteria they might think differently. Asserting the other criteria publicly helps others understand the benefits of Haskell, otherwise they just see the lower performance numbers from places like the debian contest. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] darcs patch dependencies in dot format
On 17 May 2012 03:31, Stephen Tetley stephen.tet...@gmail.com wrote: On 16 May 2012 19:43, wren ng thornton w...@freegeek.org wrote: You should probably farm out the toDot rendering to one of the libraries that focuses on that[1], since they'll have focused on the efficiency issues--- or if they haven't, then you can contribute improvements there, helping everyone win. In particular, you're using Strings which is a notorious performance sink. Using Text or ByteStrings would be far better. I'm not sure swapping to Text or ByteStrings make be much great shakes for this. If you are generating huge files, where it would count - then the files are going to be a real problem for Graphviz to render (unless Graphviz has seen some optimization recently...). I found with graphviz that switching to Text gave two advantages: 1) Easier to require UTF-8 usage 2) Printing and parsing was faster In part, the speed-up came from switching to wl-pprint-text rather than pretty (the wl-pprint method of pretty-printing seems to have some efficiency improvements in how concatenation is done over pretty) and the Text backend for polyparse lets you use manySatisfy rather than (many . satisfy) which is more efficient. But even in my initial pseudo-port (going via String a lot, etc.) there was a slight speed-up. So I think there is still a valid reason to consider using Text (or possibly ByteString, but I think that has potential issues). That said, I would recommend Sönke uses a pretty print library rather than Printf as using the former makes for much more idiomatic for Haskell and generally performs well enough for generational activities even if it uses Strings internally. Best wishes Stephen ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe -- Ivan Lazar Miljenovic ivan.miljeno...@gmail.com http://IvanMiljenovic.wordpress.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Can Haskell outperform C++?
From: Gregg Lebovitz glebov...@gmail.com Sent: Wednesday, May 16, 2012 12:02 PM I was looking at the debian coding contest benchmarks referenced by others in this discussion. debian coding contest ? It's been called many things but, until now, not that. All of the benchmarks algorithms, appear to be short computationally intensive programs with a fairly low level of abstraction. Tiny tiny toy programs - more or less 100 lines - not quite small enough to be microbenchmarks. Why might that be? Well, not IO bound. Do people usually mean IO performance when they compare programming languages? (I guess you must have excluded meteor-contest from your consideration. It's a coding contest and so doesn't specify an algorithm.) In almost all examples, the requirement says: you must implement the X functions as implemented in Java, or C#, or C++. binary-trees - No, it doesn't say that. thread-ring - No. chameneos-redux - No. pidigits - No. regex-dna - No. k-nucleotide - No. mandelbrot - No. reverse-complement - No. spectral-norm - Each program must implement 4 separate functions / procedures / methods like the C# program. (The point being cross function calling so don't amalgamate 4 functions into a single function.) fasta-redux - No. fasta - No. meteor-contest - No. fannkuch-redux - defined by programs in Performing Lisp Analysis of the FANNKUCH Benchmark n-body - Each program should model the orbits of Jovian planets, using the same simple symplectic-integrator - see the Java program. The k-nucleotide even specifies a requirement to use an update a hash-table. Probably not too onerous a requirement for a test of hash table lookup :-) Some people like hash tables, go figure. http://gregorycollins.net/posts/2011/06/11/announcing-hashtables -snip- Interesting that you would focus on this one comment in my post and not comment on one on countering the benchmarks with a new criteria for comparing languages. Too obvious to be interesting. Interesting that you haven't said how you know they are designed to favor imperative languages ;-) On 5/16/2012 12:59 PM, Isaac Gouy wrote: Wed May 16 16:40:26 CEST 2012, Gregg Lebovitz wrote: 2) ... I think the problem with current comparisons, is that they are designed to favor imperative languages. Please be specific: - Which current comparisons? - How do you know what they are designed to favor? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Haskell Symposium 2012 - deadline approaching
[Deadline for submission of abstracts is in two weeks. The submission page is open, earlier submissions welcome.] Haskell 2012 ACM SIGPLAN Haskell Symposium 2012 Copenhagen, Denmark 13th September, 2012 (directly after ICFP) CALL FOR PAPERS http://www.haskell.org/haskell-symposium/2012/ The ACM SIGPLAN Haskell Symposium 2012 will be co-located with the 2012 International Conference on Functional Programming (ICFP), in Copenhagen, Denmark. The purpose of the Haskell Symposium is to discuss experiences with Haskell and future developments for the language. Topics of interest include, but are not limited to: * Language Design, with a focus on possible extensions and modifications of Haskell as well as critical discussions of the status quo; * Theory, such as formal treatments of the semantics of the present language or future extensions, type systems, and foundations for program analysis and transformation; * Implementations, including program analysis and transformation, static and dynamic compilation for sequential, parallel, and distributed architectures, memory management as well as foreign function and component interfaces; * Tools, in the form of profilers, tracers, debuggers, pre-processors, testing tools, and suchlike; * Applications, using Haskell for scientific and symbolic computing, database, multimedia, telecom and web applications, and so forth; * Functional Pearls, being elegant, instructive examples of using Haskell; * Experience Reports, general practice and experience with Haskell, e.g., in an education or industry context. Papers in the latter three categories need not necessarily report original research results; they may instead, for example, report practical experience that will be useful to others, reusable programming idioms, or elegant new ways of approaching a problem. (Links with more advice appear on the symposium web page.) The key criterion for such a paper is that it makes a contribution from which other Haskellers can benefit. It is not enough simply to describe a program! Regular papers should explain their research contributions in both general and technical terms, identifying what has been accomplished, explaining why it is significant, and relating it to previous work (also for other languages where appropriate). In addition, we solicit proposals for system demonstrations, based on running (perhaps prototype) software rather than necessarily on novel research results. Such short demo proposals should explain why a demonstration would be of interest to the Haskell community. Travel Support: === Student attendees with accepted papers can apply for a SIGPLAN PAC grant to help cover travel expenses. PAC also offers other support, such as for child-care expenses during the meeting or for travel costs for companions of SIGPLAN members with physical disabilities, as well as for travel from locations outside of North America and Europe. For details on the PAC programme, see its web page (http://www.sigplan.org/PAC.htm). Proceedings: There will be formal proceedings published by ACM Press. In addition to printed proceedings, accepted papers will be included in the ACM Digital Library. Authors must transfer copyright to ACM upon acceptance (for government work, to the extent transferable), but retain various rights (http://www.acm.org/publications/policies/copyright_policy). Authors are encouraged to publish auxiliary material with their paper (source code, test data, etc.); they retain copyright of auxiliary material. Accepted demo proposals, assessed for relevance by the PC, will be published on the symposium web page, but not formally published in the proceedings. Submission Details: === * Abstract Submission: Thu 31st May 2012 * Paper Submission : Sat 2nd June 2012, anywhere on earth * Author Notification: Wed 27th June 2012 * Final Papers Due : Tue 10th July 2012 Submitted papers should be in portable document format (PDF), formatted using the ACM SIGPLAN style guidelines (9pt format, more details appear on the symposium web page). The length is restricted to 12 pages, except for Experience Report papers, which are restricted to 6 pages. Each paper submission must adhere to SIGPLAN's republication policy, as explained on the web. Demo proposals are limited to 2-page abstracts, in the same format. Functional Pearls, Experience Reports, and Demo Proposals should be marked as such with those words in the title at time of submission. The paper submission deadline and length limitations are firm. There will be no extensions, and papers violating the length limitations will be
[Haskell-cafe] Haskell Weekly News: Issue 227
Welcome to issue 227 of the HWN, an issue covering crowd-sourced bits of information about Haskell from around the web. This issue covers the week of May 6 to 12, 2012. Announcements Doaitse Swierstra reminded us about the Summer School on Applied Functional Programming, at Utrech University. Hurry to check it out, as the deadline for registration is May 20th! [1] http://goo.gl/TZYdd Janis Voigtlander announced the release of the 22nd edition of the Haskell Communities and Activities Report. [2] http://goo.gl/pXIZn Quotes of the Week * dcoutts: (on #darcs): [on github:] it's like the facebook of source repos * dmwit: Functional programming is a technical term that means more than just what the two words mean separately. * Axman6: GHC Warning: Did you see that in an OOP textbook? You probably don't want to be doing that * StevenKaas: Haskell's Wager: what if infinite lists can suffer infinitely even when lazily evaluated? * quicksilver: Patent covering a device for emitting greetings to the world community as a whole in computer-readable format (US Patent no 1787528391) Top Reddit Stories * Videos to the functional programming course I attend are freely available. I thought you might enjoy them. Domain: self.haskell, Score: 47, Comments: 10 On Reddit: [3] http://goo.gl/SoV7x Original: [4] http://goo.gl/SoV7x * red-black trees in haskell, using GADTs, existential types, and zippers, oh my Domain: gist.github.com, Score: 40, Comments: 21 On Reddit: [5] http://goo.gl/Ae08L Original: [6] http://goo.gl/iDxjY * Equality proofs and deferred type errors, A compiler pearl [Vytiniotis, Peyton Jones,Magalhaes PDF] Domain: research.microsoft.com, Score: 40, Comments: 17 On Reddit: [7] http://goo.gl/6OUbX Original: [8] http://goo.gl/OP6ep * LLVM now supports NVIDIA GPU's Domain: nvidianews.nvidia.com, Score: 36, Comments: 19 On Reddit: [9] http://goo.gl/DF7sY Original: [10] http://goo.gl/rvYdL * The Architecture of Open Source Applications, Volume II (with chapters on GHC and Yesod, royalties go to Amnesty International) Domain: lulu.com, Score: 35, Comments: 9 On Reddit: [11] http://goo.gl/XfsXB Original: [12] http://goo.gl/1sr6u * Jesper's Blog: My Take on Haskell vs Scala Domain: jnordenberg.blogspot.com, Score: 29, Comments: 8 On Reddit: [13] http://goo.gl/3EM45 Original: [14] http://goo.gl/aWGgn * Haskell Communities and Activities Report --- May 2012 Domain: haskell.org, Score: 27, Comments: 3 On Reddit: [15] http://goo.gl/q8XFZ Original: [16] http://goo.gl/fW3Sf * Keter: Web App Deployment Domain: yesodweb.com, Score: 23, Comments: 19 On Reddit: [17] http://goo.gl/VOSVF Original: [18] http://goo.gl/OJ783 * A small and simple tip for Google Code Jam-mers Domain: self.haskell, Score: 22, Comments: 15 On Reddit: [19] http://goo.gl/9QPDW Original: [20] http://goo.gl/9QPDW * Composable Value Editors for GTK Domain: twdkz.wordpress.com, Score: 21, Comments: On Reddit: [21] http://goo.gl/w4WoR Original: [22] http://goo.gl/LevtB * The Brittleness of Type Hierarchies (codegrunt.co.uk) and a Haskell approach Domain: self.haskell, Score: 16, Comments: 17 On Reddit: [23] http://goo.gl/w4m8o Original: [24] http://goo.gl/w4m8o Top StackOverflow Questions * Static types, polymorphism and specialization votes: 18, answers: 3 Read on SO: [25] http://goo.gl/wxDZt * Redoing the standard classes [closed] votes: 12, answers: 2 Read on SO: [26] http://goo.gl/22MCG * Using Cont to acquire values from the future and the past votes: 11, answers: 1 Read on SO: [27] http://goo.gl/1zSVo * Why is `($ 4) ( 3)` equivalent to `4 3`? votes: 9, answers: 3 Read on SO: [28] http://goo.gl/5oTei * Recursively defined instances and constraints votes: 9, answers: 1 Read on SO: [29] http://goo.gl/uliWA * Freeing memory allocated with newCString votes: 8, answers: 1 Read on SO: [30] http://goo.gl/k3Izw * What is the meaning of “quasi” in quasiquotations? votes: 8, answers: 5 Read on SO: [31] http://goo.gl/YjPbl * Ensuring files are closed promptly votes: 7, answers: 3 Read on SO: [32] http://goo.gl/UCKSB * Is there ever a good reason to use unsafePerformIO? votes: 7, answers: 5 Read on SO: [33] http://goo.gl/y2meC * What characters are permitted for haskell operators? votes: 7, answers: 3 Read on SO: [34] http://goo.gl/0n1kX * Defining an algebra module using constructive-algebra package votes: 6, answers: 2 Read on SO: [35] http://goo.gl/vqIcG * Haskell: Type safety with logically different Boolean values votes: 6, answers: 3 Read on SO: [36]
Re: [Haskell-cafe] Can Haskell outperform C++?
In a lecture today I presented (for quite other reasons) a simple combinatorial enumeration problem where the difference between two algorithms was far larger than any plausible difference between programming languages. If a programming language makes it easier to explore high level alternative algorithms, you may very easily end up with faster programs in a slower language. (Sorry about the very long line: broken return key.) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Can Haskell outperform C++?
Richard, Thank you. This is an example of what I had in mind when I talked about changing the playing field. Do you have a slide deck for this lecture that you would be willing to share with me? I am very interested in learning more. Gregg On 5/16/2012 9:13 PM, Richard O'Keefe wrote: In a lecture today I presented (for quite other reasons) a simple combinatorial enumeration problem where the difference between two algorithms was far larger than any plausible difference between programming languages. If a programming language makes it easier to explore high level alternative algorithms, you may very easily end up with faster programs in a slower language. (Sorry about the very long line: broken return key.) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Heads up: importing the Cabal issue tracker to github next week
I am planning on doing this early next week, probably in two phases. As part of the import process, github will generate a *lot* of notification emails. I'm afraid there is nothing I can do to stem the tide, as github does not provide a mechanism to suppress these. If you have a github account, and you have filed bugs against Cabal in Trac, please brace yourself. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Data Kinds and superfluous (in my opinion) constraints contexts
Hello,
The context in your example serves an important purpose: it records the
fact that the behavior of the function may differ depending on which type
it is instantiated with. This is quite different from ordinary
polymorphic functions, such as `const` for example, which work in exactly
the same way, no matter how you instantiate them. Note that it doesn't
matter that we can solve the constraint for all types of kind `D`---the
constraint is there because we can't solve it _uniformly_ for all types.
-Iavor
PS: As an aside, these two forms of polymorphism are sometimes called
parametric (when functions work in the same way for all types), and
ad-hoc (when the behavior depends on which type is being used).
On Sun, May 6, 2012 at 9:48 AM, Serguey Zefirov sergu...@gmail.com wrote:
I decided to take a look at DataKinds extension, which became
available in GHC 7.4.
My main concerns is that I cannot close type classes for promoted data
types. Even if I fix type class argument to a promoted type, the use
of encoding function still requires specification of context. I
consider this an omission of potentially very useful feature.
Example is below.
-
{-# LANGUAGE TypeOperators, DataKinds, TemplateHaskell, TypeFamilies,
UndecidableInstances #-}
{-# LANGUAGE GADTs #-}
-- a binary numbers.
infixl 5 :*
data D =
D0
| D1
| D :* D
deriving Show
-- encoding for them.
data EncD :: D - * where
EncD0 :: EncD D0
EncD1 :: EncD D1
EncDStar :: EncD (a :: D) - EncD (b :: D) - EncD (a :* b)
-- decode of values.
fromD :: D - Int
fromD D0 = 0
fromD D1 = 1
fromD (d :* d0) = fromD d * 2 + fromD d0
-- decode of encoded values.
fromEncD :: EncD d - Int
fromEncD EncD0 = 0
fromEncD EncD1 = 1
fromEncD (EncDStar a b) = fromEncD a * 2 + fromEncD b
-- constructing encoded values from type.
-- I've closed possible kinds for class parameter (and GHC
successfully compiles it).
-- I fully expect an error if I will try to apply mkD to some type
that is not D.
-- (and, actually, GHC goes great lengths to prevent me from doing that)
-- By extension of argument I expect GHC to stop requiring context
with MkD a where
-- I use mkD constant function and it is proven that a :: D.
class MkD (a :: D) where
mkD :: EncD a
instance MkD D0 where
mkD = EncD0
instance MkD D1 where
mkD = EncD1
-- But I cannot omit context here...
instance (MkD a, MkD b) = MkD (a :* b) where
mkD = EncDStar mkD mkD
data BV (size :: D) where
BV :: EncD size - Integer - BV size
bvSize :: BV (size :: D) - Int
bvSize (BV size _) = fromEncD size
-- ...and here.
-- This is bad, because this context will arise in other places, some of
which
-- are autogenerated and context for them is incomprehensible to human
-- reader.
-- (they are autogenerated precisely because of that - it is tedious
and error prone
-- to satisfy type checker.)
fromIntgr :: Integer - BV (size :: D) -- doesn't work, but desired.
-- fromIntgr :: MkD size = Integer - BV (size :: D) -- does work,
but is not that useful.
fromIntgr int = BV mkD int
-
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Can Haskell outperform C++?
On 17/05/2012, at 2:04 PM, Gregg Lebovitz wrote: Richard, Thank you. This is an example of what I had in mind when I talked about changing the playing field. Do you have a slide deck for this lecture that you would be willing to share with me? I am very interested in learning more. No slide deck required. The task is generating alternating permutations. Method 1: generate permutations using a backtracking search; when a permutation is generated, check if it is alternating. Method 2: use the same backtracking search, but only allow extensions that preserve the property of being an alternating permutation. For n=12 the second method is 94 times faster than the first, and the ratio increases with growing n. At the time I wrote the program I had not heard of Bauslaugh and Ruskey's constant-average-time algorithm for generating alternating permutations. Experimentally the Method 2 backtracking search appears to take constant time per solution anyway. n (time ms): En n! 1 (0.0):1 1 - method 1 1 (0.0):1 - method 2 2 (0.0):1 2 2 (0.0):1 3 (0.0):2 6 3 (0.0):2 4 (0.0):5 24 4 (0.0):5 5 (0.0): 16120 5 (0.0): 16 6 (0.1): 61720 6 (0.0): 61 7 (0.6): 272 5040 7 (0.1): 272 8 (4.4): 1385 40320 8 (0.3): 1385 9 ( 35.2): 7936 362880 9 (1.4): 7936 10 ( 359.7):505213628800 10 (9.3):50521 11 ( 4035.7): 353792 39916800 11 ( 67.0): 353792 12 (49584.6): 2702765 479001600 - method 1 12 ( 528.1): 2702765 - method 2 Those times are in C; SWI Prolog (which compiles to an abstract instruction set that is then interpreted by portable C) was about 24 times slower. A factor of 94 comfortably exceeds a factor of 24... ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
