[erlang-questions] Ets read concurrency tweak

[Hynek Vychodil]

I think you have to add at least few writes to see the difference. In your
case, all your scheduler threads have soon read lock (RO copy in their CPU
cache), so there is no effect of more granular locks.

On Thu, May 14, 2015 at 8:40 PM, Viacheslav V. Kovalev <kovyl2404@REDACTED>
wrote:

> 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
> >
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20150514/0783032b/attachment.htm>