Re^2: Perl 5 Optimizing Compiler

in reply to Re: Perl 5 Optimizing Compiler
in thread Perl 5 Optimizing Compiler

Invent a time machine and send the code back from 2023.

lol, perl5 is non type and too flexible, these 2 reasons lead it's hard to optimize. If we can add a brand new type and const system into perl5 and strict perl's flexibilty, it would be sped up as we think.

I am trying to improve my English skills, if you see a mistake please feel free to reply or /msg me a correction

Comment on Re^2: Perl 5 Optimizing Compiler

Replies are listed 'Best First'.
Re^3: Perl 5 Optimizing Compiler by bulk88 (Priest) on Aug 14, 2012 at 01:56 UTC
I agree. Many optimizations that can be performed in C or other no runtime eval languages can't be done in Perl since so much context and metadata has to be kept around for a rare eval string or magic to happen. Dereferencing has to be done every time -> or {} appears in code without exception in case its a magic variable. $root{l1}{l2}{l3} really takes 4 dereferences ops every time it is written, and it can be written 7 times in a sub. Very few people (I am one of them) will make a lexical reference to the has slice "\$root{l1}{l2}{l3}" to avoid all the reference ops. I still had a dereference op every time I write "${}" but its better than "load constant on stack, do deref" times 3 opcodes. Sometimes flexibility isn't so flexible. hv_common_key_len could use some refactoring to split out all the magic support into separate function calls to keep it out of the CPU cache. Here are top 18 (actually all functions over 4 KB long) fattest functions in ActivePerl 5.12 (Visual C -O1) in machine code. `_Perl_re_compile 00001021 _Perl_gv_fetchpvn_flags 0000105F S_scan_const 000010EB S_regatom 000012FB S_make_trie 0000148C _Perl_sv_vcatpvfn 00001620 _Perl_yyparse 000016C2 S_regclass 0000177A _Perl_do_sv_dump 00001A4D S_reg 00001B5F _perl_clone_using 00001D3C S_unpack_rec 0000231F S_study_chunk 00002668 S_pack_rec 00002729 S_find_byclass 00002928 _Perl_keyword 0000359D S_regmatch 0000438A _Perl_yylex 00008095` [download] un/pack I'm surprised it so fat. clone_using could use a couple strategically placed memcpy calls rather than 100s of double/quadword copies. Use B::Deparse and look at your opcode trees. Reduce number of opcodes and your code is faster. Each ; has overhead (line number switching for not present debugger). Use a comma operator sometimes to reduce nextstates.	[reply] [d/l]
Re^4: Perl 5 Optimizing Compiler by tsee (Curate) on Aug 14, 2012 at 06:35 UTC
In all fairness, the line number accounting is also important for warnings and errors. Your list would probably also be more useful if you dropped most of the compilation related functions: At least yylex, scan_const, and yyparse. Probably, worrying about regexp compilation isn't that useful either, so those functions could go, too. What are the runners up?	[reply]
Re^5: Perl 5 Optimizing Compiler by bulk88 (Priest) on Aug 15, 2012 at 01:02 UTC
Not 100% accurate. Some functions might be missing or corrupt because of my shoddy regexps used to create the data. Read more... (63 kB) edit: I hit the post size limit so list ends at 0x78 bytes long.	[reply] [d/l]
Re^6: Perl 5 Optimizing Compiler by dave_the_m (Monsignor) on Aug 15, 2012 at 16:45 UTC

In Section Seekers of Perl Wisdom