multithreading - Ets read concurrency tweak -

i'm playing ets tweaks , read_concurrency. i've written simple test measure how tweak impacts on read performance. test implementations here , there.

briefly, test sequentially creates 3 [public, set] ets tables different read_concurrency options (without tweaks, {read_concurrency, true} , {read_concurrency, false}). after 1 table created, test runs n readers (n power of 2 4 1024). readers performs random reads 10 seconds , reports how many read operation have performed.

result quite surprising me. there absolutely no difference between 3 these tests. here test result.

non-tweaked table 4 workers: 26610428 read operations 8 workers: 26349134 read operations 16 workers: 26682405 read operations 32 workers: 26574700 read operations 64 workers: 26722352 read operations 128 workers: 26636100 read operations 256 workers: 26714087 read operations 512 workers: 27110860 read operations 1024 workers: 27545576 read operations read concurrency true 4 workers: 30257820 read operations 8 workers: 29991281 read operations 16 workers: 30280695 read operations 32 workers: 30066830 read operations 64 workers: 30149273 read operations 128 workers: 28409907 read operations 256 workers: 28381452 read operations 512 workers: 29253088 read operations 1024 workers: 30955192 read operations read concurrency false 4 workers: 30774412 read operations 8 workers: 29596126 read operations 16 workers: 24963845 read operations 32 workers: 29144684 read operations 64 workers: 29862287 read operations 128 workers: 25618461 read operations 256 workers: 27457268 read operations 512 workers: 28751960 read operations 1024 workers: 28790131 read operations

so i'm wondering how should implement test see difference , realize usecase optimization?

i have run test on following installations:

1. 2-core, 1 physical cpu, erlang/otp 17 [erts-6.1] [64-bit] [smp:2:2] [async-threads:10] [hipe] [kernel-poll:false] (example test output run)
2. 2-core, 1 physical cpu, erlang/otp 17 [erts-6.1] [64-bit] [smp:2:2] [async-threads:10] [hipe] [kernel-poll:true]
3. 8-core 1 physical cpu, erlang/otp 17 [erts-6.4] [source] [64-bit] [smp:8:8] [async-threads:10] [hipe] [kernel-poll:false]
4. 8-core 1 physical cpu, erlang/otp 17 [erts-6.4] [source] [64-bit] [smp:8:8] [async-threads:10] [hipe] [kernel-poll:true]
5. 64-core 4 physical cpu, erlang/otp 17 [erts-6.3] [source] [64-bit] [smp:64:64] [async-threads:10] [hipe] [kernel-poll:false]
6. 64-core 4 physical cpu, erlang/otp 17 [erts-6.3] [source] [64-bit] [smp:64:64] [async-threads:10] [hipe] [kernel-poll:true]

there same (except absolute measurement values, of course). tell me why? , should see difference?

upd according fred's answer, i've updated my test avoid workers of mailbox thrashing. unfortunately, there no significant change in results.

upd one another implementation according @pascal advice. workers seeding random generators. again same results.

it's possible brunt of work tests scheduling abilities of node -- half work done in benchmark polling mailbox know if should exit. requires vm switch each process, put on queue, run others, check mailboxes, etc. it's cheap do, reading ets. it's quite possible you're creating lot of noise.

an alternative approach try ask workers read n million times in table, , count how long takes until done. reduce number of non-ets work done on node , instead focus on reading table only.

i don't have guarantees, i'd bet tables more concurrency faster runs.