| Age | Commit message (Collapse) | Author |
|---|
|
|
|
* john/erts/plusplus-trapping/OTP-15427:
Don't use too many reductions in lists:reverse/2
Make '++'/2 trapping
|
|
* maint:
Updated OTP version
Prepare release
Optimize operator '--' and yield on large inputs
|
|
* maint-18:
Updated OTP version
Prepare release
Optimize operator '--' and yield on large inputs
Conflicts:
OTP_VERSION
erts/doc/src/notes.xml
erts/emulator/beam/erl_alloc.types
erts/emulator/beam/erl_bif_lists.c
erts/vsn.mk
lib/stdlib/doc/src/notes.xml
lib/stdlib/vsn.mk
make/otp_version_tickets
otp_versions.table
|
|
* john/erts/OTP-18.3.4/minusminus_trapping/OTP-15371:
Optimize operator '--' and yield on large inputs
|
|
|
|
* sverker/erts/ordered_set-select-improvements/OTP-15325:
erts: Tidy some ordered_set iteration code
erts: Fix bug for catree iteration
|
|
The removal set now uses a red-black tree instead of an array on
large inputs, decreasing runtime complexity from `n*n` to
`n*log(n)`. It will also exit early when there are no more items
left in the removal set, drastically improving performance and
memory use when the items to be removed are present near the head
of the list.
This got a lot more complicated than before as the overhead of
always using a red-black tree was unacceptable when either of the
inputs were small, but this compromise has okay-to-decent
performance regardless of input size.
Co-authored-by: Dmytro Lytovchenko <[email protected]>
|
|
* maint:
Optimize operator '--' and yield on large inputs
Inline erts_cmp
Clarify a magical allocation size
Fix trapping in lists:reverse/2
|
|
with keys containing off-heap terms.
The passed key may actually be the one already saved
(if nodes have been joined), in which case we do nothing.
Calling destroy_route_key() may destroy off-heap data.
|
|
Even more scalable ETS ordered_set with write_concurrency
|
|
to provoke iteration over a moving ordered_set with write_concurrency
and make sure we hit all "stable" keys.
|
|
to generate a routing tree with keys that fit each test case.
|
|
The removal set now uses a red-black tree instead of an array on
large inputs, decreasing runtime complexity from `n*n` to
`n*log(n)`. It will also exit early when there are no more items
left in the removal set, drastically improving performance and
memory use when the items to be removed are present near the head
of the list.
This got a lot more complicated than before as the overhead of
always using a red-black tree was unacceptable when either of the
inputs were small, but this compromise has okay-to-decent
performance regardless of input size.
Co-authored-by: Dmytro Lytovchenko <[email protected]>
|
|
The original implementation did not do this due to fear of bad
performance. But we think the negative effect of "leaking" empty
base nodes is more important to fix.
To get the bad performance a special kind of access patterns is
needed where base nodes are frequently emptied and then repopulated
soon again. ets_SUITE:throughput_benchmark for example did not show
any negative effect from this commit at all.
|
|
|
|
Once an iteration key has been found, never fall back to first/last key in
next/prev tree as trees may split or join under our feet. I.e we must always
use previous key when searching for the next key.
|
|
with ets_force_split
|
|
{RouteNodes, BaseNodes, MaxRouteTreeDepth}
|
|
|
|
|
|
|
|
* dgud/stdlib/unicode-11/OTP-15111:
Update to Unicode-11
|
|
OTP-14731 Implement 'exsss' (Xorshift116**) as new default 'rand' algorithm
The new algorithm is a combination of the Xorshift116 ('exsp') state update and a new scrambler "StarStar" from the 2018 paper "Scrambled Linear Pseudorandom Number Generators" by David Blackman and Sebastiano Vigna. This combination should not have the caveat of weak low bits that the previous default algorithm(s) have had, with the cost of about 10% lower speed.
|
|
# Conflicts:
# erts/emulator/beam/erl_db_tree.c
|
|
* sverker/erts/ets-select_replace-bug/OTP-15346:
erts: Fix bug in ets:select_replace for bound key
|
|
which may cause following calls to ets:next or ets:prev to fail.
|
|
* maint:
compiler: Forward +source flag to epp and fix bug in +deterministic
epp: Allow user to set source name independently of input file name
|
|
Note that this does *not* affect -include()'d files or the -file()
directive.
|
|
|
|
|
|
* sverker/ets-test-cuddle:
ets_SUITE: Remove more redundant option combos
ets_SUITE: Try avoid redundant option combos
ets_SUITE: Reduce table type combos by removing "void"
ets_SUITE: Optimize throughput_benchmark
|
|
|
|
Update input files for the code-generator and tests.
Added emoji-data.txt for new rule with how to handle emoji.
Unicode have simpliefied the rules for emoji grapheme-clusters:
From:
GB10 (E_Base | EBG) Extend* × E_Modifier
GB11 ZWJ × (Glue_After_Zwj | EBG)
To:
GB11 \p{Extended_Pictographic} Extend* ZWJ × \p{Extended_Pictographic}
Update the code generator to handle the new way.
|
|
meta_wb
smp_insert
smp_fixed_delete
smp_select_delete
|
|
|
|
to reduce test times
|
|
Avoid repeating same tests for [] and [set].
Test case 'default' verifies 'set' to be the default type.
|
|
by populating the table with the help of a random number generator
creating series of unique integers.
|
|
Add a more scalable ETS ordered_set implementation
|
|
|
|
|
|
OTP-14737
* raimo/stdlib/gen_statem-cleanup:
Improve user's guide on time-outs
Clean up and optimize code and doc
|
|
OTP-14461 - New 'rand' algorithm: Xoroshiro928** also for 'crypto'
Implement a new 'rand' algorithm named 'exro928ss' and a new 'crypto' plugin for 'rand' named 'crypto_aes'.
Both are based on Xoroshiro928** which is derived from Xoroshiro1024** modified to use 58-bit words for performance reasons in the Erlang VM. Xoroshiro1024** has got the Xoroshiro1024 generator and the StarStar scrambler from the 2018 paper "Scrambled Linear Pseudorandom Number Generators" by David Blackman and Sebastiano Vigna.
This generator and scrambler combination shows no systematic weaknesses in standard statistical tests as TestU01(BigCrush) and PractRand, unlike the previously used * and + scramblers in the 'rand' module that exhibit statistical weaknesses for the lowest bits.
The 'crypto' plugin uses AES-256 as scrambler and the Xoroshiro928 as generator, which gives the same very long period and jump functions as for Xoroshiro928**, but a cryptographically secure scrambler gives absolutely no detectable statistical weaknesses regardless of how the generated numbers are used.
The speed of 'exro928ss' is only about 30-50% slower than the default fast 'rand' algorithm, but the state is roughly the double and it produces about 8 times the garbage per iteration.
The speed of 'crypto_aes' is about half (amortized) that of the default fast 'rand' algorithm which is fast and thanks to doing encryption in batches caching the result. Hence the state is much larger.
|
|
|
|
|
|
Conflicts:
lib/crypto/doc/src/crypto.xml
lib/crypto/src/crypto.erl
|
|
Conflicts:
lib/crypto/src/crypto.erl
|
|
|
|
|
