Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
оптимизировать доступ к массиву для многопоточного приложения
|
|||
|---|---|---|---|
|
#18+
Есть массив int, разные потоки считывают или записывают информацию. Запись происходит в 3-8 раз реже, чем считывание. Можно ли, исходя из такого соотношения для чтения и записи сделать что-то более быстрое, чем, например, блокировка с помощью mutex, atomic или spinlock? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.05.2017, 23:07 |
|
||
|
оптимизировать доступ к массиву для многопоточного приложения
|
|||
|---|---|---|---|
|
#18+
Можно вообще забить на синхронизацию. Выравненный int читается и пишется современными процессорами атомарно. Чтобы компилятор не умничал - объявить этот массив volatile. Posted via ActualForum NNTP Server 1.5 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.05.2017, 00:03 |
|
||
|
оптимизировать доступ к массиву для многопоточного приложения
|
|||
|---|---|---|---|
|
#18+
Dimitry Sibiryakov, Нет никакой необходимости писать Код: plaintext 1. , достаточно лишь написать Код: plaintext 1. и всё будет автоматически синхронизировано? А как поступать, если это не массив, а Код: plaintext 1. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.05.2017, 00:58 |
|
||
|
оптимизировать доступ к массиву для многопоточного приложения
|
|||
|---|---|---|---|
|
#18+
а если так: Код: plaintext 1. ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.05.2017, 05:08 |
|
||
|
оптимизировать доступ к массиву для многопоточного приложения
|
|||
|---|---|---|---|
|
#18+
посмотри https://github.com/khizmax/libcds её разрабатывает один местный дядька З.Ы. тема неоднократно поднималась, например http://www.sql.ru/forum/1253390/kakuu-biblioteku-posovetuete-s-potokobezopasnymi-konteynerami ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.05.2017, 05:42 |
|
||
|
оптимизировать доступ к массиву для многопоточного приложения
|
|||
|---|---|---|---|
|
#18+
baden_badenвсё будет автоматически синхронизировано? Ты бы поподробней описал что конкретно понимаешь под "синхронизировано". volatile гарантирует только что в итоге что-то будет записано и в случае с int это "что-то" будет из одного потока, т.е. если два потока сделают одновременно Код: plaintext 1. то в итоге в a[0] запишется x одного из двух потоков, неизвестно какого, но итого точно не будет смесью значений x разных потоков. Атомарность - это еще изменение, т.е. "прочитать-изменить-записать" это единая операция, которую volatile не гарантирует. Если два потока выполнят Код: plaintext 1. в результате при std::atomic_int гарантированно будет +2, а с volatile может оказаться +1 В этой книге есть пара глав разъясняющих разницу между volatile и std::atomic baden_badenА как поступать, если это не массив, а Код: plaintext 1. Чтение/запись элементов std::map можно делать одновременно с разных потоков, но добавление/удаление элементов только под блокировкой, в т.ч. запрещающей чтение/запись. Для read-write блокировок есть std::shared_mutex, правда не везде. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.05.2017, 07:47 |
|
||
|
оптимизировать доступ к массиву для многопоточного приложения
|
|||
|---|---|---|---|
|
#18+
baden_badenЕсть массив int, разные потоки считывают или записывают информацию. Запись происходит в 3-8 раз реже, чем считывание. Можно ли, исходя из такого соотношения для чтения и записи сделать что-то более быстрое, чем, например, блокировка с помощью mutex, atomic или spinlock? ReadWriteLock C++ ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.05.2017, 09:18 |
|
||
|
оптимизировать доступ к массиву для многопоточного приложения
|
|||
|---|---|---|---|
|
#18+
kealon(Ruslan) ReadWriteLock C++ Где-то читал почему std::shared_mutex только в С++17 решили добавить: оказывается это не панацея при коротких блокировках на чтение, т.к. постоянное изменение счетчика читающих само по себе тормоз, плюс усложнение логики. В таких ситуациях std::mutex может выигрывать по скорости. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.05.2017, 10:03 |
|
||
|
оптимизировать доступ к массиву для многопоточного приложения
|
|||
|---|---|---|---|
|
#18+
Dima TДля read-write блокировок есть std::shared_mutex, правда не везде. Он эффективнее, чем Код: plaintext 1. ? Код: plaintext 1. Про него я в курсе, только вопрос в том, есть ли что-то более быстрое. ReadWriteLock C++ https://github.com/khizmax/libcds Спасибо, посмотрю. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.05.2017, 10:23 |
|
||
|
оптимизировать доступ к массиву для многопоточного приложения
|
|||
|---|---|---|---|
|
#18+
baden_badenDima TДля read-write блокировок есть std::shared_mutex, правда не везде. Он эффективнее, чем Код: plaintext 1. ? Зависит от задачи, которую ты не описал. ОС тоже не указал. Поэтому обсуждаем скорость сферических коней в вакууме. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.05.2017, 10:32 |
|
||
|
оптимизировать доступ к массиву для многопоточного приложения
|
|||
|---|---|---|---|
|
#18+
std::unordered_map быстрее чем std::map PS Ты бы привел простенький пример кода, который ускоряешь. Тогда можно будет подсказывать что лучше использовать. Есть еще другие ньюансы влияющие на скорость, например выравнивание по кэшлинии проца. Тут замеры делал. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.05.2017, 10:39 |
|
||
|
оптимизировать доступ к массиву для многопоточного приложения
|
|||
|---|---|---|---|
|
#18+
авторЗависит от задачи, которую ты не описал. ОС тоже не указал. Поэтому обсуждаем скорость сферических коней в вакууме. Интересует именно "скорость сферических коней в вакууме". std::unordered_map быстрее чем std::map Хорошо, контейнер заменили. А как уже в нём увеличить скорость при наличии только операций чтения и записи (чтение встречается чаще)? P.S. Посмотрю ссылки. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.05.2017, 10:53 |
|
||
|
оптимизировать доступ к массиву для многопоточного приложения
|
|||
|---|---|---|---|
|
#18+
baden_badenИнтересует именно "скорость сферических коней в вакууме". Если бы был один универсальный способ, то все им бы и пользовались. Но его нет, поэтому надо рассматривать конкретный случай. baden_badenХорошо, контейнер заменили. А как уже в нём увеличить скорость при наличии только операций чтения и записи (чтение встречается чаще)? Если нет добавления и удаления элементов контейнера, не надо атомарного изменения значений, то быстрее всего Код: plaintext 1. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.05.2017, 11:27 |
|
||
|
оптимизировать доступ к массиву для многопоточного приложения
|
|||
|---|---|---|---|
|
#18+
Dima Tkealon(Ruslan) ReadWriteLock C++ Где-то читал почему std::shared_mutex только в С++17 решили добавить: оказывается это не панацея при коротких блокировках на чтение, т.к. постоянное изменение счетчика читающих само по себе тормоз, плюс усложнение логики. В таких ситуациях std::mutex может выигрывать по скорости. хм, не учёл что у него запись чтение в массив, которые очень быстрые операции - ReadWriteLock действительно излишен наверное, std::mutex или критической секции за глаза хватит. Если недостаточно текущего технического предела - 40 млн локов/c, то как вариант можно предложить сделать блокировки на отдельные куски массива. Но опять же если будут частые обращения в один и тот же кусок, упрёмся в тех предел ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.05.2017, 11:57 |
|
||
|
оптимизировать доступ к массиву для многопоточного приложения
|
|||
|---|---|---|---|
|
#18+
Dimitry SibiryakovМожно вообще забить на синхронизацию. Выравненный int читается и пишется современными процессорами атомарно. Чтобы компилятор не умничал - объявить этот массив volatile. Если записывается значение, вычисленное на основании этого же или других значений - то забить нельзя, и нужны либо блокировки либо доступ через interlocked функции (или примитивы компилятора). А технически, собсно сама запись - так оно конечно, вот только ТС не указал, в чем причина блокировки. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.05.2017, 12:22 |
|
||
|
оптимизировать доступ к массиву для многопоточного приложения
|
|||
|---|---|---|---|
|
#18+
Dimitry SibiryakovЧтобы компилятор не умничал - объявить этот массив volatile. Не поможет ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.05.2017, 14:59 |
|
||
|
оптимизировать доступ к массиву для многопоточного приложения
|
|||
|---|---|---|---|
|
#18+
baden_badenЕсть массив int, разные потоки считывают или записывают информацию. Запись происходит в 3-8 раз реже, чем считывание. Можно ли, исходя из такого соотношения для чтения и записи сделать что-то более быстрое, чем, например, блокировка с помощью mutex, atomic или spinlock? На самом деле если это так, то и один мьютекс только на запись уже будет достаточно быстр. Т.е. если сделать разделяемое чтение и блокирующую чтение запись. Как -- прямо сейчас не соображу, но можно. Семафор там или что... Если массив маленький, скажем, несколько тысяч, можно его перезаписывать целиком, а не поэлементно, может тоже дать прирост. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.05.2017, 15:02 |
|
||
|
оптимизировать доступ к массиву для многопоточного приложения
|
|||
|---|---|---|---|
|
#18+
baden_badenЕсть массив int, разные потоки считывают или записывают информацию. Запись происходит в 3-8 раз реже, чем считывание. Можно ли, исходя из такого соотношения для чтения и записи сделать что-то более быстрое, чем, например, блокировка с помощью mutex, atomic или spinlock? Тут все очень сильно зависит от смысла задачи. Действительно ли потокам нужно видеть синхронное изменнение разделяемого ресурса? Если каждому потоку дать копию своего массивчика но организовать между ними протокол обновления (по времени) или по событию (наполнение очереди) то можно снизить накладные расходы на мутексы и все прочие "прямые" решения. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.05.2017, 18:32 |
|
||
|
оптимизировать доступ к массиву для многопоточного приложения
|
|||
|---|---|---|---|
|
#18+
baden_badenЗапись происходит в 3-8 раз реже, чем считывание. реже - это частота, а для понимания сути происходящего нужен коэффициент заполнения. Можно ли, исходя из такого соотношения для чтения и записи соотношения - это, возможно, скважность. 1/8 .. 1/3 времени уходит на саму запись - ускоряйте запись. А если на ожидание доступа к записи - SRW lock вкупе с ограничением единичного чтения/записи в алгоритме. что-то более быстроебыстее atomic не будет. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.05.2017, 19:14 |
|
||
|
оптимизировать доступ к массиву для многопоточного приложения
|
|||
|---|---|---|---|
|
#18+
Dima Tvolatile гарантирует только что в итоге что-то будет записаноvolatile гарантирует только то, что сайд-эффекты от вычислений будут происходить в строгом соответствии с абстрактной машиной из стандарта. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.05.2017, 14:41 |
|
||
|
оптимизировать доступ к массиву для многопоточного приложения
|
|||
|---|---|---|---|
|
#18+
Лучшая оптимизация доступа к общему ресурсу из многопоточного приложения это отсутствие такого общего ресурса. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.05.2017, 14:47 |
|
||
|
оптимизировать доступ к массиву для многопоточного приложения
|
|||
|---|---|---|---|
|
#18+
Common LispЛучшая оптимизация доступа к общему ресурсу из многопоточного приложения это отсутствие такого общего ресурса.А если у меня несколько массивов данных динамической длины, которые надо обрабатывать в реалтайме, и при этом показывать 30 кадров в секунду во весь экран? о_о ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.05.2017, 05:24 |
|
||
|
оптимизировать доступ к массиву для многопоточного приложения
|
|||
|---|---|---|---|
|
#18+
CEMbCommon LispЛучшая оптимизация доступа к общему ресурсу из многопоточного приложения это отсутствие такого общего ресурса.А если у меня несколько массивов данных динамической длины, которые надо обрабатывать в реалтайме, и при этом показывать 30 кадров в секунду во весь экран? о_о что за обработка и что рисовать нужно? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.05.2017, 08:48 |
|
||
|
оптимизировать доступ к массиву для многопоточного приложения
|
|||
|---|---|---|---|
|
#18+
Изопропилчто за обработка и что рисовать нужно?10K окружностей с физическими свойствами соударяются в 2-мерном пространстве, в зависимости от силы удара или разлетаются, или слепляются в одну или разбиваются на две. Один поток считает, второй рисует. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.05.2017, 11:21 |
|
||
|
|

start [/forum/topic.php?fid=57&msg=39455994&tid=2018172]: |
0ms |
get settings: |
9ms |
get forum list: |
12ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
225ms |
get topic data: |
8ms |
get forum data: |
2ms |
get page messages: |
54ms |
get tp. blocked users: |
1ms |
| others: | 287ms |
| total: | 604ms |

| 0 / 0 |
