Более медленный и менее поточный процессор в многопотоке работает быстрее?

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

А можно модели этих процов? Может где-то кто-то тоже задавался таким вопросом и проще выудить информацию в мировой сети. )

Тема интересная.

Какая ОС? Какое именно IO? Один и тот же файл или разные?

Попробуй запустить на втором проце, но запрети занимать больше 6 ядер (и вообще разные лимиты попроверяй), сравни, вполне вероятно что дело не в проце а в том что io-драйвер захлёбывается таким режимом работы.

А вообще не понял. Ты сначала пишешь про «вроде мютекс» (уточни таки что это конкретно), потом про IO, как они связаны?

Ну и ещё. 6 нитей это 6 ядер или 3 ядра с гипертредингом? 8 это 8 ядер или 4 с гипертредингом?

Спасибо, ознакомлюсь.

А можно модели этих процов?

Phenom II X6 1090T и Core i3 10105.

Какая ОС? Какое именно IO? Один и тот же файл или разные?

На моем компьютере (с АМД) Windows 8.1, на удалённых Windows 10. На момент запуска на всех антивирус отключён (иначе с ним очень медленный IO когда много файлов).

Попробуй запустить на втором проце, но запрети занимать больше 6 ядер.

Хорошая мысль.

вполне вероятно что дело не в проце а в том что io-драйвер захлёбывается таким режимом работы.

Думаю вряд ли драйвер захлёбывается, т.к. я смотрел в мониторе ресурсов, по IO – там далеко до захлёбывания было.

А вообще не понял. Ты сначала пишешь про «вроде мютекс» (уточни таки что это конкретно), потом про IO, как они связаны?

Там суть следующем. Имеется класс с методом записи в файл. Метод записи защищён мьютексом на случай одновременного вызова этого метода из разных потоков.

Так же все экземпляры этого класса сообща ведут учёт (отдельные от класса статические структуры) сколько открыто файлов и список, с левого конца которого будет файл в который дольше всего не писали, и с правого конца будет тот в который запись была последней. Это нужно для того чтобы справляться с ограничением среды: в MS Windows (С Runtime Library) есть ограничение на максимальное количество открытых файлов – 512, для всех архитектур. С помощью специальной ф-ии этот лимит можно увеличить до 8192. Но к сожалению софт, который я сопровождаю написан на Embarcadero C++Builder, а в нём своя CRT, в которой этот лимит не меняется, и 512 только для 64 бита, а для 32, будете смеяться, всего 50 файлом можно одновременно открыть. Поэтому появился такой вот механизм обхода этого ограничения, чтобы не открывать-закрывать файлы на каждый чих, а по возможности наиболее «горячие» из них держать открытыми.

И вот эти структуры (единые на все экземпляры) защищены вторым мьютексом. И именно конкуренция за него – бутылочное горлышко. Т.е. когда файлов меньше лимита то работа с этим мьютексом будет только при открытии файлов. Когда очень много файлов (а лимит на открытие я выбрал 30), то между 10 000 потоками начинается борьба за этот мьютекс. Тот кто первый захватил – ищет в списке с лева на право (левее самые старые) есть ли завершившие объекты завершившие работу с файлом (о завершении судит по свободному мьютексу). Если удалось занять мьютекс (уникальный на объект) то файл того объекта закрывается, и поток открывает свой файл. Т.е. в итоге, когда потоков много – все сводится грубо говоря к конкуренции за один мьютекс, а сам IO весьма себя расслаблено чувствует (на ssd).

Кстати я оговорился, не 1000, я запускал на 10 000 потоках. Т.е .все что выше описал – это речь про 10 000 потоков. При этом количество файлов, с которыми они работают, где-то около 1500 тысячи выходит (есть заранее сгенерированные имена, и запускалка потоков, берет случайным образом имена, и получается +- около 1500 файлов на 10 000 потоков).

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

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

Т.е. все тормоза именно за борьбу за этот мьютекс.

Конечно в реальной работе этого кода никогда не будет в принципе более 3 потоков, и вряд ли будет более 100 объектов, представляющих файл в программе. Так что в реальных условиях этот код одинаково быстро работает на обоих компах (т.к.по ощущению разницы не видно).

Но вот просто очень интересно во первых почему возникает такая разница. Во вторых (т.к. я никогда не читал про многопоточное программирования, кроме примитивных статей из Хабра) какие существуют методики для решения вот приблизительно той задачи что я решаю. Я использовал мьютексы Си++, потому что это самое простое.

p.s. Хоть сказал про Embarcedero, но это та итоговая программа, а либа сама пишется и тестируется на MSVC, т.е. на нормальном компиляторе, как никто другой лучше подходящем под операционку.

Тот кто первый захватил – ищет в списке с лева на право (левее самые старые) есть ли завершившие объекты завершившие работу с файлом (о завершении судит по свободному мьютексу). Если удалось занять мьютекс (уникальный на объект) то файл того объекта закрывается, и поток открывает свой файл. Т.е. в итоге, когда потоков много – все сводится грубо говоря к конкуренции за один мьютекс, а сам IO весьма себя расслаблено чувствует (на ssd).

А если свободный файловый слот найти не удалось, то что он делает?

1500 тысячи

Полтора миллиона?

10 тысяч потоков это практически всегда бессмыслица (если только речь не о GPU, да)

… windows …. windows

LINUX.ORG.RU

кто-то ошибся форумом…

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

нет, это дефект алгоритма

Отпускает мьютекс, от котрый один на всех, спит 10 миллисекнуд, и пробует по новой. Спит чтобы дать другим потокам шанс завершить работу.

Кстати если эту паузу на 10 мс убрать, то процы тогда просто захлёбываются на вызовах времени ядра и работа проги очень замедляется. Если бошьше 10 мс ждать - то сначала нет эффекта, а потом наступает более долгая работа проги. Т.е. 10 подходят хорошо.

1500, не 1.5 ляма, опечатался :)

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

Тебе нужно замерять эти показатели и уже смотреть почему.

Скорее всего в кэш долбится.

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

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

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

Чтобы не сканировать зря всё каждый раз, нужен счётчик свободных слотов. Если в нём ноль - сканировать ничего не надо. Для его увеличения/уменьшения только надо использовать atomic-инкременты и atomic-декременты, чтобы два потока, записывая в него одновременно, ничего не испортили. Если в нём не ноль - надо просканировать свободные слоты, и если слот нашёлся (он может и не найтись,если кто-то уже занял) занимаем его и декрементируем счётчик. Это уже работало бы лучше чем вариант с глобальным мютексом (то есть от первого недостатка мы избавились), но всё-таки второй недостаток остаётся: ожидание слота не атомарно, даже при ненулевом счётчике есть заметный шанс что ничего не получится и придётся опять как-то чего-то ждать.

Поэтому надо использовать не просто счётчик, а семафор. Семафор - это такой счётчик, у которого можно средствами операционной системы ждать ненулевое состояние и сразу забирать из него единицу как дождались, потокобезопасно. То есть создаём семафор, записываем в него количество свободных слотов. Когда нужно открыть файл - «ждём» его, как дождались - сканируем слоты и забираем свободный (он гарантированно будет, т.к. мы забрали единицу из семафора и никто другой в скан слотов не попадёт). Когда слот больше не нужен - освобождаем сначала слот, затем «освобождаем» (инкрементируем) специальной функцией семафор.

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

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

Переписать говнище и точка. Если в память файлы влезают - зачем в диск долбиться? 10000 потоков - зачем?

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

а причем тут скорость процессоров, если тут реальный ввод-вывод и это явно тормоза от файловой системы и самого устройства.

если уж тестировать такое, надо иметь одинаковые драйверы ФС, одинаковые оси и прочие настройки ввода-вывода.

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

все эти мьютексы и ядра работают на 4 порядка быстрее записи на твой ssd.

Есть у кого-нибудь теоритические познания - которые могут объяснить в чём может быть дело?

Даже не знаю с чего и начать. Неправильно всё, начиная с постановки вопроса и заканчивая методикой измерений.

Если изначально IO-bound workload неожиданно становится CPU-bound (а уж тем более congested on a single mutex) - Вы что-то делаете фундаментально неправильно.

Если задача добиться максимума TPS - надо стараться держать все CQ Ваших SSD busy. И это выходит очень далеко за рамки дискуссии о mutex’ах.

Настоящая параллельная запись (с точки зрения прогаммы, а не диска конечно) вернется в программу тогда когда в наборе активных файлов останется 30

Управление в апликуху вернётся в момент когда ядро получит данные, а не когда они упадут на диск. Flushes - отдельная история.

Конечно в реальной работе этого кода никогда не будет в принципе более 3 потоков

Почему мы тогда вообще это обсуждаем?

Но вот просто очень интересно во первых почему возникает такая разница

Алгоритм крив донельзя.

Отпускает мьютекс, от котрый один на всех

Жесть.

спит 10 миллисекнуд

Double жесть.

сколько открыто файлов и список, с левого конца которого будет файл в который дольше всего не писали

Грамотный IO-scheduling - это искусство. Повторюсь - я уверен Вы делаете фундаментально бессмысленные вещи (начиная с 10k потоков).

Есть программа, которая ради тестирования библиотеки, создает 10 000 потоков, каждый из которых конкурирует

10к потоков - это ПО говна. Что ты собрался этим тестировать? Как быстро твоя ос будет перебирать контексты потоков? Она будет перебирать их медленно. Можешь добавить еще 10к и посмотреть, как оно будет работать еще медленнее на поток.

Есть два проца:

1. Способен выполнять 6 нитей исполнения одновременно, 3.2Ггц, >2010 год разработки.
2. 8 нитей, 4.2Ггц, 2021 год разработки.

Если вернуться к исходному вопросу - вы неправильно описываете железо!
1-й - 6 реальных ядер против 4 с гипертредингом во 2-м. Частота 2-го дутая - 4.2Ггц только при загрузке 1-го ядра! И учитывая, что у вас в Винде наверняка стоят всякие патчи против мелдоунов - это съедает 40-50% производительности!
Вот такой он - прогресс электроники за 10 лет!

О, феномчик топчик, у меня сейчас такой, только 1055T =)

создает 10 000 потоков, каждый из которых конкурирует, если обобщить то за один ресурс (мьютекс)

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

Ну ты сравнил. Нет у интеля «потоков», там у них одно название. Поищи по словам HT и SMT.

Ну ты сравнил. Нет у интеля «потоков», там у них одно название. Поищи по словам HT и SMT.

Справедливости ради - у меня настолько негативный опыт с AMD что я их «шедевры» и 3х метровой палочкой трогать не буду. Какие бы циферки их marketing dept не рисовал…

спит 10 миллисекнуд

this.

Чтобы уточнить, пишите в atomic переменную +1 каждый раз, когда поток ложится спать. Подозреваю, что на процессоре#2 спят они намного чаще.

Лежичть можно заменой сна на ожидание на conditional variable. Но я ваш алгоритм не смотрел, возможно его лучше вообще с нуля переделать, судя по комментариям в ветке.

10тыс потоков, да еще и дерущихся за один мюьтекс - не надо так делать. Никогда. Это очень неудачная архитектура софта.

Ну и тестить такое - какой смысл? Что этот тест показывает? Если боевой код написан таким образом, то его не изучать надо а переписывать.

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

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

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

Закон Амдала в данном случае мимо.

Верно подмечено! Тут не только прогресс электроники, а ещё прогресс знаний что 4 + 4HT это полноценный 8 ядерный процессор, против поди ещё монолитного кристалла с общим кэшем L3, на всё это). Хотя основная проблема и правда похоже больше в алгоритме, чем в процессорах.

1. Феном в бусте способен работать на частоте 3.6 на всех ядрах, интел на всех ядрах на базовой 3.7 (а скорее ещё меньше).
2. У фенома реальные 6 ядер, у интела 4.
3. НТ на некоторых нагрузках даёт отрицательный эффект.

Есть программа, которая ради тестирования библиотеки, создает 10 000 потоков

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

В линуксе есть гранулярность переключения между контекстами, а так же стоимость переключения контекста между тредами и между зелеными тредами (корутинами, сопрограммами и т.п.) на порядок отличается.

Что именно ты делаешь, откуда у тебя такие неправильные желания?

Нет, конкретно мой, в бусте только на одном ядре может 3.6. В отличии от i3. Я тоже думал что в бусте 4.2 только на одном, но на самом деле на всех 4.

Я потом добрался и до i7 8700, который в однопотоке в бенче от cpu-z на пару единиц всего быстрее упомянутого выше i3, но в многопотоке, за счет 12 потоков - очень шустрый.

Он быстрее чем i3 работает, но все равно медленнее чем на Феноме.

Поищи по словам HT и SMT.

Да, да я в курсе что такое HT, поэтому в старте топика я и назвал не «ядра» а нити исполнения.

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

Что и без дедлоков и без лайвлоков.

Я где-то выше писал что:

Конечно в реальной работе этого кода никогда не будет в принципе более 3 потоков

Так что 10 000 потоков, борющихся за один мьютекс не будет конечно.

Инстансов будет (реальных, с которыми будет работать программа тоже будет скорее не более 70), а в моих тестах 10 000 потоков работают приблизительно с 6 000 инстансов (случайным образом распределяется - т.е. некоторые инстансы могут принадлежать одному потоку - а некоторые многим).

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

Но просто стало интересно почему процессор почти 10 летней давности работает в данном случае шустрее чем новейшие, при том что мощность новейших видна не только в тестах или комплиции но даже просто в вебсеерфинге, даже удаленно по VNC многие веб штуки в удаленном бразуере работают быстрее чем в локальном (кроме анимаций конечно) но а тут хоба на и на те, софтина, на старом проце шустрее :)

В принципе может Винда 10 тому виной и там из-за каких-то секурностей переключения контекста или борьба за мьютекс идут медленнее. Так-то Феном никаким метлдаунам и спектрам вроде бы не подвержен, и соотвественно есть надежда что не исполняет за зря в рантайме патчи фиксящие эти уязвимости.

Не пробовал сделать синтетический бенчмарк? Сделать тысячи нитей, которые в цикле берут мьютекс, увеличивают счётчик, отпускают мьютекс. Каждый поток делает одинаковое число итераций. Интересно узнать, например:

• есть ли на такой синтетике разница в общем времени выполнения?
• если есть, все ли потоки завершаются примерно одновременно?
• как время выполнения зависит от числа потоков?
• меняется ли время выполнения, если ограничить процессу допустимые ядра так, чтобы SMT не вмешивался?
• есть ли разница в ответах на предыдущие вопросы при запуске на Windows и на Linux?
• есть ли зависимость от версии glibc на Linux? (на совсем древних не было lock elision)
• что насчёт других ядер, вроде FreeBSD?

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

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

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

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

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

Да, тоже сегодня подумал что надо сделать синтетику на основе того кода. И даже сделаю, но скорее всего вернусь к этому вопросу в конце следующей недели.

И на Linux и FreeBSD смогу тоже смогу проверить на обоих компах, но только в VirtualBox, в прочем, если не считать ограниченной поддержки OpenGL и соотвественно некоторые лаги в анимациях DE, остальное (компиляция например) в виртуалках по ощущению не медлееннее чем в реальных машинах, особенно если выделить все ядра проца в виртуалку.

А ещё у меня есть старый Интел дома, не помню какой, но кажется в нем 2 ядра и 4 нити - вот будет прикол если он тоже уделывает новые Интелы :)

вот будет прикол если он тоже уделывает новые Интелы :)

Via Nano уделывает Intel Skylake в скорости инструкции LOOP, раз в пять-шесть, если считать в тактах. Разница в частотах у них всего в два-три раза, так что Nano уделывает Skylake и при расчётах в наносекундах. Только вот есть ли в этом толк.

я про симафоры только слышал, ни разу не пробовал. Так что пока не понимаю.

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

Когда слот больше не нужен - освобождаем сначала слот

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

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

это да, есть такое. Я себе на sTRX4 собрал систему с 64 гига ECC. Доволен.

я про симафоры только слышал, ни разу не пробовал. Так что пока не понимаю.

Семафор а не симафор. И я описал как он работает, по-моему всё понятно.

Я как раз строю всю логику из предположения что слоты нужны всегда и такого как слот больше не нужен - нет,

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

1. Феном в бусте способен работать на частоте 3.6 на всех ядрах, интел на всех ядрах на базовой 3.7 (а скорее ещё меньше).

2. У фенома реальные 6 ядер, у интела 4.
3. НТ на некоторых нагрузках даёт отрицательный эффект.

Но всё это наглухо перекрывается отвратительнейшим по современным меркам IPC у Фенома. Даже у Атомов пайплайн уже шире.

Если у вас разные ssd, то можете ещё их сравнить. И посмотреть, что на них показывает тест случайного чтения/записи по 4к (в один и много потоков).

Ну вон у ТС-а не помогает этот пайплайн i3 обогнать феном.

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

При этом оба процессора были на одной частоте, а исходники в рамдиске.

Многопоточная сборка софта может быть медленнее когда озу не хватает. Я когда во FreeBSD пересобираю некоторые пакеты (не свои), а там вместо make - ninja частенько юзается, и я не знаю как в Нинзя ограничить количество потоков. Приходится выключать виртуальку и ставить например два ядра на машину. Потому-что в некоторых случаях один поток компиляции мог разрастаться до 800 мегабайт в ОЗУ, и 800*6 - столько не было ram у виртуалки и могли начаться фризы на свопе.

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

Вот, серьёзный подход. Так сразу всплывёт еще дохрена интересных вопросов.