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

Re: [perl #116296] [PATCH] remove PL_patchlevel from and optimizeS_minus_v

Thread Previous | Thread Next
Tony Cook
July 8, 2013 06:19
Re: [perl #116296] [PATCH] remove PL_patchlevel from and optimizeS_minus_v
Message ID:
On Sat, Jul 06, 2013 at 09:10:12AM -0700, bulk88 via RT wrote:
> On Sat Jul 06 07:45:05 2013, davem wrote:
> > On x86_64 platforms with the "first 6 args are in registers" calling
> > convention, using newSVpvn() will likely involve no more code, since
> > my_perl will already be in the relevant register; while on x86, its
> > likely
> > just a push of a register value.
> >
> On Win64 that is wrong. my_perl has to be copied every time to the 1st
> callee register by the caller from the caller's non-vol register that it
> saved or caller's c stack auto. There will always be an assignment to
> first register (callee's my_perl) on x64 on cdecl for each perl func
> call. The calling convention does not say anywhere that a callee must
> keep incoming params in registers nonvolatile. What if the callee
> doesn't need to every use my_perl again until it returns and calls
> strlen which doesn't take a my_perl? The caller just lost their my_perl
> pointer.
> Keeping func params const on assembly level, to avoid copying in the
> caller for each call, would require a machine code JITer and/or random
> calling conventions. Random calling conventions are implemented in some
> C compilers for Windows, but only for Win32, not Win64.

While Dave was wrong about the registers, his general argument about
the micro-optimization is correct, MSVC isn't the only compiler.

With gcc/clang the change *costs* 5 bytes[1] - while making the code a
little harder to read.  Both gcc and clang optimize out the

> > I really don't like this part. Its just an excessive level of
> > micro-optimisation for code that's only called once at most, and will
> > have
> > a negligible effect on the overall binary size.
> ................
> > The downside is that the src code becomes more bloated and confusing.
> And this is why people give up, switch languages, then tell all their
> friends Perl [5 or Perl world] is dead. If the git repo is locked, code
> will never become more confusing. The assumption that progress is for
> communists and hippies is the death of Perl 5.

I think it's great that you're enthusiastic about optimizing perl's
implementation, but treating a comment about fairly questionable
optimization as an attack on all changes is reaching.

We optimize for several things, generated code size is important, but
not more important than a) developer time - the poor sob who comes
along in 6 months or 5 years and needs to understand the code, b)

And code size doesn't map one-to-one to performance - several
performance optimizations produce significantly larger code.

Performance doesn't matter much for S_minus_v(), but developer time
matters as much there as it does anywhere else.


[1] gcc, default Configure set optimization, -Duseithreads,
git_version.h edited to match a tagged release, first

00000000000050a0 <S_minus_v>:
    50a0:	41 54                	push   %r12
    50a2:	be 00 00 00 00       	mov    $0x0,%esi
			50a3: R_X86_64_32	.rodata+0x8ad
    50a7:	31 c0                	xor    %eax,%eax
    50a9:	55                   	push   %rbp
    50aa:	48 89 fd             	mov    %rdi,%rbp
    50ad:	bf 00 00 00 00       	mov    $0x0,%edi
			50ae: R_X86_64_32	.rodata.str1.1+0x55
    50b2:	53                   	push   %rbx
    50b3:	e8 00 00 00 00       	callq  50b8 <S_minus_v+0x18>
			50b4: R_X86_64_PC32	Perl_newSVpvf_nocontext+0xfffffffffffffffc

Then newSVpvn():

00000000000050a0 <S_minus_v>:
    50a0:	41 54                	push   %r12
    50a2:	31 d2                	xor    %edx,%edx
    50a4:	be 00 00 00 00       	mov    $0x0,%esi
			50a5: R_X86_64_32	.rodata+0x8ad
    50a9:	55                   	push   %rbp
    50aa:	53                   	push   %rbx
    50ab:	48 89 fb             	mov    %rdi,%rbx
    50ae:	e8 00 00 00 00       	callq  50b3 <S_minus_v+0x13>
			50af: R_X86_64_PC32	Perl_newSVpvn+0xfffffffffffffffc

Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About