On Thu, 29 Mar 2001 06:53:49 +0200, Otto Wyss [EMAIL PROTECTED] wrote:
- Make readability your main objective. Readability is possibly the
weakest part of Perl.
- Keep your eyes on modularity. Modularity is by far the best concept
where complexity could be hidden.
- Don't
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
Nicely put, Merijn.
Stomping into (any) programming language camp and telling loudly that
what you are doing is wrong is a bit like stomping into a Mongol camp
and asking what's up with the funny fur hats.
Or, in the of case Perl, accusing us of too much line noise and being
too hard to read,
Quoting [EMAIL PROTECTED]:
:I'm choosing a new language only if is suitable for most of my tasks and
:these range from the 10 line script up to several million line project.
:Currently Perl is rather capable for any small scripting task but it's
:out of questions if there are more than 2 person
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 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
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.)
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 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 06:53 AM 3/29/2001 +0200, Otto Wyss wrote:
It seems you are not interested in critics, so lets end this thread.
More to the point, I said let it rest, so the thread should end. Now. And
this means *everyone*.
Thank you.
Dan
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
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
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
-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
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 optimizer will
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:
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
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
attribute
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 gcc, which
"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
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
24 matches
Mail list logo
