[#65451] [ruby-trunk - Feature #10333] [PATCH 3/1] optimize: "yoda literal" == string — ko1@...
Issue #10333 has been updated by Koichi Sasada.
9 messages
2014/10/07
[#65458] Re: [ruby-trunk - Feature #10333] [PATCH 3/1] optimize: "yoda literal" == string
— Eric Wong <normalperson@...>
2014/10/07
[email protected] wrote:
[#65502] Re: [ruby-trunk - Feature #10333] [PATCH 3/1] optimize: "yoda literal" == string
— Eric Wong <normalperson@...>
2014/10/08
Eric Wong <[email protected]> wrote:
[#65538] Re: [ruby-trunk - Feature #10333] [PATCH 3/1] optimize: "yoda literal" == string
— Eric Wong <normalperson@...>
2014/10/09
Eric Wong <[email protected]> wrote:
[#65549] Re: [ruby-trunk - Feature #10333] [PATCH 3/1] optimize: "yoda literal" == string
— SASADA Koichi <ko1@...>
2014/10/09
On 2014/10/09 11:04, Eric Wong wrote:
[#65551] Re: [ruby-trunk - Feature #10333] [PATCH 3/1] optimize: "yoda literal" == string
— Eric Wong <normalperson@...>
2014/10/09
SASADA Koichi <[email protected]> wrote:
[#65453] [ruby-trunk - Feature #10328] [PATCH] make OPT_SUPPORT_JOKE a proper VM option — ko1@...
Issue #10328 has been updated by Koichi Sasada.
3 messages
2014/10/07
[#65559] is there a name for this? — Xavier Noria <fxn@...>
When describing stuff about constants (working in their guide), you often
7 messages
2014/10/09
[#65560] Re: is there a name for this?
— Nobuyoshi Nakada <nobu@...>
2014/10/09
On 2014/10/09 20:41, Xavier Noria wrote:
[#65561] Re: is there a name for this?
— Xavier Noria <fxn@...>
2014/10/09
On Thu, Oct 9, 2014 at 1:59 PM, Nobuyoshi Nakada <[email protected]> wrote:
[#65566] [ruby-trunk - Feature #10351] [Open] [PATCH] prevent CVE-2014-6277 — shyouhei@...
Issue #10351 has been reported by Shyouhei Urabe.
3 messages
2014/10/09
[#65741] Re: [ruby-cvs:55121] normal:r47971 (trunk): test/ruby/test_rubyoptions.rb: fix race — Nobuyoshi Nakada <nobu@...>
On 2014/10/16 10:10, [email protected] wrote:
5 messages
2014/10/16
[#65742] Re: [ruby-cvs:55121] normal:r47971 (trunk): test/ruby/test_rubyoptions.rb: fix race
— Eric Wong <normalperson@...>
2014/10/16
Nobuyoshi Nakada <[email protected]> wrote:
[#65750] Re: [ruby-cvs:55121] normal:r47971 (trunk): test/ruby/test_rubyoptions.rb: fix race
— Tanaka Akira <akr@...>
2014/10/16
2014-10-16 12:48 GMT+09:00 Eric Wong <[email protected]>:
[#65753] [ruby-trunk - Feature #10333] [PATCH 3/1] optimize: "yoda literal" == string — ko1@...
Issue #10333 has been updated by Koichi Sasada.
3 messages
2014/10/16
[#65818] [ruby-trunk - Feature #10351] [PATCH] prevent CVE-2014-6277 — shyouhei@...
Issue #10351 has been updated by Shyouhei Urabe.
3 messages
2014/10/20
[ruby-core:65458] Re: [ruby-trunk - Feature #10333] [PATCH 3/1] optimize: "yoda literal" == string
From:
Eric Wong <normalperson@...>
Date:
2014-10-07 07:54:04 UTC
List:
ruby-core #65458
[email protected] wrote: > Comments for this ticket and the following tickets: > > > 1) [Feature #10326] optimize: recv << "literal string" > > 2) [Feature #10329] optimize: foo == "literal string" > To continue this kind of hack, we need tons of instructions for each > methods. What do you think about it? I am not completely happy with my current patches because of verbosity and also icache footprint in the main VM loop. Ruby executable sizes (even stripped) seem to get bigger with every release :< However, perhaps the biggest performance problem is still too many allocations and garbage objects; so I am willing to trade some code size to reduce dynamic allocations. > Basically, we need to add them more carefully. For example, persuasive > explanation are needed, such as statistics (analysis by > parser/compier), benchmark results for major use cases (maybe "<< > 'literal'" for templates. but not sure this ticket for) . Right, we will need to find more real benchmarks. Sadly, there are many places where garbage grows. So maybe this change is only 1-2% overall. We may need a lot of small changes to add up to noticeable improvements. > Another idea is to make more general approach to indicate arguments > (and a receiver) are string literal. It is called specialization. > Specialized instructions (opt_plus and so on) is a kind of > specialization by hands. I've been thinking along these lines, too. For example, I would like to see String#tr! and String#gsub! able to avoid allocations for literal strings. Or even optimize: Time.now.{to_f,to_i,strftime("lit"))} As suggested by akr, users may .freeze (or use constants), but that is verbose and requires VM internal knowledge. My goal is to make optimization as transparent as possible so users may write concise, idiomatic Ruby code. It would be great if things like ruby-trunk r47813 (unicode_norm_gen.rb: optimize concatenation) can be done transparently, even. > Small comments: > > (1) iseq_compile_each() should not use opt_* instructions because we > should be able to make instructions without opt_* insns (on/off by > compile options). Right. I'll see about making it optional and doing it more idiomatically. I mainly used existing opt_{aref,aset}_with compilation as a guide. > (2) Name of instructions should be reconsidered. OK, I do not mind changing names. I also did informal benchmarks with my system Perl installation (Perl 5.14.2 on Debian stable x86-64): > loop_whileloop2 use strict; my $i = 0; while ($i < 6_000_000) { # benchmark loop 2 $i += 1; } Perl 0.228s > trunk 0.10645449301227927 > built 0.10581812914460897 Without the string compare, we're already faster than Perl \o/ > vm2_streq1 use strict; my $i = 0; my $foo = "literal"; while ($i < 6_000_000) { # benchmark loop 2 $i += 1; $foo eq "literal"; } Perl 0.0349s > trunk 0.4726782930083573 > built 0.18452610215172172 We lose to Perl without the optimization, but win with it :) This is just a micro-benchmark, of course, but I think it's an important data point to show gains by avoiding allocations when possible