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.
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 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
[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
20 matches
Mail list logo
