[erlang-questions] Ets read concurrency tweak

[Viacheslav V. Kovalev]

I have run this test on following installations (without any
dramatical changes, except absolute values).

2 logical, 1 physical CPU, Erlang/OTP 17 [erts-6.1] [64-bit] [smp:2:2]
[async-threads:10] [hipe]
8 logical, 1 physical CPU, Erlang/OTP 17 [erts-6.4] [64-bit] [smp:8:8]
[async-threads:10] [hipe]
64 logical, 4 physical CPU, Erlang/OTP 17 [erts-6.3] [64-bit]
[smp:64:64] [async-threads:10] [hipe]

Also I've experimented with kernel-poll options. I believe it is about
another things, but anyway was interested.

2015-05-14 19:58 GMT+03:00 Sergej Jurecko <sergej.jurecko@REDACTED>:
> I think read_concurrency/write_concurrency are about mutexes between schedulers. So if you have 1000 processes on a single scheduler it makes no difference. How many logical cpus did the machine you were executing tests have?
>
>
> Sergej
>
> On 14 May 2015, at 17:50, Viacheslav V. Kovalev <kovyl2404@REDACTED> wrote:
>
>>>> - Your two tests which use the read_concurrency option are both setting it to 'true' (lines 31 and 50 in the gist)
>> Ah yep, my fault. Shameful copypaste. However, as you noticed,
>> `{read_concurrency, false}` should be the same as first test with
>> default parameters. When I've fixed this, nothing was changed.
>>
>> What about eprof - it is the last thing I've added to this test. With
>> or without profiler - same results (except of absolute values). Main
>> purpose of profiling was to see if `ets:lookup` is really most
>> expensive operation in this test (and this is true).
>>
>> Also I've experimented with different sizes of table and different
>> sizes of keys in table. Seems all this things doesn't matter, so I am
>> really confused with this option and have no ideas.
>>
>> 2015-05-14 17:52 GMT+03:00 Chandru <chandrashekhar.mullaparthi@REDACTED>:
>>> Hi,
>>>
>>> A few comments.
>>>
>>> - Your two tests which use the read_concurrency option are both setting it
>>> to 'true' (lines 31 and 50 in the gist)
>>>
>>> - I wouldn't run profiling when trying to compare two different options. It
>>> could be that the overhead of profiling is masking any differences between
>>> the two use cases.
>>>
>>> - Setting {read_concurrency, false} is the same as not specifying it (so in
>>> effect 2 of the tests are the same)
>>>
>>> cheers
>>> Chandru
>>>
>>>
>>> On 14 May 2015 at 11:29, Viacheslav V. Kovalev <kovyl2404@REDACTED> wrote:
>>>>
>>>> Hi, List!
>>>>
>>>> I'm playing with ets tweaks and specifically with read_concurrency.
>>>> I've written simple test to measure how this tweak impacts on read
>>>> performance. Test implementations is here
>>>> https://gist.github.com/kovyl2404/826a51b27ba869527910
>>>>
>>>> Briefly, this test sequentially creates three [public, set] ets tables
>>>> with different read_concurrency options (without any tweaks, with
>>>> {read_concurrency, true} and with {read_concurrency, false}). After
>>>> one table created, test pupulates table with some random data and runs
>>>> N readers (N is power of 2 from 4 to 1024). Readers performs K random
>>>> reads and exists.
>>>>
>>>> Result is quite surprising for me. There absolutely no difference
>>>> between 3 these tests. I have run this test on Erlang 17 on 2-, 8-,
>>>> and 64-core machines and could not find any significant performance
>>>> impact from this tweak.
>>>>
>>>> Could anybody explain usecase of this tweak? What should I do to see
>>>> any difference and understand when to use this option?
>>>> _______________________________________________
>>>> erlang-questions mailing list
>>>> erlang-questions@REDACTED
>>>> http://erlang.org/mailman/listinfo/erlang-questions
>>>
>>>
>> _______________________________________________
>> erlang-questions mailing list
>> erlang-questions@REDACTED
>> http://erlang.org/mailman/listinfo/erlang-questions
>