powered by simpleCommunicator - 2.0.59     © 2025 Programmizd 02
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Форумы / C++ [игнор отключен] [закрыт для гостей] / оптимизировать доступ к массиву для многопоточного приложения
24 сообщений из 24, страница 1 из 1
оптимизировать доступ к массиву для многопоточного приложения
    #39455719
baden_baden
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Есть массив int, разные потоки считывают или записывают информацию.
Запись происходит в 3-8 раз реже, чем считывание.
Можно ли, исходя из такого соотношения для чтения и записи сделать что-то более быстрое, чем, например, блокировка с помощью mutex, atomic или spinlock?
...
Рейтинг: 0 / 0
оптимизировать доступ к массиву для многопоточного приложения
    #39455734
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Можно вообще забить на синхронизацию. Выравненный int читается и пишется современными
процессорами атомарно. Чтобы компилятор не умничал - объявить этот массив volatile.
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
оптимизировать доступ к массиву для многопоточного приложения
    #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
оптимизировать доступ к массиву для многопоточного приложения
    #39455764
Фотография CEMb
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
а если так:
Код: plaintext
1.
std::map<std::string, std::atomic<int>> msi;

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

З.Ы. тема неоднократно поднималась, например http://www.sql.ru/forum/1253390/kakuu-biblioteku-posovetuete-s-potokobezopasnymi-konteynerami
...
Рейтинг: 0 / 0
оптимизировать доступ к массиву для многопоточного приложения
    #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
оптимизировать доступ к массиву для многопоточного приложения
    #39455828
kealon(Ruslan)
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
baden_badenЕсть массив int, разные потоки считывают или записывают информацию.
Запись происходит в 3-8 раз реже, чем считывание.
Можно ли, исходя из такого соотношения для чтения и записи сделать что-то более быстрое, чем, например, блокировка с помощью mutex, atomic или spinlock?

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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


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