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

Re: PL_sv_objcount

Thread Previous | Thread Next
From:
bulk88
Date:
February 28, 2013 21:15
Subject:
Re: PL_sv_objcount
Message ID:
BLU0-SMTP461B310185FA2FA61EA77FDDFFE0@phx.gbl
Nicholas Clark wrote:
> Pretty much *any* real world code of any form is going to end up with
> PL_sv_objcount non-zero at destruction time.

What is real world code? LAMP alone?

> 
>> The ++/-- code is unmeasurable. It will be executed async to all the 
>> other instructions ahead/behind it since its not related to any previous 
>>   calculation/data. Regarding "nano optimization", I'll point out this 
> 
> It will, however, mean that that location has to be kept in the L1 cache.
> 

I ran out of time to find a source for the following (the actual 
eviction/storing algorithm I am thinking is a trade secret of 
AMD/Intel), not *all* memory data is saved in caches. Cache isn't FIFO, 
it remembers frequency of access. memcpy won't empty L2. If no 
instructions in the near future on the pipeline touch it, and it hasn't 
been accessed in the past, it is evicted before other more used cache 
lines. A list of evicted address exists. Next time the address is seen, 
it is stored in cache for much longer. Hints about the last time the 
instructions executed also influence eviction policy. All the asm code 
is compiled and peepholed by the CPU the same way the C compiler does 
since the Pentium Pro. Mitigation of anti-patterns of existing compilers 
is what separates an Intel/AMD from a Z80 or Via.

> 
> You are arguing in favour of optimising about 30 *micro*-seconds from the
> runtime of *trivial* one-liners (ie don't use Exporter or Config)

Yes. Not everyone uses persistent processes. What will replace these 30 
micro-seconds? Nothing? If they are trivial, why not deprecate and 
remove -e? It would make maintenance much easier to have newlines in code.

> 
> In the long game, maintainability and better algorithms win.

*Who* will do the better algorithms? Maintainability is subjective. Lock 
the git, put a page welcoming existing Perl users to Rakudo and be done 
with it if it is unmaintainable.

> 
> Code reviewing micro-optimisations takes time from everything else.

Removing optimizations to make life easy is a great plan.

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