Front page | perl.perl5.porters |
Postings from March 2013
March 1, 2013 19:34
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
>> 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.
>> $_ = (($a * 5) + $_)/$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
> 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?