develooper Front page | perl.perl5.porters | Postings from March 2021

Re: RFC / POC - more than 32 features

Thread Previous | Thread Next
From:
Philip R Brenan
Date:
March 24, 2021 22:04
Subject:
Re: RFC / POC - more than 32 features
Message ID:
CALhwFR=004ZdJm9-kmRoHAbPpPJ6TBu108tsueKin6RJ=Lf3Zg@mail.gmail.com
Please allow me to propose that the proposition that "the CPU cache will be
overwhelmed" is one that should be tested with running code.

If users wish to explore new territory they might well encounter new bugs:
fortunately there is a well defined way for reporting them.  If they prefer
to stay on "the primrose path of dalliance" and  "bear those ills we have
rather than fly to others that we know not of" then they will get all the
usual bugs aka features that we have worked with and around for so long a
time.  We should give them that choice in the hope that then they will find
Perl more interesting and compelling than the many alternatives out there
which do offer them choices, in aggregate, that we do not.



On Wed, Mar 24, 2021 at 7:46 PM Nicholas Clark <nick@ccl4.org> wrote:

> On Wed, Mar 24, 2021 at 06:34:35PM +0000, Philip R Brenan wrote:
> > Please provide a feature bit for every feature of Perl so that users can
> > remove all the features they do not want to obtain a custom language that
> > reflects their exact requirements with maximal performance unburdened by
> > features that other people "might" want.
>
> I think that if one actually did that, the sheer number of C code branches
> that it created would would flood the CPU's branch prediction cache, even
> if
> each of those branches (in a particular program run) were taken the same
> way. The cache just wouldn't have space to record all of this.
>
> The result would be that the interpreter would actually run more slowly
> than
> the case *without* the super-granular feature options.
>
> The other problem (and I'd not considered it until LeoNerd mentioned it) is
> that number of combinations of features grows exponentially with the number
> of feature options. Meaning that it becomes hard to test all combinations
> (or even reason about them), making it likely that there would be bugs and
> inconsistencies lurking that burn more time than seeming performance or
> flexibility gains.
>
> Nicholas Clark
>


-- 
Thanks,

Phil <https://metacpan.org/author/PRBRENAN>

Philip R Brenan <https://metacpan.org/author/PRBRENAN>

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