- Haskell-Cafe - Haskell.org

Confusing performance variation while optimising a tight loop
by Patai Gergely 19 Apr '11

19 Apr '11

Hello all, I've been trying to improve the performance of Hemkay, my MOD player. The mixing routines are in a separate library with no special dependencies. Most of the time is spent in a small loop in the mixToBuffer function [1] (note that this version is not the master branch in case you give it a try). Each iteration does the following: it advances a pointer in a waveform (float vector) with a fractional amount (depending on the frequency at which it's played back), multiplies it by the desired volume and distributes it over the two channels (two more multiplication). The case where the step is less than zero is special cased for efficiency (lines 170-183), but commenting that out won't affect the output, just make it take about 15% more time. The isEmpty and stepWave' functions come from the Music module. The confusion is the following: a waveform can be of three kinds (empty, single-shot or looped), which is represented by a plain sum type. In the fastest version I match this pattern twice for every sample output (through the isEmpty and stepWave' functions). Since the kind of waveform doesn't change during this tight loop, I figured I could speed it up by moving the pattern match out of the loop and only increasing the index into the vector, thereby doing strictly less work per sample. This is the version on lines 204-234. However, this modification makes the program twice as slow as the original, and I simply don't understand what I'm doing wrong or what could possibly cause this! The speed test is a self-contained program in the test directory, you can compile it after installing the library. If you pass it a MOD music file, it'll perform mixing and quit immediately afterwards. Gergely [1] https://github.com/cobbpg/hemkay-core/blob/vector/Sound/Hemkay/Mixer.hs -- http://www.fastmail.fm - The professional email service

1 0

deriving instances in GHC 7.*
by Alberto G. Corona 19 Apr '11

19 Apr '11

By my little experience with GHC 7.* it seems that this version is more "deterministic" when deriving instances. For example if there is a general instance declaration such is: instance C1 x=> C2 x where .... then the absence of the C1 instance becomes an error. C1 instance becomes a prerequisite for any C2 instance, where in previous versions, that was just a overlapping instance in collision with any other less general instance of the C2 class, so it could be overcomed with the "OverlappingInstances" flag. Given that is not possible to hide instances, this is annoying. I´m not saying that this is wrong or even If this is so, because this could be a misinterpretation on my side based on the tests I have done. Where can I read about the rationale of this change?. General Instance derivations rules, as any rule system seem to me naturally flexible and with different degrees of generalization rather tan rigid.

1 1

Errata for "Pearls of Functional Algorithm Design" by Richard Bird, 2010, page 25 #Haskell
by KC 18 Apr '11

18 Apr '11

Errata for "Pearls of Functional Algorithm Design" by Richard Bird, 2010, page 25 #Haskell smallest :: (Ord a) => Int -> (Array Int a, Array Int a) -> a smallest k (xa,ya) = search k (0,m+1) (0,n+1) where (0,m) = bounds xa (0,n) = bounds ya search k (lx,rx) (ly,ry) | lx == rx = ya ! (k+ly) | ly == ry = xa ! (k+lx) | otherwise = case (xa ! mx < ya ! my, k <= mx-lx+my-ly) of (True, True) -> search k (lx,rx) (ly,my) (True, False) -> search (k-(mx-lx)-1) (mx+1,rx) (ly,ry) (False, True) -> search k (lx,mx) (ly,ry) (False, False)-> search (k-(my-ly)-1) (lx,rx) (my+1,ry) where mx = (lx+rx) `div` 2 my = (ly+ry) `div` 2 -- -- Regards, KC

1 0

ANNOUNCE: floatshow-0.1 faster String representations for Double and Float
by Daniel Fischer 18 Apr '11

18 Apr '11

The Show instances for RealFloat types provided in base are very elegant, as they produce the shortest string which 'read' converts back to the original number. That, however, involves a check after each digit has been determined and arithmetic of usually fairly large Integers, which makes these Show instances rather slow. For cases where having the conversion fast is more important than having it produce elegant output, the floatshow package provides alternative conversions, which avoid the checks and reduce the occurrences of large Integers by just producing a sufficiently long output string. The speed gain can be substantial if the numbers have exponents of large absolute modulus, but for the more common case of numbers whose exponents have small absolute modulus, the difference is (although still significant for Double) too small in my opinion to seriously consider replacing the Show instances. Therefore I've put these functions into their own package. In my benchmarks, the speed gain ranges from 4x to 10x for Double and from 1.25x to 5x for Float, so the package may be a useful alternative for tasks requiring the output of many floating point numbers. Sadly, floatshow is non-portable and requires ghc >= 6.12.

1 0

Re: [Haskell-cafe] [Haskell] select(2) or poll(2)-like function?
by Don Stewart 18 Apr '11

18 Apr '11

Redirecting to haskell-cafe@, where this kind of long discussion belongs. On Mon, Apr 18, 2011 at 9:07 AM, Colin Adams <colinpauladams(a)googlemail.com> wrote: > > > On 18 April 2011 16:54, Ertugrul Soeylemez <es(a)ertes.de> wrote: >> >> > >> > Well, *someone* has to worry about robustness and scalability. Users >> > notice when their two minute system builds start taking four minutes >> > (and will be at my door wanting me to fix it) because something didn't >> > scale fast enough, or have to be run more than once because a failing >> > component build wasn't restarted properly. I'm willing to believe that >> > haskell lets you write more scalable code than C, but C's tools for >> > handling concurrency suck, so that should be true in any language >> > where someone actually thought about dealing with concurrency beyond >> > locks and protected methods. The problem is, the only language I've >> > found where that's true that *also* has reasonable tools to deal with >> > scaling beyond a single system is Eiffel (which apparently abstracts >> > things even further than haskell - details like how concurrency is >> > achieved or how many concurrent operations you can have are configured >> > when you start an application, *not* when writing it). Unfortunately, >> > Eiffel has other problems that make it undesirable. >> >> I can't make a comparison, because I don't know Eiffel. > > I do, and I don't recognize what the OP is referring to - I suspect he meant > Erlang. > > -- > Colin Adams > Preston, Lancashire, ENGLAND > () ascii ribbon campaign - against html e-mail > /\ www.asciiribbon.org - against proprietary attachments > > _______________________________________________ > Haskell mailing list > Haskell(a)haskell.org > http://www.haskell.org/mailman/listinfo/haskell > >

2 1

Adjoint Folds and Unfolds Or: Scything through the Thicket of Morphisms
by KC 18 Apr '11

18 Apr '11

Just tripped over this: Adjoint Folds and Unfolds Or: Scything through the Thicket of Morphisms Folds and unfolds are at the heart of the algebra of programming. They allow the cognoscenti to derive and manipulate programs rigorously... Ralf Hinze Lecture Notes in Computer Science, 2010, Volume 6120, Mathematics of Program Construction, Pages 195-228 -- -- Regards, KC

1 0

Adjoint Folds and Unfolds Or: Scything through the Thicket of Morphisms
by KC 18 Apr '11

18 Apr '11

Just tripped over this: Adjoint Folds and Unfolds Or: Scything through the Thicket of Morphisms Folds and unfolds are at the heart of the algebra of programming. They allow the cognoscenti to derive and manipulate programs rigorously... Ralf Hinze Lecture Notes in Computer Science, 2010, Volume 6120, Mathematics of Program Construction, Pages 195-228 -- -- Regards, KC

1 0

Summer school on Applied Functional Programming at Utrecht University; deadline for registration May 15
by S. Doaitse Swierstra 18 Apr '11

18 Apr '11

Again we will teach an "Applied Functional Programming Summer in Haskell" school this year at Utrecht University. In the previous two occasions students were all very happy with the school and we plan to repeat this success this year. The intended audience are prospective master students who have been in contact with Functional Programming, e.g. by taking a general course on programming languages, and want to learn more about Haskell and its typical programming patterns. In the previous two years we have taught an introductory part (advanced bachelor level), an advanced part (beginning master level) and a shared part for both groups. Topics covered are, besides some examples of domain specific languages, also monads, monad transformers, arrows, parser combinators and self-analysing programs, underlying principles, type inferencing, etc. Half of the course time is spent on a larger programming exercise; you can also come with a problem of your own if you want, and get help from the Utrecht University Software Technology group in finding the proper Haskell idioms, tools and libraries, for solving it. Important links: -- our own page where we supply information based on questions asked http://www.cs.uu.nl/wiki/bin/view/USCS2011/WebHome -- the poster you can print and hang somewhere (why not your office door): http://www.cs.uu.nl/wiki/pub/USCS2011/WebHome/USCSpos11.pdf -- the official summerschool site where you can register: http://www.utrechtsummerschool.nl/index.php?type=courses&code=H9 Furthermore we ask for your cooperation to bring this announcement under the attention of potential participants. Best, Doaitse Swierstra PS: apologies if you get this mail more than once

1 0

Re: [Haskell-cafe] How to contact OpenGL package maintainer (where is Sven?)
by Joachim Breitner 18 Apr '11

18 Apr '11

[Moving to haskell-cafe, not really library specific any more] Hi, Am Sonntag, den 17.04.2011, 12:39 -0700 schrieb Jason Dagit: > In this specific case, I'll do what I can to clean things up but your > request makes me pause and think that the debian packaging for cabal > packages is not automated enough. As haskell developers it seems a > little odd to me that we need to consider the cost of creating new > packages for the sake of debian. I like debian, so please don't take > that the wrong way :) the observation is correct, but unfortunately hard to change – Debian is large, slow moving, and unlikely to change policies for a corner-case such as Haskell libraries. Also, the policies that make life a bit more harder for us are also the policies that make Debian a good distribution: E.g. manually creating a copyright file describing who all has copyright on the files, and what license the files are under – .cabal has fields for that, but unfortunately, they very often do not reflect the reality of the .hs files. Or the other one, requiring that an upload of a source package is accompanied by a manually built and signed binary package ensures that the maintainer actually checked that the package builds and hopefully has tested it. If you think more about it, the lack of some of the policies on Hackage, e.g. nobody checking that licenses and copyright are correctly specified and actually compatible with dependencies, make Hackage a dangerous source for serious users. I am not saying that this should change, but the cheapness of Hackage uploads has its downsides. Greetings, Joachim -- Joachim Breitner e-Mail: mail(a)joachim-breitner.de Homepage: http://www.joachim-breitner.de ICQ#: 74513189 Jabber-ID: nomeata(a)joachim-breitner.de

4 4

Killing threads in foreign calls.
by Jason Dusek 18 Apr '11

18 Apr '11

I am building an application that uses Postgres for storage. If a query runs too long, I would like to kill the querying thread, releasing its lock on the connection; if the connection is a in a bad state -- for example, busy -- I would like to clean up the connection. Unfortunately, killing calls in to libpq seems not to work. I have put a minimal example on hpaste: http://hpaste.org/45774/minimal_pg_contention_example If you install libpq with Cabal, you can run it. In the example, the main thread spawns a worker thread that queries Postgres, running "SELECT pg_sleep(10);"; the main thread waits half a second and then tries to kill the worker. Unfortunately, the worker always manages to get as far as printing "complete". In the code, I call `Database.PQ.exec': http://hackage.haskell.org/packages/archive/libpq/0.4.1/doc/html/src/Databa… This in turn calls a `safe' binding, `c_PQexec', to `PQexec' in the C library: http://hackage.haskell.org/packages/archive/libpq/0.4.1/doc/html/src/Databa… There are async interfaces, too; they do not seem to be any more killable then the sync ones. Maybe the problem is that you can't kill a thread while it's in a foreign call? I do not see any documentation to this effect; but I may have missed it. -- Jason Dusek () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments

3 3