http://www.agner.org/optimize/instruction_tables.pdf

эх, но это ж не офф

http://www.agner.org/optimize/instruction_tables.pdf

хотя от такой же для армов я бы не отказался :)

Ммм... армы...

Ну<. Как я понял, чувак исследует эту тему

По х86

Я пожалуй в диссер впильну референс на эту табличку

http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0408h/ch02s03s02.html

Для армов.

Я пожалуй в диссер впильну референс на эту табличку

Серьезно? Впервые про агнера слышишь?

Да(

Мб слыхал, и забыл

http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0408h/ch02s03s02.html

И это утащу

ребят, кто-нибудь работал с OpenCL?

? неа

Посоны. нужна критика...

Межпоточное взаимодействие. Для выталкивания данных из потока у него на выходе есть статический буфер. Также у каждого потока есть условно-говоря "входная" лок-фри очередь, куда ему складывают указатели на данные, которые пишучий поток хранит в "своем" экземпляре буфера. Читающий выбирает элементы из своей входной очереди, и лезет за данными к потоку-родителю, в его выходной буфер, где твориться самая "грязь"... суть такова, что пишущий поток условно идет перед читающим и проверяет постоянно его "позицию" на своем выходе, чтобы не наступить на хвост... read/write offset в выходном буфере под "атомиками"... т.е. у буфера есть только метод addItem() в котором это колдунство творится, ломаю голову над тем, что можно улучшить. Схема не самая удачная, могу рассазать про подводные камни, с которыми столкнулись, однако скорость работы весьма достойная...

После ухода от мютексов и прочих критических секций прирост скорости значительный, но теперь глаз настолько замылен, что ничего другого не придумывается

Ща подумаю

буфер аллокейтится перед началом работы, в зависимости от количества потоков размер очереди от 100 мбайт до 2-5 гбайт и от 10к до 1КК элементов.

Кольцевые буферы, аддитем и пр

Кольцевые буферы, аддитем и пр

так точно

а что за потоки вообще есть

Есть поток с данными

Есть всп для него на чтение/запист

один поток решает одну задачу над данными, второй - другую... условно так

средний размер блока 100 кбайт

а что за потоки вообще есть

в одном экземпляре ПО на обработку задействуется 5-10 потоков. зависит от сценария...

между ними все это и происходит...

сейчас есть небольшие проблемы с тем, чтобы все это хозяйство корректно тормозить... особенно когда появляются "обратные" связи

Межпоточное взаимодействие. Для выталкивания данных из потока у него на выходе есть статический буфер. Также у каждого потока есть условно-говоря "входная" лок-фри очередь, куда ему складывают указатели на данные, которые пишучий поток хранит в "своем" экземпляре буфера. Читающий выбирает элементы из своей входной очереди, и лезет за данными к потоку-родителю, в его выходной буфер, где твориться самая "грязь"... суть такова, что пишущий поток условно идет перед читающим и проверяет постоянно его "позицию" на своем выходе, чтобы не наступить на хвост... read/write offset в выходном буфере под "атомиками"... т.е. у буфера есть только метод addItem() в котором это колдунство творится, ломаю голову над тем, что можно улучшить. Схема не самая удачная, могу рассазать про подводные камни, с которыми столкнулись, однако скорость работы весьма достойная...

А нельзя создать поток, который будет наполнять локальную очередь?

А нельзя создать поток, который будет наполнять локальную очередь?

каждый из потоков может сам "порождать" данные, которые ему нужно отдать дальше.

очередей много ...

попробую нарисовать схемку...

как вы бы сами замутили межпоточный обмен. где критичны каждое выделение памяти и блокировки...

На статичном бкфере

Че делать? Зависла, еле закрыл VS, походу сбросилась, и теперь игра отображается неправильно

выйти-зайти?

опять же - в супапро слабый оффтоп можно

а паскаль разрешил, потому что решение в нем хуже))))

Как использовать дефолтные значения параметров в шаблонных функциях?

template<typename T> T str_to_decimal(std::string &s, int base = 10); template<> int32_t str_to_decimal<int32_t?std::string &s, int base = 10) { }

не пашет? иль что?

Ругается на присвоение во второй перегрузке

дык убери

И будет норм?

В плане работы

да

правило одного определения и пр. муть

После ухода от мютексов и прочих критических секций прирост скорости значительный, но теперь глаз настолько замылен, что ничего другого не придумывается

Решили?

Решили?

что решили?

Ну задачу свою.

решение я описал. юзаем.

Понятно.

Ну разве что иогу предложить полиси у атомиков поменять

Если еще не сделали

На load-consume

У читающих тредов.

Потому что указатели.

Чтобы включить реордеринг обратно для независимых инструкций.

У пишущих store release у читающих по указателям load-consume

Вместо load-acquire

спс, попробуем потрогать так

так, погодь, между тредами кольцевой буфер, у которого офсеты лежат в атомиках. пишущий/читающий обращаются именно к ним

при обращении говорить потоку как ему load делать?

Буфер не весь из атомиков ведь правда?

ERROR: S client not available

нет

Только указатель на него атомик

Да.

а это в с11 есть?

мне кажется только в 14м появилось

В с++11

Атомику пишешь

хорошо, благодарю

myatomicptr.store(rawptr, std:: memory_order_release) у читающего ptr = atomicdatasourceptr.load(std::memory_order_comsume)

Еще в языке есть всякие штуки типа std::kill_dependency

Можно вот на таком уровне все сделать и ручками memory fence поднимать.

от души! я все никак не могу в memory order осилить :( остался в прошлом веке почти

Да там легко. 40 минут есть? Посмотри лекцию. https://m.youtube.com/watch?v=_-3syPxgwqs

Да там легко. 40 минут есть? Посмотри лекцию. https://m.youtube.com/watch?v=_-3syPxgwqs

thx

Лекция зачот!

Я понял что нам ослабленный порядок вполне себе подходит

Главное что обеспечивается атомарность изменений.

Это по идее ещё больше добавит скорости. На миллионе элементов должно быть заметно

Да.

ммм.... ослабенный порядок...

Тебе не нужен sequential consistency

только release-consume

Потому как у тебя там указатели.

Ох, вспоминаю я код 2009 года, ядро системы на делфи и все обвешано этими критическими секциями

Причём в 2009 его с плюсов на на Паскаль переложили изза менеджера памяти

Намучились мы за эти годы с паскакалем

Ребят, чем черевато если оставаться на старой версии плюсов и не изучать новые 11 и 14 версии? Или это дело вкуса?

тем, что устареешь

Чревато остаться без работы плюсера :D

Ребят, чем черевато если оставаться на старой версии плюсов и не изучать новые 11 и 14 версии? Или это дело вкуса?

Старением :)

И обрастанием мхом ;)

Почитал вас тут, пишете что все новое в новых версиях не так легко дается когда привык к старому.