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
From:
Tony Cook
Date:
July 8, 2013 06:19
Subject:
Re: [perl #116296] [PATCH] remove PL_patchlevel from and optimizeS_minus_v
Message ID:
20130708061931.GB12268@mars.tony.develop-help.com
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
conditional.
> > 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)
performance.
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.
Tony
[1] gcc, default Configure set optimization, -Duseithreads,
git_version.h edited to match a tagged release, first
Perl_newSVpvf_no_context:
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