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. Optimise mininal date conversion function? (Patrick LeBoutillier)
2. Re: Optimise mininal date conversion function? (Daniel Fischer)
3. Re: Optimise mininal date conversion function?
(Patrick LeBoutillier)
4. Re: filesystem verification utility (Anand Mitra)
5. Parser as an instance of the monad class (Paul Higham)
6. Re: Parser as an instance of the monad class (Iustin Pop)
----------------------------------------------------------------------
Message: 1
Date: Tue, 11 Jan 2011 09:21:56 -0500
From: Patrick LeBoutillier <patrick.leboutill...@gmail.com>
Subject: [Haskell-beginners] Optimise mininal date conversion
function?
To: beginners <beginners@haskell.org>
Message-ID:
<aanlkti=d8i=5xveayrauih0bynfrfvnt_qzyirg3x...@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
Hi,
I have this crude function that converts a date in YYYY/MM/DD format
to an Int, but it's slow.
Does any one have a clue on how to optimize it?
date2int :: B.ByteString -> Int
date2int b = y*12*31 + (m-1)*31 + (d-1)
where y = read . B.unpack . B.take 4 $ b
m = read . B.unpack . B.take 2 . B.drop 5 $ b
d = read . B.unpack . B.drop 8 $ b
Here is the original C++ function that was ported:
static unsigned date2int (const char *date){
return atoi(date)*12*31+(atoi(date+5)-1)*31+atoi(date+8)-1;
}
Thanks,
Patrick
--
=====================
Patrick LeBoutillier
Rosem?re, Qu?bec, Canada
------------------------------
Message: 2
Date: Tue, 11 Jan 2011 15:44:50 +0100
From: Daniel Fischer <daniel.is.fisc...@googlemail.com>
Subject: Re: [Haskell-beginners] Optimise mininal date conversion
function?
To: beginners@haskell.org
Message-ID: <201101111544.50869.daniel.is.fisc...@googlemail.com>
Content-Type: text/plain; charset="iso-8859-1"
On Tuesday 11 January 2011 15:21:56, Patrick LeBoutillier wrote:
> Hi,
>
> I have this crude function that converts a date in YYYY/MM/DD format
> to an Int, but it's slow.
> Does any one have a clue on how to optimize it?
Try Data.ByteString[.Lazy].Char8.readInt
>
> date2int :: B.ByteString -> Int
> date2int b = y*12*31 + (m-1)*31 + (d-1)
> where y = read . B.unpack . B.take 4 $ b
> m = read . B.unpack . B.take 2 . B.drop 5 $ b
> d = read . B.unpack . B.drop 8 $ b
>
date2int b0 = fromMaybe 0 $ do
(y,b1) <- readInt b0
(m,b2) <- readInt $ unsafeTail b1
(d,_) <- readInt $ unsafeTail b2
return $ y*12*31 + (m-1)*31 + (d-1)
(perhaps use bang-patterns, that may speed it up a bit [or not]).
>
> Here is the original C++ function that was ported:
>
> static unsigned date2int (const char *date){
> return atoi(date)*12*31+(atoi(date+5)-1)*31+atoi(date+8)-1;
> }
>
>
> Thanks,
>
> Patrick
------------------------------
Message: 3
Date: Tue, 11 Jan 2011 14:17:34 -0500
From: Patrick LeBoutillier <patrick.leboutill...@gmail.com>
Subject: Re: [Haskell-beginners] Optimise mininal date conversion
function?
To: Daniel Fischer <daniel.is.fisc...@googlemail.com>
Cc: beginners@haskell.org
Message-ID:
<aanlkti=x2hzf8rsh6ztja3c+njao7mwmfwje1sdff...@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
On Tue, Jan 11, 2011 at 9:44 AM, Daniel Fischer
<daniel.is.fisc...@googlemail.com> wrote:
> On Tuesday 11 January 2011 15:21:56, Patrick LeBoutillier wrote:
>> Hi,
>>
>> I have this crude function that converts a date in YYYY/MM/DD format
>> to an Int, but it's slow.
>> Does any one have a clue on how to optimize it?
>
> Try Data.ByteString[.Lazy].Char8.readInt
Thanks, that's exactly what I needed...
Patrick
>
>>
>> date2int :: B.ByteString -> Int
>> date2int b = y*12*31 + (m-1)*31 + (d-1)
>> ? where y = read . B.unpack . B.take 4 $ b
>> ? ? ? ? m = read . B.unpack . B.take 2 . B.drop 5 $ b
>> ? ? ? ? d = read . B.unpack . B.drop 8 $ b
>>
>
> date2int b0 = fromMaybe 0 $ do
> ? ?(y,b1) <- readInt b0
> ? ?(m,b2) <- readInt $ unsafeTail b1
> ? ?(d,_) <- readInt $ unsafeTail b2
> ? ?return $ y*12*31 + (m-1)*31 + (d-1)
>
> (perhaps use bang-patterns, that may speed it up a bit [or not]).
>
>>
>> Here is the original C++ function that was ported:
>>
>> static unsigned date2int (const char *date){
>> ? ? ? ? return atoi(date)*12*31+(atoi(date+5)-1)*31+atoi(date+8)-1;
>> }
>>
>>
>> Thanks,
>>
>> Patrick
>
>
--
=====================
Patrick LeBoutillier
Rosem?re, Qu?bec, Canada
------------------------------
Message: 4
Date: Wed, 12 Jan 2011 01:06:22 +0530
From: Anand Mitra <mi...@kqinfotech.com>
Subject: Re: [Haskell-beginners] filesystem verification utility
To: Stephen Tetley <stephen.tet...@gmail.com>
Cc: beginners@haskell.org
Message-ID:
<aanlktik3qif5s+tktqyoh7=jzo-4eb_ws+xxsh9o0...@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
Hi Stephen,
Thanks for you reply. I will give you my motivation behind this
application so that you have better context. We have been porting ZFS
to linux and have written a few programs to stress the filesystem and
generate IO load similar to what would be expected in a production
environment. The key objective is to find bugs in the ZFS code. I have
been interested in haskell for quite some time and used this as an
excuse to write something which might be useful. It is possible that
what I am doing would be much more efficient in C than in haskell.
However if my objective is fulfilled to within a fair degree, the
effort will be fun as well as worth the time invested in it.
On the high level I expect the program to do the following
- ability to perform multi-threaded i/o both threadlevel and process
level to increasing contention on locks and shared resources in the
filesystem data structures to expose race conditions.
- verify each write that has been written. i.e. the content of the
file is a function of a random seed which will allow us to detect
errors like misplaced writes lost writes etc.
- the contents should be self identifying for debugging purposes. If
mysterious data appears within a file the contents would make it
obvious where it should actually belong. I.e. file name, offset, size
and io sequence number.
- ability to generate metadata load
The existing code does only some of these but it could be expanded to
cover all aspects if the existing performance is promising.
Getting back to the problem at hand. I had some luck in identifying
the cause of the "handle is closed". I suspected that it could be
because I was mixing calls from System.IO and System.POSIX.IO. After
making the them uniform atleast I don't get a "handle is closed" error
but it is hung. Not being familiar with the debugger I resorted to
more traditional means of putting putStrLn to find what was happening.
And it appeared that the program was getting hung just before starting
the random IO. At this point I was distracted with some other work
while the apparently hung program was executing. When I came back to
the xterm there was the debug putStrLn I had added. This told me that
it wasn't hung but just taking a lot of time. From this evidence it
was instantly clear what was happening. To simplify the verification
process I was checking that there weren't any overlaping I/O. It seems
that a large number of them were overlapping and hence an inordinate
amount of time was being spent generating the list. I could bet that
is where my memory was going as well. I have removed the constraints
on the random list generator and now program is able to saturate the
disk bandwidth without any trouble. Thanks for you help I'll welcome
suggestions to improve the code.
regards
--
mitra
On Tue, Jan 11, 2011 at 3:38 PM, Stephen Tetley
<stephen.tet...@gmail.com> wrote:
> Hi Anand
>
> Firstly apologies - my advice from yesterday was trivial advice,
> changing to a better representation of Strings and avoiding costly
> operations (++) is valuable and should improve the performance of the
> program, but it might be a small overall improvement and it doesn't
> get to the heart of things.
>
> Really you need to do two things - one is consider what you are doing
> and evaluate whether it is appropriate for a performance sensitive
> app, the other is to profile and find the bits that are too slow.
>
> I rarely use Control.Concurrent so I can't offer any real experience
> but I'm concerned that it is adding overhead for no benefit. Looking
> at the code and what the comments say it does - I don't think your
> situation benefits from concurrency. A thread in your program could do
> all is work in one go, its not that you need to be servicing many
> clients (cf. a web server that needs to service many clients without
> individual long waits so it makes sense to schedule them) or that you
> are waiting on other processes making resources available. So for your
> program, any changes to execution caused by scheduling / de-scheduling
> threads (probably) just add to the total time.
>
> If you have a multi-core machine you could potentially benefit from
> parallelism - splitting the work amongst available cores. But in GHC
> forkIO spawns "green threads" which run in the same OS thread so you
> won't be getting any automatic parallelism from the code even if you
> have multi-core.
>
> However don't take my word for this - I could easily be wrong. If you
> want performance you really do need to see what the profiler tells
> you.
>
> Best wishes
>
> Stephen
>
> _______________________________________________
> Beginners mailing list
> Beginners@haskell.org
> http://www.haskell.org/mailman/listinfo/beginners
>
------------------------------
Message: 5
Date: Tue, 11 Jan 2011 23:39:48 -0800
From: Paul Higham <polyg...@mac.com>
Subject: [Haskell-beginners] Parser as an instance of the monad class
To: beginners@haskell.org
Message-ID: <e0f16653-1b1a-4185-8833-d4fa06856...@mac.com>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
I am working my way through Graham Hutton's book and find that his
approach to introducing monads is rather nice. Trouble is that the
code there does not work "out of the book". Specifically, if you
define the Parser type as follows:
type Parser a :: String -> [(a,String)]
you can then define the return and bind functions as
return v = \x -> [(v,x)]
p >>= f = \x -> case p x of
[] -> []
[(v,y)] -> (f v) y
but you get name conflicts with the functions of the same names in the
Prelude. Fair enough.
There are a number of ugly things that you can do at this point that
are just plain wrong, so I thought that the right thing to do would be
to get the Parser type to be manifested as an instance of the Monad
class. Ok, now what? Since Parser is only a type synonym it cannot
be used directly in the following way:
instance Monad Parser where
return v = . . .
p >>= f = . . .
but since Parser is not an algebraic type as it is defined that won't
work either. So how do you do it? help .
::paul
------------------------------
Message: 6
Date: Wed, 12 Jan 2011 09:01:30 +0100
From: Iustin Pop <iu...@k1024.org>
Subject: Re: [Haskell-beginners] Parser as an instance of the monad
class
To: Paul Higham <polyg...@mac.com>
Cc: beginners@haskell.org
Message-ID: <20110112080130.ga23...@teal.hq.k1024.org>
Content-Type: text/plain; charset=us-ascii
On Tue, Jan 11, 2011 at 11:39:48PM -0800, Paul Higham wrote:
> There are a number of ugly things that you can do at this point that
> are just plain wrong, so I thought that the right thing to do would
> be to get the Parser type to be manifested as an instance of the
> Monad class. Ok, now what? Since Parser is only a type synonym it
> cannot be used directly in the following way:
>
> instance Monad Parser where
> return v = . . .
> p >>= f = . . .
>
> but since Parser is not an algebraic type as it is defined that
> won't work either. So how do you do it? help .
Have you looked at the book's website? He provides the entire
Parsing.lhs library, and you can see there an example of how to do it.
regards,
iustin
------------------------------
_______________________________________________
Beginners mailing list
Beginners@haskell.org
http://www.haskell.org/mailman/listinfo/beginners
End of Beginners Digest, Vol 31, Issue 10
*****************************************
