>
> But we don't have, and may never have, one that is as fast and
> bug-free as pcre and that is compatible with pcre. The user
> of a library doesn't care whether it's written in Pascal or C.
True. But if native, it isn't a library but linked into the main (static)
binary, with all deployment
--- L <[EMAIL PROTECTED]> wrote:
> > >> Ok, now somebody has to fix the regexpr unit and accelerate it *g*
> > >
> > > The C program in the shootout uses pcre (Perl-compatible
> > > regular expressions). It would be very nice if FPC came
> > > with pcre.
> >
> > Well, that way we can never win
> >> Ok, now somebody has to fix the regexpr unit and accelerate it *g*
> >
> > The C program in the shootout uses pcre (Perl-compatible
> > regular expressions). It would be very nice if FPC came
> > with pcre.
>
> Well, that way we can never win :) Anyways, I think having an libc
> independent
--- Florian Klaempfl <[EMAIL PROTECTED]> wrote:
> S. Fisher schrieb:
> > --- Florian Klaempfl <[EMAIL PROTECTED]> wrote:
> >
> >
> >> Ok, now somebody has to fix the regexpr unit and accelerate it *g*
> >
> > The C program in the shootout uses pcre (Perl-compatible
> > regular expressions). I
> The C program in the shootout uses pcre (Perl-compatible
> regular expressions). It would be very nice if FPC came
> with pcre.
I am also looking to ship PCRE with Powtils too since TRegexp isn't the best in
all situations.
We wrapped Tregexp too:
http://z505.com/cgi-bin/powtils/docs/1.6/idx.c
> The compiler uses shortstrings internally, which are the fastest string
> type. Pchars are between ansistrings and strings, but offer the least
> comfort of all.
Also WordString or LongIntString would be as fast or faster than a 255
Bytestring..
But haven't implemented or supplied a patch yet ;
Daniël Mantione schrieb:
>
> Op Tue, 6 Nov 2007, schreef Florian Klaempfl:
>
>> S. Fisher schrieb:
>>> --- Florian Klaempfl <[EMAIL PROTECTED]> wrote:
>>>
>>>
Ok, now somebody has to fix the regexpr unit and accelerate it *g*
>>> The C program in the shootout uses pcre (Perl-compatible
>>> r
> Op Tue, 6 Nov 2007, schreef Florian Klaempfl:
> > S. Fisher schrieb:
> > > --- Florian Klaempfl <[EMAIL PROTECTED]> wrote:
> > >
> > >> Ok, now somebody has to fix the regexpr unit and
> accelerate it *g*
>
> If we want to win we could build in compler support and
> compile the regu
Op Tue, 6 Nov 2007, schreef Florian Klaempfl:
> S. Fisher schrieb:
> > --- Florian Klaempfl <[EMAIL PROTECTED]> wrote:
> >
> >
> >> Ok, now somebody has to fix the regexpr unit and accelerate it *g*
> >
> > The C program in the shootout uses pcre (Perl-compatible
> > regular expressions). It
S. Fisher schrieb:
> --- Florian Klaempfl <[EMAIL PROTECTED]> wrote:
>
>
>> Ok, now somebody has to fix the regexpr unit and accelerate it *g*
>
> The C program in the shootout uses pcre (Perl-compatible
> regular expressions). It would be very nice if FPC came
> with pcre.
Well, that way we c
--- Florian Klaempfl <[EMAIL PROTECTED]> wrote:
>
> Ok, now somebody has to fix the regexpr unit and accelerate it *g*
The C program in the shootout uses pcre (Perl-compatible
regular expressions). It would be very nice if FPC came
with pcre.
_
> The compiler uses shortstrings internally, which are the fastest string
> type. Pchars are between ansistrings and strings, but offer the least
> comfort of all.
With the exception that not having a compiler flag to check
shorstrings' overflows make for for some tricky to debug problems ;-)
-Fl
Op Tue, 6 Nov 2007, schreef L:
> The funny thing I see is everyone recommending Pchars. Why not
> setlength/uniquestring? Still too slow?
Memory management, especially when you get reallocations, is expensive.
With case ansistrings can perform well. However, you do have to care, and
Pchars ca
L schrieb:
There has been a long discussion on the Shootout forums about it. Isaac
believes that it is more fair this way for languages that don't have all
benchmarks implemented. Now we simply have to make him retract all our
poor performing programs :)
>>> Exactly. A not very
> > > There has been a long discussion on the Shootout forums about it. Isaac
> > > believes that it is more fair this way for languages that don't have all
> > > benchmarks implemented. Now we simply have to make him retract all our
> > > poor performing programs :)
> >
> > Exactly. A not very fa
On 11/6/07, S. Fisher <[EMAIL PROTECTED]> wrote:
>
> --- Dani�l Mantione <[EMAIL PROTECTED]> wrote:
>
> > > Is it true that a slow program has a worse effect on the shootout
> > > results than a missing program? That seems wrong to me.
> >
> > There has been a long discussion on the Shootout forum
--- Dani�l Mantione <[EMAIL PROTECTED]> wrote:
> > Is it true that a slow program has a worse effect on the shootout
> > results than a missing program? That seems wrong to me.
>
> There has been a long discussion on the Shootout forums about it. Isaac
> believes that it is more fair this wa
--- Peter Vreman <[EMAIL PROTECTED]> wrote:
> reasonable time. The updated source can be found in:
>
>
http://svn.freepascal.org/svn/fpc/trunk/tests/bench/shootout/src/regexdna.pp
>
> But the code is a lot slower than gcc so there is still a lot of
> performance tuning to do:
>
>
--- Marc Weustink <[EMAIL PROTECTED]> wrote:
> > if not GenerateRegExprEngine( target, [ref_caseinsensitive], engine)
> then
> > begin
> > writeln( 'Failed to generate regex. engine for "',target,'".' );
> > halt(1)
> > end;
>
> For this benchmark you don't need extra unneeded cod
--- Vincent Snijders <[EMAIL PROTECTED]> wrote:
> S. Fisher schreef:
> >
> > Is it true that a slow program has a worse effect on the shootout
> > results than a missing program? That seems wrong to me.
>
> To me is seems wrong too, but is nevertheless the case.
Right. A missing program shou
S. Fisher wrote:
--- Marco van de Voort <[EMAIL PROTECTED]> wrote:
http://shootout.alioth.debian.org/gp4/benchmark.php?test=all&lang=all
The reason is that D's mean degraded from 1.40 to 1.43. I wonder how
that could happen.
They change often. Clean is also quite variable. I assume the diffe
S. Fisher schreef:
Is it true that a slow program has a worse effect on the shootout
results than a missing program? That seems wrong to me.
To me is seems wrong too, but is nevertheless the case. Look carefully
at the scoring rules at
http://shootout.alioth.debian.org/gp4/benchmark.php?tes
Op Mon, 5 Nov 2007, schreef S. Fisher:
>
> --- Peter Vreman <[EMAIL PROTECTED]> wrote:
>
>
> > around. I have update the program to use a pchar instead of an ansistring
> > so it finishes within
> > reasonable time. The updated source can be found in:
> >
> >
> http://svn.freepascal.org/svn/
--- Peter Vreman <[EMAIL PROTECTED]> wrote:
> around. I have update the program to use a pchar instead of an ansistring
> so it finishes within
> reasonable time. The updated source can be found in:
>
>
http://svn.freepascal.org/svn/fpc/trunk/tests/bench/shootout/src/regexdna.pp
>
> But the co
On Mon, 5 Nov 2007, Florian Klaempfl wrote:
> Peter Vreman schrieb:
> > I submitted this regex-dna program on 2007-10-31. It's still in limbo:
> > neither accepted nor rejected.
> Thanks, I've added it to the fpc repository so the source will not be
> >>> lost
> >>>
> >>> For me th
Peter Vreman schrieb:
> I submitted this regex-dna program on 2007-10-31. It's still in limbo:
> neither accepted nor rejected.
Thanks, I've added it to the fpc repository so the source will not be
>>> lost
>>>
>>> For me the code didn't finish in a reasonable time. It spend too much
>> >> I submitted this regex-dna program on 2007-10-31. It's still in limbo:
>> >> neither accepted nor rejected.
>> >
>> > Thanks, I've added it to the fpc repository so the source will not be
>> lost
>>
>> For me the code didn't finish in a reasonable time. It spend too much time
>> in moving an
--- Peter Vreman <[EMAIL PROTECTED]> wrote:
> >>
> >> --- Marco van de Voort <[EMAIL PROTECTED]> wrote:
> >>
> >>> > http://shootout.alioth.debian.org/gp4/benchmark.php?test=all&lang=all
> >>> >
> >>> > The reason is that D's mean degraded from 1.40 to 1.43. I wonder how
> >>> > that could happe
>>
>> --- Marco van de Voort <[EMAIL PROTECTED]> wrote:
>>
>>> > http://shootout.alioth.debian.org/gp4/benchmark.php?test=all&lang=all
>>> >
>>> > The reason is that D's mean degraded from 1.40 to 1.43. I wonder how
>>> > that could happen.
>>>
>>> They change often. Clean is also quite variable.
>
> --- Marco van de Voort <[EMAIL PROTECTED]> wrote:
>
>> > http://shootout.alioth.debian.org/gp4/benchmark.php?test=all&lang=all
>> >
>> > The reason is that D's mean degraded from 1.40 to 1.43. I wonder how
>> > that could happen.
>>
>> They change often. Clean is also quite variable. I assume
S. Fisher schreef:
--- Florian Klaempfl <[EMAIL PROTECTED]> wrote:
S. Fisher schrieb:
--- Marco van de Voort <[EMAIL PROTECTED]> wrote:
http://shootout.alioth.debian.org/gp4/benchmark.php?test=all&lang=all
The reason is that D's mean degraded from 1.40 to 1.43. I wonder how
that could happ
--- Florian Klaempfl <[EMAIL PROTECTED]> wrote:
> S. Fisher schrieb:
> > --- Marco van de Voort <[EMAIL PROTECTED]> wrote:
> >
> >>> http://shootout.alioth.debian.org/gp4/benchmark.php?test=all&lang=all
> >>>
> >>> The reason is that D's mean degraded from 1.40 to 1.43. I wonder how
> >>> that
S. Fisher schrieb:
> --- Marco van de Voort <[EMAIL PROTECTED]> wrote:
>
>>> http://shootout.alioth.debian.org/gp4/benchmark.php?test=all&lang=all
>>>
>>> The reason is that D's mean degraded from 1.40 to 1.43. I wonder how
>>> that could happen.
>> They change often. Clean is also quite variable
--- Marco van de Voort <[EMAIL PROTECTED]> wrote:
> > http://shootout.alioth.debian.org/gp4/benchmark.php?test=all&lang=all
> >
> > The reason is that D's mean degraded from 1.40 to 1.43. I wonder how
> > that could happen.
>
> They change often. Clean is also quite variable. I assume the diff
Marco van de Voort schreef:
http://shootout.alioth.debian.org/gp4/benchmark.php?test=all&lang=all
The reason is that D's mean degraded from 1.40 to 1.43. I wonder how
that could happen.
They change often. Clean is also quite variable. I assume the differences
are simply in the magnitude of th
They change often. Clean is also quite variable. I assume the differences
are simply in the magnitude of the uncertainty of the measuring.
No, I don't think so. I think it depends on weight you give to each
benchmark. I always set all weight to 1 and consistently I got fpc
always on the first
> http://shootout.alioth.debian.org/gp4/benchmark.php?test=all&lang=all
>
> The reason is that D's mean degraded from 1.40 to 1.43. I wonder how
> that could happen.
They change often. Clean is also quite variable. I assume the differences
are simply in the magnitude of the uncertainty of the me
http://shootout.alioth.debian.org/gp4/benchmark.php?test=all&lang=all
The reason is that D's mean degraded from 1.40 to 1.43. I wonder how
that could happen.
__
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://
38 matches
Mail list logo
