Re: [Haskell-cafe] Streaming bytes and performance

On 03/20/2013 12:47 AM, Branimir Maksimovic wrote: Your problem is that main_6 thunks 'i' and 'a' . If you write (S6 !i !a) <- get than there is no problem any more... Nope :( Unfortunately that doesn't change anything. Still allocating... ___ Hask

[Haskell-cafe] Does GHC 7.8 make targeting bare metal ARM any easier?

There have been at least a couple projects, such as hOp and HaLVM which attempt to run GHC on the bare metal or something similar. Both these projects required a substantial set of patches against GHC to remove dependencies things like POSIX/libc. Due to the highly invasive nature, they are also h

Re: [Haskell-cafe] Associated types for number coercion

On 20 March 2013 06:58, Christopher Done wrote: > From the paper Fun with Type Funs, it's said: > >> One compelling use of such type functions is to make type >> coercions implicit, especially in arithmetic. Suppose we want to be able to >> write add a b to add two numeric values a and b even if o

[Haskell-cafe] Extracting exposed modules from an installed library

Hi Cafe! I'm looking for how to extract the exposed modules (as a list of strings) from an installed library, giving the library name. I can see some structures in Cabal (InstalledPackageInfo) and some functions in ghc-pkg.hs in GHC, but nothing readily useable... Thanks, Corenti __

Re: [Haskell-cafe] Associated types for number coercion

(But I get annoyed about having to convert between five string types (String, Text, lazy Text, ByteString, lazy ByteString), so maybe I'm just generally more bothered by the whole “not being able to just write the program” than others.) On 20 March 2013 00:22, Christopher Done wrote: > On 20 Marc

Re: [Haskell-cafe] Associated types for number coercion

On 20 March 2013 00:05, Johan Tibell wrote: > I prefer the current way (which is interestingly what Go chose as well). > With implicit casts it's easy to shoot yourself in the foot e.g. when doing > bit-twiddling. I don't think it's an either-or case, though, is it? I would use the magic implicit

Re: [Haskell-cafe] Associated types for number coercion

On Tue, Mar 19, 2013 at 3:58 PM, Christopher Done wrote: > From the paper Fun with Type Funs, it's said: > > > One compelling use of such type functions is to make type > > coercions implicit, especially in arithmetic. Suppose we want to be able > to > > write add a b to add two numeric values a a

Re: [Haskell-cafe] Streaming bytes and performance

> To: haskell-cafe@haskell.org > From: to.darkan...@gmail.com > Date: Tue, 19 Mar 2013 23:27:09 +0200 > Subject: Re: [Haskell-cafe] Streaming bytes and performance > > On 03/19/2013 10:49 PM, Konstantin Litvinenko wrote: > > {-# LANGUAGE BangPatterns #-} > > > > import Control.Monad.State.Strict

[Haskell-cafe] package show needs QuickCheck<2.6?

Hi, I noticed that compilation of mueval (recent: 0.8.2) breaks because show (0.5) cannot be built: it seems the type of Failure changed in QuickCheck (from 2.5 to 2.6). The build succeeds with --constraint 'QuickCheck<2.6' . ___ Haskell-Cafe mailing

Re: [Haskell-cafe] Streaming bytes and performance

I guess the optimizations that went into making lazy bytestring IO fast (on disks) are increasingly irrelevant as SSDs take over. On Mar 19, 2013 9:49 PM, "Peter Simons" wrote: > Hi Don, > > > "Using this input file stored in /dev/shm" > > > > So not measuring the IO performance at all. :) > >

Re: [Haskell-cafe] Streaming bytes and performance

Hi Don, > "Using this input file stored in /dev/shm" > > So not measuring the IO performance at all. :) of course the program measures I/O performance. It just doesn't measure the speed of the disk. Anyway, a highly optimized benchmark such as the one you posted is eventually going to beat on

Re: [Haskell-cafe] Streaming bytes and performance

Oh I see what you're doing ... "Using this input file stored in /dev/shm" So not measuring the IO performance at all. :) On Mar 19, 2013 9:27 PM, "Peter Simons" wrote: > Hi Don, > > > Compare your program (made lazy) on lazy bytestrings using file IO: > [...] > > if I make those changes, the pr

Re: [Haskell-cafe] Streaming bytes and performance

Hi Don, > Compare your program (made lazy) on lazy bytestrings using file IO: [...] if I make those changes, the program runs even faster than before: module Main ( main ) where import Prelude hiding ( foldl, readFile ) import Data.ByteString.Lazy.Char8 countSpace :: Int -> Char -> In

Re: [Haskell-cafe] Streaming bytes and performance

On 03/19/2013 10:49 PM, Konstantin Litvinenko wrote: {-# LANGUAGE BangPatterns #-} import Control.Monad.State.Strict data S6 = S6 !Int !Int main_6 = do let r = evalState go (S6 1 0) print r where go = do (S6 i a) <- get if (i == 0) then return a else (pu

Re: [Haskell-cafe] Streaming bytes and performance

This isn't a valid entry -- it uses strict IO (so allocates O(n) space) and reads from standard input, which pretty much swamps the interesting constant factors with buffered IO overhead. Compare your program (made lazy) on lazy bytestrings using file IO: import Prelude hiding ( readFile, foldl )

Re: [Haskell-cafe] Streaming bytes and performance

Don Stewart writes: > Here's the final program: [...] Here is a version of the program that is just as fast: import Prelude hiding ( getContents, foldl ) import Data.ByteString.Char8 countSpace :: Int -> Char -> Int countSpace i c | c == ' ' || c == '\n' = i + 1 | oth

Re: [Haskell-cafe] Streaming bytes and performance

On 03/19/2013 10:53 PM, Nicolas Trangez wrote: On Tue, 2013-03-19 at 20:32 +, Don Stewart wrote: So about 8x faster. Waiting for some non-lazy bytestring benchmarks... :) You could try something like this using Conduit: {-# LANGUAGE BangPatterns #-} module Main (main) where import Data.C

Re: [Haskell-cafe] Streaming bytes and performance

On Tue, 2013-03-19 at 20:32 +, Don Stewart wrote: > Oh, I forgot the technique of inlining the lazy bytestring chunks, and > processing each chunk seperately. > > $ time ./fast > 4166680 > ./fast 1.25s user 0.07s system 99% cpu 1.325 total > > Essentially inline Lazy.foldlChunks and speciali

Re: [Haskell-cafe] Streaming bytes and performance

On 03/19/2013 10:32 PM, Don Stewart wrote: Oh, I forgot the technique of inlining the lazy bytestring chunks, and processing each chunk seperately. $ time ./fast 4166680 ./fast 1.25s user 0.07s system 99% cpu 1.325 total Essentially inline Lazy.foldlChunks and specializes is (the inliner shoul

Re: [Haskell-cafe] Streaming bytes and performance

Oh, I forgot the technique of inlining the lazy bytestring chunks, and processing each chunk seperately. $ time ./fast 4166680 ./fast 1.25s user 0.07s system 99% cpu 1.325 total Essentially inline Lazy.foldlChunks and specializes is (the inliner should really get that). And now we have a nice un

Re: [Haskell-cafe] Streaming bytes and performance

Just for fun. Here's some improvements. about 6x faster. I'd be interested to see what io-streams could do on this. Using a 250M test file. -- strict state monad and bang patterns on the uncons and accumulator argument: $ time ./A 4166680 ./A 8.42s user 0.57s system 99% cpu 9.037 total -- just

Re: [Haskell-cafe] Announcement - HGamer3D - 0.2.1 - featuring FRP based GUI and more

Peter Althainz wrote: Dear All, I'm happy to announce release 0.2.1 of HGamer3D, the game engine with Haskell API, featuring FRP based API and FRP based GUI. The new FRP API is based on the netwire package. Currently only available on Windows: http://www.hgamer3d.org. Nice work! Of course,

Re: [Haskell-cafe] Streaming bytes and performance

On 03/18/2013 02:14 PM, Gregory Collins wrote: Put a bang pattern on your accumulator in "go". Since the value is not demanded until the end of the program, you're actually just building up a huge space leak there. Fixed that Secondly, unconsing from the lazy bytestring will cause a lot of al

Re: [Haskell-cafe] Specialized Computer Architecture - A Question

OWP wrote: > Ironically, you made an interesting point on how Moore's Law created > the on chip "real estate" that made specialized machines possible. As > transistor sizing shrinks and die sizes increase, more and more real > estate should now be available for usage. Oddly, what destroyed > spe

Re: [Haskell-cafe] Fwd: Now Accepting Applications for Mentoring Organizations for GSoC 2013

On 03/18/2013 08:49 PM, Johan Tibell wrote: [bcc: hask...@haskell.org ] We should make sure that we apply for Google Summer of Code this year as well. It's been very successful in the previous year, where we have gotten several projects funded every year. Definitely

Re: [Haskell-cafe] Need some advice around lazy IO

On Tue, Mar 19, 2013 at 2:01 PM, Konstantin Litvinenko wrote: > Yes. You (and Dan) are totally right. 'Let' just bind expression, not > evaluating it. Dan's evaluate trick force rnf to run before hClose. As I > said - it's tricky part especially for newbie like me :) To place this in perspective,

Re: [Haskell-cafe] Need some advice around lazy IO

On 03/19/2013 07:12 AM, Edward Kmett wrote: Konstantin, Please allow me to elaborate on Dan's point -- or at least the point that I believe that Dan is making. Using, let bug = Control.DeepSeq.rnf str `seq` fileContents2Bug str or ($!!)will create a value that *when forced* cause the rnf