develooper Front page | perl.perl5.porters | Postings from February 2013

Re: Perl 7 or Perl 2013?

Thread Previous | Thread Next
From:
Nicholas Clark
Date:
February 7, 2013 09:11
Subject:
Re: Perl 7 or Perl 2013?
Message ID:
20130207091112.GY5653@plum.flirble.org
On Wed, Feb 06, 2013 at 07:58:18PM -0500, bulk88 wrote:
> Note, I've grouped all my responses into 1 post for thread organization.

That's certainly something I find makes life easier. Thanks for doing this.

> mentality needs to stop. Seeing Perl 5.8 support questions online in 
> 2012 and 2013 says something is wrong. You don't see Windows 98/NT 4 
> support questions in 2013 (I searched a forum I visit for anecdotal 
> evidence, last NT 4 question 2006 (active directory), last win98 
> question 2008 (driver request)). Why are there still 5.8 questions?

Because it's the version shipped by various Linux vendors, on releases that
they still support commercially, and still have firms using them.
And rather a lot of firms, for whatever reason, feel a lot more comfortable
using the perl binary that (they think that) their vendor supports, than
building a current version from source, even though that current version
is more capable (and almost certainly faster*)

The lag isn't going to get any *better*, as (at least) Red Hat and Canonical
have announced that their commercial support window is at least a decade.

It's not just Perl that has this. A recent rather poorly researched article
blamed us for the fact that current Red Hat is shipping a version 5.10.
That same current Red Hat version is shipping Python 2.6.6
That's *not* even the current security release version 2.6.8.
And certainly not the version that Guido would like you to be running.
(That's 3.3. Obviously. Despite the fact that no release of Django supports
it yet. Nor does Twisted. Major Python frameworks haven't even caught up.)

I don't know what version of Ruby it ships (my informant didn't have it
installed) but it's probably 1.8.something.

Nicholas Clark

* Nearly every Linux vendor ships with ithreads enabled, which is a
  performance hit. Recompiling without ithreads will get you (probably) a
  30% speedup on older versions. If you need ithreads, compiling a newer
  version will *still* get you a speedup, because I patched things to reduce
  the overhead. You'll also get a faster runloop as of 5.14.0 (my fault, IIRC)
  and O(1) ISA lookups instead of O(n) as of 5.10.1 (my fault, IIRC).
  Plus a lot of the core SV structures as smaller, which should reduce cache
  pressure (my fault).
  As a side effect of this, I know I also inadvertently introduced bugs. Most
  of which I believe are fixed. It's not humanly possible to change this
  codebase without also making mistakes.

Thread Previous | Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About