At 03:38 PM 3/29/2001 -0800, David Whipp wrote:
> > From: Dan Sugalski [mailto:[EMAIL PROTECTED]]
> > I'm hoping to have this stage of optimization in perl. Off by
> > default with
> > a normal parse-and-go run (though certainly enableable if you
> > want), on by
> > default with the bytecode comp
Dan Sugalski wrote:
>
> At 02:52 PM 3/29/2001 -0800, Russ Allbery wrote:
> >James Mastros <[EMAIL PROTECTED]> writes:
> >
> > > Ahh, bingo. That's what a number of people (inculding me) are
> > > suggesting -- a :functional / :pure / :stateless /
> > > :somthingelseIdontrecall attribute attachab
> From: Dan Sugalski [mailto:[EMAIL PROTECTED]]
> I'm hoping to have this stage of optimization in perl. Off by
> default with
> a normal parse-and-go run (though certainly enableable if you
> want), on by
> default with the bytecode compiler.
Don't forget about run-time information: You coul
At 06:22 PM 3/29/2001 -0500, Uri Guttman wrote:
> > "DS" == Dan Sugalski <[EMAIL PROTECTED]> writes:
>
> >> This will probably be harder in Perl than in C because C can afford to
> >> take more time to do global optimization passes.
>
> DS> I'm hoping to have this stage of optimization i
> "DS" == Dan Sugalski <[EMAIL PROTECTED]> writes:
>> This will probably be harder in Perl than in C because C can afford to
>> take more time to do global optimization passes.
DS> I'm hoping to have this stage of optimization in perl. Off by
DS> default with a normal parse-and-go ru
At 02:52 PM 3/29/2001 -0800, Russ Allbery wrote:
>James Mastros <[EMAIL PROTECTED]> writes:
>
> > Ahh, bingo. That's what a number of people (inculding me) are
> > suggesting -- a :functional / :pure / :stateless /
> > :somthingelseIdontrecall attribute attachable to a sub.
>
>The experience from
James Mastros <[EMAIL PROTECTED]> writes:
> Ahh, bingo. That's what a number of people (inculding me) are
> suggesting -- a :functional / :pure / :stateless /
> :somthingelseIdontrecall attribute attachable to a sub.
The experience from gcc, which has a similar attribute, is that such an
attrib
Dan Sugalski <[EMAIL PROTECTED]> writes:
> Aliasing is actually one of the bigger problems with C, or so I'm lead
> to believe. It gets in the way of a number of optimizations rather
> badly. (So say some of Compaq's C and Fortran compiler folks, and I have
> no reason to doubt them. The Fortran
At 10:57 PM 3/29/2001 +0100, Piers Cawley wrote:
>How painful would an 'potential' optimization that marked that area in
>the bytecode/optree/whatever, with something along the lines of the
>following be?
>
> If you get to this point and $i is not tied, and '=' is not
> overridden for $i's
Dan Sugalski <[EMAIL PROTECTED]> writes:
> True enough. This is a small subset of general optimizations. For example,
> this:
>
>
>$i = 0;
>foreach (1..1000) {
> $i++;
>}
>
> can be easily optimized to:
>
>$i = 1000;
>
> and most language implementations with any sort of o
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Thu, 29 Mar 2001 10:36:48 -0800, "Hong Zhang" <[EMAIL PROTECTED]>
wrote:
> The function in Ada can not have any side effect, i.e. no change to
> globals.
Unless my reading of the Ada 95 standard is wrong, there's nothing
that precludes function
On Thu, Mar 29, 2001 at 10:36:48AM -0800, Hong Zhang wrote:
> I have to say that I agree to disagree. Since it has been so controversal,
> I just don't think this optimization is a good one.
Hmm, we aren't talking sort() specificly anymore. Look at the subject line.
> The function in Ada can no
> >Who really needs this kind of optimization for Perl?
>
> I do. Lots of people with web apps do. Pretty much anyone with a large or
> long-running perl program does.
I have to say that I agree to disagree. Since it has been so controversal,
I just don't think this optimization is a good one.
>
On Thu, Mar 29, 2001 at 11:29:16AM -0500, Dan Sugalski wrote:
> At 05:19 PM 3/29/2001 +0100, Dave Mitchell wrote:
> >Jarkko Hietaniemi <[EMAIL PROTECTED]> wrote:
> > > Somewhat tangentially: this reminds me of a message a week ago or so
> > > (can't find it anymore in my inbox) which proposed writ
At 03:41 PM 3/28/2001 -0800, Hong Zhang wrote:
>Are we over-optimizing? The Perl is just an interpreter language.
Perl's not just an interpreter language, and hasn't been for a while.
(Granted the bytecode compiler's not fully functional, but it does work in
some cases)
>Who really needs this
At 05:19 PM 3/29/2001 +0100, Dave Mitchell wrote:
>Jarkko Hietaniemi <[EMAIL PROTECTED]> wrote:
> > Somewhat tangentially: this reminds me of a message a week ago or so
> > (can't find it anymore in my inbox) which proposed writing C (or C++)
> > code for Perl 6 so that "modern CPU architectures a
At 10:25 AM 3/29/2001 -0500, James Mastros wrote:
>On Wed, Mar 28, 2001 at 03:41:42PM -0800, Hong Zhang wrote:
> > Are we over-optimizing? The Perl is just an interpreter language.
> > Who really needs this kind of optimization for Perl? Even C does
> > not provide this feature.
>Umm, art thou sur
Dave Mitchell wrote:
> The main thrust of that was whether a PDD on coding conventions
> should have sections on:
>...
> * Performance guidelines
>
> ...I guess we can safely dispense with that last entry.
No, performance guidelines are probably still appropriate;
but doing hand-coded peephole o
Jarkko Hietaniemi <[EMAIL PROTECTED]> wrote:
> Somewhat tangentially: this reminds me of a message a week ago or so
> (can't find it anymore in my inbox) which proposed writing C (or C++)
> code for Perl 6 so that "modern CPU architectures are happy" (no
> pipeline stalls because of "if"-s, etc.)
Jarkko Hietaniemi wrote:
> ... proposed writing C (or C++)
> code for Perl 6 so that "modern CPU architectures are happy" (no
> pipeline stalls because of "if"-s, etc.) ... in
> general, for large codebases, the C compilers are much, much,
> better in optimizing than humans.
I totally agree. Th
On Thu, Mar 29, 2001 at 10:25:06AM -0500, James Mastros wrote:
> On Wed, Mar 28, 2001 at 03:41:42PM -0800, Hong Zhang wrote:
> > Are we over-optimizing? The Perl is just an interpreter language.
> > Who really needs this kind of optimization for Perl? Even C does
> > not provide this feature.
> U
On Wed, Mar 28, 2001 at 03:41:42PM -0800, Hong Zhang wrote:
> Are we over-optimizing? The Perl is just an interpreter language.
> Who really needs this kind of optimization for Perl? Even C does
> not provide this feature.
Umm, art thou sure? C can optimize better then we currently do many times
On Wed, 28 Mar 2001 11:11:20 -0500, Dan Sugalski wrote:
> "Can perl automatically optimize away function and tie calls inside
>a sort function, and under what circumstances?"
>
>It doesn't really matter if the functions inside the sort function are
>idempotent--what matters is whether it's
ki" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Wednesday, March 28, 2001 3:01 PM
Subject: Re: What can we optimize (was Re: Schwartzian transforms)
> On Wed, Mar 28, 2001 at 05:57:30PM -0500, James Mastros wrote:
> > [A bunch of stuff]
> Oh, and I agree with
On Wed, Mar 28, 2001 at 05:57:30PM -0500, James Mastros wrote:
> [A bunch of stuff]
Oh, and I agree with sombody else on this thread that unless otherwise
stated, the sort should always assume statelessness (and thus the ability to
cache at will). If it's trivial to see that the sort function isn
On Wed, Mar 28, 2001 at 04:36:58PM -0500, Dan Sugalski wrote:
> With perl, though, this does
> potentially unexpected things if $i is tied. Do we still optimize it away?
> Do we only do it if we can tell that $i's not tied?
Yep. And in non-trivial cases, the only way to do that might be for $i
At 01:22 PM 3/28/2001 -0800, Russ Allbery wrote:
>Dan Sugalski <[EMAIL PROTECTED]> writes:
>
> > I'm actually considering whether we even need to care what the
> > programmer's said. If we can just flat-out say "We may optimize your
> > sort function, and we make no guarantees as to the number of
Russ Allbery wrote:
> I'd really like to see a concrete example of a sane sorting function which
> cannot be memoized. (Issues of syntax aside; just caching the result of
> comparing any two pairs of data results in caching data that a sane
> sorting algorithm will never use again.
Well, we se
> From: Russ Allbery [mailto:[EMAIL PROTECTED]]
> >we can just flat-out say "We may optimize your
> > sort function"
>
> I am strongly in favor of that approach. I see no reason to allow for
> weird side effects in Perl 6.
Let me second the motion. "Allow optimisation" should be the default. A
John Porter <[EMAIL PROTECTED]> writes:
> If the user-supplied key extraction function is tagged with
> :function/:pure (or whatever), then perl is free to optimize
> the operation of sort() by memoizing the results of calls to
> that function.
I'd really like to see a concrete example o
Dan Sugalski <[EMAIL PROTECTED]> writes:
> I'm actually considering whether we even need to care what the
> programmer's said. If we can just flat-out say "We may optimize your
> sort function, and we make no guarantees as to the number of times tied
> data is fetched or subs inside the sort sub
Since I'm supposed to be summarizing this thread for Simon's weekly write-up,
let me make sure I have the four(?) basic suggestions/stances.
1) There are too many variations/problems/issues to bother having Perl try to
handle them all. If folks want an optimized sort, they should continue to
At 11:59 AM 3/28/2001 -0500, John Porter wrote:
>Dan Sugalski wrote:
> >...
> > subs inside the sort sub are called" then life becomes much easier.
>
>Easier for perl. Don't we want to make life easier for the programmer?
>I mean, in general, it would be nice if there were a way to have
>perl mem
On Wed, Mar 28, 2001 at 11:59:19AM -0500, John Porter wrote:
> I mean, in general, it would be nice if there were a way to have
> perl memoize for us, rather than have to arrange it ourself.
Again with the over-specific solutions! What you seem to want is for
(for instance)
sub foo :memoize
Dan Sugalski wrote:
>...
> subs inside the sort sub are called" then life becomes much easier.
Easier for perl. Don't we want to make life easier for the programmer?
I mean, in general, it would be nice if there were a way to have
perl memoize for us, rather than have to arrange it ourself.
It c
On Wednesday 28 March 2001 11:47, Dan Sugalski wrote:
> At 11:22 AM 3/28/2001 -0500, John Porter wrote:
> >Dan Sugalski wrote:
> > > It doesn't really matter if the functions inside the sort function are
> > > idempotent--what matters is whether it's OK for us to go and memoize
> > > the things (o
James Mastros wrote:
> I'm of the opinion that we should consider 3 to be Just Plain Silly and not
> worth worring about overmuch.
AFAICT, you're worrying about everything overmuch.
It suffices, I believe, to put the following contract on the
sort() function:
If the user-supplied comparison
At 11:22 AM 3/28/2001 -0500, John Porter wrote:
>Dan Sugalski wrote:
> > It doesn't really matter if the functions inside the sort function are
> > idempotent--what matters is whether it's OK for us to go and memoize the
> > things (or whatever else we might choose to do)
>
>Exactly, that's what I
On Wed, Mar 28, 2001 at 11:11:20AM -0500, Dan Sugalski wrote:
>"Can perl automatically optimize away function and tie calls inside
> a sort function, and under what circumstances?"
Agreed.
> It doesn't really matter if the functions inside the sort function are
> idempotent--what matters
Dan Sugalski wrote:
> It doesn't really matter if the functions inside the sort function are
> idempotent--what matters is whether it's OK for us to go and memoize the
> things (or whatever else we might choose to do)
Exactly, that's what I've been trying to say.
And that's why I propose the :c
40 matches
Mail list logo
