LINUX.ORG.RU

Многопоточность в С++11

 ,


0

1

Всем привет, читаю в данный момент книгу по многопоточности в С++, так вот там есть примерно такой код:

template<typename Iterator,typename T>
T parallel_accumulate(Iterator first,Iterator last,T init)
{
unsigned long const length=std::distance(first,last);
if(!length)
return init;
unsigned long const min_per_thread=25;
unsigned long const max_threads=
(length+min_per_thread-1)/min_per_thread;
unsigned long const hardware_threads=
std::thread::hardware_concurrency();

Я надеюсь что по контексту будет примерно понятно что код делает.

Может быть кто-то знает почему min_per_thread=25? В гугле найти не могу, в книге объяснений нет, единственное:

«Although this is quite a long function, it’s actually straightforward. If the input range is empty B, you just return the initial value init. Otherwise, there’s at least one element in the range, so you can divide the number of elements to process by the minimum block size in order to give the maximum number of threads c. This is to avoid creating 32 threads on a 32-core machine when you have only five values in the range.»

Или же это цифра просто с потолка взята? Чтобы совсем маленькие куски не обрабатывать в разных потоках?

Если да, то не должно быть каких-то объективных критериев в плане много/мало? Или так и плодятся те самые магические числа?

Kronick
() автор топика
Ответ на: комментарий от Kronick

Ну да, взято с потолка. Что бы получить объективные критерии, нужно делать замеры производительности для разных значений min_per_thread

four_str_sam
()
Ответ на: комментарий от hippi90

Ясно, я уж было начал думать что это какая системная константа, может к битности привязана или еще к чему.

Kronick
() автор топика
Ответ на: комментарий от four_str_sam

Понятно, что-то я сразу не подумал об этом.

Ну и всем спасибо, закрываю тему.

Kronick
() автор топика

потому что это говнокод. лядь! ну почему вы учите с++ по говнокнигам вместо того, чтоб понять как работает процессор на примере 486го и как выкладываются ваши команды в инструкции проца? те кто знают асм, почему-то не страдают от С++.

и еще - надо пописать gui приложения чтоб понимать как и что делается. чтоб в голове отложилось что такое работа по событиям, таймауты, и пр.

эти книги пишут петухи убогие, которые ни разу не писали реальных программ. если тебе нужны реально параллельные вычисления, то у тебя не должно быть функции parallel_accumulate. у тебя есть такая задача? создай объект, который запустит через пул потоков много функций-workerов. сделай сигнализацию окончания и возможность прервать рассчеты. по окончании рассчетов продолжи вычисления как обычно. это - правильный, нормальный подход.

а если так не делать, то приходится ныть что С++ опять обосрал шаровары.

ckotinko ☆☆☆
()
Ответ на: комментарий от ckotinko

Ну вообще автор книги Anthony Williams, вот что про него нашел:

«He has been an active member of the BSI C++ Standards Panel since 2001, and is author or coauthor of many of the C++ Standards Committee papers that led up to the inclusion of the thread library in the new C++ Standard, known as C++11 or C++0x. He has been the maintainer of the Boost Thread library since 2006, and is the developer of the just::thread implementation of the C++11 thread library from Just Software Solutions Ltd.»

Ну а так да, задача бесполезная, никто ж не спорит. Хеллоуворлды тоже бесполезны, а вот разобраться в языке помогают ведь. Да и что за странная ненависть к книгам?

Kronick
() автор топика
Ответ на: комментарий от Kronick

«Уж коли зло пресечь: Забрать все книги бы да сжечь» (c)

anonymous
()
Ответ на: комментарий от Kronick

это отсылка к «авторитету»(в переводе с латыни - власть). то есть у этого чела якобы есть моральная власть(authority) диктовать остальным что правильно а что нет.

да пошел он нахер. научный(действительно научный, а не с отсылками к «авторитетам») подход говорит, что любое утверждение надо проверять.

тут чел из академии. что он написал? где его истории успеха? я скорее поверю разрабам Qt, mariadb, gtk, linux и т.д. чем кому-то из академии, которые просто теоретизируют на ровном месте.

если язык будет двигать целиком коммунити, то получится раст - убожество если честно потому что он явно несет в себе уродства унаследованные от разработки на С++ в веб-бэкэндах. Просто ну видно как эти люди латают характерные для говнопроектов проблемы языком программирования. Даже в документации видно, что её по сути нет. Я же смотрел туда, это блин позор какой-то. rust memory model - wtf? я ожидал увидеть model а не код на расте.

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

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

ckotinko ☆☆☆
()
Ответ на: комментарий от ckotinko

да, вообще не понятно, чего бы людям сразу эффективный рендер на CPU не писать, или там МКЭ решатели. Нет ведь, литературу какую-то читают, примеры синтетические разбирают. Что такого вообще может быть сложного в таком элементарном языке как C++ и в сторонних библиотеках, всего-то раскурил i486 и вперед.

arkhnchul ★★★
()
Ответ на: комментарий от ckotinko

Ну так сам ведь говоришь что баланс нужен. А какой же это баланс, если теорию не знать?

Я тут с boost::asio ковырялся и понял что не хватает знаний именно по многопоточности в С++. Вот и взялся почитать как оно хотя бы в теории должно выглядеть.

Автор может и не прав, но явно знает теоретическую основу, вот это и можно отсюда вынести. А потом пойти и посмотреть как оно реализовано в реальном мире. И как раз получится то что надо.

Ну и все кто обычно пишет так как ты имеют хорошее образование в нормальных школах/универах, я же когда выпустился - то не знал что такое компилятор. Вот и где таким как я брать теоретическую базу, кроме как из книг?

Kronick
() автор топика
Ответ на: комментарий от Kronick

теория у тех, кто кодает и тех кто в академии различается. те, кто кодают, знают как оно «в бою». что надо делать не для красоты а для удобства. академики как правило воротят «для красоты», а потом это оказывается ненужно. академикам похеру, им tenure нужен.

boost::asio это вообще лютый ахтунг, это моё личное мнение. слишком сложно и мне лично было проще писать на libevent. есть еще libev, но авторы просто не удосужились написать документацию к ней.

ckotinko ☆☆☆
()
Ответ на: комментарий от slackwarrior

Интересно, читал как-то, но с реальностью не связывал. Да в любом случае мне бы разобраться как оно в общем случае работает и как хотя бы пару потоков запустить чтобы ничего не сломать. А так я не припадочный чтобы параллелить все подряд.

Kronick
() автор топика
Ответ на: комментарий от ckotinko

Ахтунг, тут соглашусь. Но опять же полистал в течении недели и примерно разобрался как клиент-серверы писать, как открывать сокеты и все в таком духе, уперся вот в совсем зубодробильный пример с потоками и понял, что вообще нихрена не понимаю что происходит, решил про это почитать. Опять же - не вижу ничего плохого, общее представление появится и можно уже самому что-то делать.

Kronick
() автор топика
Ответ на: комментарий от arkhnchul

эффективный рендер на CPU не писать

пфффф. а ведь ты не знаешь про алгоритмы рендера. не знаешь, почему на GPU до сих пор нормально 2Д не ускоряют. или знаешь? ну просто я свой проц делаю, который и gpu и cpu, и вопросы рисования pathов исследовал. Знаешь в чем там проблема? не знаешь. например нужен stencil buffer хотя бы в один бит, но который можно бесплатно сбрасывать хоть постоянно. Сможешь такую структуру данных придумать? Причем чтоб предыдущие буфера еще немного жили пока по ним шейдеры бегают, и чтоб можно было по ним сказать где есть единички.

Вы все сраные теоретики очень умные в теории. Но на практике те, кто ботал асм, почему-то не бомбят пуканом от С++, понимают откуда прилетают проблемы, и вообще лучше разбираются в вопросах производительности. А теоретики живут в своём мирке где gc, абстракции, «щас нам jvm все заинлайнит». А в итоге ничего. Даже раст ваш существует только ради самого себя.

ckotinko ☆☆☆
()
Ответ на: комментарий от Kronick

вот что про него нашел

Для сравнения, найди что-нибудь про ckotinko - ну там его темы на ЛОРе. И подумай еще раз, как относиться к написанному обоими.

anonymous
()
Ответ на: комментарий от Kronick

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

но ска. всё доводится до абсурда. с 1000 уровней абстракции. asio же в свое время в tr1 пихали, но оттуда его погнали в ужасе.

ckotinko ☆☆☆
()
Ответ на: комментарий от anonymous

Опять же - почитал теоретика и почитал что пишет тот кто код пишет - вот разные точки зрения и можно на основе этого выстроить какое-нибудь мнение.

Kronick
() автор топика
Ответ на: комментарий от slackwarrior

остановись, ты его сейчас обозлишь и владельцы видеокарт от АМД будут без свежих драйверов жить

anonymous
()
Ответ на: комментарий от slackwarrior

да хоть из машины времени. не надо мне за рендер на CPU рассказывать, я больше рассказать могу. я в конце концов программировать научился потому что у меня был в моей деревне комп 166ММХ и диск «160игр», и больше ничего. И игры кончились. Поэтому я добыл qbasic4.5. он тормозил и тогда мне подогнали borland c++ 4.5 а потом еще книжку по асму зубкова. там в конце еще была таблица с таймингами инструкций, и я для своей игры растеризатор с mmx писал, на асме раскладывая вручную по U и V pipe инструкции. У зубкова еще было написано как ломать Tie Fighter.

Я на этом деле собак съел больше чем корейцы. Что вы мне парите.

На растеризацию в QPainter посмотрите, если не треснете. У них даже статьи были на эту тему. На CPU кстати можно было бы растеризовать, но есть проблемы именно по части stencil buffer. Быстрый сброс например, иерархические запросы. Это делается только аппаратно.

ckotinko ☆☆☆
()
Ответ на: комментарий от ckotinko

ну почему вы учите с++ по говнокнигам вместо того, чтоб понять как работает процессор на примере 486го и как выкладываются ваши команды в инструкции проца? те кто знают асм, почему-то не страдают от С++.

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

Именно такие дядечки-железячники, думающие, что имеют представление о том, какие у процессора есть инструкции, и о том, как их код можно было бы переписать на ассемблер, потом пытаются доказывать вещи вида «эта гонка данных не опасна», «я могу использовать (слава богу если volatile) int для синхронизации тут», «неинициализированная локальная переменная содержит случайный мусор со стека» и прочее. А после обновления компилятора код за ними приходится переписывать.

В терминальной стадии это выглядит как «я буду писать x & 1 вместо x % 2».

vzzo ★★★
()
Последнее исправление: vzzo (всего исправлений: 1)
Ответ на: комментарий от vzzo

когда компиляторы стали на порядок умнее программистов

кот и лампа,жпг.

это ты мне сейчас рассказываешь, когда gcc7 не может switch от константы свернуть и поэтому ведро не собирает? или когда пятый gcc мне лично херню генерил в зависимости от того в каком месте в коде(явно перед for явно или в выражении по месту применения) я привожу int к uint? или когда это говно «оптимизировало» мне операцию побитового И так, что (x & 8191) оказывалось меньше нуля?

местные питухи тут пели что это UB. только не смогли объяснить, почему UB при оптимизации переполнения при сложении-вычитании распространяется на логические операции. но им похеру, главное прокурарекать

ckotinko ☆☆☆
()
Ответ на: комментарий от ckotinko

А, всё, я вспомнил, кто ты такой. Сливаюсь из треда, так как доказывать тебе что-то бесполезно.

Рекомендую ещё раз прогуглить, чем behaviour отличается от value, и зачем оптимизатору анализировать допустимые диапазоны значений переменных. Московские школьники 9-11 классов вполне в состоянии это понять за двухчасовую лекцию.

vzzo ★★★
()
Ответ на: комментарий от vzzo

В терминальной стадии это выглядит как «я буду писать x & 1 вместо x % 2».

нет, это выглядит как теоретики решили, что могут генерировать говнокод, расширительно трактуя понятие UB и требуюя от других приспосабливаться их из «оптимизациям», нарушающим логику программы. Потому что x&1 это вполне законная операция, перед которой х должен быть вычислен и никакие оптимизации сквозь операцию И идти не должны просто потому что они невозможны. сложения и логические операции неассоциативны и некоммутативны друг с другом.

ckotinko ☆☆☆
()
Ответ на: комментарий от vzzo

Сливайся нахер.

зачем оптимизатору анализировать допустимые диапазоны значений

потому что такие как ты и привели к тому, что gcc7 ядро не собирает, и делают вид что так и должно быть. теоретики сраные. зато за два часа лекций можно школьникам в башку насрать, благо они возразить не могут в силу недостатка опыта. Кроме как школьникам и ололошам от жабы вы больше никому в башку насрать не можете. вы все - эдакий навальный от программирования.

Нет таких оптимизаций, которые для x&8191 дают отрицательные значения. Это факт. Который вам никогда не понять

ckotinko ☆☆☆
()
Последнее исправление: ckotinko (всего исправлений: 1)
Ответ на: комментарий от slackwarrior

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

ckotinko ☆☆☆
()
Ответ на: комментарий от ckotinko

насрать

Точняк, ты лучше к проктологу сходи, к гастроэнтерологу и психотерапевту. «Копролалия» — это симптом :)

рано или поздно мир форкнется

Ты рискуешь не дожить :)

slackwarrior ★★★★★
()
Ответ на: комментарий от slackwarrior

а ты веселый походу и находчивый. наверно к КВН выступаешь или в камедиклабе, судя по искрометности юмора.

ckotinko ☆☆☆
()
Ответ на: комментарий от ckotinko

А ты по ночам людей убиваешь или просто стулья жжошь от «лютой ненависти»?

slackwarrior ★★★★★
()
Ответ на: комментарий от ckotinko

недостойные зваться программистами быдломакаки всю жизнь считали, что в С «&» - арифметическая операция битового И, но великий гуру скотинко открыл им глаза: оказывается, именно это логическое И, а не &&

arkhnchul ★★★
()

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

попробуй сделать микробенчмарк - взять реальный ворклоад, и позапускать с min_per_thread от 1 до 100, и построить график в LibreOffice Calc

если бы у тебя был какой-то умный рантайм типа Java, возможно он сам бы вычислял такие говноконстанты в рантайме, под конкретную машину, но раз уж у тебя C++ - сиди в компайл тайме циферку вычисляй, и ета циферка будет для твоего конкретного компутера, под твой конкретный ворклоад

stevejobs ★★★★☆
()
Ответ на: комментарий от arkhnchul

логическое И это коньюнкция. В си своя отдельная терминология сложилась от бедности.

«Синонимы: логи́ческое «И», логи́ческое умноже́ние, иногда просто «И». Конъюнкция может быть бинарной операцией (т. e. иметь два операнда), тернарной операцией (т. e. иметь три операнда), или n-арной операцией (т. e. иметь n операндов).»

нет никакого «арифметического И» в природе. В си есть логическое И и сишное И. То, что в Си себе отдельный новояз замутили не меняет смысла коньюнкции. Сишная «арифметическая И» = «логической И», а «логическая И» = вообще хз чему ибо воздействует на операнды(например может их не вычислять с side effect).

ckotinko ☆☆☆
()
Последнее исправление: ckotinko (всего исправлений: 1)
Ответ на: комментарий от ckotinko

но ведь чуваки, которые заседают в коммитете, за одним еще и код конпеляторов-реализаций пишут своими собственными руками? А в конпеляторе дофига многопоточности и лютого ада, не?

stevejobs ★★★★☆
()
Ответ на: комментарий от stevejobs

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

есть математическое определение операции. есть её аппаратная реализация в процессоре. «&&» - это некоторое «сложное И», окей. Но «&» - это честная конъюнкция, и на неё UB при сложении не распространяется, т.к. его эффекты должны закончиться до операции &. Есть конечно эвристика типа заведомо-1 и заведомо-0, я смотрел как это в компиляторе сделно, но слово «заведомо» означает что UB нет. Заведомо - значит все defined.

ckotinko ☆☆☆
()
Последнее исправление: ckotinko (всего исправлений: 1)
Ответ на: комментарий от stevejobs

У вас обоих каша в голове.

В компиляторах не особо увлекаются многопоточностью. В Комитете есть компиляторщики, но не так много. Как и академиков. В основном там представители корпораций-пользователей C++, и практика их интересует больше всего. И да, в ассемблерах и многопоточности народ там шарит весьма, не исключая того же Уильямса.

anonymous
()
Ответ на: комментарий от Kronick

Не слушай местных кукаретиков, отличная книга для понимания многопоточности и подводных камней в с++11. Кстати и задача с пулом воркеров там тоже разбирается.

four_str_sam
()
Ответ на: комментарий от stevejobs

в общем, моя позиция такова, что нельзя злоупотреблять UB, нельзя толковать его расширительно, т.е. из того что UB при сложении-вычитании не следует, что его результат распространяется дальше через остальные операции. Потому это де-факто это приводит к UB там, где он не оговорен.

И судя по стремным багам с int->uint, практика распространения UB по цепочке триггерит всякие баги в компиляторе и приводит уже к жестким и непредсказуемым глюкам. Конкретно у меня в алгоритме обсчета видимости из точки образовывались «невидимые» сегменты в 45 градусов если вручную все не загнать в uint перед циклом. А собственно в uint был угол нормированный в диапазон от 0 до 8191. Вот откуда моя проблема с отрицательными значениями.

А судя по багам с gcc+linux kernel, там еще целый вагон других проблем под ковром от расширенных трактовок.

ckotinko ☆☆☆
()
Ответ на: комментарий от four_str_sam

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

Kronick
() автор топика
Ответ на: комментарий от stevejobs

Да не, к чему это все, это же не реальная задача, а так, посмотреть что да как. Вот когда дело дойдет до реальных высоконагруженых приложений(если когда-нибудь я дойду до того уровня), вот тогда да, настанет время бенчмарков

Kronick
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.