Send Beginners mailing list submissions to
beginners@haskell.org
To subscribe or unsubscribe via the World Wide Web, visit
http://www.haskell.org/mailman/listinfo/beginners
or, via email, send a message with subject or body 'help' to
beginners-requ...@haskell.org
You can reach the person managing the list at
beginners-ow...@haskell.org
When replying, please edit your Subject line so it is more specific
than "Re: Contents of Beginners digest..."
Today's Topics:
1. playing music openAL (Maria Gabriela Valdes)
2. Pattern matching vs bit twiddling? (Patrick LeBoutillier)
3. Re: Pattern matching vs bit twiddling? (Felipe Lessa)
4. Re: Pattern matching vs bit twiddling? (Daniel Fischer)
----------------------------------------------------------------------
Message: 1
Date: Tue, 6 Jul 2010 21:24:20 -0430
From: Maria Gabriela Valdes <mgvaldesgrate...@gmail.com>
Subject: [Haskell-beginners] playing music openAL
To: ope...@haskell.org, haskell-c...@haskell.org,
beginners@haskell.org
Message-ID:
<aanlktinjyrbvgbbm_bdqg9i6y9ns1xdye-pophmh7...@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
Hi ! We have a question about about openAL. We would like to know if anybody
knows how to read a WAV file by chunks of a determined size, and after doing
some processing with a specific chunk send that same chunk back to the sound
card so we can play the whole WAV continiously (just like a music player).
Thanks in advance,
--
Maria Gabriela Valdes G.
Linux Registered User #485743
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://www.haskell.org/pipermail/beginners/attachments/20100706/9f14b77d/attachment-0001.html
------------------------------
Message: 2
Date: Fri, 9 Jul 2010 10:15:30 -0400
From: Patrick LeBoutillier <patrick.leboutill...@gmail.com>
Subject: [Haskell-beginners] Pattern matching vs bit twiddling?
To: beginners <beginners@haskell.org>
Message-ID:
<aanlktim9k8hdkplji-ikuskahtlq2ujrkoygnu3td...@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
Hi all,
I recently started writing a simulator for Knuth's MIX computer in
Haskell. My first attempt had the basic data types for the machine
defined like this:
type Byte = Word8
type Address = Word16
type Word = Word32
type FieldSpec = (Int,Int)
data Register = A Word | X Word | I Address | J Address
type Memory = M.Map Address Word
After hitting some kind of dead end with this setup (basically getting
frustrated/lost with all the bit-twiddling), I tried again with these
more abstract types:
data Byte = Byte Word8
data Sign = Plus | Minus
data Address = Address Byte Byte
data SignedAddress = SignedAddress Sign Address
data Word = Word Sign Byte Byte Byte Byte Byte
data FieldSpec = FieldSpec Int Int
data Memory = Memory (M.Map Address Word)
Now I find my code is much clearer (it almost writes itself...) and
practically absent of low-level bit operations (except, for example,
converting a Word into an actual Haskell Int32 to perform the actual
arithmetic). However, I'm wondering about the cost of all the
"packing/unpacking" via pattern-matching and/or accessors. Perhaps I
should not worry about this and optimize later if required? Is this
type of premature optimization (assuming the previous version was
faster...) really the root of all evil?
Note: I'm not far enough into the simulator to be able to actually
test it out and get metrics.
Patrick
Thanks,
Patrick
--
=====================
Patrick LeBoutillier
Rosemère, Québec, Canada
------------------------------
Message: 3
Date: Fri, 9 Jul 2010 11:27:52 -0300
From: Felipe Lessa <felipe.le...@gmail.com>
Subject: Re: [Haskell-beginners] Pattern matching vs bit twiddling?
To: Patrick LeBoutillier <patrick.leboutill...@gmail.com>
Cc: beginners <beginners@haskell.org>
Message-ID:
<aanlktimknarodpfj8gssihwarev5out81gmctidbn...@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
On Fri, Jul 9, 2010 at 11:15 AM, Patrick LeBoutillier
<patrick.leboutill...@gmail.com> wrote:
> Now I find my code is much clearer (it almost writes itself...) and
> practically absent of low-level bit operations (except, for example,
> converting a Word into an actual Haskell Int32 to perform the actual
> arithmetic). However, I'm wondering about the cost of all the
> "packing/unpacking" via pattern-matching and/or accessors. Perhaps I
> should not worry about this and optimize later if required? Is this
> type of premature optimization (assuming the previous version was
> faster...) really the root of all evil?
Yes, you should test before worrying too much about it. There's only
one bit you should do regardless: use strict and unpacked fields. For
example:
data Word = Word !Sign {-# UNPACK #-} !Byte
{-# UNPACK #-} !Byte
{-# UNPACK #-} !Byte
{-# UNPACK #-} !Byte
This should give you boost. I didn't give an UNPACK pragma to Sign
because AFAIK it won't unpacked anyway.
Of course there's a performance penalty, but if it matters or not
you'll find only by testing.
One possible solution is to never use pattern matching, only
accessors. That way the code will work for any representation you
choose. In fact, all bit-fiddling will be contained in your
accessors.
Cheers! =)
--
Felipe.
------------------------------
Message: 4
Date: Fri, 9 Jul 2010 17:11:59 +0200
From: Daniel Fischer <daniel.is.fisc...@web.de>
Subject: Re: [Haskell-beginners] Pattern matching vs bit twiddling?
To: beginners@haskell.org
Message-ID: <201007091711.59556.daniel.is.fisc...@web.de>
Content-Type: text/plain; charset="iso-8859-1"
On Friday 09 July 2010 16:15:30, Patrick LeBoutillier wrote:
> Hi all,
>
> I recently started writing a simulator for Knuth's MIX computer in
> Haskell. My first attempt had the basic data types for the machine
> defined like this:
>
> type Byte = Word8
> type Address = Word16
> type Word = Word32
> type FieldSpec = (Int,Int)
> data Register = A Word | X Word | I Address | J Address
> type Memory = M.Map Address Word
>
> After hitting some kind of dead end with this setup (basically getting
> frustrated/lost with all the bit-twiddling), I tried again with these
> more abstract types:
>
> data Byte = Byte Word8
This could be type Byte = Word8, I don't think that would complicate
anything. If it would, newtype Byte = Byte Word8 would eliminate the run-
time cost of the data constructor.
> data Sign = Plus | Minus
> data Address = Address Byte Byte
> data SignedAddress = SignedAddress Sign Address
> data Word = Word Sign Byte Byte Byte Byte Byte
> data FieldSpec = FieldSpec Int Int
As Felipe said, make the fields strict and {-# UNPACK #-} them for better
performance, {-# UNPACK #-}-ing Sign too should be better, then all the
data is in one place and you needn't visit the heap multiple times.
If you don't need to access individual bytes, using Word16/Word32 instead
of multiple Byte fields would be faster, too.
> data Memory = Memory (M.Map Address Word)
>
> Now I find my code is much clearer (it almost writes itself...) and
> practically absent of low-level bit operations (except, for example,
> converting a Word into an actual Haskell Int32 to perform the actual
> arithmetic). However, I'm wondering about the cost of all the
> "packing/unpacking" via pattern-matching and/or accessors. Perhaps I
> should not worry about this and optimize later if required?
Probably. For example, it is likely that the lookups in the Map take far
longer than the pattern matching/field accesses.
So before you go into low-level optimisations, you should investigate
different memory representations (since the memory will probably be mutated
a lot, you might look at STArrays, if that doesn't cut it, STUArrays [that
would mean Word should become a native type again]).
> Is this type of premature optimization (assuming the previous version was
> faster...) really the root of all evil?
No. But it's the cause of a lot of unnecessary headaches.
If you know that performance matters much and you know that low-level code
is faster for your task and you are familiar enough with the needed low-
level stuff, then start out writing the low-level code.
If you're not at home with e.g the bit-twiddling stuff, it will be easier
to write the code high-level first and then translate it to low-level-bit-
twiddling.
If you don't know that the low-level stuff will be faster (the optimiser is
pretty good), write the high-level code and measure.
Translate to low-level if necessary.
(Translating from high-level to low-level tends to be much easier than
writing low-level from scratch, since in the translation, you can focus on
small details while the big picture is already there).
>
> Note: I'm not far enough into the simulator to be able to actually
> test it out and get metrics.
>
>
> Patrick
>
>
> Thanks,
>
> Patrick
------------------------------
_______________________________________________
Beginners mailing list
Beginners@haskell.org
http://www.haskell.org/mailman/listinfo/beginners
End of Beginners Digest, Vol 25, Issue 27
*****************************************
