[ruby-core:113268] [Ruby master Bug#4040] SystemStackError with Hash[*a] for Large _a_

Issue #4040 has been updated by jeremyevans0 (Jeremy Evans).


Eregon (Benoit Daloze) wrote in #note-23:
> @jeremyevans0 
> > I rebased my branch against master, and then ran all of the app_* benchmarks, here are the results:
> 
> Are the +N% there improvements or regressions? From those numbers it sounds like `+` would be regressions (i.e., more time to execute the same thing).

+N% is an improvement in iterations per second, -N% is a decrease in iterations per second.

> I am thinking a bit more about the implications of this for Ruby implementations and JITs.
> Only passing on the stack means not allowed to pass a huge number of arguments (the case on TruffleRuby).
> Only passing as a heap array seems inefficient in general (would cause extra allocations, at least in interpreter, for `foo(1, 2)`).
> I guess one could use 2 different calling conventions, on stack if no rest parameter, on heap if there is a rest parameter. But more calling conventions is a clear cost as it causes extra checks for every call, even more so for polymorphic call site (+ it's messy to do callee-specific logic in the caller).

For CRuby, a heap array is used for large array splats (configurable, but currently 129+ elements).  Smaller array splats use the VM stack.  A heap array is only used for method calls with argument splat, never for other method calls (even if you pass 129+ arguments). On CRuby, there is a minor cost for checking for whether a heap_allocated array was used.

> * There is probably no hope to ever revert that decision and to remove those costs, because some code will likely start to depend on it.

@ko1 has already told me that the heap_argv part of the patch will be reverted if it becomes an significant obstacle to future CRuby optimization work.  We'll keep the other optimizations in the pull request in that case.

> * It might encourage Ruby users to abuse splats more since they seem not much slower than non-splat on CRuby and they don't trigger SystemStackError.

This is incorrect.  Passing arrays via splats is always slower than passing arrays as positional arguments.  The pull request makes passing large arrays via splats not trigger SystemStackError.  For arrays with 129+ elements, the pull request actually slows down such calls by using a temporary array instead of passing the elements on the VM stack.  So if anything, the patch encourages users not to pass large arrays as splats, as doing so is even worse for performance than before.

We may want to consider adding a performance warning for passing large arrays via splats.

----------------------------------------
Bug #4040: SystemStackError with Hash[*a] for Large _a_
https://bugs.ruby-lang.org/issues/4040#change-102830

* Author: runpaint (Run Paint Run Run)
* Status: Open
* Priority: Normal
* Assignee: ko1 (Koichi Sasada)
* ruby -v: ruby 1.9.3dev (2010-11-09 trunk 29737) [x86_64-linux] 
* Backport: 2.2: UNKNOWN, 2.3: UNKNOWN, 2.4: UNKNOWN
----------------------------------------
=begin
 I've been hesitating over whether to file a ticket about this, so please feel free to close if I've made the wrong choice.
 
 I often use Hash[*array.flatten] in IRB to convert arrays of arrays into hashes. Today I noticed that if the array is big enough, this would raise a SystemStackError. Puzzled, I looked deeper. I assumed I was hitting the maximum number of arguments a method's argc can hold, but realised that the minimum size of the array needed to trigger this exception differed depending on whether I used IRB or not. So, presumably this is indeed exhausting the stack...
 
 In IRB, the following is the minimal reproduction of this problem:
 
   Hash[*130648.times.map{ 1 }]; true
 
 I haven't looked for the minimum value needed with `ruby -e`, but the following reproduces:
 
   ruby -e 'Hash[*1380888.times.map{ 1 }]'
 
 I suppose this isn't technically a bug, but maybe it offers another argument for either #666 or an extension of #3131.
=end




-- 
https://bugs.ruby-lang.org/
 ______________________________________________
 ruby-core mailing list -- [e-mail]
 To unsubscribe send an email to [e-mail]
 ruby-core info -- https://ml.ruby-lang.org/mailman3/postorius/lists/ruby-core.ml.ruby-lang.org/