|
|
|
responsiveness vs throughput
|
|||
|---|---|---|---|
|
#18+
В concurency in practice есть такой код: http://jcip.net/listings/TimedPutTakeTest.java Код: 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. и представлены результаты в виде графика: Как может такое случиться, что пропускная способность упала при увеличении тредов? Скажем на 1 потоке 8.5 op/sec а на двух потоках 4 op/sec я ожидал, что как минимум ухудшиться не должно. Из-за переключений контекста такое поведение может случиться? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.03.2017, 17:07 |
|
||
|
responsiveness vs throughput
|
|||
|---|---|---|---|
|
#18+
Как я себе это представляю. Пусть у нас есть один воркер и он делает работу за 0.5 sec latency -0.5 sec throughput - 2 op/sec добавляем ещё один поток(ядер >=2 и кроме jvm ничего не выполняется на компутере) latency -0.5 sec throughput - 4 op/sec Ну и так далее. Чем больше потоков, тем больше throughput. Или тут идёт речь про то, что исполнение сваливается на сплошное переключении контекста ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.03.2017, 17:21 |
|
||
|
responsiveness vs throughput
|
|||
|---|---|---|---|
|
#18+
Была вполне реальная ситуация. Некая задача считалась на одном пень-четыре более двадцати часов. Купили другой пень-четыре из какой-то экстрим-эдишен и время счёта упало до трёх с половиной часов. Основная разница между двумя процами - размер L2-кэша. Задаче повезло и она влезла в кэш экстремальной редакции проца. А ещё есть прикол lock-free алгоритмов, которые сначала оптимистично пытаются лезть без очереди и только если совсем не пролазит - дисциплинированно встают в очередь. В результате, при низкой конкуренции всё работает быстрее synchronised, но при высокой - может оказаться медленнее. P.S. "... а в очко - думать надо, шанс считать" (ц) "Две сорванные башни". ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.03.2017, 17:46 |
|
||
|
responsiveness vs throughput
|
|||
|---|---|---|---|
|
#18+
Basil A. SidorovБыла вполне реальная ситуация. Некая задача считалась на одном пень-четыре более двадцати часов. Купили другой пень-четыре из какой-то экстрим-эдишен и время счёта упало до трёх с половиной часов. Основная разница между двумя процами - размер L2-кэша. Задаче повезло и она влезла в кэш экстремальной редакции проца. А ещё есть прикол lock-free алгоритмов, которые сначала оптимистично пытаются лезть без очереди и только если совсем не пролазит - дисциплинированно встают в очередь. В результате, при низкой конкуренции всё работает быстрее synchronised, но при высокой - может оказаться медленнее. P.S. "... а в очко - думать надо, шанс считать" (ц) "Две сорванные башни". А в случае как на моём графике это значит, что затраты на шедулинг и создание тредов дороже чем исполнение самой задачи? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.03.2017, 19:03 |
|
||
|
responsiveness vs throughput
|
|||
|---|---|---|---|
|
#18+
Нет, это означает, что условиях авторов замеров получились "вот такие результаты". ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.03.2017, 12:43 |
|
||
|
|

start [/forum/topic.php?fid=59&msg=39416822&tid=2123083]: |
0ms |
get settings: |
10ms |
get forum list: |
15ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
84ms |
get topic data: |
10ms |
get forum data: |
3ms |
get page messages: |
59ms |
get tp. blocked users: |
2ms |
| others: | 229ms |
| total: | 420ms |

| 0 / 0 |
