Browse files

Add LICENSE, finish 2012-09-10 summary

  • Loading branch information...
1 parent 21fb46d commit 4509d3ae0f337f9113c46a05dc323f28ab1ec07f @mrallen1 committed Sep 24, 2012
Showing with 487 additions and 4 deletions.
  1. +173 −4 2012/09/
  2. +314 −0 LICENSE
@@ -4,7 +4,11 @@ Perl 5 Porters Weekly: September 10-September 16, 2012
Welcome to Perl 5 Porters Weekly, a summary of the email traffic on
the perl5-porters email list. Once again subroutine signatures dominated
the list. I'll put all of the discussion about them at the end of this
+summary. I've added an "official" license to these summaries. It's
+[Creative Commons BY-NC 3.0][License]. You can find the summary of rights
+granted by that license by following that link. The full license text is
+available in the [github repo][github]. Obviously, the content of emails
+quoted here are owned by their respective authors.
This week's dusty thread is [CALL FOR DOCS: how to dual life?][1] from the
week of August 6, 2012. Rik was looking for a volunteer to document the
@@ -118,10 +122,174 @@ objects into the core (someday.)
**Named prototypes (again)**
-I O U a summary to be named later
+Recall that [last week][], there was a big technical discussion about what the
+default behavior for a subroutine signature (aka named prototype) ought to
+be. Some argued for a read-only alias to @\_, and some argued for a
+read-write copy following the principle of least surprise, and still others
+argued for read-write aliases which would eliminate the overhead of @\_ setup.
+Nicholas Clark answered:
+ Perl 6 specifies that the default is an alias (to avoid a copy, for
+ speed) and read-only (for the least surprise):
+ In an ideal world these seem sane defaults, because they are made for
+ sane reasons. We're not *confident* that we are able to implement
+ read-only aliases (of read-write values). But
+ a) Chip had proposed a working patch
+ b) And asked for help measuring its impact
+ c) No-one helped.
+ So a good start here would be for SOMEONE TO VOLUNTEER to help get that
+ restarted. To at least get an answer to "is this approach going to
+ work?" (and possibly "does it look likely that no approach would work?")
+But, Ricardo Signes wrote just a bit later that:
+ The reasonable default is copy, because decades of Perl programming have
+ told us that our arguments are copies. That is, as was said elsewhere
+ in this thread, we'd codifying existing patterns here.
+Which seems to be the dispostive word on the matter. Chip Salzenberg added:
+ I agree here for four reasons:
+ 1. Rik is right
+ 2. Copies happen a lot; we'd be better off making copies faster (and
+ use less memory) than making them rarer or (as I once thought was a
+ good idea) introducing readonly aliases
+ 3. I already have a patch half-done, the "minimal copy" patch, to make
+ copies smaller; I haven't gotten round tuition for them but I have
+ high expectation of having them ready for 5.18
+ 4. It's possible to keep small strings in bodiless SVs, or making COW
+ good (if it isn't), which also makes copying cheaper
+Later, Jesse Luehrs applied the patch in question (which creates read-only
+aliases to $_[0], etc) to measure its impact as Nicholas asked above and
+reported that:
+ [P]reliminary benchmarks don't look promising:
+ Current:
+ ./perl -Ilib lib/unicore/mktables -C lib/unicore -P pod -maketest
+ -makelist - 14.40s user 0.10s system 99% cpu 14.565 total
+ With SVt_BIND patch:
+ ./perl -Ilib lib/unicore/mktables -C lib/unicore -P pod -maketest
+ -makelist - 16.23s user 0.09s system 99% cpu 16.372 total
+ Copies might actually turn out to be faster than read-only aliases,
+ given the way the perl 5 interpreter is implemented.
+There was also a serious digression that took on a life of its own, mostly
+revolving around how P5P interacts with feature suggestions, commentary on
+the same, and how the Perl community ought to spend more effort on
+performance enhancements than new shinies.
+David Golden wrote:
+ [M]any people on p5p express dissatisfaction with the status quo
+ [ed. about performance], yet are unable or unwilling to:
+ (a) climb up the learning curve to contribute effectively
+ (b) take on less demanding tasks, freeing up the time of experts
+ Until more people do (a) or (b), the "hard" problems will continue to
+ suffer a lack of tuits.
+Nicholas Clark added:
+ There are SIX HUNDRED subscribers to the list. About SIXTY are active in
+ e-mail discussions. Of the order of SIX people actually commit stuff.
+ And yet somehow the sixty (plus) seem to assume that if an idea is worth
+ talking about *to death* then somehow that is enough to steer the six
+ (busy) people into acting upon it.
+ If one looks at the archives from (say) 2003 compared with 2012
+ one notices two things
+ 1: 2003 has many more medium sized threads
+ 2012 has either massive threads, or messages with ZERO or one reply
+ 2: 2003 has far more discussion of code
+ People cared just as much about perl then. But more people helped do
+ things.
+ I'd like us to get back to that. I don't know how.
+Peter Rabbitson argued that p5p ought to more carefully weigh the impact of
+adding features to core since the Perl core has been famously reluctant to
+remove bits of the language.
+ [T]he level of scrutiny before inclusion does not seem to match the fact
+ that perl5 does not have a backtrack mechanism. I do not know what
+ would constitute "enough" scrutiny. I just know (based on past
+ achievements) that we do not scrutinize new syntax enough.
+To support the claim that Perl's performance has deteriorated over time,
+[Steffen Schwigon][perf] posted some summaries of his work comparing Perl
+version X vs. Perl version Y doing fibonacci sequence generation. He
+ fib (plain subs) in Perl is ~2500x slower than symmetric
+ implementation with C
+ - C comparison not part of Perl::Formance, done separately
+ * fibOO (selfmade/Moose/Mouse) is ~1.5x slower than plain subs
+ * fibMXDeclare is about ~500x times slower than plain subs.
+ - yes, that's 120000 times slower than C, sorry.
+ - but probably due to some follow-up effects like huge mem triggering
+ swapping or similar
+ - anyway, the number itself is not an artifact or mistake, it's
+ stable over different Perl versions, it's a complete mess,
+ therefore I don't run it often
+ Trends, still fibonacci:
+ * Perl 5.10 to 5.14 improved a runtime of 90s down to 76s.
+ * Perl 5.16 deteriorated back to ~90s runtime.
+ * The overhead of "threaded" over "non-threaded"
+ ... was in 5.10 ~5% more time
+ ... got worse in 5.12 to ~15% more time
+ ... improved in 5.14 to nearly zero
+ ... and is now back worse in 5.16 with ~20% more time
+ * I don't have conclusive 5.17.x numbers due to current issues, but
+ first experiments seem to indicate a trend towards more slowness.
+Dave Mitchell wrote (not specifically in reply to the above):
+ The idea that p5p doesn't care about, nor does anything related to
+ performance, is a bit of a myth. There have been lots of optimisations
+ added over the years. These tend to be low-key affairs: no major new
+ language syntax, nor porting to shiny new VMs etc (that's what the perl6
+ effort is for); but in many small, but accumulative ways we've been
+ fixing things. E.g. regex Tries; reorganising SV structures so they're
+ smaller and quicker.
+ I think the net affect of these efforts is that we've managed to
+ generally avoid perl5 slowing down any further over years as new
+ features and bug fixes have been added (which would normally have the
+ accumulative effect of gradually slowing things down).
+[Read the thread][10]
[avoid csh]:
@@ -131,5 +299,6 @@ I O U a summary to be named later
+[last week]:
Oops, something went wrong.

0 comments on commit 4509d3a

Please sign in to comment.