|
по поводу тормозов lock
|
|||
---|---|---|---|
#18+
случайно мне тут попалась статья на мсдн про spinlock http://msdn.microsoft.com/ru-ru/library/dd460716(v=vs.110).aspx дай думаю быстро наколбашу тестик и посмотрю как все стало круто и быстро. Да и добавлю еще concurrentcollection. Вообщем, товарищи, я расстроился. тест тут: Код: c# 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.
результат у меня такой: авторelapsed ms with lock: 7482 elapsed ms with spinlock: 6795 elapsed ms with concurrent: 7830 Press a key и это при диком колбасе в 10000000 итераций. "я думал лучше будет". Обсудите. ... |
|||
:
Нравится:
Не нравится:
|
|||
20.10.2014, 22:56 |
|
по поводу тормозов lock
|
|||
---|---|---|---|
#18+
netivan , А что тут обсуждать? Ваш бенчмарк надо срочно выкинуть на помойку, и никому никогда не показывать, так как он некорректен, и сравнивает теплое с мягким. Почитайте на досуге про трудности написания микробенчмарков. Если вкратце, то вы сейчас измеряете не скорость работы локов, а скорость пута в очередь, скорость боксинга, и скорость ToString(). ... |
|||
:
Нравится:
Не нравится:
|
|||
21.10.2014, 10:03 |
|
по поводу тормозов lock
|
|||
---|---|---|---|
#18+
А чего обсуждать то? Запускаете таски, значит уже детерминированное время. Да и всего 4 конкурирующих потока - маловато. Попробуйте еще через Interlocked.Exchange: СТАРТ: Код: c# 1. 2. 3.
СТОП: Код: c# 1. 2. 3.
В ТЕЛЕ ПОТОКА: Код: c# 1. 2. 3. 4. 5. 6.
... |
|||
:
Нравится:
Не нравится:
|
|||
21.10.2014, 10:16 |
|
по поводу тормозов lock
|
|||
---|---|---|---|
#18+
Arm79А чего обсуждать то? Запускаете таски, значит уже детерминированное время. Да и всего 4 конкурирующих потока - маловато. Попробуйте еще через Interlocked.Exchange: СТАРТ: Код: c# 1. 2. 3.
СТОП: Код: c# 1. 2. 3.
В ТЕЛЕ ПОТОКА: Код: c# 1. 2. 3. 4. 5. 6.
не то чтобы обсуждать, а просто принимать во внимание,что посты "лок тормозит" смешны. И не кидаться все переписывать. Т.к. весьма сомнительный выигрыш. Через Интрлок сегодня добавлю. авторА что тут обсуждать? Ваш бенчмарк надо срочно выкинуть на помойку, и никому никогда не показывать, так как он некорректен, и сравнивает теплое с мягким. Почитайте на досуге про трудности написания микробенчмарков. Если вкратце, то вы сейчас измеряете не скорость работы локов, а скорость пута в очередь, скорость боксинга, и скорость ToString(). я измеряю относительную скорость. ... |
|||
:
Нравится:
Не нравится:
|
|||
21.10.2014, 10:21 |
|
по поводу тормозов lock
|
|||
---|---|---|---|
#18+
netivanне то чтобы обсуждать, а просто принимать во внимание,что посты "лок тормозит" смешны. И не кидаться все переписывать. Т.к. весьма сомнительный выигрыш. Через Интрлок сегодня добавлю. Вообще в вашем тесте нет нелоковых вариантов. concurrent* коллекции сплошь заполнены volatile полями, что означает постоянные обращения к оперативке для синхронизации значений. То есть это УЖЕ не быстро, особенно если подобных обращений миллионы. Идеальным был бы код вообще без локов и какой либо синхронизации. Данные размещаешь в стэк, компилятор удачно раскидывает их по регистрам процессора, потоки автономно крутятся на процессоре, все очень быстро. PS Interlocked гарантирует атомарное обращение к полю класса, а не блокировку участка кода. Вам придется помучаться с ним, чтобы синтетический тест сделать адекватным. ... |
|||
:
Нравится:
Не нравится:
|
|||
21.10.2014, 10:32 |
|
по поводу тормозов lock
|
|||
---|---|---|---|
#18+
Arm79netivanне то чтобы обсуждать, а просто принимать во внимание,что посты "лок тормозит" смешны. И не кидаться все переписывать. Т.к. весьма сомнительный выигрыш. Через Интрлок сегодня добавлю. Вообще в вашем тесте нет нелоковых вариантов. concurrent* коллекции сплошь заполнены volatile полями, что означает постоянные обращения к оперативке для синхронизации значений. То есть это УЖЕ не быстро, особенно если подобных обращений миллионы. Идеальным был бы код вообще без локов и какой либо синхронизации. Данные размещаешь в стэк, компилятор удачно раскидывает их по регистрам процессора, потоки автономно крутятся на процессоре, все очень быстро. PS Interlocked гарантирует атомарное обращение к полю класса, а не блокировку участка кода. Вам придется помучаться с ним, чтобы синтетический тест сделать адекватным. ну тут сравнение стандартных блокирующих конструкций и slim вариантов. Режим ядра против пользовательского (вроде бы так это называется). ... |
|||
:
Нравится:
Не нравится:
|
|||
21.10.2014, 10:58 |
|
по поводу тормозов lock
|
|||
---|---|---|---|
#18+
netivanпропущено... ну тут сравнение стандартных блокирующих конструкций и slim вариантов. Режим ядра против пользовательского (вроде бы так это называется). Я всегда считал, что lock - это критическая секция, и она легковесная. Если интересна синхронизация уровня ядра, используйте Mutex либо именованный Event. ... |
|||
:
Нравится:
Не нравится:
|
|||
21.10.2014, 11:05 |
|
по поводу тормозов lock
|
|||
---|---|---|---|
#18+
Arm79netivanпропущено... ну тут сравнение стандартных блокирующих конструкций и slim вариантов. Режим ядра против пользовательского (вроде бы так это называется). Я всегда считал, что lock - это критическая секция, и она легковесная. Если интересна синхронизация уровня ядра, используйте Mutex либо именованный Event. с Net 4. втирают при гибридные конструкции, которые обеспечивают супер производительность :) ... |
|||
:
Нравится:
Не нравится:
|
|||
21.10.2014, 12:05 |
|
по поводу тормозов lock
|
|||
---|---|---|---|
#18+
netivanс Net 4. втирают при гибридные конструкции, которые обеспечивают супер производительность :) Если речь об этом: http://habrahabr.ru/post/91027/, то не совсем. Суперпроизводительность будет только в том случае, если реального ожидания не будет. Про Interlocked я выше упоминал, он действительно шустрый. Собственно, легковесная spin-блокировка на его основе - это достойная альтернатива lock-у. В куске моего кода есть _isAllowed(), там как раз и сделан timeout. Объясню, почему sleep делается всегда на 1 - чтобы поток был отзывчивым, и смог завершить свою работу, даже когда он "спит" (-1 - никакого ожидания, связанного с переключением контекста, нет). Обращаю внимание, что мой код не предназначен для работы в многопоточной среде. У него немного другая функциональность. Я его привел для иллюстрации варианта альтернативы Monitor.Enter - while + Interlocked + Sleep: Код: c# 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18.
Но в случае конкуренции все равно будет обращение к ядру, что сравнительно тяжело. В общем, для синхронизации потоков в одном процессе применение объектов уровня ядра нецелесообразно, ввиду излишних временнЫх затрат. Если речь не идет о наносекундах, пользуйте lock и не парьтесь. ... |
|||
:
Нравится:
Не нравится:
|
|||
21.10.2014, 12:38 |
|
по поводу тормозов lock
|
|||
---|---|---|---|
#18+
Arm79, автор Если речь не идет о наносекундах, пользуйте lock и не парьтесь. примерно это и хотел сказать/ показать. Все равно вечером добавлю вариант с Interlocked. ... |
|||
:
Нравится:
Не нравится:
|
|||
21.10.2014, 12:49 |
|
по поводу тормозов lock
|
|||
---|---|---|---|
#18+
netivanArm79, автор Если речь не идет о наносекундах, пользуйте lock и не парьтесь. примерно это и хотел сказать/ показать. Все равно вечером добавлю вариант с Interlocked. хотя вот тут http://habrahabr.ru/post/91027/ разница заметна. Но ведь WaitHandle это объект ядра Windows если я правильно помню. Так что надо попробывать еще сравнить Mutex vs SlimMutex Ж) ... |
|||
:
Нравится:
Не нравится:
|
|||
21.10.2014, 12:52 |
|
по поводу тормозов lock
|
|||
---|---|---|---|
#18+
Arm79netivanне то чтобы обсуждать, а просто принимать во внимание,что посты "лок тормозит" смешны. И не кидаться все переписывать. Т.к. весьма сомнительный выигрыш. Через Интрлок сегодня добавлю. Вообще в вашем тесте нет нелоковых вариантов. concurrent* коллекции сплошь заполнены volatile полями, что означает постоянные обращения к оперативке для синхронизации значений. То есть это УЖЕ не быстро, особенно если подобных обращений миллионы. Идеальным был бы код вообще без локов и какой либо синхронизации. Данные размещаешь в стэк, компилятор удачно раскидывает их по регистрам процессора, потоки автономно крутятся на процессоре, все очень быстро. PS Interlocked гарантирует атомарное обращение к полю класса, а не блокировку участка кода. Вам придется помучаться с ним, чтобы синтетический тест сделать адекватным.Я же вам вроде объяснял, что volatile не означает, что каждое обращение лезет именно в оперативу, не? ... |
|||
:
Нравится:
Не нравится:
|
|||
21.10.2014, 17:31 |
|
по поводу тормозов lock
|
|||
---|---|---|---|
#18+
cdtyjvЯ же вам вроде объяснял, что volatile не означает, что каждое обращение лезет именно в оперативу, не? 1) Если хочется пообщаться конкретно со мной, пишите на почту 2) Если речь идет о демонстрации своих знаний/исправлении неточностей в предыдущих комментах - нужно писать более подробно, с указанием места ошибки/неточности Мы в прошлый раз договорились до того, что отнюдь не во всех случаях volatile нужен. Во многих - можно прекрасно обойтись и без него. Более того, не самая простая концепция этого volatile (+ограничение по доступным типам) провоцирует ошибки. Нужно быть проще - использовать concurrent-коллекции или банальный lock. Теперь что касается оперативки. У вас есть данные, отрицающие, что распространение изменений, внесенных в кэш на одном процессоре, на другие происходит через оперативную память? ... |
|||
:
Нравится:
Не нравится:
|
|||
21.10.2014, 18:04 |
|
по поводу тормозов lock
|
|||
---|---|---|---|
#18+
Arm79, Гуглите по фразе cache snooping ... |
|||
:
Нравится:
Не нравится:
|
|||
21.10.2014, 19:05 |
|
по поводу тормозов lock
|
|||
---|---|---|---|
#18+
cdtyjvArm79, Гуглите по фразе cache snooping Давайте не будем углубляться в гугление. Там много мусора всплыло, разбираться дорого. Вы сразу ссылку на наиболее адекватное изложение материала дайте ... |
|||
:
Нравится:
Не нравится:
|
|||
21.10.2014, 19:37 |
|
по поводу тормозов lock
|
|||
---|---|---|---|
#18+
cdtyjvArm79, Гуглите по фразе cache snooping Давайте не будем углубляться в гугление. Там много мусора всплыло, разбираться дорого. Вы сразу ссылку на наиболее адекватное изложение материала дайте ... |
|||
:
Нравится:
Не нравится:
|
|||
21.10.2014, 19:37 |
|
по поводу тормозов lock
|
|||
---|---|---|---|
#18+
Arm79Давайте не будем углубляться в гугление. Там много мусора всплыло, разбираться дорого. Вы сразу ссылку на наиболее адекватное изложение материала дайтеЕсли вы не будете углубляться, то так и не разберетесь в архитектуре компьютеров. Предположите следующую ситуацию. У вас есть два процессора, два кэша. Первый процессор запрашивает адрес A, к которому никто раньше не обращался. Ему приходится идти в память, которая находится на другом конце материнской платы. Через какое-то время второй процессор так же запрашивает адрес А. Как вы думаете, можно ли реализовать такую оптимизацию, что если процессору 2 нужен адрес, который уже есть в процессоре 1, то вместо того, что бы идти в память, можно получить значение из кэша процессора 1? ... |
|||
:
Нравится:
Не нравится:
|
|||
21.10.2014, 20:22 |
|
по поводу тормозов lock
|
|||
---|---|---|---|
#18+
cdtyjvArm79Давайте не будем углубляться в гугление. Там много мусора всплыло, разбираться дорого. Вы сразу ссылку на наиболее адекватное изложение материала дайтеЕсли вы не будете углубляться, то так и не разберетесь в архитектуре компьютеров. Предположите следующую ситуацию. У вас есть два процессора, два кэша. Первый процессор запрашивает адрес A, к которому никто раньше не обращался. Ему приходится идти в память, которая находится на другом конце материнской платы. Через какое-то время второй процессор так же запрашивает адрес А. Как вы думаете, можно ли реализовать такую оптимизацию, что если процессору 2 нужен адрес, который уже есть в процессоре 1, то вместо того, что бы идти в память, можно получить значение из кэша процессора 1? Давайте вы свой поучительный тон оставите для студентов вашего курса? Эти намеки и прочее только раздражают. Вы либо кидаете ссылку, где это обстоятельно рассказывают, либо рассказываете сами. ... |
|||
:
Нравится:
Не нравится:
|
|||
21.10.2014, 23:45 |
|
по поводу тормозов lock
|
|||
---|---|---|---|
#18+
Arm79 , То есть, разбираться самостоятельно вы не хотите, хотя я привел вам название механизма, который это реализует. Ну вот вам статейка, например: http://www.realworldtech.com/common-system-interface/5/ Но она уже достаточно специализирована. Надо начинать с азов - как в принципе устроен кэш, что такое MESI, что такое store forwarding, store buffer, invalidate queue, NUMA, и т.д.. Ключевая выдержка из статьи: авторIntel’s solution to this issue is rather elegant. They adapted the standard MESI protocol to include an additional state, the Forwarding (F) state, and changed the role of the Shared (S) state. In the MESIF protocol, only a single instance of a cache line may be in the F state and that instance is the only one that may be duplicated [3]. Other caches may hold the data, but it will be in the shared state and cannot be copied. In other words, the cache line in the F state is used to respond to any read requests , while the S state cache lines are now silent. This makes the line in the F state a first amongst equals, when responding to snoop requests. By designating a single cache line to respond to requests, coherency traffic is substantially reduced when multiple copies of the data exist. ... |
|||
:
Нравится:
Не нравится:
|
|||
21.10.2014, 23:59 |
|
по поводу тормозов lock
|
|||
---|---|---|---|
#18+
Зачем топик засрали? Память в отдельной ветке можно обсуждать ... |
|||
:
Нравится:
Не нравится:
|
|||
22.10.2014, 00:04 |
|
по поводу тормозов lock
|
|||
---|---|---|---|
#18+
На пальцах это выглядит примерно так. Предположим, что у нас есть два процессора. Когда первый процессор запрашивает адрес А, он должен отправить куда-то запрос на это. Куда? В шину данных. А шину данных одновременно слушает и оперативка, и кэш второго процессора. Поэтому, когда первый кэш отправит запрос на чтение A, этот запрос придет и во второй кэш. И этот второй кэш ответит первому значительно быстрее, чем медленная оператива. Вот и вся магия. Как на это влияет volatile? Никак, на уровне железа понятия volatile нет. Там есть специальные команды синхронизации кэшей, вроде префикса "lock" на x86. Но что бы понять, как эта синхронизация работает, вам надо понимать работу MESI, а вы не хотите "углубляться" во все это. Так вот, volatile, что в .Net, что в Java, работает одинаково: 1) Он запрещает оптимизации доступа к переменной на уровне JIT-компилятора. 2) Он добавляет инструкции синхронизации кэшей вокруг этих переменных. Например, в Java на x86 это инструкция "lock addl(0, esp)" - то есть прибаление нуля к значению текущего указателя стэка. Сама по себе операция смысла не имеет, но префикс lock запрещает процессору заниматься спекуляциями в окресностях этой команды, а так же заставляет предыдущие записи, сидящие в store buffer, синхронизироваться с кэшами других процессоров. Ну да ладно, это дебри уже. Важно понимать, что volatile сам по себе никак не может влиять на то, откуда будет прочитано значение переменной - из кэша текущего процессора, кэша другого процессора, или из оперативы. Это зависит только от того, что (и в каком состоянии) сейчас находится в кэшах процессора. ... |
|||
:
Нравится:
Не нравится:
|
|||
22.10.2014, 00:11 |
|
по поводу тормозов lock
|
|||
---|---|---|---|
#18+
netivanЗачем топик засрали? Память в отдельной ветке можно обсуждатьНу дак с вашей темой мы же разобрались уже - там бенчмарки некорректные, нет предмета обсуждения. ... |
|||
:
Нравится:
Не нравится:
|
|||
22.10.2014, 00:13 |
|
по поводу тормозов lock
|
|||
---|---|---|---|
#18+
cdtyjvНа пальцах это выглядит примерно так. Предположим, что у нас есть два процессора. Когда первый процессор запрашивает адрес А, он должен отправить куда-то запрос на это. Куда? В шину данных. А шину данных одновременно слушает и оперативка, и кэш второго процессора. Поэтому, когда первый кэш отправит запрос на чтение A, этот запрос придет и во второй кэш. И этот второй кэш ответит первому значительно быстрее, чем медленная оператива. Вот и вся магия. Как на это влияет volatile? Никак, на уровне железа понятия volatile нет. Там есть специальные команды синхронизации кэшей, вроде префикса "lock" на x86. Но что бы понять, как эта синхронизация работает, вам надо понимать работу MESI, а вы не хотите "углубляться" во все это. Так вот, volatile, что в .Net, что в Java, работает одинаково: 1) Он запрещает оптимизации доступа к переменной на уровне JIT-компилятора. 2) Он добавляет инструкции синхронизации кэшей вокруг этих переменных. Например, в Java на x86 это инструкция "lock addl(0, esp)" - то есть прибаление нуля к значению текущего указателя стэка. Сама по себе операция смысла не имеет, но префикс lock запрещает процессору заниматься спекуляциями в окресностях этой команды, а так же заставляет предыдущие записи, сидящие в store buffer, синхронизироваться с кэшами других процессоров. Ну да ладно, это дебри уже. Важно понимать, что volatile сам по себе никак не может влиять на то, откуда будет прочитано значение переменной - из кэша текущего процессора, кэша другого процессора, или из оперативы. Это зависит только от того, что (и в каком состоянии) сейчас находится в кэшах процессора. Не успел ответить до этого сообщения. Неужели трудно было в двух словах сказать - существуют протоколы когерентности кэшей (например, MESI), согласно которым кэши могут обмениваться информацией вне оперативки? Зачем были эти ненужные сообщения? Будем считать, что вы уточнили мое сообщение, что не только через оперативку, заодно просветили меня по поводу аппаратной части. Что касается cdtyjvЕсли вы не будете углубляться, то так и не разберетесь в архитектуре компьютеров. то мне это уже не нужно, я закончил (по крайней мере как с основным источником дохода) с программированием в 2013 году. Теперь это хобби :-) Ну и фриланс совсем помаленечку, чтобы не забывать ... |
|||
:
Нравится:
Не нравится:
|
|||
22.10.2014, 00:24 |
|
по поводу тормозов lock
|
|||
---|---|---|---|
#18+
Arm79Не успел ответить до этого сообщения. Неужели трудно было в двух словах сказать - существуют протоколы когерентности кэшей (например, MESI), согласно которым кэши могут обмениваться информацией вне оперативки? Зачем были эти ненужные сообщения?Елы палы: 1) Открыть Гугл; 2) Вбить "cache snooping", как я и предлагал; 3) Открыть первый результат: http://en.wikipedia.org/wiki/Bus_sniffing 4) Прочитать первую строчку: "Bus sniffing or Bus snooping is a technique used in distributed shared memory systems and multiprocessors to achieve cache coherence ." Я же не знал, что вы настолько ленивый :-) ... |
|||
:
Нравится:
Не нравится:
|
|||
22.10.2014, 00:44 |
|
|
start [/forum/topic.php?fid=20&msg=38782659&tid=1402329]: |
0ms |
get settings: |
9ms |
get forum list: |
13ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
42ms |
get topic data: |
9ms |
get forum data: |
2ms |
get page messages: |
55ms |
get tp. blocked users: |
1ms |
others: | 336ms |
total: | 473ms |
0 / 0 |