- Haskell-Cafe - Haskell.org

Modeling the performance of a non-trivial software app
by C K Kashyap 11 May '11

11 May '11

Hi, I was wondering if it would be a good idea to model a software app's performance using Haskell. The idea is a little abstract in my mind right now. I'll try and illustrate it with an example - Let's say, I want to model a web app - to, model it, I could think of the following entities - 1. One or more clients and as many connections (essentially bandwidth of each connection) 2. A Load balancer ( and bandwidths to the webservers) 3. Bunch of webservers (and bandwidths to the database server) 4. A database server Using the model, I could generate performance characteristics and figure out if database is the bottleneck or not ... if so, what level of sharding would be useful etc Is there already a wheel I am trying to re-invent? Has anyone attempted this? Regards, kashyap

2 2

Cairo package broken on Windows, or am I cooking it wrong?
by Eugene Kirpichov 10 May '11

10 May '11

Hello, After a moderate struggle with getting gtk2hs to install on Windows, I tried to install Chart and got a linker message saying "_cairo_image_surface_get_data" was missing. After another struggle I figured that if I launch ghci -lcairo-2 then everything works fine. I tried patching cairo.cabal by adding this line: extra-libraries: cairo-2 and reinstalling cairo. This helped, I could install Chart without problems. My question is: Should this line be added to cairo.cabal, or should everything have worked fine in some other magical way, but did not, because of some other error? How can I diagnose what's wrong? How is "cabal install" generally supposed to find that a dll is needed, if I don't write it down in the extra-libraries field? -- Eugene Kirpichov Principal Engineer, Mirantis Inc. http://www.mirantis.com/ Editor, http://fprog.ru/

1 0

Crypto-api performance
by Johan Brinch 10 May '11

10 May '11

Does anyone have experience with the crypto-api package? It seems to define a nice common API for block ciphers, hash functions and prng's. However, I get very low performance using it. I ran its benchmark on a NOP block cipher, where encryptBlock k = id, and it's still very slow. After expanded the included block cipher benchmark (which uses ECB) to include CBC and CTR I got the following: ECB: 30 MB/s -- somewhat slow CBC: 12 MB/s -- very slow CTR: 4 MB/s -- why is adding a counter so bad? Have anyone else benchmarked this and if so with what results? Are there any other high level crypto API? Here's my benchmark code for CTR (easily modified to use ECB/CBC): https://gist.github.com/954093 And here's my patched Benchmark/Crypto.hs: https://gist.github.com/954099 Package in question: http://hackage.haskell.org/package/crypto-api -- Johan Brinch, Dept. of Computer Science, University of Copenhagen

6 9

Those damned parentheses
by Eitan Goldshtrom 10 May '11

10 May '11

Hi. I am kind of tired of all of the parentheses I have to put in places and I'm trying to figure out what is the correct way to write code such that I can leave out parentheses. For example, I have the following: data Message = ... --leaving this out because it's not important data Plane = Plane { id :: Int, position :: (Int,Int,Int), direction :: Int, path :: [Int], messagebuf :: Chan Message } main = do c <- newChan :: Chan Message p <- Plane 0 (0,0,0) 0 [] c f p f p = putStrLn $ (show Main.id p) ++ " - message received" This causes an error "The function `show' is applied to two arguments". If I put instead: f p = putStrLn $ (show . Main.id p) ++ " - message received" I get the error "Couldn't match expected type `[Char]' with actual type `a0 -> c0'". The only way it seems to work is f p = putStrLn $ (show (Main.id p)) ++ " - message received" This seems to be the same for many other situations where I try to use function composition of some sort. It's just getting kind of annoying. -Eitan

9 11

Hackage build failure
by Jonas Almström Duregård 10 May '11

10 May '11

Hi, Is there something wrong with the Hackage build system? It fails to build BNFC-meta: http://hackage.haskell.org/package/BNFC-meta It complains about a missing dep even though it (the dependency) has been built successfully. Also the dependencies are exactly the same as in the previous version (which configures fine but fails to build because of some bug in HsColor). Regards Jonas

2 1

Re: [Haskell-cafe] [Haskell] ANN: syntactic-0.1
by Emil Axelsson 10 May '11

10 May '11

2011-05-10 15:31, Heinrich Apfelmus skrev: >>> I'm also unhappy about some of the boilerplate. For instance, have a >>> look at the function goE in compileAccumB (line 210), it's just a >>> generic applicative traversal through the data type. >> >> Most likely, this boilerplate could be simplified using syntactic. > > Hm, does the boilerplate get removed or only simplified? I was hoping > that one could use a completely generic traversal; but is that actually > the case? I was using careful wording :) I think the traversal can be completely generic. But syntactic brings its own (constant) overhead, so I felt the word "remove" might be too strong. > On closer inspection, I'm discovering another issue, namely the need for > the Typeable class. This is quite unfortunate, because it would mean > that I won't be able to make an API built on type classes like Functor > or Applicative. Some discussion on that can be found at the end of > > http://apfelmus.nfshost.com/blog/2011/04/24-frp-push-driven-sharing.html Hm... The only reason (afair) for having Typeable constraints in the tree was that my code motion transform (not yet released) needs to move around nodes in a way that the type checker is not happy with. But as long as my algorithm is correct, the type casts will actually always succeed. So it might be possible to use unsafeCoerce directly and get rid of Typeable. There might also be ways to make Typeable optional... I will look into this. > So, it looks like I can't make use of syntactic at the moment. Then > again, my library is probably one of the strongest tests of expressivity > for endeavors like syntactic , so that's fine. Another example of > similar difficulty would be D. Swierstra's recent parser/grammar > combinators that can handle left-recursive grammars. Once syntactic > can deal with those, you're the king! :) Thanks for the tip! It would be interesting to try out these libraries for real, if only for the sake of getting to know the practical limits of syntactic. But my focus is currently on the Feldspar implementation, so I probably won't have time for things like this in a (long) while. / Emil

1 0

An update on ICFP'11 in Tokyo (September 18-24, 2011)
by Wouter Swierstra 10 May '11

10 May '11

Given the fairly recent severe earthquake and tsunami in Japan, you may wonder how this affects the preparations for ICFP'11 in Tokyo. Luckily, Tokyo was significantly less affected by these saddening events than the regions further north. In fact, the situation in Tokyo is almost back to normal, after only two months, with another four months until ICFP. Moreover, all major embassies have in the meantime lifted their travel advisories for the Tokyo metropolitan region (while they still maintain active advisories for some other regions.) Our local organisational team has completed major parts of the preparations and recently summarised the most important facts on a local information page for ICFP'11: http://www.biglab.org/icfp11local/index.html The main conference site is at http://www.icfpconference.org/icfp2011/ We are looking forward to seeing you in Tokyo in September! Manuel Chakravarty Zhenjiang Hu (General Chairs of ICFP'11)

1 0

Template Haskell reified type.
by Serguey Zefirov 10 May '11

10 May '11

Language.Haskell.TH.Type contains, among others, two constructors: TupleT Int and ListT. I can safely construct types using them, but reification returns ConT "GHC.Tuple.(,)" and ConT "GHC.Types.[]" respectively. This is not fair asymmetry, I think. Also, it took purity from one of my functions while I debugged that problem. I had to make it into Q monad. ;)

2 2

Locking, unsafePerformIO and bolt-on thread safety.
by Jason Dusek 10 May '11

10 May '11

A friend is making bindings to a C library that offers some fast math operations. The normal way to use the library is like this: int a = ...; int b = ...; int c = ...; int d = ...; int x = ...; int m, n; create_lookup_table(x); m = perform_math(a, b, x); n = perform_math(c, d, x); We see that the lookup table for x must be created before we can perform math in the field/ring/what-have-you defined by x. Once we have created the table, though, we're done. My friend would like to create a pure interface to this library. One thought was to write an interface to perform_math that checked if the table was created, created it if not, and did all this while locking an MVar so that no other instance could be called at the same time, trashing the table. Doing this behind unsafePerformIO would seem to be the ticket. We end up with an implementation like this: module FastMath where import Control.Concurrent import Foreign import Foreign.C foreign import ccall create_lookup_table :: CInt -> IO () foreign import ccall perform_math :: CInt -> CInt -> CInt -> IO CInt masterLock = unsafePeformIO (newMVar [CInt]) safe_perform_math a b x = do list <- takeMVar masterLock toPut <- if not (x `elem` list) then do create_lookup_table x return (x:list) else return list result <- perform_math a b x putMVar masterLock toPut return result performMath a b x = unsafePerformIO (safe_perform_math a b x) This does not compile but I think it gets the point across. Is this approach safe? The unsafePerformIO in conjunction with locking has me worried. -- Jason Dusek () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments

2 1

Re: [Haskell-cafe] Asynchronous Arrows need Type Specialization - Help!
by Paul L 10 May '11

10 May '11

I now understand where you are coming from, but I don't quite get your motivation to develop new classes for arrows. Tupling is Haskell is of course very lazy, it does not evaluate any of its element. As for the spatial and logical concepts, don't you think they are over-specifying what is really necessary for your system model? So I guess what I'm having trouble with is your arr f example. If f is sufficiently lazy, it does not evaluate the elements in its input tuple at all. Most pure functions we use to wire up arrows are like this: arr fst, arr snd, arr swap, arr (\x -> (x, x)), etc. I also don't quite follow your example of passing a time stamp together with value. Do you intend to keep the time stamp always updated? If you are getting unwanted results, it is perhaps due to wrong computation, rather than the composition to a pure functions. Maybe you want to give a specific example of "f". Regards, Paul Liu On Fri, Apr 1, 2011 at 1:55 PM, David Barbour <dmbarbour(a)gmail.com> wrote: > On Fri, Apr 1, 2011 at 11:47 AM, Paul L <ninegua(a)gmail.com> wrote: >> On Sun, Mar 20, 2011 at 10:18 PM, David Barbour <dmbarbour(a)gmail.com> wrote: >> >>> The (***) and (&&&) operations, as specified in Control.Arrow, are >>> inherently synchronization points. >>> >>> Ideally one could do something like: >>> >>> (a1 *** a2) >>> first a3 >>> >>> and the output from a1 would be piped directly as input to a3, without >>> touching a2. However, arrows also allow: >>> >>> (a1 *** a2) >>> arr f >>> >>> And, in this case, the current state of a1 and a2 must be combined >>> into a stream of pairs so that f may be mapped over the stream. >>> Obtaining both streams at a single place (a single vat) and time is a >>> synchronizing operation. The synchronization operations are severely >>> undermining the intended scalability and performance of this agent >>> abstraction. >> >> If what you mean by "synchronization" is that for every output of a1 >> there must be an output of a2, then YES. >> >> But if you mean that both the outputs of a1 and a2 have to be >> available (fully evaluated) due to the tupling, then NO, at least not >> in Haskell where things are evaluated lazily. > > What I mean by synchronization is that the outputs from a1 and a2 must > occur at the same logical or physical space and time. > > Assume 'a1' and 'a2' represent external, asynchronous resources. > * 'a1' loads a file, with latency 40 milliseconds. (input is filename) > * 'a2' is a database query, with a latency of 100 milliseconds. (input is query) > > (a1 *** a2) both loads a file and performs a query, then tuples the > results as (r1,r2). > > (a1 *** a2 >>> first a3) further processes the file state r1, > generating (r3,r2). > > Logically, a pair is a spatial-temporal concept: if you have a pair, > you have access to a fst and a snd value at the same place and the > same time. This synchronization is obvious if you pass values into an > 'arr' arrow. The 'physical' synchronization issue is that the naive > way to implement (a1 *** a2) is to wait for both resources to be > available (time) in the same thread (space), then generate a tuple > that couples the responses. > > For my programming model, however, I must avoid both forms of > synchronization. The 'logical' synchronization is minimized. You might > model this, roughly, by pairing the responses with their latencies: > ((40,r1),(100,r2)). This would essentially be a 'futures' passing > style. The idea is that '(a1 *** a2) >>> first a3' might generate > something like ((80,r3),(100,r2)). Explicit synchronization might > bring this to ((100,r3),(100,r2)). > > Futures passing might work well enough for the problem as I've > explained it to you. My programming model is operating under several > additional constraints to support reactivity, concurrency, > parallelism, scalability, distribution, and open systems. Under the > more stringent requirements, I've been unable to make futures fit the > problem. However, in the time since my last Haskell-cafe post, I have > found a way to leverage GADTs to at least keep elements of a product > distinct under-the-hood and minimize physical synchronization. > > data A a d r where > Aprim :: a d r -> A a d r > Aid :: A a r r > Acomp :: A a d' r -> A a d d' -> A a d r > Aarr :: (d -> r) -> A a d r > Aprod :: A a d r -> A a d' r' -> A (a,a') (d,d') > Adup :: A a (a,a) > Afst :: A a (b,c) b > Asnd :: A a (b,c) c > ... > >> >> BTW, according to arrow laws, (a1 *** a2) >>> first a3 is equivalent >> to (a1 >>> a3) *** a2, does the latter look more appealing to you? If >> yes, I don't see where is the problem, unless you intentionally want >> to make them different, and then it is no longer arrow. > > While both expressions should have equivalent observable properties, > neither Haskell nor Arrow laws assure they will possess the same > operational characteristics. In a naive implementation, the latter > will generally be the more efficient option. > > For efficiency reasons, I have also abandoned Ross's Control.Arrow. > The main problem with it is Ross's use of pragmas: > > {-# RULES > "first/arr" forall f . first (arr f) = arr (first f) > "second/arr" forall f . second (arr f) = arr (second f) > "product/arr" forall f g . arr f *** arr g = arr (f *** g) > "fanout/arr" forall f g . arr f &&& arr g = arr (f &&& g) > #-} > > These rules go the wrong direction, making the program more opaque to > the runArrow operation, and actually change both the physical and > logical synchronization characteristics for the worse. I.e. if I pass > ((80,r3),(100,r2)) to 'arr f', the output becomes available at logical > time 100 rather than time 80. > > Peter Gammie suggested use of Adam Megacz's Generalized Arrows, which > would avoid this problem by use of an opaque product type that can > only be converted to a pair by an explicit operation (i.e. 'synch :: a > (b**c) (b,c)' for opaque product type (**)). I'm still debating > whether to take this approach. > -- Regards, Paul Liu

2 1