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

Re: OP_PADSV_NOLV

Thread Previous | Thread Next
From:
bulk88
Date:
March 1, 2013 19:34
Subject:
Re: OP_PADSV_NOLV
Message ID:
BLU0-SMTP225918E80CF396AD2CAD939DFFF0@phx.gbl
Steffen Mueller wrote:
>>
>> Ideally as I mentioned on perlmonks, if there is no eval/do and no bless
>> or tie calls on the lexical, and a lexical is never passed to another
>> sub, in a sub, use a different set of opcodes to create 2 or 3 paths
>> (pure UV, pure IV, or pure NV math), then doing all operators on a
>> statement using something close to machine math without using the SV
>> abstraction or Perl stack, or place native machine numbers on the Perl
>> stack (not SV *). I know NULLs now appear on the Perl stack in some
>> cases. There is an unrealistically work level to introducing a 3rd VM
>> into perl which is what this idea is. I guess there were plans a long
>> time ago to have alternate optree optimizers/opcodes and override at
>> runtime the ck_() funcs.
> 
> Umm, you've seen my crazy JIT hacks, right? Check github. :)

Sounds interesting, I will look. There is "use integer" and it has its 
own opcodes.

>> A slimmer idea would be an opcode that has a var len bitfield/array, it
>> will do arbitrary math ops on a list/perl stack going down/up the stack
>> with the intermediate number stored in a C auto. When it reaches the end
>> of array it assigns to the last SV on the list.
>>
>> $_[1] = (($a * 5) + $_[0])/$main::global;
>> pushmark, padsv, const, aelemfast, gvsv, aelemfast, megamathop(mul << 8
>> | add << 4 | div), nextstate
>>
>> Last choice is remove or deprecate/de-default it from the build process
>> PERL_PRESERVE_IVUV as unmaintainable and a performance degradation. If
>> you dont like FP rounding/precision, complain to your CPU/CC vendor,
>> Perl is just a wrapper around your native C/POSIX support, I hear GCC
>> now offers __float128. Perl is not an OS and emulator/hypervisor wrapped
>> together in 1 binary.
> 
> Perl is a dynamic programming language. It does these things for a 
> reason. If you want C, you know where to find it. This will not be 
> negotiable. Correctness beats speed in almost all cases.
> 

But Perl leaks through C in many places for example 
https://rt.perl.org/rt3/Ticket/Display.html?id=60318 .

> Something that would be perfectly tractable (and even fundamentally 
> doable as an extension!) is maintaining a copy of the respective OP or 
> OPs without the PRESERVE_UVIV logic and then using a hook into the 
> peephole optimizer and a lexical pragma to opt in to the faster, but 
> less accurate behaviour.

A "use float" with its own opcodes?

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