|
|
|
test synchronized vs ReentrantLock
|
|||
|---|---|---|---|
|
#18+
ваш тест некорректен по следующим причинам (включая, но наверняка не ограничиваясь ими): - переменная counter не используется, т.е., компилятор имеет право выбросить ее, а значит и выбросить циклы. И он это сделает, как только поймет это. Спасет ли чтение волатильной переменной (условие i < N в цикле for), если цикл пустой? Хз, точно сказать не могу. - нет гарантии, что потоки выполняются параллельно. Система имеет полное право отработать так: сначала отрабатывает 1 и завершается поток, потом второй и тд. При этом видимость одновременного доступа есть, но по факту доступ последовательный, а это значит что кешлайн не гуляет между ядрами, и вы не нарываетесь на такую штуку как flase sharing (в данном случае это корректней обозвать true sharing потому что переменная одна, но механизм тот же). А раз вы на нее не нарываетесь, то примерно раз в 20...100 оно будет работать быстрей. - для работы снхронизедов надо, чтобы чтобы компилятор собрал профиль и откомпилил код. Пока он этого не сделает, оно может работать хуже. таким образом вы померяли неверно. У вас что-то померялось, но не то. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.10.2013, 13:16 |
|
||
|
test synchronized vs ReentrantLock
|
|||
|---|---|---|---|
|
#18+
Хм... AtomicInteger реализован как вызовы класса Unsafe. Возможно синхронизация этих сущностей вынесена из JVM во вне для скорости. Код: java 1. 2. 3. 4. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.10.2013, 14:09 |
|
||
|
test synchronized vs ReentrantLock
|
|||
|---|---|---|---|
|
#18+
mayton, ты ли это? Atomic реализованы на CAS на уровне команд процессора. Естественно никакой Java API для этого не используется. Только натив. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.10.2013, 14:11 |
|
||
|
test synchronized vs ReentrantLock
|
|||
|---|---|---|---|
|
#18+
Это я. И это просто рассуждения вслух. Просто разбираясь с оптимизацией перформанса полезно знать стек. Тоесть что чего вызывает и что от чего зависит. ТС-у полезно также знать что механизмы синхронизации Java построенные на других механизмах Java вряд-ли дадут ему особый прирост скорости. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.10.2013, 14:39 |
|
||
|
test synchronized vs ReentrantLock
|
|||
|---|---|---|---|
|
#18+
chabapokваш тест некорректен по следующим причинам (включая, но наверняка не ограничиваясь ими): - переменная counter не используется, т.е., компилятор имеет право выбросить ее, а значит и выбросить циклы. И он это сделает, как только поймет это. Спасет ли чтение волатильной переменной (условие i < N в цикле for), если цикл пустой? Хз, точно сказать не могу. Жду от вас корректного теста и результатов :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.10.2013, 19:49 |
|
||
|
test synchronized vs ReentrantLock
|
|||
|---|---|---|---|
|
#18+
Atum1Жду от вас корректного теста и результатов :)Коллега, вы совершенно зря язвите. Вы будете удивлены, но написать качественный многопоточный бенчмарк какого-нибудь реального сценария, в котором есть СУБД, сокеты, работа с файловой системой, и прочие прелести, в разы проще , чем написать качественный бенчмарк, который измерит какой-нибудь volatile vs non-volatile или synchronized vs ReentrantLock. Еще раз акцентирую ваше внимание: в разы проще . Это как в физике. Когда вы рассматриваете тела макроскопически, то это обычная материя, к которой применимы, например, законы Ньютона. Но когда вы спускаетесь на квантовый уровень, вы сразу же начинаете охреневать от неопределенности Гейзенберга, корпусклуярно-волнового Дуализма и прочих "прелестей". В микромире законы маркомира не работают. Микромир значительно сложнее. И Java тут не является исключением. Если хотите лучше понимать, что происходит на таких уровнях, то рекомендую вам сделать следующее: 1) Почитать Java Concurreny in Practice - для разгона 2) Почитать The Art of Multiprocessor Programming - что бы понимать, как создавали классы из java.util.concurrent, тут уже ягодки идут 3) Почитать папИр Дага Ли, в котором он рассказывает, как создавался AbstractQueueSynchronzer: http://gee.cs.oswego.edu/dl/papers/aqs.pdf 4) Подписаться на мэилинг-лист concurrency-interest 5) Посмотреть презенташки по многопоточности из JUG.RU: http://vk.com/jugru 6) Почитать и пощупать Шипилевский JMH. Вот когда сделаете это, тогда и будете здесь подстебывать мемберов, и пытаться брать их "на слабо". А сейчас "слабо" вам, так что лучше не отвергать предлагаемую помощь, и слушать советы. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.10.2013, 20:17 |
|
||
|
test synchronized vs ReentrantLock
|
|||
|---|---|---|---|
|
#18+
cdtyjv, обычно уже на 3-4 пункте начинаешь осознавать свою неполноценность:) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.10.2013, 20:23 |
|
||
|
test synchronized vs ReentrantLock
|
|||
|---|---|---|---|
|
#18+
cdtyjvМикромир значительно сложнееПроще. Но от этого не легче. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.10.2013, 20:31 |
|
||
|
test synchronized vs ReentrantLock
|
|||
|---|---|---|---|
|
#18+
cdtyjvВот когда сделаете это, тогда и будете здесь подстебывать мемберов, и пытаться брать их "на слабо". А сейчас "слабо" вам, так что лучше не отвергать предлагаемую помощь, и слушать советы. Да я и не подстебывал . все замечания описанные выше имеют место быть. А так же опираясь на Ваш тезис о микромире - можно сказать след. А что мешает : А) переменная counter не используется - а может и используется. или сделать простую проверку чтобы она использовалась. Б) нет гарантии, что потоки выполняются параллельно - но и нет опровержения. В) для работы снхронизедов надо, чтобы чтобы компилятор собрал профиль и откомпилил код - если добавить более четкие параметры для кода - получим точно такую же ситуацию - исходя из пунктов А и Б. Это JAVAAAA (c) - тут вообще нет честных тестов :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.10.2013, 20:41 |
|
||
|
test synchronized vs ReentrantLock
|
|||
|---|---|---|---|
|
#18+
Atum1, От меня корректного теста не будет, по той причине что я сам пока не знаю как это померять. Когда-то скачивал jmh - и не понял его. Документировано там все слабовато, и есть самоисключающие примеры. Самоисключающие - это когда результаты теста противоречат сами себе. Так и не понял, как им пользоваться. Верней, как пользоваться ясно, но как правильно написать тест и померять именно то, что я хочу - неясно. И судя по тому как вы злитесь, подстебнули не вы меня, а я вас. :) Сам меряю производительность так: пишутся варианты реальной программы и ей подсовываю данные близкие к реальным. На микроуровне я уже понял, что тестить что-то бесполезно. Насчет используется/не используется тоже не все так очевидно. На самом деле, использовать переменную просто - выводим ее на печать. Только такое использование спасет от оптимизации "выбрасывания", но не спасет от оптимизации анролинга циклов, например. А просто использование проверкой тоже может быть оптимизировано, если оно не несет смысловой нагрузки. > Б) нет гарантии, что потоки выполняются параллельно - но и нет опровержения. вот я и говорю - мы меряем непонятно что. из личных практических наблюдеий - если есть 10 потоков, то эти потоки по факту стартуют не в той последовательности как их запускаешь в цикле. Следовательно, как минимум, часть инкрементов была выполнена без реальной конкуренции за данные, а значит и завершение потоков было не одновременным на сколько-то. Это с высокой вероятностью можно предполагать. ps. Посмотрите исходники ReentrantLock, может накопаете чего интересного. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.10.2013, 14:53 |
|
||
|
test synchronized vs ReentrantLock
|
|||
|---|---|---|---|
|
#18+
chabapokОт меня корректного теста не будет, по той причине что я сам пока не знаю как это померять. Что-то ты перемудрил. И так везде пишут что при высокрой нагруженности ReentrantLock более производительный чем synchronized, что тест выше и показал. Но в реальности это ничего не даёт. Так как подобная конкуренция встречается не часто. А при низкой конкурентности synchronized покажет лучшие результаты. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.10.2013, 14:56 |
|
||
|
test synchronized vs ReentrantLock
|
|||
|---|---|---|---|
|
#18+
Blazkowicz, Я не перемудрил, я привык критически смотреть на то, что пишут в интернете, выборочно проверяя (в том числе с целью самообучения) некоторые утверждения. Да, ReentrantLock, да пишут. Но как повторить самому это дома - я незнаю, о чем и сообщил. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.10.2013, 23:01 |
|
||
|
test synchronized vs ReentrantLock
|
|||
|---|---|---|---|
|
#18+
chabapokНо как повторить самому это дома - Ну создаешь Код: java 1. 2. 3. 4. 5. 6. 7. 8. 9. Массивчик на 1000 инкрементеров. И два потока которые много раз пробегают по массиву (в разные стороны) и вызывают inc(). И тоже самое через Lock. Встречаться они должны не часто - вот и низкая конкуренция. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.10.2013, 12:15 |
|
||
|
test synchronized vs ReentrantLock
|
|||
|---|---|---|---|
|
#18+
Возник такой вопрос : а как построить самый быстрый счетчик - инкремент , который будет безопасно работать многопоточной среде ? что то есть быстрее AtomicInteger ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.06.2014, 23:23 |
|
||
|
test synchronized vs ReentrantLock
|
|||
|---|---|---|---|
|
#18+
Atum1Возник такой вопрос : а как построить самый быстрый счетчик - инкремент , который будет безопасно работать многопоточной среде ? что то есть быстрее AtomicInteger ? Есть. Каждому потоку выдать по своему счетчику и в конце просуммировать по всем потокам. На сколько я помню, должно быть быстрее AtomicInteger. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.06.2014, 23:31 |
|
||
|
test synchronized vs ReentrantLock
|
|||
|---|---|---|---|
|
#18+
Atum1 , LongAdder. Основан на другом принципе - инкременты с разных потоков идут в разные переменные, тем самым снижая contention. А когда надо получить сумму - просто проходим по ним, и суммируем. Для точных вычислений он не пригоден, но очень резв. С другой стороны, начиная с Java7 для CASов стандартных атомиков сделаны интринсики, которые устремляют к нулю количество "обломов" на одновременных CAS-ах с разных потоков, поэтому с выходом Java7 атомики стали заметно шустрее на некоторых платформах, включая наш родной x86. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.06.2014, 23:34 |
|
||
|
test synchronized vs ReentrantLock
|
|||
|---|---|---|---|
|
#18+
Вернее, не для самих CASов, а для некоторых других методов, которые основаны на них. Например, incrementAndGet(), addAndGet() и т.д.. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.06.2014, 23:40 |
|
||
|
test synchronized vs ReentrantLock
|
|||
|---|---|---|---|
|
#18+
О! спасибо! как раз нашел https://github.com/takipi/counters-benchmark/tree/master/src/main/java/com/takipi/tests/counters/implementations и описание : http://www.takipiblog.com/2014/04/16/java-8-longadders-the-fastest-way-to-add-numbers-concurrently/ видимо не я один такими вопросами задаюсь :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.06.2014, 23:52 |
|
||
|
test synchronized vs ReentrantLock
|
|||
|---|---|---|---|
|
#18+
Вспомнив, что ускорение на порядок куска кода, занимающего десять процентов общего времени даёт (всего) девять процентов выигрыша, начинаешь прикидывать - стОит ли вообще овчинка выделки?.. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.06.2014, 02:11 |
|
||
|
test synchronized vs ReentrantLock
|
|||
|---|---|---|---|
|
#18+
Basil A. Sidorov, ну хз.... может в торговых система и имеет :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.06.2014, 13:59 |
|
||
|
test synchronized vs ReentrantLock
|
|||
|---|---|---|---|
|
#18+
Кто может объяснить на каких операциях будет разница между этими типами : AtomicInteger vs LongAdder vs LongAccumulator http://winterbe.com/posts/2015/05/22/java8-concurrency-tutorial-atomic-concurrent-map-examples/ написал тест такого плана - разницу не увидел , почему ? только от N=10000000 - но там и погрешность есть ... Код: java 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43. 44. 45. 46. 47. 48. 49. 50. 51. 52. 53. 54. 55. 56. 57. 58. 59. 60. 61. 62. 63. 64. 65. 66. 67. 68. 69. 70. 71. 72. 73. 74. 75. 76. 77. 78. 79. 80. 81. 82. 83. 84. 85. 86. 87. 88. 89. 90. 91. 92. 93. 94. 95. 96. 97. 98. 99. 100. 101. 102. 103. 104. 105. 106. 107. 108. 109. 110. 111. 112. 113. 114. 115. 116. 117. 118. 119. 120. 121. 122. Код: vbnet 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.07.2015, 10:54 |
|
||
|
test synchronized vs ReentrantLock
|
|||
|---|---|---|---|
|
#18+
Atum1, Разницы не видно из-за того, что бенчамарк тестирует не счетчики, а создание и остановку потоков. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.07.2015, 14:09 |
|
||
|
test synchronized vs ReentrantLock
|
|||
|---|---|---|---|
|
#18+
schwaAtum1, Разницы не видно из-за того, что бенчамарк тестирует не счетчики, а создание и остановку потоков. ??? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.07.2015, 15:01 |
|
||
|
test synchronized vs ReentrantLock
|
|||
|---|---|---|---|
|
#18+
Atum1, Код: java 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. Что делает этот код? 1 - создать 4 потока 2 - выполнить какой-то код в 4 потоках 3 - остановить потоки Шаги 1 и 3 в сумме съедают больше времени, чем суммирование счетчиков. Из-за того, что у вашем бенчмарке фиксированное число потоков (при этом очень маленькое), вы иногируете тот факт, что классы LongAdder и LongAccumulator разработаны для совершенно иной ситуации - когда потоков много и они соревнуются между собой за одну единствунную ячейку памяти. Вот результат бенчмарка, запущенного на n1-standard x16 CPU виртуалке на Google Compute Engine Код: html 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. Характеристики виртуалки $ lscpu Architecture: x86_64 CPU op-mode(s): 32-bit, 64-bit Byte Order: Little Endian CPU(s): 8 On-line CPU(s) list: 0-7 Thread(s) per core: 2 Core(s) per socket: 4 Socket(s): 1 NUMA node(s): 1 Vendor ID: GenuineIntel CPU family: 6 Model: 45 Model name: Intel(R) Xeon(R) CPU @ 2.60GHz Stepping: 7 CPU MHz: 2600.000 BogoMIPS: 5200.00 Hypervisor vendor: KVM Virtualization type: full L1d cache: 32K L1i cache: 32K L2 cache: 256K L3 cache: 20480K NUMA node0 CPU(s): 0-7 Сам бенчмарк, не претендует на идеал, но по крайней мере здесь всеми потоками рулит JMH и, следовательно, числа в итогом отчете содержат минимум шума. Можно запустить побольше форков и поиграться со счетчиком в цикле, но отличия в производительности уже и так есть (что не удивительно). java -jar target/benchmarks.jar -wi 10 -i 10 -f 1 Код: java 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43. 44. 45. 46. 47. 48. 49. 50. 51. 52. 53. 54. 55. 56. 57. 58. 59. 60. 61. 62. 63. 64. 65. 66. 67. 68. 69. 70. 71. 72. 73. 74. 75. 76. 77. 78. 79. 80. 81. 82. 83. 84. 85. 86. 87. 88. 89. 90. 91. 92. 93. 94. 95. 96. 97. 98. 99. 100. 101. 102. 103. 104. 105. 106. 107. 108. 109. 110. 111. 112. 113. 114. 115. 116. 117. 118. 119. 120. 121. 122. 123. 124. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.07.2015, 00:24 |
|
||
|
|

start [/forum/topic.php?fid=59&msg=38436925&tid=2125136]: |
0ms |
get settings: |
6ms |
get forum list: |
10ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
142ms |
get topic data: |
10ms |
get forum data: |
2ms |
get page messages: |
59ms |
get tp. blocked users: |
1ms |
| others: | 213ms |
| total: | 449ms |

| 0 / 0 |
