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 compiler.
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 attachable to a sub.
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 OK
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
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 sure? C
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 are
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,
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
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.
G
The function in Ada can not
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.
Umm, art
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 writing C (or
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. That
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.)
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.
C
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 could
-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 functions
"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 run (though
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 in perl. Off by
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 is
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've been
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
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
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 times
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
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
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 are
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 of a
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
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
[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 sombody else on this thread that unle
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
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 memoize for
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
33 matches
Mail list logo
