WordString Re[2]: [Haskell-cafe] Re: Difficult memory leak in array processing

[Bulat Ziganshin]

Hello Niko,

Tuesday, November 28, 2006, 1:42:10 PM, you wrote:

> I personally find doing higher order functions with IO extremely
> difficult, and the resulting compiler errors are often downright scary.
> But this is probably a direct consequence my rather limited
> understanding of the monadic operators that the do notion hides. It
> seems that one has to be /very/ good in Haskell before one can do IO
> effectively.

i will say that one should be very good in general program
optimization and know a few haskell-specific tricks, such as avoiding
laziness and boxing

optimization is my lovely problem, so i can help you somewhat. first,
look at http://haskell.org/haskellwiki/Performance page. second, look
at sources of ByteString (FPS) library - because it both shows efficient
programming style and can be used for your sound processing

> inefficient beyond imagination. The overhead of one list element is

8 bytes on 32-bit system

> probably larger than the size of the element itself (16 to 32 bit
> integers) and a new list would have to be generated every time more data
> is read from the hard disk. So the garbage collector would be working
> really hard all the time. And this list would have to be converted into
> an IO buffer for passing it to the C sound API anyway. These were the
> reasons why I went for the IOUArray way to begin with. For this
> particular problem, probably the most natural and efficient solution is
> to have a static buffer in memory to which data is read from the hard
> drive and which is then passed to the sound API for playback. For me,
> this seems the best way to do the job.

it seems that you are ideal consumer for unboxed parallel arrays
or extended ByteStrings (WordStrings :)

we can ask Donald and Duncan whether they interested in implementing such
extension?

> But even this is not so obvious since I don't really know the
> performance implications of different Haskell constructs and the
> strong/weak points of the GHC compiler.

i can give you pointers to some longer threads which discussed these topics



-- 
Best regards,
 Bulat                            mailto:Bulat.Ziganshin at gmail.com