- Haskell-Cafe - Haskell.org

MPC 2008: SECOND CALL FOR PAPERS
by Shin-Cheng Mu 23 Dec '07

23 Dec '07

SECOND CALL FOR PAPERS 9th International Conference on Mathematics of Program Construction (MPC'08) Marseille (Luminy), France, July 15-18th 2008 http://mpc08.lri.fr BACKGROUND The biennial MPC conferences aim to promote the development of mathematical principles and techniques that are demonstrably practical and effective in the process of constructing computer programs. Topics of interest range from algorithmics to support for program construction in programming languages and systems. The previous conferences were held in Twente, The Netherlands (1989), Oxford, UK (1992), Kloster Irsee, Germany (1995), Marstrand, Sweden (1998), Ponte de Lima, Portugal (2000), Dagstuhl, Germany (2002), Stirling, UK (2004, colocated with AMAST '04) and Kuressaare, Estonia (2006, colocated with AMAST '06). The 2008 conference will be held in Marseille, France at the International Center for Mathematical Meetings (http://www.cirm.univ-mrs.fr/web.ang) INVITED SPEAKERS To be announced. IMPORTANT DATES * Submission of abstracts: 14 January 2008 * Submission of full papers: 21 January 2008 * Notification of authors: 10 March 2008 * Camera-ready version: 10 April 2008 TOPICS Papers are solicited on mathematical methods and tools put to use in program construction. Topics of interest range from algorithmics to support for program construction in programming languages and systems. Some typical areas are type systems, program analysis and transformation, programming-language semantics, program logics. Theoretical contributions are welcome provided their relevance for program construction is clear. Reports on applications are welcome provided their mathematical basis is evident. SUBMISSION Submission is in two stages. Abstracts (plain text, 10 to 20 lines) must be submitted by 14 January 2008. Full papers (pdf) adhering to the llncs style must be submitted by 21 January 2008. There is no official page limit, but authors should strive for brevity. The web-based submission system is now open http://www.easychair.org/conferences/?conf=mpc08. Papers must report previously unpublished work and not be submitted concurrently to another conference with refereed proceedings. Accepted papers must be presented at the conference by one of the authors. The proceedings of MPC'08 will be published in the Lecture Notes in Computer Science series of Springer-Verlag. After the conference, the authors of the best papers will be invited to submit revised versions to a special issue of the Science of Computer Programming journal of Elsevier. PROGRAMME COMMITTEE Christine Paulin-Mohring INRIA-UniversitÈ Paris-Sud, France (chair) Philippe Audebaud Ecole Normale SupÈrieure Lyon, France (co-chair) Ralph-Johan Back Abo Akademi University, Finland Eerke Boiten University of Kent, UK Venanzio Capretta University of Nijmegen, Netherlands Sharon Curtis Oxford Brookes University, UK Jules Desharnais UniversitÈ Laval, QuÈbec, Canada Peter Dybjer Chalmers University of Technology, Sweden Jeremy Gibbons University of Oxford, UK Lindsay Groves Victoria University of Wellington, New Zealand Ian Hayes University of Queensland, Australia Eric Hehner University of Toronto, Canada Johan Jeuring Utrecht University, Netherlands Dexter Kozen Cornell University, USA Christian Lengauer Universit‰t Passau, Germany Lambert Meertens University of Utrecht, Netherlands Bernhard Mˆller Universit‰t Augsburg, Germany Carroll Morgan University of New South Wales, Australia Shin-Cheng Mu Academia Sinica, Taiwan Jose Nuno Oliveira Universidade do Minho, Portugal Tim Sheard Portland State University, USA Tarmo Uustalu Institute of Cybernetics Tallin, Estonia VENUE The conference will be held in Marseille, the second largest city in France next to Paris. Its port is the most important in France, and opens the city to the world through the Mediterranean Sea. MPC'08 will be hosted by the International Center for Mathematical Meetings. The center is located inside the Campus of Luminy Faculty. It is close to the "Calanques", an astounding wild coastline composed of creeks stretching from Marseille to Cassis. LOCAL ORGANIZERS MPC 2008 is organized with the support of INRIA. The local organizers are Philippe Audebaud and Christine Paulin-Mohring with the help of Marie-RenÈe Fleury. Enquiries regarding the programme (submission etc.) should be addressed to mpc08(at)lri.fr

1 0

[15/16] SBM: Predictions compared to the measurements
by Peter Firefly Brodersen Lund 23 Dec '07

23 Dec '07

Don Stewart and Duncan Coutts were nice enough to give me some predictions regarding the performance of the programs in my teaser email. When I answered them, I hadn't yet written the code to merge reports so I hadn't yet noticed the general pattern of much worse memory performance on 6.9. Also, Don Stewart hadn't yet released bytestring 0.9.0.2 (he did so in order to fix performance problems pointed out by my teaser benchmarks, actually). >From Duncan Coutts: >I'll try guessing at some ratios: > >1.0 space-bslc8-foldlx-1 >1.1 space-bslc8-acc-1 >2.0 space-bs-c8-foldlx-1 >2.1 space-bs-c8-acc-1 >4.0 space-xxxxx-acc-1 >15 space-xxxxx-foldl I would put them in two groups (I disregard the lenfil benchmark because it was for "extra credit"): space-bslc8-foldlx-1 around 1.4/1.5s (1.2/1.1s with bytestring 0.9.0.2) space-bs-c8-foldlx-1 around 1.2s space-bs-c8-acc-1 around 1.1s (1.3s on 6.6.1) space-bslc8-acc-1 around 3.4s (6.4s on 6.6.1!) space-xxxxx-acc-1 around 5.0s (5.4s on 6.8.2) space-xxxxx-foldl around 5.0s (5.3/5.4s on 6.8.2) >From Duncan Coutts (on the "extra credit" program hs/space-bslc8-lenfil-1): >Hmm. So that should work in constant memory, a few 64 chunks at once. >I'd expect this to be pretty fast. Ok, this was mean of me. I knew there was a memory bug here :) >From Don Stewart: >Summary: the suspicious lazy bytestring program works now. (constant >space, and fastest overall, as expected originally) > >Program 1, lazy bytestring length . filter > > Yesterday: > ./A +RTS -sstderr < 150M 1.01s user 0.10s system 98% cpu 1.123 total > 40M allocated > > * Today (fixed!): > ./A +RTS -sstderr < 150M 0.26s user 0.06s system 96% cpu 0.332 total > 2M allocated > > Reason, deprecated array fusion mucking up the optimiser. > >I think we can close this regression. Nope. Look at the memory graphs: hs/space-bslc8-lenfil-1: 38632 ██████████▌ | -- 38644 ██████████▌ | -- 1940 ▌ | -- 109404 █████████████████████████████▋ | -- 82324 ██████████████████████▍ | -- 109388 █████████████████████████████▋ | -- 82304 ██████████████████████▎ | It is fixed for ghc 6.8.2 running bytestring 0.9.0.2 but not for ghc 6.9.20071119 and head (as of noon 2007-12-19), no matter the bytestring version. There are lots of memory performance bugs in ghc 6.9. I've reordered the time bar charts to use the same order as my teaser email. hs/space-bslc8-lenfil-1: 1.521 7‰ 0.2 ███████▊ | -- 1.295 1‰ 0.2 ██████▌ | -- 0.429 0‰ 0.2 ██▏ | -- 1.323 1‰ 0.1 ██████▊ | -- 0.483 2‰ 0.4 ██▌ | -- 1.327 1‰ 0.2 ██████▊ | -- 0.482 2‰ 0.4 ██▌ | (this was the "extra credit" program) hs/space-bs-c8-acc-1: 1.287 20‰ 0.2 ██████▌ | -- 1.131 2‰ 0.1 █████▊ | -- 1.132 2‰ 0.3 █████▊ | -- 1.145 1‰ 0.2 █████▊ | -- 1.150 1‰ 0.2 █████▉ | -- 1.147 2‰ 0.1 █████▊ | -- 1.147 2‰ 0.2 █████▊ | hs/space-bslc8-acc-1: 6.367 17‰ 0.2 ████████████████████████████████▎ | -- 3.396 7‰ 0.1 █████████████████▎ | -- 3.508 4‰ 0.1 █████████████████▊ | -- 3.388 10‰ 0.1 █████████████████▏ | -- 3.441 10‰ 0.1 █████████████████▍ | -- 3.438 3‰ 0.0 █████████████████▍ | -- 3.434 13‰ 0.1 █████████████████▍ | hs/space-xxxxx-acc-1: 5.036 7‰ 0.1 █████████████████████████▌ | -- 5.381 6‰ 0.0 ███████████████████████████▎ | -- 5.358 8‰ 0.1 ███████████████████████████▏ | -- 4.991 1‰ 0.1 █████████████████████████▎ | -- 5.047 7‰ 0.1 █████████████████████████▌ | -- 5.051 3‰ 0.1 █████████████████████████▋ | -- 5.049 4‰ 0.1 █████████████████████████▋ | hs/space-bs-c8-foldlx-1: 1.272 1‰ 0.2 ██████▌ | -- 1.205 2‰ 0.2 ██████▏ | -- 1.164 3‰ 0.0 █████▉ | -- 1.221 1‰ 0.1 ██████▏ | -- 1.176 1‰ 0.3 ██████ | -- 1.259 1‰ 0.1 ██████▍ | -- 1.176 1‰ 0.2 ██████ | hs/space-bslc8-foldlx-1: 1.430 1‰ 0.1 ███████▎ | -- 1.400 1‰ 0.1 ███████▏ | -- 1.197 1‰ 0.0 ██████ | -- 1.458 0‰ 0.1 ███████▍ | -- 1.060 1‰ 0.0 █████▍ | -- 1.457 1‰ 0.1 ███████▍ | -- 1.060 1‰ 0.2 █████▍ | hs/space-xxxxx-foldl: 5.024 5‰ 0.0 █████████████████████████▌ | -- 5.371 9‰ 0.0 ███████████████████████████▎ | -- 5.301 9‰ 0.1 ██████████████████████████▉ | -- 5.035 2‰ 0.1 █████████████████████████▌ | -- 5.037 3‰ 0.0 █████████████████████████▌ | -- 5.046 4‰ 0.0 █████████████████████████▌ | -- 5.042 4‰ 0.0 █████████████████████████▌ | -Peter

2 1

GtkMathView wrapper for Haskell / Gtk2HS?
by Peter Verswyvelen 23 Dec '07

23 Dec '07

Did anybody already wrap http://helm.cs.unibo.it/mml-widget so it can be used with Haskell / Gtk2HS? If not, would it be good project for me to learn Haskell's FFI? It involves C++, so I guess that would be harded to wrap? Thanks, Peter

2 1

Reducing the executable output filesize with GHC (on Windows)
by Peter Verswyvelen 22 Dec '07

22 Dec '07

I remember having read how to do this a while ago, but I can't google it back. How can I force the linker to exclude all the sections that are not referenced? I thought it had to do something with -split-objs? I've written a short consolemode program, but it compiles to 1.3MB. Since I will be creating a lot of these small apps, surely this filesize can be reduced? Thanks, Peter PS: The program I wrote is 250 lines of code. It is a simple vectormath exercise generator for my students which I wrote in 5 hours, something I would never been able to do in C++/C#, even though I have much more experience in the latter languages. Haskell's sooo nice, and I'm just scratching the surface of it. Thank to all of you guys for the hard work J

2 1

Is a type synonym declaration really a synonym ?
by alpheccar 22 Dec '07

22 Dec '07

Can someone confirm me that: type TA = A :+: B type TB = C :+: D type T = TA :+: TB is not equivalent to type T = A :+: B :+: C :+: D where I have defined infixr 6 :+: data (f :+: g) data A data B data C data D I have a computation at type level which is working with the later definition of T but not with the former (ghc 6.8.1) Thanks.

3 3

MonadFix
by Joost Behrends 22 Dec '07

22 Dec '07

Hi, since about three weeks i am learning Haskell now. One of my first excercises is to decompose an Integer into its primefactors. I already posted discussion on the solution to the problem 35 in "99 excercises". My simple algorithm uses a datatype DivIter of 4 named fields together with the core iteration divstep :: DivIter -> DivIter divstep x | divisor x > bound x = x | ximod > 0 = x { divisor = (divisor x) +2 } | otherwise = x {dividend=xidiv, bound=intsqrt(xidiv), result = result x ++ [divisor x] } where (xidiv, ximod) = divMod (dividend x) (divisor x) (dividend x is already odd, when this is called). The problem to solve for really large Integers is how to call divstep iterated without not accumulating billions of stack frames. Here is one possibility: divisions = do y <- get if divisor y <= bound y then do put ( divstep y ) divisions else return y (this for a version of divstep without the first guard) called from res = execState divisions (DivIter { dividend = o1, divisor = 3, bound = intsqrt(o1), result = o2 }) ( where o1 "the odd part" of the number to decompose, o2 a list of its "contained" twos). This computes the primefactors of 2^120+1 in 17 minutes after all. But i cannot help feeling that this is an abuse of the State monad. The MonadFix has a function fix (a -> a) -> a and i added the first guard in divstep above for making this a fixpoint problem. For me the signature looks, as if using fix doesn't afford to create explicitely a variable of a MonadFix instance and a simple twoliner for divisions could do the job. What i do not understand at all from the documentation of fix is: "fix f is the least fixed point of the function f, i.e. the least defined x such that f x = x." What does "least" mean here ? There is nothing said about x being a variable of an instance of Ord. And why fix has not the type a -> (a -> a) -> a, means: How can i provide a starting point of the iteration x ==> f x ==> f (f x) ==> ...?

7 17

Hoogle search scope question -- was: [HXT] Simple question
by Steve Lihn 22 Dec '07

22 Dec '07

I have a hoogle question. While I was reading the HXT discussion (below), I tried to search "runX" and "readString" in Hoogle (since I am new to HXT and Arrows). But neither search yielded any result and I had to use google to find the Haskell docs. So I am wondering what is the scope of Hoogle that people can search? Only things in the standard library? How much does it cover in the Hackage? I tried to find the scope description in the Tutorial but in vain. It is fair to say if someone needs to use Hoogle, he/she probably has no idea what he is looking for, needless to say, what is in scope of Hoogle or what is not. Thanks, Steve On Dec 19, 2007 7:48 AM, Miguel Mitrofanov <miguelimo38(a)yandex.ru> wrote: > Seems rather strange for me, I've just installed HXT and got this: > > Prelude Text.XML.HXT.Arrow> runX $ readString [(a_validate,"0")] "<this> </this>" >>> writeDocumentToString [] > ["<?xml version=\"1.0\" encoding=\"UTF-8\"?>\n<this> </this>"] > > > Everything works fine except for the fact that all the nodes <this> > > </this> > > (that is, a space (an XML text node whose contents are a single space > > character) > > within a <this> element node) get transformed to a <this/> element node, > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe(a)haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe >

2 1

Functions are first class values in C
by Cristian Baboi 22 Dec '07

22 Dec '07

Let me show you an example to prove it. The example is limited to composition of unary functions defined on int u::Int->Int v::Int->Int o ::(Int->Int)->(Int->Int)->(Int->Int) o u v= \x->u(v(x)) #include <stdio.h> #include <conio.h> #include "functional.h" int f1(int x){ return x+x; } int f2(int x){ return 2*x; } int g1(int x){ return x+1; } int g2(int x){ return x-1; } #define P1 P0 int main(){ #define P2 P1 printf("%d,%d,%d\n",2, #define P3 O(f1,f2,P2)(2), #define P4 O(g1,g2,P3)(3)); #define P5 P4 getch(); #define P6 P5 } MAIN P6 Here is the file functional.h #define FUNC2(x,y) x##y #define FUNC1(x,y) FUNC2(x,y) #define FUNC(x) FUNC1(x,__COUNTER__) #define COMP(c,f,g,p) \ int c (int x) { return f(g(x)); }; \ p \ c #define O(f,g,p) COMP( FUNC(a), f, g, p) #define P0 #define MAIN

6 9

Dynamic typing of polymorphic functions
by oleg＠okmij.org 22 Dec '07

22 Dec '07

Alfonso Acosta wrote: > mapSY :: (Typeable a, Typeable b) => (a -> b) -> Signal a -> Signal b > mapSY f (Signal primSig) = Signal (PrimSignal (MapSY (toDyn f) primSig)) > > The following process would be really useful but its compilation > obviously fails: > > mapSnd :: Signal (a, a) -> Signal a > mapSnd = mapSY snd > > > Could not deduce (Typeable a) from the context () arising from a > use of `mapSY' > Possible fix: > add (Typeable a) to the context of the type signature for `mapSnd' It seems the compiler's complaint is reasonable. The signature of the mapSY function says that mapSY may only be applied _provided_ that type variables 'a' and 'b' are instantiated to the types that are members of Typeable. That is, mapSY has a condition on its use. When you write > mapSndInt :: Signal (Int, Int) -> Signal Int > mapSndInt = mapSY (snd :: (Int, Int) -> Int) the condition is satisfied: 'a' and 'b' are instantiated to Int, and Int is a member of Typeable. The definition of mapSnd has no constraint. The compiler is upset: mapSY requires a condition, and mapSnd does not provide any, and there is no obvious way how an obligation Typeable a could have been satisfied otherwise. So, writing > mapSnd :: Typeable a => Signal (a, a) -> Signal a > mapSnd = mapSY snd is the logical thing to do. > Well, strangely enough, adding the "Typeable a" constraint hushed GHC > but an error was instead triggered at runtime. Perhaps the latter is the real problem. If one switches to dynamic typing, the type errors show up as run-time errors. I believe the typing of eval is a bit odd (and also not very useful). The following code seems to work. It also shows how to apply a polymorphic function, pairing, to to signals of any type. Here's a test: > signal3 = cons const0 (cons const0 const1) *Foo> :t signal3 signal3 :: Signal (Int, (Int, Float)) > test1 = mapSnd signal3 test1 :: Signal (Int, Float) > test12 = beval test1 *Foo> :t test12 test12 :: (Int, Float) *Foo> test12 (0,1.0) {-# OPTIONS -fglasgow-exts #-} module Foo where import Data.Typeable import Data.Dynamic -- the phantom type parameter makes signal typing consistent newtype Signal a = Signal PrimSignal newtype PrimSignal = PrimSignal (Proc (PrimSignal)) data Proc input = MapSY Dynamic -- The processing function input -- The process input -- the rest of the processes are omitted | Const Dynamic | Cons Dynamic input input eval :: PrimSignal -> Dynamic -- evaluates the output of a process for one input eval (PrimSignal (MapSY dynF dynIn)) = dynApp dynF (eval dynIn) eval (PrimSignal (Cons cns a1 a2)) = dynApp (dynApp cns (eval a1)) (eval a2) eval (PrimSignal (Const inp)) = inp -- better eval beval :: Typeable a => Signal a -> a beval (Signal s) = maybe undefined id (fromDynamic (eval s)) -- sample signals const0 :: Signal Int const0 = Signal (PrimSignal (Const (toDyn (0::Int)))) const1 :: Signal Float const1 = Signal (PrimSignal (Const (toDyn (1::Float)))) -- the map process constructor mapSY :: (Typeable a, Typeable b) => (a -> b) -> Signal a -> Signal b mapSY f (Signal primSig) = Signal (PrimSignal (MapSY (toDyn f) primSig)) add1 :: Signal Int -> Signal Int add1 = mapSY ((+1) :: Int -> Int) mapSndInt :: Signal (Int, Int) -> Signal Int mapSndInt = mapSY (snd :: (Int, Int) -> Int) -- it is important to give the signature to (,) below: we pack the cons -- function of the right type! cons :: forall a b. (Typeable a, Typeable b) => Signal a -> Signal b -> Signal (a,b) cons (Signal sig1) (Signal sig2) = Signal (PrimSignal (Cons (toDyn ((,)::a->b->(a,b))) sig1 sig2)) mapSnd :: (Typeable a, Typeable b) => Signal (b, a) -> Signal a mapSnd = mapSY snd signal3 = cons const0 (cons const0 const1) -- *Foo> :t signal3 -- signal3 :: Signal (Int, (Int, Float)) test1 = mapSnd signal3 -- test1 :: Signal (Int, Float) test11 = let Signal s = test1 in eval s -- *Foo> test11 -- <<(Int,Float)>> -- Too bad. But we can do better. test12 = beval test1 {- *Foo> :t test12 test12 :: (Int, Float) *Foo> test12 (0,1.0) -}

2 2

[14/16] SBM: Behind the measurements (rationale)
by Peter Firefly Brodersen Lund 22 Dec '07

22 Dec '07

// I am getting sick and tired of working on this project and it's probably // better to get it fired off than polishing it any further. // // This email could benefit from being rewritten from a rough draft into a // well-crafted letter but that would take a couple of hours. // // So here it is, a lot rougher than I'd like -- but it *IS* :) why so big input files? easiest way to spot non-linearity and bad memory behaviour. Anyway, files should be big enough to overflow caches and kick the gc in. (short files interesting, too, but the big ones cause more complex behaviour of run-time system and CPU. If complex behaviour is behaved then simple behaviour probably is too -- but can still get its constant factors improved. If complex behaviour bad, then shouldn't that be fixed in any case?) waitpid4() has a struct w/ info about the child program's resource usage. unfortunately, the peakrss field is not filled in. Seems to be a general Unix problem. I've seen complaints on the net that Solaris doesn't fill it in, either. Other solution needed. pause-at-end, /proc/self/maps + /proc/self/status. VmmHWM = peak of VmmRSS, which is Resident (working) Set Size. It doesn't say what is shared with other processes or the operating system, though. In our case, we don't expect to share anything but some libraries -- which nobody else wants to share with us anyway (except for the C library). We are the only user of them. Discovered about a week ago that I could probably have used waitid() w/ WNOWAIT flag but didn't know. Was quick to write pause-at-end, anyway. It took about 15 minutes from the desire to know the peak memory use to having written and tested the first cut of it. Pause-at-end not completely bullet-proof in case of dyn libraries that get unloaded before the end of the program has been reached. On the other hand, plenty good enough for these tests + can conceivably allow more intricate poking around than waitid() solution. getting good measurements - eatmem, dd, probably should also dd library. good to have a "sacrificial run". Good to measure how good the measurements are (rel. std.dev + user/sys/real check). why average -- disturbances are mostly interrupts, daemons that everybody have anyway, slightly luckier/unluckier physical pages. These are real effects that nobody can control anyway. I'm not interested in the best possible times on an ideal, undisturbed machine with a helpful kernel. I'm interested in clean times under realistic circumstances. Therefore average instead of minimum. why I use real and not user/sys -- handling of blocking reads vs. mmap vs. madvise/fadvise vs. reading in separate thread in the future. User+sys would probably give me better numbers at the moment and I could change to real later. Still, I choose to stay with real (and the difference is marginal, anyway). Funny that the exact distribution of time between sys and user fluctuates a lot. In space-bslc8-lenfil-2 sys varies between 0.160s and 0.244s. Real is completely stable with 5x 1.396s and 1x 1.397s. look at /proc/interrupts, perhaps copy before/after to .intr? Warn if more than 100 (or 1000) Hz + 10%? write date/time + runlevel to platforminfo and/or sysinfo. barcharts why barcharts. should the time/mem barcharts be equal length? don't think so (hard to colour them in a text file. Would work with less -r and the console but not in an email or a text editor. Visual difference is good). But should perhaps not be /that/ different. visible markers if measurements bad. (5% real/user/sys check, typically within 0.1% on old laptop when doing a quick or thorough benchmark. Occasionally up to 1% - and 3% on c/byte-4k because it only takes 56ms in total.) prints out how tight the user/sys/real thing is. microarchitecture -- performance counters. Would be interesting to look at once the obvious performance problems have been handled. Let's fix the memory usage of bytestrings, the performance of lazy bytestrings, and start using registers in the machine code first. regularity of input file probably means that branch predictor on all three CPUs can remember pattern of spaces vs. non-spaces (or at least part of the pattern). Branch predictors not only use two-bit saturating counter for strongly non-taken/weakly non-taken/weakly taken/strongly taken. They also try to remember the pattern of jumps/non-jumps. A more realistic test would have less regular input file. This effect is very small given the current performance limiters, though. cache -- turned out to be pretty regular (by eyeballing cachegrind reports). Go up a factor of 10 in filesize and the number of access also went up a factor of 10. The miss ratios stayed the same. The miss ratios differed a bit between the benchmarks but I don't think it's time to look into that yet. The data are available, though, for those who can't wait to look into that. minor page faults we gather that through /usr/bin/time -- and could also get the same info from dumping the right file inside /proc/self/. Probably not important yet. Probably will be once all the low-lying fruit has been gathered up from the ground. More of a factor on slower OS'es than Linux. C files. Buffer size. reading it all in one go is slower than (re)using a small buffer. Cache effects, both in the operating system when copying (because the destination will be cached with a small buffer but non-cached with a big buffer) and in the application (everything will be cached with the small buffer, nothing with the big buffer). Note that at least the Core and the Athlon64 have automatic prefetchers that tries to fill the cache in advance so we don't have to wait for the cache misses. Doesn't quite seem to work. Older caches had a different write behaviour, they were write-through instead of the modern (lazy) write-back. For those caches the writing to the user-space buffer should be slow even when a small buffer is reused all the time (because we would have to wait for all the writes to be flushed out to main memory). C files. getchar/getchar_unlocked. A comparison with getchar() is NOT what the simple haskell program does [grammar!]. Thread-safe by default (cause of libraries). getchar_unlocked() is what the haskell programs do. getchar() and getchar_unlocked() use a single buffer for stdin. getwchar() and getwchar_unlocked() included at the insistence of wli. Much slower, because it is run-time dependent on locale (to choose encoding). Therefore, can't be a macro like getchar_unlocked() is. With an indirect jump, should be same speed as getchar() on Core and Athlon64 -- but curiously isn't. C and Haskell integer sizes and other limitations. Haskell uses unboxed 32-bit signed integers, except in lazy lenfil tests. Most of the C programs are simple and just use an int for the space count. One of them (space-megabuf)is more complicated. off_t is 64-bit. ssize_t is 32-bit. Potential overflow in c/space-megabuf. Potential 32-bit wrap-around in all my C tests. Same problem with all Haskell tests, except for the two lenfil tests that use lazy bytestrings, because they use a 64-bit int for the length of the intermediate string of just the spaces filtered out from stdin. Also potentially out of memory. In practice, they have almost the same limit because they use about 107MB for the 143MB input file. In other words, it will run out of virtual address space or RAM or swap at about the same time that the others will run out of bits in a 32-bit signed integer. -Peter

1 0