* hash.c (ruby_setenv): do not check environment block size.
c.f. https://msdn.microsoft.com/en-us/library/windows/desktop/ms682653(v=vs.85).aspx
Starting with Windows Vista and Windows Server 2008, there is no
technical limitation on the size of the environment block.
[ruby-core:88400] [Bug #14979]
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@64293 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
Both methods Hash#length and Hash#size share the same source code in
Ruby, but they also share the same documentation. Now when you look at
the documentation of Hash#size you only see examples for Hash#length,
which is confusing. This commit includes Hash#size in the examples and
also remarks that both methods are equivalent to each other.
Co-authored-by: Alberto Almagro <alberto.almagro@rakuten.com>
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@64081 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
* time.c (rb_localtime_r): call tzset() only after TZ environment
variable is changed.
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@63994 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
* In Enumerable, Enumerator::Lazy, Array, Hash and Set
[Feature #13784] [ruby-core:82285]
* Share specs for the various #select#select! methods and
reuse them for #filter/#filter!.
* Add corresponding filter tests for select tests.
* Update NEWS.
[Fix GH-1824]
From: Alexander Patrick <adp90@case.edu>
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@62575 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
which has been developed by Takashi Kokubun <takashikkbn@gmail> as
YARV-MJIT. Many of its bugs are fixed by wanabe <s.wanabe@gmail.com>.
This JIT compiler is designed to be a safe migration path to introduce
JIT compiler to MRI. So this commit does not include any bytecode
changes or dynamic instruction modifications, which are done in original
MJIT.
This commit even strips off some aggressive optimizations from
YARV-MJIT, and thus it's slower than YARV-MJIT too. But it's still
fairly faster than Ruby 2.5 in some benchmarks (attached below).
Note that this JIT compiler passes `make test`, `make test-all`, `make
test-spec` without JIT, and even with JIT. Not only it's perfectly safe
with JIT disabled because it does not replace VM instructions unlike
MJIT, but also with JIT enabled it stably runs Ruby applications
including Rails applications.
I'm expecting this version as just "initial" JIT compiler. I have many
optimization ideas which are skipped for initial merging, and you may
easily replace this JIT compiler with a faster one by just replacing
mjit_compile.c. `mjit_compile` interface is designed for the purpose.
common.mk: update dependencies for mjit_compile.c.
internal.h: declare `rb_vm_insn_addr2insn` for MJIT.
vm.c: exclude some definitions if `-DMJIT_HEADER` is provided to
compiler. This avoids to include some functions which take a long time
to compile, e.g. vm_exec_core. Some of the purpose is achieved in
transform_mjit_header.rb (see `IGNORED_FUNCTIONS`) but others are
manually resolved for now. Load mjit_helper.h for MJIT header.
mjit_helper.h: New. This is a file used only by JIT-ed code. I'll
refactor `mjit_call_cfunc` later.
vm_eval.c: add some #ifdef switches to skip compiling some functions
like Init_vm_eval.
win32/mkexports.rb: export thread/ec functions, which are used by MJIT.
include/ruby/defines.h: add MJIT_FUNC_EXPORTED macro alis to clarify
that a function is exported only for MJIT.
array.c: export a function used by MJIT.
bignum.c: ditto.
class.c: ditto.
compile.c: ditto.
error.c: ditto.
gc.c: ditto.
hash.c: ditto.
iseq.c: ditto.
numeric.c: ditto.
object.c: ditto.
proc.c: ditto.
re.c: ditto.
st.c: ditto.
string.c: ditto.
thread.c: ditto.
variable.c: ditto.
vm_backtrace.c: ditto.
vm_insnhelper.c: ditto.
vm_method.c: ditto.
I would like to improve maintainability of function exports, but I
believe this way is acceptable as initial merging if we clarify the
new exports are for MJIT (so that we can use them as TODO list to fix)
and add unit tests to detect unresolved symbols.
I'll add unit tests of JIT compilations in succeeding commits.
Author: Takashi Kokubun <takashikkbn@gmail.com>
Contributor: wanabe <s.wanabe@gmail.com>
Part of [Feature #14235]
---
* Known issues
* Code generated by gcc is faster than clang. The benchmark may be worse
in macOS. Following benchmark result is provided by gcc w/ Linux.
* Performance is decreased when Google Chrome is running
* JIT can work on MinGW, but it doesn't improve performance at least
in short running benchmark.
* Currently it doesn't perform well with Rails. We'll try to fix this
before release.
---
* Benchmark reslts
Benchmarked with:
Intel 4.0GHz i7-4790K with 16GB memory under x86-64 Ubuntu 8 Cores
- 2.0.0-p0: Ruby 2.0.0-p0
- r62186: Ruby trunk (early 2.6.0), before MJIT changes
- JIT off: On this commit, but without `--jit` option
- JIT on: On this commit, and with `--jit` option
** Optcarrot fps
Benchmark: https://github.com/mame/optcarrot
| |2.0.0-p0 |r62186 |JIT off |JIT on |
|:--------|:--------|:--------|:--------|:--------|
|fps |37.32 |51.46 |51.31 |58.88 |
|vs 2.0.0 |1.00x |1.38x |1.37x |1.58x |
** MJIT benchmarks
Benchmark: https://github.com/benchmark-driver/mjit-benchmarks
(Original: https://github.com/vnmakarov/ruby/tree/rtl_mjit_branch/MJIT-benchmarks)
| |2.0.0-p0 |r62186 |JIT off |JIT on |
|:----------|:--------|:--------|:--------|:--------|
|aread |1.00 |1.09 |1.07 |2.19 |
|aref |1.00 |1.13 |1.11 |2.22 |
|aset |1.00 |1.50 |1.45 |2.64 |
|awrite |1.00 |1.17 |1.13 |2.20 |
|call |1.00 |1.29 |1.26 |2.02 |
|const2 |1.00 |1.10 |1.10 |2.19 |
|const |1.00 |1.11 |1.10 |2.19 |
|fannk |1.00 |1.04 |1.02 |1.00 |
|fib |1.00 |1.32 |1.31 |1.84 |
|ivread |1.00 |1.13 |1.12 |2.43 |
|ivwrite |1.00 |1.23 |1.21 |2.40 |
|mandelbrot |1.00 |1.13 |1.16 |1.28 |
|meteor |1.00 |2.97 |2.92 |3.17 |
|nbody |1.00 |1.17 |1.15 |1.49 |
|nest-ntimes|1.00 |1.22 |1.20 |1.39 |
|nest-while |1.00 |1.10 |1.10 |1.37 |
|norm |1.00 |1.18 |1.16 |1.24 |
|nsvb |1.00 |1.16 |1.16 |1.17 |
|red-black |1.00 |1.02 |0.99 |1.12 |
|sieve |1.00 |1.30 |1.28 |1.62 |
|trees |1.00 |1.14 |1.13 |1.19 |
|while |1.00 |1.12 |1.11 |2.41 |
** Discourse's script/bench.rb
Benchmark: https://github.com/discourse/discourse/blob/v1.8.7/script/bench.rb
NOTE: Rails performance was somehow a little degraded with JIT for now.
We should fix this.
(At least I know opt_aref is performing badly in JIT and I have an idea
to fix it. Please wait for the fix.)
*** JIT off
Your Results: (note for timings- percentile is first, duration is second in millisecs)
categories_admin:
50: 17
75: 18
90: 22
99: 29
home_admin:
50: 21
75: 21
90: 27
99: 40
topic_admin:
50: 17
75: 18
90: 22
99: 32
categories:
50: 35
75: 41
90: 43
99: 77
home:
50: 39
75: 46
90: 49
99: 95
topic:
50: 46
75: 52
90: 56
99: 101
*** JIT on
Your Results: (note for timings- percentile is first, duration is second in millisecs)
categories_admin:
50: 19
75: 21
90: 25
99: 33
home_admin:
50: 24
75: 26
90: 30
99: 35
topic_admin:
50: 19
75: 20
90: 25
99: 30
categories:
50: 40
75: 44
90: 48
99: 76
home:
50: 42
75: 48
90: 51
99: 89
topic:
50: 49
75: 55
90: 58
99: 99
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@62197 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
* hash.c (prime2): turned into a uint32_t prime, as the lower
32bits, non-prime part only was used always.
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@61473 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
Current check for __uint128_t in hash.c is not valid, since it ignores
compilers other than gcc. We hit this on lcc on e2k platform.
Configure script properly checks from 128-bit data types support and
sets HAVE_UINT128_T accordingly. This approach is already used within
ruby at bignum.c, random.c, etc.
Probably hash.c is an overlooked remnant of old days. This patch fixes
this.
[ruby-core:84438] [Bug #14231] [Fix GH-1781]
From: Andrew Savchenko <bircoph@altlinux.org>
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@61471 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
and specialized Array#any? and Hash#any?
Based on patch by D.E. Akers [#11286]
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@61098 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
Traditionally, method coverage measurement was implemented by inserting
`trace2` instruction to the head of method iseq. So, it just measured
methods defined by `def` keyword.
This commit drastically changes the measuring mechanism of method
coverage; at `RUBY_EVENT_CALL`, it keeps a hash from rb_method_entry_t*
to runs (i.e., it counts the runs per method entry), and at
`Coverage.result`, it creates the result hash by enumerating all
`rb_method_entry_t*` objects (by `ObjectSpace.each_object`).
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@61023 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
* hash.c: [DOC] clarify description for Hash#slice and remove
a sentence that might suggest that the receiver is modified;
improve example to also include a case where a hash with
several elements is returned.
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@60713 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
* array.c (rb_to_array_type): make public to share common code
internally.
* hash.c (rb_to_hash_type): make public to share common code
internally.
* symbol.c (rb_to_symbol_type): make public to share common code
internally.
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@60438 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
hash.c (rb_hash_compare_by_id): avoid unnecessary allocation of st_table.
formerly, st_table created in rb_hash_modify() was not used and replaced immediately.
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@60337 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
The new function rb_yield_assoc_or_values() will reduce branching.
* vm_eval.c: add rb_yield_assoc_or_values()
* internal.h: ditto
* hash.c: use rb_yield_assoc_or_values()
* struct.c: ditto
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@60095 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
st.c was improved in r56650 that it permits deletion during iteration.
In this commit, special treatments for previous implementation are
removed.
* hash.c: don't use *_check and *_safe functions in st.c
* internal.h: remove HASH_DELETED flag
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@60076 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
Sometimes, size of a hash can be calcluated a priori. By providing
such info to the constructor we can avoid unnecessary internal re-
allocations. This can boost for instance creation of hash literals.
[Bug #13861]
Signed-off-by: Urabe, Shyouhei <shyouhei@ruby-lang.org>
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@59744 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
* hash.c (rb_hash_compact_bang): [DOC] update the case if no
changes were made. [ruby-core:82591] [Bug #13855] [Fix GH-1692]
Author: Lucas Buchala <lucasbuchala@gmail.com>
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@59719 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
* hash.c (env_enc_str_new): convert to the expected encoding
without intermediate string, and set econv flags if default
internal encoding is set too.
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@59449 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
These caused numerous CI failures I haven't been able to
reproduce [ruby-core:82102]
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@59364 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
The same hash keys may be loaded from tainted data sources
frequently (e.g. parsing headers from socket or loading
YAML data from a file). If a non-tainted fstring already
exists (because the application expects the hash key),
cache and deduplicate the tainted version in the new
tainted_frozen_strings table.
For non-embedded strings, this also allows sharing with the
underlying malloc-ed data.
* vm_core.h (rb_vm_struct): add tainted_frozen_strings
* vm.c (ruby_vm_destruct): free tainted_frozen_strings
(Init_vm_objects): initialize tainted_frozen_strings
(rb_vm_tfstring_table): accessor for tainted_frozen_strings
* internal.h: declare rb_fstring_existing, rb_vm_tfstring_table
* hash.c (fstring_existing_str): remove (moved to string.c)
(hash_aset_str): use rb_fstring_existing
* string.c (rb_fstring_existing): new, based on fstring_existing_str
(tainted_fstr_update): new
(rb_fstring_existing0): new, based on fstring_existing_str
(rb_tainted_fstring_existing): new, special case for tainted strings
(rb_str_free): delete from tainted_frozen_strings table
* test/ruby/test_optimization.rb (test_hash_reuse_fstring): new test
[ruby-core:82012] [Bug #13737]
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@59354 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
Fix up r59328. It is possible that the given block abuses
ObjectSpace.each_object to shrink the temporary array.
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@59334 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
* hash.c (hash_aset_str): create frozen string for tainted objects.
(should not use fsting table on this case).
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@59310 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
In typical applications, hash entries are read after being
written to. Blindly writing to hashes which are never read
makes little sense. So, for any hash which is read from, an
fstring entry for the key should already exist for the key.
We no longer blindly create fstrings if the code is blindly
setting random hash keys, preventing the performance regression
in the reverted r43870.
Regarding <https://bugs.ruby-lang.org/issues/9188>, this has a
minimum impact on the bm_so_k_nucleotide where hash keys are set
and not reused, performance is within 1-2% of existing cases.
* hash.c: #include gc.h for rb_objspace_garbage_object_p
(hash_aset_str): do read-only check of fstring table and
reuse fstring if it exists and is still alive (not garbage)
[ruby-core:81942] [Feature #13725]
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@59304 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
To convert the object implicitly, it has had two parts in convert_type() which are
1. lookink up the method's id
2. calling the method
Seems that strncmp() and strcmp() in convert_type() are slightly heavy to look up
the method's id for type conversion.
This patch will add and use internal APIs (rb_convert_type_with_id, rb_check_convert_type_with_id)
to call the method without looking up the method's id when convert the object.
Array#flatten -> 19 % up
Array#+ -> 3 % up
[ruby-dev:50024] [Bug #13341] [Fix GH-1537]
### Before
Array#flatten 104.119k (± 1.1%) i/s - 525.690k in 5.049517s
Array#+ 1.993M (± 1.8%) i/s - 10.010M in 5.024258s
### After
Array#flatten 124.005k (± 1.0%) i/s - 624.240k in 5.034477s
Array#+ 2.058M (± 4.8%) i/s - 10.302M in 5.019328s
### Test Code
require 'benchmark/ips'
class Foo
def to_ary
[1,2,3]
end
end
Benchmark.ips do |x|
ary = []
100.times { |i| ary << i }
array = [ary]
x.report "Array#flatten" do |i|
i.times { array.flatten }
end
x.report "Array#+" do |i|
obj = Foo.new
i.times { array + obj }
end
end
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@58978 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
* hash.c: [DOC] fix return value in call-seq of Hash#transform_values;
other small fixes.
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@58888 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
Hash#transform_values! returns the receiver rather than a new Hash
object.
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@58845 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
Explicitly says that the methods return a new hash rather than just
stating it return a new something we don't know.
[ci skip]
[Fix GH-1619]
Author: Nicolas Cavigneaux <nico@bounga.org>
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@58830 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
* hash.c (rb_hash_merge): use rb_hash_dup() instead of rb_obj_dup() to duplicate
Hash object. rb_hash_dup() is faster duplicating function for Hash object
which got rid of Hash#initialize_dup method calling.
Hash#merge will be faster around 60%.
[ruby-dev:50026] [Bug #13343] [Fix GH-1533]
### Before
user system total real
Hash#merge 0.160000 0.020000 0.180000 ( 0.182357)
### After
user system total real
Hash#merge 0.110000 0.010000 0.120000 ( 0.114404)
### Test code
require 'benchmark'
Benchmark.bmbm do |x|
hash1 = {}
100.times { |i| hash1[i.to_s] = i }
hash2 = {}
100.times { |i| hash2[(i*2).to_s] = i*2 }
x.report "Hash#merge" do
10000.times do
hash1.merge(hash2)
end
end
end
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@58811 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
* st.c (rb_hash_bulk_insert): new API to bulk insert entries
into a hash. Given arguments are first inserted into the
table at once, then reindexed. This is faster than inserting
things using rb_hash_aset() one by one.
This arrangement (rb_ prefixed function placed in st.c) is
unavoidable because it both touches table internal and write
barrier at once.
* internal.h: delcare the new function.
* hash.c (rb_hash_s_create): use the new function.
* vm.c (core_hash_merge): ditto.
* insns.def (newhash): ditto.
* test/ruby/test_hash.rb: more coverage on hash creation.
* test/ruby/test_literal.rb: ditto.
-----------------------------------------------------------
benchmark results:
minimum results in each 7 measurements.
Execution time (sec)
name before after
loop_whileloop2 0.136 0.137
vm2_bighash* 1.249 0.623
Speedup ratio: compare with the result of `before' (greater is better)
name after
loop_whileloop2 0.996
vm2_bighash* 2.004
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@58492 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
We need to fix GC bug before merging this. Revert revisions
58452, 58435, 58434, 58428, 58427 in this order.
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@58463 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
nobu
tenderlove
ktsj
shyouhei
eregon
k0kubun
mrkn
normal
usa
marcandre
mame
stomar
kazu
glass
hsbt
rhe
ko1
watson1978