Гость
Целевая тема:
Создать новую тему:
Автор:
Форумы / C++ [игнор отключен] [закрыт для гостей] / оптимизировать доступ к массиву для многопоточного приложения / 24 сообщений из 24, страница 1 из 1
18.05.2017, 23:07
    #39455719
baden_baden
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
оптимизировать доступ к массиву для многопоточного приложения
Есть массив int, разные потоки считывают или записывают информацию.
Запись происходит в 3-8 раз реже, чем считывание.
Можно ли, исходя из такого соотношения для чтения и записи сделать что-то более быстрое, чем, например, блокировка с помощью mutex, atomic или spinlock?
...
Рейтинг: 0 / 0
19.05.2017, 00:03
    #39455734
Dimitry Sibiryakov
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
оптимизировать доступ к массиву для многопоточного приложения
Можно вообще забить на синхронизацию. Выравненный int читается и пишется современными
процессорами атомарно. Чтобы компилятор не умничал - объявить этот массив volatile.
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
19.05.2017, 00:58
    #39455748
baden_baden
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
оптимизировать доступ к массиву для многопоточного приложения
Dimitry Sibiryakov,

Нет никакой необходимости писать
Код: plaintext
1.
std::atomic_int ai[10];

, достаточно лишь написать
Код: plaintext
1.
volatile int ai[10];

и всё будет автоматически синхронизировано?

А как поступать, если это не массив, а
Код: plaintext
1.
std::map<std::string, int> msi;
...
Рейтинг: 0 / 0
19.05.2017, 05:08
    #39455764
CEMb
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
оптимизировать доступ к массиву для многопоточного приложения
а если так:
Код: plaintext
1.
std::map<std::string, std::atomic<int>> msi;

?
...
Рейтинг: 0 / 0
19.05.2017, 05:42
    #39455770
m_Sla
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
оптимизировать доступ к массиву для многопоточного приложения
посмотри https://github.com/khizmax/libcds
её разрабатывает один местный дядька

З.Ы. тема неоднократно поднималась, например http://www.sql.ru/forum/1253390/kakuu-biblioteku-posovetuete-s-potokobezopasnymi-konteynerami
...
Рейтинг: 0 / 0
19.05.2017, 07:47
    #39455781
Dima T
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
оптимизировать доступ к массиву для многопоточного приложения
baden_badenвсё будет автоматически синхронизировано?
Ты бы поподробней описал что конкретно понимаешь под "синхронизировано".

volatile гарантирует только что в итоге что-то будет записано и в случае с int это "что-то" будет из одного потока, т.е. если два потока сделают одновременно
Код: plaintext
1.
a[0] = x;


то в итоге в a[0] запишется x одного из двух потоков, неизвестно какого, но итого точно не будет смесью значений x разных потоков.

Атомарность - это еще изменение, т.е. "прочитать-изменить-записать" это единая операция, которую volatile не гарантирует.

Если два потока выполнят
Код: plaintext
1.
a[0]++;


в результате при std::atomic_int гарантированно будет +2, а с volatile может оказаться +1

В этой книге есть пара глав разъясняющих разницу между volatile и std::atomic

baden_badenА как поступать, если это не массив, а
Код: plaintext
1.
std::map<std::string, int> msi;


Чтение/запись элементов std::map можно делать одновременно с разных потоков, но добавление/удаление элементов только под блокировкой, в т.ч. запрещающей чтение/запись.

Для read-write блокировок есть std::shared_mutex, правда не везде.
...
Рейтинг: 0 / 0
19.05.2017, 09:18
    #39455828
kealon(Ruslan)
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
оптимизировать доступ к массиву для многопоточного приложения
baden_badenЕсть массив int, разные потоки считывают или записывают информацию.
Запись происходит в 3-8 раз реже, чем считывание.
Можно ли, исходя из такого соотношения для чтения и записи сделать что-то более быстрое, чем, например, блокировка с помощью mutex, atomic или spinlock?

ReadWriteLock C++
...
Рейтинг: 0 / 0
19.05.2017, 10:03
    #39455860
Dima T
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
оптимизировать доступ к массиву для многопоточного приложения
kealon(Ruslan) ReadWriteLock C++
Где-то читал почему std::shared_mutex только в С++17 решили добавить: оказывается это не панацея при коротких блокировках на чтение, т.к. постоянное изменение счетчика читающих само по себе тормоз, плюс усложнение логики. В таких ситуациях std::mutex может выигрывать по скорости.
...
Рейтинг: 0 / 0
19.05.2017, 10:23
    #39455880
baden_baden
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
оптимизировать доступ к массиву для многопоточного приложения
Dima TДля read-write блокировок есть std::shared_mutex, правда не везде.
Он эффективнее, чем
Код: plaintext
1.
std::atomic<int>

?

Код: plaintext
1.
std::map<std::string, std::atomic<int>> msi;


Про него я в курсе, только вопрос в том, есть ли что-то более быстрое.

ReadWriteLock C++
https://github.com/khizmax/libcds
Спасибо, посмотрю.
...
Рейтинг: 0 / 0
19.05.2017, 10:32
    #39455891
Dima T
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
оптимизировать доступ к массиву для многопоточного приложения
baden_badenDima TДля read-write блокировок есть std::shared_mutex, правда не везде.
Он эффективнее, чем
Код: plaintext
1.
std::atomic<int>

?
Зависит от задачи, которую ты не описал. ОС тоже не указал. Поэтому обсуждаем скорость сферических коней в вакууме.
...
Рейтинг: 0 / 0
19.05.2017, 10:39
    #39455900
Dima T
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
оптимизировать доступ к массиву для многопоточного приложения
std::unordered_map быстрее чем std::map

PS Ты бы привел простенький пример кода, который ускоряешь. Тогда можно будет подсказывать что лучше использовать. Есть еще другие ньюансы влияющие на скорость, например выравнивание по кэшлинии проца. Тут замеры делал.
...
Рейтинг: 0 / 0
19.05.2017, 10:53
    #39455917
baden_baden
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
оптимизировать доступ к массиву для многопоточного приложения
авторЗависит от задачи, которую ты не описал. ОС тоже не указал. Поэтому обсуждаем скорость сферических коней в вакууме.
Интересует именно "скорость сферических коней в вакууме".
std::unordered_map быстрее чем std::map
Хорошо, контейнер заменили. А как уже в нём увеличить скорость при наличии только операций чтения и записи (чтение встречается чаще)?

P.S. Посмотрю ссылки.
...
Рейтинг: 0 / 0
19.05.2017, 11:27
    #39455969
Dima T
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
оптимизировать доступ к массиву для многопоточного приложения
baden_badenИнтересует именно "скорость сферических коней в вакууме".
Если бы был один универсальный способ, то все им бы и пользовались. Но его нет, поэтому надо рассматривать конкретный случай.
baden_badenХорошо, контейнер заменили. А как уже в нём увеличить скорость при наличии только операций чтения и записи (чтение встречается чаще)?
Если нет добавления и удаления элементов контейнера, не надо атомарного изменения значений, то быстрее всего
Код: plaintext
1.
std::unordered_map<std::string, int> msi;
...
Рейтинг: 0 / 0
19.05.2017, 11:57
    #39455994
kealon(Ruslan)
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
оптимизировать доступ к массиву для многопоточного приложения
Dima Tkealon(Ruslan) ReadWriteLock C++
Где-то читал почему std::shared_mutex только в С++17 решили добавить: оказывается это не панацея при коротких блокировках на чтение, т.к. постоянное изменение счетчика читающих само по себе тормоз, плюс усложнение логики. В таких ситуациях std::mutex может выигрывать по скорости.

хм, не учёл что у него запись чтение в массив, которые очень быстрые операции - ReadWriteLock действительно излишен наверное, std::mutex или критической секции за глаза хватит.

Если недостаточно текущего технического предела - 40 млн локов/c, то как вариант можно предложить сделать блокировки на отдельные куски массива. Но опять же если будут частые обращения в один и тот же кусок, упрёмся в тех предел
...
Рейтинг: 0 / 0
19.05.2017, 12:22
    #39456019
ну я
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
оптимизировать доступ к массиву для многопоточного приложения
Dimitry SibiryakovМожно вообще забить на синхронизацию. Выравненный int читается и пишется современными
процессорами атомарно. Чтобы компилятор не умничал - объявить этот массив volatile.

Если записывается значение, вычисленное на основании этого же или других значений - то забить нельзя, и нужны либо блокировки либо доступ через interlocked функции (или примитивы компилятора). А технически, собсно сама запись - так оно конечно, вот только ТС не указал, в чем причина блокировки.
...
Рейтинг: 0 / 0
19.05.2017, 14:59
    #39456205
MasterZiv
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
оптимизировать доступ к массиву для многопоточного приложения
Dimitry SibiryakovЧтобы компилятор не умничал - объявить этот массив volatile.


Не поможет
...
Рейтинг: 0 / 0
19.05.2017, 15:02
    #39456212
MasterZiv
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
оптимизировать доступ к массиву для многопоточного приложения
baden_badenЕсть массив int, разные потоки считывают или записывают информацию.
Запись происходит в 3-8 раз реже, чем считывание.
Можно ли, исходя из такого соотношения для чтения и записи сделать что-то более быстрое, чем, например, блокировка с помощью mutex, atomic или spinlock?

На самом деле если это так, то и один мьютекс только на запись уже будет достаточно быстр.
Т.е. если сделать разделяемое чтение и блокирующую чтение запись. Как -- прямо сейчас не соображу, но можно.
Семафор там или что...

Если массив маленький, скажем, несколько тысяч, можно его перезаписывать целиком, а не поэлементно, может тоже дать прирост.
...
Рейтинг: 0 / 0
19.05.2017, 18:32
    #39456429
mayton
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
оптимизировать доступ к массиву для многопоточного приложения
baden_badenЕсть массив int, разные потоки считывают или записывают информацию.
Запись происходит в 3-8 раз реже, чем считывание.
Можно ли, исходя из такого соотношения для чтения и записи сделать что-то более быстрое, чем, например, блокировка с помощью mutex, atomic или spinlock?
Тут все очень сильно зависит от смысла задачи.
Действительно ли потокам нужно видеть синхронное изменнение разделяемого ресурса?

Если каждому потоку дать копию своего массивчика но организовать между ними
протокол обновления (по времени) или по событию (наполнение очереди)
то можно снизить накладные расходы на мутексы и все прочие
"прямые" решения.
...
Рейтинг: 0 / 0
19.05.2017, 19:14
    #39456447
Bred eFeM
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
оптимизировать доступ к массиву для многопоточного приложения
baden_badenЗапись происходит в 3-8 раз реже, чем считывание. реже - это частота, а для понимания сути происходящего нужен коэффициент заполнения.

Можно ли, исходя из такого соотношения для чтения и записи соотношения - это, возможно, скважность.

1/8 .. 1/3 времени уходит на саму запись - ускоряйте запись.
А если на ожидание доступа к записи - SRW lock вкупе с ограничением единичного чтения/записи в алгоритме.

что-то более быстроебыстее atomic не будет.
...
Рейтинг: 0 / 0
20.05.2017, 14:41
    #39456626
Common Lisp
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
оптимизировать доступ к массиву для многопоточного приложения
Dima Tvolatile гарантирует только что в итоге что-то будет записаноvolatile гарантирует только то, что сайд-эффекты от вычислений будут происходить в строгом соответствии с абстрактной машиной из стандарта.
...
Рейтинг: 0 / 0
20.05.2017, 14:47
    #39456629
Common Lisp
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
оптимизировать доступ к массиву для многопоточного приложения
Лучшая оптимизация доступа к общему ресурсу из многопоточного приложения это отсутствие такого общего ресурса.
...
Рейтинг: 0 / 0
22.05.2017, 05:24
    #39457017
CEMb
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
оптимизировать доступ к массиву для многопоточного приложения
Common LispЛучшая оптимизация доступа к общему ресурсу из многопоточного приложения это отсутствие такого общего ресурса.А если у меня несколько массивов данных динамической длины, которые надо обрабатывать в реалтайме, и при этом показывать 30 кадров в секунду во весь экран? о_о
...
Рейтинг: 0 / 0
22.05.2017, 08:48
    #39457058
Изопропил
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
оптимизировать доступ к массиву для многопоточного приложения
CEMbCommon LispЛучшая оптимизация доступа к общему ресурсу из многопоточного приложения это отсутствие такого общего ресурса.А если у меня несколько массивов данных динамической длины, которые надо обрабатывать в реалтайме, и при этом показывать 30 кадров в секунду во весь экран? о_о

что за обработка и что рисовать нужно?
...
Рейтинг: 0 / 0
22.05.2017, 11:21
    #39457171
CEMb
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
оптимизировать доступ к массиву для многопоточного приложения
Изопропилчто за обработка и что рисовать нужно?10K окружностей с физическими свойствами соударяются в 2-мерном пространстве, в зависимости от силы удара или разлетаются, или слепляются в одну или разбиваются на две. Один поток считает, второй рисует.
...
Рейтинг: 0 / 0
Форумы / C++ [игнор отключен] [закрыт для гостей] / оптимизировать доступ к массиву для многопоточного приложения / 24 сообщений из 24, страница 1 из 1
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]