It's worth remembering that the main gain from lex/yacc had originally to do
with making the generated programs fit into 64K address space on a PDP11 more
than with any direct performance efficiency.
--
brandon s allbery kf8nh
Sent with Sparrow (http://www.sparrowmailapp.com/?sig)
On Thursday
(I'll be brief because my head is hurting, but please don't interpret that
as an intent to offend)
A few points:
1) Capture groups are all you need to do some meaningful interpretation of
data; these were around long before perl.
2) Yacc is typically used in conjunction with lex, partly for (a)
On 2/13/13 11:18 PM, wren ng thornton wrote:
On 2/13/13 11:32 AM, Nicolas Bock wrote:
Since I have very little experience with Haskell and am not used to
Haskell-think yet, I don't quite understand your statement that
regexes are
seen as foreign to Haskell-think. Could you elaborate? What would
Just to play devil's advocate:
100% agreed that there are better things to do in Haskell _source code_ than
regexps.
The thing about regexps is that they can be accepted at run time as _data_.
This means, for example, that they can be put in whatever you use for
localisation.
See for exam
I have to agree that reading and maintaining regular expressions can be
challenging :)
On Wed, Feb 13, 2013 at 9:50 PM, Erik de Castro Lopo
wrote:
> wren ng thornton wrote:
>
> > Regexes are powerful and concise for recognizing regular languages. They
> > are not, however, very good for *parsing
wren ng thornton wrote:
> Regexes are powerful and concise for recognizing regular languages. They
> are not, however, very good for *parsing* regular languages; nor can
> they handle non-regular languages (unless you're relying on the badness
> of pcre). In other languages people press regexes
On 2/13/13 11:32 AM, Nicolas Bock wrote:
Since I have very little experience with Haskell and am not used to
Haskell-think yet, I don't quite understand your statement that regexes are
seen as foreign to Haskell-think. Could you elaborate? What would a more
"native" solution look like? From what
On Wed, Feb 13, 2013 at 5:45 PM, wrote:
> > On 13.02.2013 21:41, Brandon Allbery wrote:
> >> The native solution is a parser like parsec/attoparsec.
>
> "Aleksey Khudyakov" replied
>
> > Regexps only have this problem if they are compiled from string. Nothing
> > prevents from building them usin
> On 13.02.2013 21:41, Brandon Allbery wrote:
>> The native solution is a parser like parsec/attoparsec.
"Aleksey Khudyakov" replied
> Regexps only have this problem if they are compiled from string. Nothing
> prevents from building them using combinators. regex-applicative[1] uses
> this approa
On 10.02.2013 02:30, Nicolas Bock wrote:
Hi Aleksey,
could you show me how I would use ByteString? I can't get the script to
compile. It's complaining that:
No instance for (RegexContext
Regex Data.ByteString.ByteString
(AllTextSubmatches [] a0))
which is too cryptic fo
On 13.02.2013 21:41, Brandon Allbery wrote:
On Wed, Feb 13, 2013 at 11:32 AM, Nicolas Bock mailto:nicolasb...@gmail.com>> wrote:
Since I have very little experience with Haskell and am not used to
Haskell-think yet, I don't quite understand your statement that
regexes are seen as for
On Wed, Feb 13, 2013 at 12:46 PM, David Thomas wrote:
> The fact that parsec and attoparsec exist and can be pressed into service
> with reasonable performance (I think?) on tasks for which regexps are
> suitable is probably another big part of the reason no one's done it yet.
> I expect much of
The fact that parsec and attoparsec exist and can be pressed into service
with reasonable performance (I think?) on tasks for which regexps are
suitable is probably another big part of the reason no one's done it yet.
I expect much of the plumbing would wind up looking a lot like those,
actually.
I don't think you can do much about "fails to match the input string" -
indeed, that's often desired behavior... and "matches the wrong thing" you
can only catch with testing.
The simplest place template haskell could help with is when the expression
isn't a valid expression in the first place, a
On Wed, Feb 13, 2013 at 11:32 AM, Nicolas Bock wrote:
> Since I have very little experience with Haskell and am not used to
> Haskell-think yet, I don't quite understand your statement that regexes are
> seen as foreign to Haskell-think. Could you elaborate? What would a more
> "native" solution l
Well, this runtime errors are actually type errors. Regexps are actually a DSL,
which is not embedded in Haskell. But it could be. Strings won't work for that,
but something like that would:
filter (match $ "a" <> many anyChar <> ".txt") filenames
and this certainly can be produced by TH like t
On Wed, 2013-02-13 at 08:39 -0800, David Thomas wrote:
> One way in which regexps are "foreign to Haskell-think" is that, if
> they
> break, they generally break at run-time. This could be ameliorated
> with
> template haskell
Care to elaborate on the "ameliorate using TH" part? I figure regexes
One way in which regexps are "foreign to Haskell-think" is that, if they
break, they generally break at run-time. This could be ameliorated with
template haskell, but a substantial portion of Haskell coders find that a
smell itself.
On Wed, Feb 13, 2013 at 8:32 AM, Nicolas Bock wrote:
> Since
Since I have very little experience with Haskell and am not used to
Haskell-think yet, I don't quite understand your statement that regexes are
seen as foreign to Haskell-think. Could you elaborate? What would a more
"native" solution look like? From what I have learned so far, it seems to
me that
On Tue, Feb 12, 2013 at 11:32 PM, wrote:
> actualy native code compiler. Can't regex be done effectively in haskell
> ? Is it something that can't be done, or is it just such minimal effort to
> link to pcre that it's not worth the trouble ?
>
PCRE is pretty heavily optimized. POSIX regex eng
replacing it.
> Date: Tue, 12 Feb 2013 20:32:01 -0800
> From: bri...@aracnet.com
> To: nicolasb...@gmail.com
> CC: bm...@hotmail.com; b...@redivi.com; haskell-cafe@haskell.org
> Subject: Re: [Haskell-cafe] performance question
>
> On Tue, 12 Feb 2013 15:57:37 -0700
> Nicolas Bock
t; > loop i
> > > | i < (snd $ bounds strataBounds) =
> > > if (b >= (strataBounds ! i)) && (b < (strataBounds !
> > > (i+1)))
> > > then do
> > > c <- readArr
if (b >= (strataBounds ! i)) && (b < (strataBounds !
> > (i+1)))
> > then do
> > c <- readArray counts i
> > writeArray counts i (c+1)
> > else
> >
i)) && (b < (strataBounds !
> (i+1)))
> then do
> c <- readArray counts i
> writeArray counts i (c+1)
> else
> loop (i+1)
> | otherwise = return ()
> if is
loop 0calculate counts ls (n+1)
From: nicolasb...@gmail.com
Date: Fri, 8 Feb 2013 12:26:09 -0700
To: haskell-cafe@haskell.org
Subject: [Haskell-cafe] performance question
Hi list,
I wrote a script that reads matrix elements from standard input, parses the
input using a regular expression
I've been playing with your example to optimize it a bit, I have to run but
here's what I have so far. It's about as fast as the Python code, I'll make
it faster when I have more time over the next few days.
See https://gist.github.com/etrepum/4747507 and
https://gist.github.com/etrepum/4747507/re
On Fri, Feb 8, 2013 at 1:23 PM, Aleksey Khudyakov wrote:
> On 08.02.2013 23:26, Nicolas Bock wrote:
>
>> Hi list,
>>
>> I wrote a script that reads matrix elements from standard input, parses
>> the input using a regular expression, and then bins the matrix elements
>> by magnitude. I wrote the s
On Fri, Feb 8, 2013 at 1:23 PM, Aleksey Khudyakov wrote:
> On 08.02.2013 23:26, Nicolas Bock wrote:
>
>> Hi list,
>>
>> I wrote a script that reads matrix elements from standard input, parses
>> the input using a regular expression, and then bins the matrix elements
>> by magnitude. I wrote the s
ataBounds[i], strataBounds[i+1],strataCounts[i],
100*(double(strataCounts[i])/N), total); }}
From: nicolasb...@gmail.com
Date: Fri, 8 Feb 2013 12:26:09 -0700
To: haskell-cafe@haskell.org
Subject: [Haskell-cafe] performance question
Hi list,
I wrote a script that reads matrix elements from stan
On 09.02.2013 01:02, Nicolas Bock wrote:
Yes, a histogram. The binning code is really a little awkward. I haven't
gotten used to thinking in terms of inmutable objects yet and this list
appending is really a pretty bad hack to kind of allow me to increment
the bin counts. How would one do this mo
On Fri, Feb 8, 2013 at 1:23 PM, Aleksey Khudyakov wrote:
> On 08.02.2013 23:26, Nicolas Bock wrote:
>
>> Hi list,
>>
>> I wrote a script that reads matrix elements from standard input, parses
>> the input using a regular expression, and then bins the matrix elements
>> by magnitude. I wrote the s
Sorry, should have done this right away. Here are the other two scripts.
On Fri, Feb 8, 2013 at 1:45 PM, Bob Ippolito wrote:
> Do you mind posting createMatrixDump.py and printMatrixDecay.py? That
> would certainly make it easier to help you.
>
>
> On Fri, Feb 8, 2013 at 11:26 AM, Nicolas Bock
Do you mind posting createMatrixDump.py and printMatrixDecay.py? That would
certainly make it easier to help you.
On Fri, Feb 8, 2013 at 11:26 AM, Nicolas Bock wrote:
> Hi list,
>
> I wrote a script that reads matrix elements from standard input, parses
> the input using a regular expression, a
On 08.02.2013 23:26, Nicolas Bock wrote:
Hi list,
I wrote a script that reads matrix elements from standard input, parses
the input using a regular expression, and then bins the matrix elements
by magnitude. I wrote the same script in python (just to be sure :) )
and find that the python version
Hi list,
I wrote a script that reads matrix elements from standard input, parses the
input using a regular expression, and then bins the matrix elements by
magnitude. I wrote the same script in python (just to be sure :) ) and find
that the python version vastly outperforms the Haskell script.
To
A lte reply, but if you still need to have circular module depency: 4.6.9.
How to compile mutually recursive modules in
http://www.haskell.org/ghc/docs/latest/html/users_guide/separate-compilation.html
On 21 March 2010 01:31, Arnoldo Muller wrote:
> Hello Daniel,
>
> Regarding your solution, can
Hello Daniel,
Regarding your solution, can I apply {-# SPECIALISE ... #-} statements to
datatypes I define?
And if so, I am not able to import the datatypes to the module where
binarySearch is.
The problem is that if I import them a circular dependency is detected and
the compiler gives an error.
>Right now, the bottleneck of my program is in binarySearch', the function
must be called a few billion times.
>Do you have any ideas on how to improve the performance of this function?
Bast solution for speeding up is to write it in assembler!
Ragards, Andrey
--
View this message in context:
On 19/03/2010, at 08:48, Daniel Fischer wrote:
> Am Donnerstag 18 März 2010 21:57:34 schrieb Daniel Fischer:
>>
>> Contrary to my expectations, however, using unboxed arrays is slower
>> than straight arrays (in my tests).
>>
>
> However, a few {-# SPECIALISE #-} pragmas set the record straight
Am Donnerstag 18 März 2010 21:57:34 schrieb Daniel Fischer:
>
> Contrary to my expectations, however, using unboxed arrays is slower
> than straight arrays (in my tests).
>
However, a few {-# SPECIALISE #-} pragmas set the record straight.
Specialising speeds up both, boxed and unboxed arrays, si
Daniel Fischer wrote:
If it's called often, and the arrays are 0-based and Int-indexed,
import Data.Array.Base (unsafeAt)
and replacing ! with `unsafeAt` should give a speed-up, though probably not
terribly much. If you don't need the polymorphism and your array elements
are unboxable, using
Am Donnerstag 18 März 2010 20:49:30 schrieb Daniel Fischer:
> Am Donnerstag 18 März 2010 19:59:33 schrieb Arnoldo Muller:
> > Hello!
> >
> > I am trying to implement a binary search function that returns the
> > index of an
> > exact or the (index + 1) where the item should be inserted in an array
Am Donnerstag 18 März 2010 19:59:33 schrieb Arnoldo Muller:
> Hello!
>
> I am trying to implement a binary search function that returns the index
> of an
> exact or the (index + 1) where the item should be inserted in an array
> if the item to be searched is not found (I am not trying to insert dat
Hello!
I am trying to implement a binary search function that returns the index of
an
exact or the (index + 1) where the item should be inserted in an array if
the item to be searched is not found (I am not trying to insert data in the
array) .
Right now, the bottleneck of my program is in binary
On 2009 Feb 27, at 1:50, Ketil Malde wrote:
Lennart Augustsson writes:
C's rand() function is very bad and should never be used really.
On Linux (really GNU libc, I suppose) it is the same as random(). But
for portability, one is encouraged to spend the two extra letters. I
don't understand
The random() function is only marginally better than rand().
On Fri, Feb 27, 2009 at 6:50 AM, Ketil Malde wrote:
> Lennart Augustsson writes:
>
>> C's rand() function is very bad and should never be used really.
>
> On Linux (really GNU libc, I suppose) it is the same as random(). But
> for por
Lennart Augustsson writes:
> C's rand() function is very bad and should never be used really.
On Linux (really GNU libc, I suppose) it is the same as random(). But
for portability, one is encouraged to spend the two extra letters. I
don't understand the details, but I think the Mersenne twiste
On Thu, Feb 26, 2009 at 6:23 PM, Don Stewart wrote:
> But note the lazy list of Double pairs, so the inner loop still looks like
> this though:
>
> $wlgo :: Int# -> [(Double, Double)] -> Int
>
> $wlgo =
> \ (ww_s1pv :: Int#)
> (w_s1px :: [(Double, Double)]) ->
> case w_s1
How about an FFI call to rand() and then measure the performance
On Thu, Feb 26, 2009 at 3:37 AM, Felipe Lessa wrote:
> On Thu, Feb 26, 2009 at 7:56 AM, Eugene Kirpichov
> wrote:
> > Here is a variant that uses mersenne-random-pure64 and works less than
> > 2x slower than C++:
>
> And I would li
vandijk.roel:
> I replaced the standard random number generated with the one from
> mersenne-random. On my system this makes the resulting program about
> 14 times faster than the original. I also made a change to
> accumulateHit because it doesn't need to count to total. That is
> already known.
>
I looked at the core and the tuples were already unboxed IIRC.
2009/2/26 Don Stewart :
> Ben.Lippmeier:
>>
>> On 26/02/2009, at 9:27 PM, hask...@kudling.de wrote:
>>>
>>> Currently i can only imagine to define a data type in order to use
>>> unboxed Ints instead of the accumulator tuple.
>>
>> Tha
Ben.Lippmeier:
>
> On 26/02/2009, at 9:27 PM, hask...@kudling.de wrote:
>>
>> Currently i can only imagine to define a data type in order to use
>> unboxed Ints instead of the accumulator tuple.
>
> That would probably help a lot. It would also help to use two separate
> Double# parameters inst
Awesome, Felipe. Thanks.
--Tracy
On Thu, Feb 26, 2009 at 11:07 AM, Felipe Lessa wrote:
> 2009/2/26 Tracy Wadleigh :
> > On Thu, Feb 26, 2009 at 7:17 AM, Lennart Augustsson <
> lenn...@augustsson.net>
> > wrote:
> >>
> >> You can implement a reasonable split if you can fast-forward the
> >> gener
2009/2/26 Tracy Wadleigh :
> On Thu, Feb 26, 2009 at 7:17 AM, Lennart Augustsson
> wrote:
>>
>> You can implement a reasonable split if you can fast-forward the
>> generator.
>> There's no known method to fast-forward the MT, but other generators
>> like MRG32k3a can handle it.
>
> Are you aware o
On Thu, Feb 26, 2009 at 7:17 AM, Lennart Augustsson
wrote:
> You can implement a reasonable split if you can fast-forward the generator.
> There's no known method to fast-forward the MT, but other generators
> like MRG32k3a can handle it.
>
Are you aware of any existing (C/C++/Haskell) library im
You can implement a reasonable split if you can fast-forward the generator.
There's no known method to fast-forward the MT, but other generators
like MRG32k3a can handle it.
-- Lennart
On Thu, Feb 26, 2009 at 12:08 PM, Bertram Felgenhauer
wrote:
> hask...@kudling.de wrote:
>> Do you think it w
hask...@kudling.de wrote:
> Do you think it would be feasable to replace the GHC implementation
> of System.Random with something like System.Random.Mersenne?
There's a problem with using the Mersenne Twister: System.Random's
interface has a split method:
class RandomGen g where
split:: g
C's rand() function is very bad and should never be used really.
On Thu, Feb 26, 2009 at 11:37 AM, Felipe Lessa wrote:
> On Thu, Feb 26, 2009 at 7:56 AM, Eugene Kirpichov
> wrote:
>> Here is a variant that uses mersenne-random-pure64 and works less than
>> 2x slower than C++:
>
> And I would li
On Thu, Feb 26, 2009 at 7:56 AM, Eugene Kirpichov wrote:
> Here is a variant that uses mersenne-random-pure64 and works less than
> 2x slower than C++:
And I would like to notice that rand() is incredibly dumber than the
Mersenne twister, so probably if we took rand()'s code from glibc and
rewrot
I, personally, do, but I think that's more of a question to the GHC people :)
2009/2/26 :
> Do you think it would be feasable to replace the GHC implementation of
> System.Random with something like System.Random.Mersenne?
>
>>Here is a variant that uses mersenne-random-pure64 and works less tha
Do you think it would be feasable to replace the GHC implementation of
System.Random with something like System.Random.Mersenne?
>Here is a variant that uses mersenne-random-pure64 and works less than
>2x slower than C++:
>
> - You don't need to compute samples count an extra time
> - You don't n
>accumulateHit because it doesn't need to count to total. That is
>already known.
Well in theory i agree. But somone could feed a non-infite number of doubles.
Then the argument "n" would not necessarily be the same as the number of random
number pairs really used.
__
I replaced the standard random number generated with the one from
mersenne-random. On my system this makes the resulting program about
14 times faster than the original. I also made a change to
accumulateHit because it doesn't need to count to total. That is
already known.
{-# LANGUAGE BangPattern
Here is a variant that uses mersenne-random-pure64 and works less than
2x slower than C++:
- You don't need to compute samples count an extra time
- You don't need to assemble double pairs from a list
- Notice the strictness in randomDoublePairs: it doubled performance
{-# LANGUAGE BangPattern
Ben Lippmeier wrote:
>>> The first thing I would do is replace your isInCircle :: (Floating
>>> a, Ord a) => (a,a) -> Bool with isInCircle :: (Double, Double) ->
>>> Bool
>>
>> Can you point me to why that matters?
>
> At the machine level, GHC treats the (Floating a, Ord a) as an extra
> arg
On 26/02/2009, at 9:27 PM, hask...@kudling.de wrote:
Currently i can only imagine to define a data type in order to use
unboxed Ints instead of the accumulator tuple.
That would probably help a lot. It would also help to use two separate
Double# parameters instead of the tuple.
The thin
Hi,
thanks for your input.
>You can get reasonable numeric performance out of GHC, but you need to
>work at it. There is some advice in the GHC manual at
>http://www.haskell.org/ghc/docs/latest/html/users_guide/faster.html
I am using -O2 and strictness already.
Currently i can only imagine t
hask...@kudling.de writes:
> Profiling says that the majority of the time is spend in "main". But i have
> no idea where.
> Can someone give me a hint?
Yes. Lots of them, but somehow, I suspect nobody tried your code.
> COST CENTRE MODULE
Yep, this program will crawl.
You can get reasonable numeric performance out of GHC, but you need to
work at it. There is some advice in the GHC manual at http://www.haskell.org/ghc/docs/latest/html/users_guide/faster.html
.
The first thing I would do is replace your
isInCircle :: (Floating
>> But you can remove sqrt from the C++ implementation as well, so it only
>> improves the relative performance if the C++ implementation of sqrt is
>> worse than its Haskell counterpart.
>
>Oops, of course I mean, you only improve if Haskell's implementation is
>worse than C++'s implementation :)
But you can remove sqrt from the C++ implementation as well, so it only
improves the relative performance if the C++ implementation of sqrt is
worse than its Haskell counterpart.
Oops, of course I mean, you only improve if Haskell's implementation is
worse than C++'s implementation :)
__
First thing I noticed, how about removing the sqrt in isInCircle:
isInCircle :: (Floating a, Ord a) => (a,a) -> Bool
isInCircle (x,y) = x*x + y*y <= 1.0
But you can remove sqrt from the C++ implementation as well, so it only
improves the relative performance if the C++ implementation of sqrt i
Hi,
i have compared a C++ implementation with a Haskell implementation of the Monte
Carlo Pi approximation:
http://lennart.kudling.de/haskellPi/
The Haskell version is 100 times slower and i wonder whether i do something
obvious wrong.
Profiling says that the majority of the time is spend in
On Mon, Jan 17, 2005 at 08:54:38PM -0800, Ben Rudiak-Gould wrote:
> If performance is the main concern, I would flatten the data structure:
>
>data Interval = IlII Double Double
> | IlIE Double Double
> | IlEI Double Double
> | IlEE Double Dou
Stijn De Saeger wrote:
>>data Bound = I Double | E Double deriving (Eq, Show, Ord)
>>data Interval = Il Bound Bound | Nil Bound Bound deriving (Eq,Ord)
>
>>isIn :: Double -> Interval -> Bool
>>isIn r (Nil x y) = not (isIn r (Il x y))
>>isIn r (Il (I x) (I y)) = r >= x && r <= y
>>isIn r (Il (I
Hello all,
A question on that most elusive of subjects performance in haskell (GHC 6.2)
Using the GHC profiler, I obtained the following analysis results (i
hope the code doesn't come out too ugly by mail):
total time =0.92 secs (46 ticks @ 20 ms)
total alloc = 83,
76 matches
Mail list logo
