On Thursday 17 April 2008 12:35:42 Andy Dougherty wrote:
> If optimized builds are to be the default, however, someone needs to
> either hunt down and fix all the wrong attribute_null decorations, or
> apply a patch similar in spirit to the one I proposed in
>
> [PATCH] Re: [perl #50684] String F
On Thu, 2008-04-17 at 15:35 -0400, Andy Dougherty wrote:
> If optimized builds are to be the default, however, someone needs to
> either hunt down and fix all the wrong attribute_null decorations, or
> apply a patch similar in spirit to the one I proposed in
>
> [PATCH] Re: [perl #50684] String
If optimized builds are to be the default, however, someone needs to
either hunt down and fix all the wrong attribute_null decorations, or
apply a patch similar in spirit to the one I proposed in
[PATCH] Re: [perl #50684] String Failures with -O2 (GCC 4.1.3, 32-bit x86
Linux)
Otherwise core d
On Wed, 2008-04-16 at 09:47 +0100, Tim Bunce wrote:
> I agree with Geoffrey that optimized builds should be the default.
Thank you!
> Developers working on parrot (wanting unoptimized/debug quick builds)
> would just need to set an env var in their .profile, for example, and
> carry on as now. N
Tim Bunce wrote:
I'd suggest a simpler approach than Geoffrey's: The default 'make'
target could default to a reasonably safe portable optimized target, but
be overridable by an env var.
[snip]
Developers working on parrot (wanting unoptimized/debug quick builds)
would just need to set an env
On Wed, Apr 16, 2008 at 12:10:54AM +0200, Leopold Toetsch wrote:
> Am Freitag, 11. April 2008 21:02 schrieb Nuno 'smash' Carvalho:
> > Greetings all,
> >
> > I just posted a little Parrot benchmark in my use.perl's journal
>
> Just a reminder:
>
> Please don't use unoptimzed builds for benchmark
On Wed, 2008-04-16 at 00:10 +0200, Leopold Toetsch wrote:
> Am Freitag, 11. April 2008 21:02 schrieb Nuno 'smash' Carvalho:
> > Greetings all,
> >
> > I just posted a little Parrot benchmark in my use.perl's journal
>
> Just a reminder:
>
> Please don't use unoptimzed builds for benchmarking. Th
Am Freitag, 11. April 2008 21:02 schrieb Nuno 'smash' Carvalho:
> Greetings all,
>
> I just posted a little Parrot benchmark in my use.perl's journal
Just a reminder:
Please don't use unoptimzed builds for benchmarking. There are a lot of code
asserts and other slowdowns due to compiler goodwil
On Mon, Apr 14, 2008 at 10:07:14AM +0100, Alberto Simoes wrote:
> Bob Rogers wrote:
> > From: Alberto Simoes <[EMAIL PROTECTED]>
> > >3. A semi-log plot would be easier to interpret.
> >
> > Smash tried a log plot, but it wasn't easier to interpret. I am not
> > sure what is a semi-log
Bob Rogers wrote:
From: Alberto Simoes <[EMAIL PROTECTED]>
Date: Sun, 13 Apr 2008 19:16:39 +0100
This is my fault. I prefer smooth curves.
But I think smash can include the gplot data together with the source code.
That would be ideal.
>3. A semi-log plot would be easier
On Sun, 2008-04-13 at 14:35 -0700, chromatic wrote:
> As well, the optimizations I recommend for Parrot (if you want to use
> optimization flags) are:
>
> -O2, to choose the fastest available runcore
Not so, unless this has been fixed without resolving the RT bug:
http://rt.perl.org/rt3//
From: Alberto Simoes <[EMAIL PROTECTED]>
Date: Sun, 13 Apr 2008 19:16:39 +0100
This is my fault. I prefer smooth curves.
But I think smash can include the gplot data together with the source code.
That would be ideal.
>3. A semi-log plot would be easier to interpret.
Smas
Bob Rogers wrote:
From: "Nuno 'smash' Carvalho" <[EMAIL PROTECTED]>
Date: Sun, 13 Apr 2008 18:57:26 +0100
Greetings all,
We did another Parrot benchmarking, this time using a common
programming technique: recursion. We created a function to calculate
From: chromatic <[EMAIL PROTECTED]>
Date: Sun, 13 Apr 2008 14:35:11 -0700
. . .
If they're stable (and they're not always perfectly stable), -Oc should
improve the recursion benchmark.
-- c
AFAICS, there are no calls in tail position, and hence no opportunity
for tailcall opt
On Sunday 13 April 2008 10:57:26 Nuno 'smash' Carvalho wrote:
> We did another Parrot benchmarking, this time using a common
> programming technique: recursion. We created a function to calculate
> the number of nodes in a full binary tree given the tree's height. I
>
On Sun, Apr 13, 2008 at 07:21:06PM +0100, Nuno 'smash' Carvalho wrote:
> On Sun, Apr 13, 2008 at 7:06 PM, Patrick R. Michaud <[EMAIL PROTECTED]> wrote:
> >
> > On Sun, Apr 13, 2008 at 06:57:26PM +0100, Nuno 'smash' Carvalho wrote:
> > > G
On Sun, Apr 13, 2008 at 7:13 PM, Bob Rogers
<[EMAIL PROTECTED]> wrote:
>From: "Nuno 'smash' Carvalho" <[EMAIL PROTECTED]>
>Date: Sun, 13 Apr 2008 18:57:26 +0100
>
>
>
>Greetings all,
>
> We did another Parrot benchmark
On Sun, Apr 13, 2008 at 7:06 PM, Patrick R. Michaud <[EMAIL PROTECTED]> wrote:
>
> On Sun, Apr 13, 2008 at 06:57:26PM +0100, Nuno 'smash' Carvalho wrote:
> > Greetings all,
> >
> > We did another Parrot benchmarking, this time using a common
> >
From: "Nuno 'smash' Carvalho" <[EMAIL PROTECTED]>
Date: Sun, 13 Apr 2008 18:57:26 +0100
Greetings all,
We did another Parrot benchmarking, this time using a common
programming technique: recursion. We created a function to calculate
the number of n
On Sun, Apr 13, 2008 at 06:57:26PM +0100, Nuno 'smash' Carvalho wrote:
> Greetings all,
>
> We did another Parrot benchmarking, this time using a common
> programming technique: recursion. We created a function to calculate
> the number of nodes in a full binary tree g
Greetings all,
We did another Parrot benchmarking, this time using a common
programming technique: recursion. We created a function to calculate
the number of nodes in a full binary tree given the tree's height. I
guess this time the results where not so satisfactory, for Parrot. You
can se
On Fri, Apr 11, 2008 at 8:55 PM, Nuno 'smash' Carvalho <[EMAIL PROTECTED]>
wrote:
> On Fri, Apr 11, 2008 at 8:18 PM, chromatic <[EMAIL PROTECTED]> wrote:
> > On Friday 11 April 2008 12:02:23 Nuno 'smash' Carvalho wrote:
> >
> > > I just posted a little Parrot benchmark in my use.perl's journa
On Fri, Apr 11, 2008 at 08:56:32PM +0100, Nuno 'smash' Carvalho wrote:
> On Fri, Apr 11, 2008 at 8:38 PM, Patrick R. Michaud <[EMAIL PROTECTED]> wrote:
> > On Fri, Apr 11, 2008 at 08:02:23PM +0100, Nuno 'smash' Carvalho wrote:
> > > Greetings all,
> > >
> > > I just posted a little Parrot bench
On Fri, Apr 11, 2008 at 8:38 PM, Patrick R. Michaud <[EMAIL PROTECTED]> wrote:
> On Fri, Apr 11, 2008 at 08:02:23PM +0100, Nuno 'smash' Carvalho wrote:
> > Greetings all,
> >
> > I just posted a little Parrot benchmark in my use.perl's journal that
> > i think it would be interesting for every
On Fri, Apr 11, 2008 at 8:18 PM, chromatic <[EMAIL PROTECTED]> wrote:
> On Friday 11 April 2008 12:02:23 Nuno 'smash' Carvalho wrote:
>
> > I just posted a little Parrot benchmark in my use.perl's journal that
> > i think it would be interesting for everyone to take a look. From my
> > point of
On Fri, Apr 11, 2008 at 08:02:23PM +0100, Nuno 'smash' Carvalho wrote:
> Greetings all,
>
> I just posted a little Parrot benchmark in my use.perl's journal that
> i think it would be interesting for everyone to take a look.
Excellent! Is this benchmark pure PIR, or coming from a HLL
language
On Friday 11 April 2008 12:02:23 Nuno 'smash' Carvalho wrote:
> I just posted a little Parrot benchmark in my use.perl's journal that
> i think it would be interesting for everyone to take a look. From my
> point of view Parrot finished in a very comfortable place between
> compiled and interpret
Greetings all,
I just posted a little Parrot benchmark in my use.perl's journal that
i think it would be interesting for everyone to take a look. From my
point of view Parrot finished in a very comfortable place between
compiled and interpreted languages. I've made the benchmarking very
easy to r
28 matches
Mail list logo
