Re: [Haskell-cafe] Faster timeout but is it correct?
Hi Bas, The solution is probably to reverse the order of: unsafeUnmask $ forkIO to forkIO $ unsafeUnmask. Or just use forkIOUnmasked. The reason I didn't used that in the first place was that it was much slower for some reason. The reason is probably that in order for the forkIOUnmaske-d thread to receive an exception (which it must, to be killed), it first has to be activated at least once, to perform the unsafeUnmask. So the worker thread's call to killThread will block. Now if there were a way to specify the exception mask of the newly created thread directly, it should be just as fast as the unsafeUnmask . forkIO version. I have not checked the event manager based implementation in detail, but from your numbers it looks like the best option at this time. Best regards, Bertram ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Haskell for children? Any experience?
Message: 7 Date: Sun, 20 Feb 2011 04:34:56 +0900 From: Benjamin L. Russell dekudekup...@yahoo.com Subject: Re: [Haskell-cafe] Haskell for children? Any experience? To: haskell-cafe@haskell.org Message-ID: ijp613$9q5$1...@dough.gmane.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Actually, I've been wishing for a high-level way of creating an interactive three-dimensional virtual world in Haskell that doesn't require explicit knowledge of linear algebra. Ideally, I'm looking for a Haskell way of creating a functional counterpart to, say, Open Cobalt (see http://www.opencobalt.org/) that is high-level-enough not to require explicit manipulation of row and column vectors. One of the main problems, however, is the lack of reflection. Ideally, I would like the project to be able to modify its own framework in real time, so that, for example, within the virtual world, users would be able to create portals to other virtual worlds, and then write code while the project was running to change the configuration without restarting the project. Then users would be able to write code in the functional style to change the virtual environment _in situ._ It's not Haskell, but this sounds a lot like Newspeak: http://bracha.org/Site/Newspeak.html John L. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] PhD Studentships in Functional Programming
Apologies for multiple copies. -- Henrik Nilsson School of Computer Science The University of Nottingham n...@cs.nott.ac.uk +--+ PhD Studentships in Functional Programming School of Computer Science University of Nottingham, UK The Functional Programming Lab (FP Lab) in the School of Computer Science at the University of Nottingham is seeking to appoint up to two new PhD students, starting on 1st October 2011. The topics for the studentships are open, but will be within the general area of functional programming. The studentships are for 3.5 years, include a maintenance grant of 13,590 UK pounds per year and UK/EU tuition fees, and are open to UK and EU applicants. Particularly strong candidates from outside the EU may also be considered, subject to additional funds being available. Applicants will require a first-class Honours degree (or equivalent) in Computer Science, Mathematics, and/or Physics, experience in functional programming, and an aptitude for mathematical subjects. A higher degree (e.g. Masters) would be desirable. Additionally, experience in one or more of the following will be particularly welcome: formal semantics, type theory, program verification, theorem provers, domain-specific languages, languages for physical modelling, programming language implementation and tools. Successful applicants will work under the supervision of Dr Graham Hutton or Dr Henrik Nilsson in the FP Lab in Nottingham, a leading centre for research on functional programming. The group currently comprises 5 academic staff, 1 research fellow, and 10 PhD students. In order to apply, please submit the following to Dr Graham Hutton (g...@cs.nott.ac.uk) or Dr Henrik Nilsson (n...@cs.nott.ac.uk) by 1st March 2011: an up-to-date copy of your CV (including the results of all your University examinations to date) along with a brief covering letter that describes your experience in functional programming, your reasons for wishing to pursue a PhD in this area, and any ideas you have regarding possible research directions. Note: applicants to the FP Lab should follow the procedure above, rather than applying directly to the School or University, e.g. in response to a general advert for PhD studentships. Closing date for applications: 1st March 2011. +--+ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANN: unordered-containers - a new, faster hashing-based containers library
If you want to use the library and need a short term fix, just write a small wrapper type/module newtype SizedMap = SizedMap (Int, HashMap) and track the size yourself. only complication is that on inserts and deletes you'll need to check if the key existed. other than that, it shouldn't be too difficult. This way, the library stays super optimized but, if you need, you can track the size. As Johan said, it would slow down insert and delete a bit. shouldn't affect lookup though.. max On Feb 20, 2011, at 11:40 AM, Louis Wasserman wrote: I'd like to complain about that, too ;) Louis Wasserman wasserman.lo...@gmail.com http://profiles.google.com/wasserman.louis On Sat, Feb 19, 2011 at 9:02 PM, Edward Kmett ekm...@gmail.com wrote: On Sat, Feb 19, 2011 at 7:27 PM, Sterling Clover s.clo...@gmail.com wrote: On Sat, Feb 19, 2011 at 3:04 PM, Johan Tibell johan.tib...@gmail.com wrote: On Sat, Feb 19, 2011 at 11:58 AM, Louis Wasserman wasserman.lo...@gmail.com wrote: A couple thoughts: size takes O(n). That's just depressing. Really. This applies to all the container types. We could support O(1) size at the cost of slowing down e.g lookup, insert, and delete a little bit. I haven't measure how much yet. Would it be worth it? Getting a bit picky, but for the record, Data.Map and Data.Sequence provide O(1) size, and Data.HashTable I believe stores the information but doesn't expose it from its tiny API. That's not an argument either way for what a HashMap should do, however :-) NB: Data.IntMap, which Data.HashMap is based on, actually only provides O(n) size. -Edward ___ 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] ANN: unordered-containers - a new, faster hashing-based containers library
On Mon, Feb 21, 2011 at 12:58 PM, Max Cantor mxcan...@gmail.com wrote: If you want to use the library and need a short term fix, just write a small wrapper type/module newtype SizedMap = SizedMap (Int, HashMap) and track the size yourself. only complication is that on inserts and deletes you'll need to check if the key existed. other than that, it shouldn't be too difficult. This way, the library stays super optimized but, if you need, you can track the size. As Johan said, it would slow down insert and delete a bit. shouldn't affect lookup though.. This isn't sufficient in all cases. How would you know the resulting size of a union or intersection? Cheers, -- Felipe. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] iteratee-compress space leak?
Hi Maciej, Thanks for looking in to this. From: Maciej Piechotka uzytkown...@gmail.com On Fri, 2011-02-18 at 17:27 +0300, Michael A Baikov wrote: I am trying to play with iteratee making parser for squid log files, but found that my code do not run in constant space when it tries to process compressed log files. So i simplified my code down to this snippet: import Data.ByteString (ByteString) import Data.Iteratee as I import Data.Iteratee.Char import Data.Iteratee.ZLib import System main = do args - getArgs let fname = args !! 0 let blockSize = read $ args !! 1 fileDriver (leak blockSize) fname = print leak :: Int - Iteratee ByteString IO () leak blockSize = joinIM $ enumInflate GZip defaultDecompressParams chunkedRead where consChunk :: Iteratee ByteString IO String consChunk = (joinI $ I.take blockSize I.length) = return . show chunkedRead :: Iteratee ByteString IO () chunkedRead = joinI $ convStream consChunk printLines First argument - file name (/var/log/messages.1.gz will do) second - size of block to consume input. with low size (10 bytes) of consumed blocks it leaks very fast, with larger blocks (~1) it works almost without leaks. So. Is it bugs within my code, or iteratee-compress should behave differently? After looking into problem (or rather onto your code) - the problem have nothing to do with iteratee-compress I believe. I get similar behaviour and results when I replace joinIM $ enumInflate GZip defaultDecompressParams chunkedRead by chunkedRead. (The memory is smaller but it is due to decompression not iteratee fault). This is due to printLines. Whether it's a bug depends on what the correct behavior of printLines should be. printLines currently only prints lines that are terminated by an EOL (either \n or \r\n). This means that it needs to hold on to the entire stream received until it finds EOL, and then prints the stream, or drops it if it reaches EOF first. In your case, the stream generated by convStream consChunk printLines is just a stream of numbers without any EOL, where the length is dependent on the specified block size. This causes the space leak. If I change the behavior of printLines to print lines that aren't terminated by EOL, the leak could be fixed. Whether that behavior is more useful than the present, I don't know. Alternatively, if you insert some newlines into your stream this could be improved as well. As a result of investigating this, I realized that Data.Iteratee.ListLike.break can be very inefficient in cases where the predicate is not satisfied relatively early. I should actually provide an enumeratee interface for it. So thanks very much for (indirectly) suggesting that. Cheers, John L ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANN: unordered-containers - a new, faster hashing-based containers library
On Mon, Feb 21, 2011 at 8:07 AM, Felipe Almeida Lessa felipe.le...@gmail.com wrote: On Mon, Feb 21, 2011 at 12:58 PM, Max Cantor mxcan...@gmail.com wrote: If you want to use the library and need a short term fix, just write a small wrapper type/module newtype SizedMap = SizedMap (Int, HashMap) and track the size yourself. only complication is that on inserts and deletes you'll need to check if the key existed. other than that, it shouldn't be too difficult. This way, the library stays super optimized but, if you need, you can track the size. As Johan said, it would slow down insert and delete a bit. shouldn't affect lookup though.. This isn't sufficient in all cases. How would you know the resulting size of a union or intersection? Note that the library does not at present support union or intersection! There are various ways to deal with the problem without caching sizes at nodes, one of which is to count overlap during union or intersection operations (since this involves counting leaves that are visited during these operations). -Jan-Willem Maessen ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Please review my Xapian foreign function interface
Excerpts from Oliver Charles's message of Mon Feb 21 08:53:48 -0500 2011: Yes, this is a concern to me as well. The only places I've used unsafePerformIO is with Query objects, which I am mostly treating as immutable data, and never exposing anyway to modify query objects. That is a good way to start thinking about it. If there is an efficient mechanism for copying query objects, you can also implement persistent update (e.g. copy the structure and then mutate it). However, what is better? Should I avoid taking this risk/assumption of immutability and use this within the IO monad also? I guess my biggest fear is that this entire library is only usable in the IO monad, which from what I understand limits my ability to test easily. Don't take the risk: verify for yourself that there is no risk! Note that putting things in IO doesn't get you off the concurrency hook: things in IO can be run in different threads and you need to synchronize them. Indeed, as the Xapian faq states: If you want to use the same object concurrently from different threads, it's up to you to police access (with a mutex or in some other way) to ensure only one method is being executed at once. It is admittedly more annoying to test things in IO. One thing you can do is if database objects are completely isolated from one another (which seems to be the case) you can build up a custom monad for manipulating this object in a single-threaded and/or thread safe manner. I did something like this (actually, I needed to enforce more complex invariants about when what functions could get called), but unfortunately it was for work and the code hasn't been cleared for publication yet. Cheers, Edward ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANN: unordered-containers - a new, faster hashing-based containers library
On 20 February 2011 03:40, Louis Wasserman wasserman.lo...@gmail.com wrote: I'd like to complain about that, too ;) I'm curious, when do people find that they need a really fast way to get map size? I use them quite a lot, and almost never call length - and when I do, it is typically only to get some statistics about the map for user display - certainly not in an inner loop. I find it is still useful to have a way to quickly test if a map is empty (for e.g. fixed points that slowly grow a map by unioning in a new bit every time) but null works OK for that purpose. Cheers, Max ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Infinite types should be optionally allowed
On Sun, Feb 20, 2011 at 8:56 PM, Brandon Moore brandon_m_mo...@yahoo.comwrote: Typechecking with regular types isn't hard. So do I have the right idea then? To check against a signature, I can just unify the two types and then check if the unified type is 'equivalent' (is there a special word for this kind of equivalence?) to the original signature? I've gotten the impression from multiple people that type checking with infinite types is hard. Maybe this isn't so? The problem is, the type system is almost useless for catching bad programs. Every closed lambda expression is typeable if infinite types are allowed. Yes, this part I understand quite well :) Usually systems add some sort of ad-hoc restriction on regular types, like requiring that all all cycles pas through a record type. Yeah, what I really want is just a better ad-hoc restriction or annotation. I quite routinely work with code that would be much more simple and elegant with infinite types. - Job ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Infinite types should be optionally allowed
From: Job Vranish jvran...@gmail.com On Sun, Feb 20, 2011 at 8:56 PM, Brandon Moore brandon_m_mo...@yahoo.com wrote: Typechecking with regular types isn't hard. So do I have the right idea then? To check against a signature, I can just unify the two types and then check if the unified type is 'equivalent' (is there a special word for this kind of equivalence?) to the original signature? I've gotten the impression from multiple people that type checking with infinite types is hard. Maybe this isn't so? I haven't thought about checking against signatures. I think what you do is replace all the variables in the signature with Skolem constants, and unify the inferred type against that. There may be more complications if type inference is directed by the signature. Usually systems add some sort ofad-hoc restriction on regular types, like requiring that all all cycles pas through a record type. Yeah, what I really want is just a better ad-hoc restriction or annotation. I quite routinely work with code that would be much more simple and elegant with infinite types. The restrictions I mentioned are supposed to allow using recursive record types to build an object system. It sounds like you want to allow infinite types only as specified by signatures. I think you could take a signature with explicit recursion, label those indicated cycles as allowed, somehow propagate the labels during unification, and check that the only cycles that appear are those specifically licensed by the signature. Brandon ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Faster timeout but is it correct?
On 19 February 2011 00:04, Bas van Dijk v.dijk@gmail.com wrote: So, since the new implementation is not really faster in a representative benchmark and above all is buggy, I'm planning to ditch it in favour of the event-manager based timeout. The patch is ready for review: http://hackage.haskell.org/trac/ghc/attachment/ticket/4963/faster_timeout.dpatch Bas ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Faster timeout but is it correct?
On Mon, Feb 21, 2011 at 12:39 PM, Bas van Dijk v.dijk@gmail.com wrote: On 19 February 2011 00:04, Bas van Dijk v.dijk@gmail.com wrote: So, since the new implementation is not really faster in a representative benchmark and above all is buggy, I'm planning to ditch it in favour of the event-manager based timeout. The patch is ready for review: http://hackage.haskell.org/trac/ghc/attachment/ticket/4963/faster_timeout.dpatch Instead of defining registerTimeout :: EventManager - Int - (TimeoutKey - TimeoutCallback) - IO TimeoutKey include TimeoutKey in the TimeoutCallback type. Someone who better understands the exception masking parts could give you better feedback on that code. Johan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Faster timeout but is it correct?
I'm curious, is it possible that your new timeout implementation would fix this problem?: doesntWork :: Int - Int doesntWork x = last $ cycle [x] test :: IO (Maybe Bool) test = timeout 1 $ evaluate $ doesntWork 5 == 5 -- never terminates, even with the timeout From what I can gather, this problem is caused by a lack of context switches in the code for 'doesntWork' so I doubt that a new implementation of timeout would fix it, but I thought I'd ask :) It's super annoying, especially when it happens when you're not expecting it. (btw, I've only tested the above code in ghc 6.x, so I have no idea if the behavior is the same in 7) - Job On Mon, Feb 21, 2011 at 3:39 PM, Bas van Dijk v.dijk@gmail.com wrote: On 19 February 2011 00:04, Bas van Dijk v.dijk@gmail.com wrote: So, since the new implementation is not really faster in a representative benchmark and above all is buggy, I'm planning to ditch it in favour of the event-manager based timeout. The patch is ready for review: http://hackage.haskell.org/trac/ghc/attachment/ticket/4963/faster_timeout.dpatch Bas ___ 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] Infinite types should be optionally allowed
On Sun, Feb 20, 2011 at 6:01 PM, Job Vranish jvran...@gmail.com wrote: My current algorithm says that neither of the types you gave is strictly more general than the other, which I'm guessing is probably not true. I'm curious what the correct answer is and would appreciate someone pointing out the flaw in my reasoning/code :) I don't remember how I constructed those terms, and I admit that I was arguing out of my depth. I really should have exposed my construction -- we're all good engineers here, we know the difference between an algorithm and intuition. Things I have read since have suggested that I was wrong. Pierce's Types and Programming Languages has a chapter on equi-recursive types which, if it does not provide insight itself, I'm sure has references to papers that go into all the detail needed to answer this technical question. Luke My test code is on github here: https://github.com/jvranish/InfiniteTypes Also, is there a book you'd recommend that would explain this in further detail? Thanks, - Job On Mon, Feb 16, 2009 at 5:16 PM, Luke Palmer lrpal...@gmail.com wrote: On Sat, Feb 14, 2009 at 2:06 PM, Job Vranish jvran...@gmail.com wrote: I'm pretty sure that the problem is decidable, at least with haskell 98 types (other type extensions may complicate things a bit). It ends up being a graph unification algorithm. I've tried some simple algorithms and they seem to work. What do you mean by the inference engine is only half of the story? From what I understand, the inference engine infers types via unification, if the types unify, then the unified types are the inferred types, if the types don't unify, then type check fails. Am I missing/misunderstanding something? Sorry it took me so long to respond. It took a while to formulate this example. Here are two (convoluted) functions, passed to the fixtypes inference engine: Expr y (b (c i) (c (b b (b c (c i) (fix b . (a - b - (a - c - d) - d) - c) - c Expr y (b (c i) (b (c (b b (b c (c i (b (c i) k))) (fix c . ((a - ((b - c) - d) - (a - d - e) - e) - f) - f) These are somewhat complex types; sorry about that. But here's a challenge: is one of these types more general than the other? For example, if you wrote the first term and gave the second signature, should it typecheck? If you figure it out, can you give an algorithm for doing so? I'm not going to say how I came up with these functions, because that would give away the answer :-) Luke I almost think that the problem might be solvable by just generating the appropriate newtype whenever an infinite type shows up, and doing the wrapping/unwrapping behind the scenes. This would be a hacked up way to do it, but I think it would work. On Fri, Feb 13, 2009 at 6:09 PM, Luke Palmer lrpal...@gmail.com wrote: On Fri, Feb 13, 2009 at 4:04 PM, Luke Palmer lrpal...@gmail.com wrote: On Fri, Feb 13, 2009 at 3:13 PM, Job Vranish jvran...@gmail.com wrote: There are good reasons against allowing infinite types by default (mostly, that a lot of things type check that are normally not what we want). An old haskell cafe conversation on the topic is here: http://www.nabble.com/There%27s-nothing-wrong-with-infinite-types!-td7713737.html However, I think infinite types should be allowed, but only with an explicit type signature. In other words, don't allow infinite types to be inferred, but if they are specified, let them pass. I think it would be very hard to shoot yourself in the foot this way. Oops! I'm sorry, I completely misread the proposal. Or read it correctly, saw an undecidability hiding in there, and got carried away. What you are proposing is called equi-recursive types, in contrast to the more popular iso-recursive types (which Haskell uses). There are plentiful undecidable problems with equi-recursive types, but there are ways to pull it off. The question is whether these ways play nicely with Haskell's type system. But because of the fundamental computational problems associated, there needs to be a great deal of certainty that this is even possible before considering its language design implications. That inference engine seems to be a pretty little proof-of-concept, doesn't it? But it is sweeping some very important stuff under the carpet. The proposal is to infer the type of a term, then check it against an annotation. Thus every program is well-typed, but it's the compiler's job to check that it has the type the user intended. I like the idea. But the inference engine is only half of the story. It does no type checking. Although checking is often viewed as the easier of the two problems, in this case it is not. A term has no normal form if and only if its type is equal to (forall a. a). You can see the problem here. Luke Newtype is the standard solution to situations where you really need an infinite
Re: [Haskell-cafe] Faster timeout but is it correct?
On 21 February 2011 21:55, Johan Tibell johan.tib...@gmail.com wrote: ...include TimeoutKey in the TimeoutCallback type. Done: http://hackage.haskell.org/trac/ghc/attachment/ticket/4963/faster_timeout.dpatch Thanks, Bas ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Faster timeout but is it correct?
On 21 February 2011 22:11, Job Vranish job.vran...@gmail.com wrote: I'm curious, is it possible that your new timeout implementation would fix this problem?: doesntWork :: Int - Int doesntWork x = last $ cycle [x] test :: IO (Maybe Bool) test = timeout 1 $ evaluate $ doesntWork 5 == 5 -- never terminates, even with the timeout I just tested this with the new timeout and unfortunately it's not fixed. Bas ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Faster timeout but is it correct?
On Mon, Feb 21, 2011 at 3:16 PM, Bas van Dijk v.dijk@gmail.com wrote: On 21 February 2011 21:55, Johan Tibell johan.tib...@gmail.com wrote: ...include TimeoutKey in the TimeoutCallback type. Done: http://hackage.haskell.org/trac/ghc/attachment/ticket/4963/faster_timeout.dpatch Could we store a full TimeoutCallback in the PSQ? At the line that reads sequence_ $ map Q.value expired you'll need to pass the PSQ key (which is the Unique) to the callback. Most callbacks will ignore this key but by doing this we 1) decrease the size of the closure we store in the PSQ and 2) make the mechanism more flexible for future use. (There's a small chance that I've read the diff wrong. I haven't applied the patch and look at it in a real diff viewer). Johan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Can i split a String by its element ?
See the http://hackage.haskell.org/package/split package. You should be able to do this by splitting the string on comma, and then splitting the result on 0, plus some plumbing. Luke On Mon, Feb 21, 2011 at 11:46 PM, z_axis z_a...@163.com wrote: I want to split 2,15,33,0,8,1,16,18 to ([2,15,33],[8,1,16,18]). the 0 will by discarded. However, it seems that there isnot any standard function to do it. Sincerely! - e^(π.i) + 1 = 0 -- View this message in context: http://haskell.1045720.n5.nabble.com/Can-i-split-a-String-by-its-element-tp3395066p3395066.html Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com. ___ 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] Performance difference between ghc and ghci
Hi, Is there a runtime performance difference between a haskell program running under GHCI vs in its compiled form? Especially for a long running program - as in, ignoring the initial setup time. If I understand right, in both case tree reduction is what is happening and performance should be similar. Regards, Kashyap ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Performance difference between ghc and ghci
In general code compiled with GHC will be a lot faster than code interpreted by GHCI. You can also call compiled code from within GHCI, in which case you would hardly see a performance difference. On 22 February 2011 08:26, C K Kashyap ckkash...@gmail.com wrote: Hi, Is there a runtime performance difference between a haskell program running under GHCI vs in its compiled form? Especially for a long running program - as in, ignoring the initial setup time. If I understand right, in both case tree reduction is what is happening and performance should be similar. Regards, Kashyap ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANN: unordered-containers - a new, faster hashing-based containers library
* Max Bolingbroke batterseapo...@hotmail.com [2011-02-21 14:57:08+] On 20 February 2011 03:40, Louis Wasserman wasserman.lo...@gmail.com wrote: I'd like to complain about that, too ;) I'm curious, when do people find that they need a really fast way to get map size? I use them quite a lot, and almost never call length - and when I do, it is typically only to get some statistics about the map for user display - certainly not in an inner loop. I find it is still useful to have a way to quickly test if a map is empty (for e.g. fixed points that slowly grow a map by unioning in a new bit every time) but null works OK for that purpose. For example, consider a situation where you have two sets (they can be maps as well), 'a' and 'b', such that by construction you know that 'a' is a subset (submap) of 'b'. Now, size a size b is a convenient O(1) way to test whether 'a' is a proper subset (submap) of 'b'. -- Roman I. Cheplyaka :: http://ro-che.info/ Don't worry what people think, they don't do it very often. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Performance difference between ghc and ghci
On 2/22/11 2:26 AM, C K Kashyap wrote: Hi, Is there a runtime performance difference between a haskell program running under GHCI vs in its compiled form? Especially for a long running program - as in, ignoring the initial setup time. If I understand right, in both case tree reduction is what is happening and performance should be similar. GHCi doesn't perform any optimizations, so whenever you're running interpreted bytecode there's a significant performance hit. However, if you compile the code, you can run the compiled/optimized version from GHCi as well. -- Live well, ~wren ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
