--- 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
Hi,
Micha Nelissen wrote:
function evk_malloc (size: longword): pointer;
const
ALIGNMENT = 16;
var
ptr: pointer;
begin
ptr := getmem(size + ALIGNMENT);
result := Align (ptr, ALIGNMENT);
if result = ptr then
pbyte(result) += 16;
Why not use ALIGNMENT here also?
Hah, I got stu
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
David Pethes wrote:
> pointer. So I mixed the two codes and come with something like this:
>
> function evk_malloc (size: longword): pointer;
> const
> ALIGNMENT = 16;
> var
> ptr: pointer;
> begin
> ptr := getmem(size + ALIGNMENT);
> result := Align (ptr, ALIGNMENT);
> if result = ptr t
--- 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
Is there a way in the fpc.cfg file to detect what platform the (arm) cross
compiler is running on (not the target platform).
I want to do one thing when compiling on a win32 platform and another
thing when compiling on a Linux platform (commands to the linker and the
-Tlinux command on the win32 p
Hi,
I'm writing a video codec. I need some of my memory aligned to 16-byte
boundaries, since I'm using SSE2 instructions in asm code, that assume
this alignment. I was using a custom getmem, that called classic getmem
to get some memory block, then cast the pointer and adjust it to next
aligne
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://
26 matches
Mail list logo
