Языковая политика
Общие обсуждения => Компьютеры и интернет => Topic started by: Yougi on 22 July 2023, 16:17:33
-
Прочитал тут невнятную статейку про мультитреды в линуксе, появились вопросы.
В статейке вроде как написано, что треды выполняются параллельно и независимо.
Так вот, если я сто операций умножения разнесу на четыре треда по двадцать пять операций в каждом, будут ли они выполняться в четыре раза быстрее?
Сколько тредов я могу создать единовременно? Могу ли я прибить тред и запустить его с новой задачей?
Там предлагается использовать какую-то левую библиотеку, насколько быстродействие определяется рукожопостью её создателя?
-
Так вот, если я сто операций умножения разнесу на четыре треда по двадцать пять операций в каждом, будут ли они выполняться в четыре раза быстрее?
Сколько тредов я могу создать единовременно? Могу ли я прибить тред и запустить его с новой задачей?
Если сто операций -- то оверхед по созданию или коммуникации будет больше, чем выгода от распараллеливания. Если сто миллионов и есть четырёхядерный процессор -- то да, будет ускорение в 4 раза.
Тредов где-то до тысячи думаю можно создать, зависит от свободных ресурсов системы. Но как только количество тредов превысит количество логических процессоров -- производительность начнёт снижаться. Прибить тред можно, но обычно не рекомендуется, т.к. это может оставить программу в невалидном состоянии и могут утечь ресурсы. Но если реально знаешь что делаешь, то можно. Насчёт последнего -- как правило от библиотеки зависит только оверхед по созданию тредов, а дальше треды уже сами по себе.
-
Если сто операций -- то оверхед по созданию или коммуникации будет больше, чем выгода от распараллеливания.
Я, может, коряво выразился - мне нужно делать 100-150 плавучих умножений каждые 120 микросекунд, по прерыванию от АЦП. Как я понял, треды создадутся один раз, а дальше будут молотить параллельно.
-
Я, может, коряво выразился - мне нужно делать 100-150 плавучих умножений каждые 120 микросекунд, по прерыванию от АЦП. Как я понял, треды создадутся один раз, а дальше будут молотить параллельно.
Вот тут честно говоря хз, наверное только экспериментальным путём можно выяснить, есть ли выгода.
И кстати, как прерывания ловятся? Через read() из девайса или через модуль ядра?
-
Придётся эксперимент ставить... В линуксе системный таймер с какой частотой молотит? И как до него доступиться?
И кстати, как прерывания ловятся?
Пока - через ножку GPIO, ну, то есть это и не прерывание вовсе. Просто флаг ставится, что новые данные есть, и они обрабатываются. Не вкурил я ещё, как настоящие прерывания на малинах работают.
-
В линуксе системный таймер с какой частотой молотит?
Гугль говорит, что 250 герц по дефолту, у меня powertop показывает около 250 tick_sched_timer если нет активных задач, но если запущены тяжёлые задачи -- то падает до 100.
И как до него доступиться?
В смысле достучаться? Померить?
Пока - через ножку GPIO, ну, то есть это и не прерывание вовсе. Просто флаг ставится, что новые данные есть, и они обрабатываются. Не вкурил я ещё, как настоящие прерывания на малинах работают.
В таком случае думаю действительно не будет оверхеда от тредов и скорее всего получится быстрее данные обрабатывать.
-
Гугль говорит, что 250 герц по дефолту
пичалько... четыре миллисекунды - это офигительно много.
Странно это как-то. В том же кодесисе под тем же линуксом системный тик - микросекунды.
Что-то тут не то.
В смысле достучаться? Померить?
ну да. По флагу запомнить значение, просчитать математику, снова прочитать, сравнить.
-
Для таких задач есть ещё отдельно hrtimer-ы.
-
пичалько... четыре миллисекунды - это офигительно много.
Странно это как-то. В том же кодесисе под тем же линуксом системный тик - микросекунды.
Давно не занимался этим, но вроде есть какой-то системный вызов (?), который позволяет заказывать ожидание на времена, измеряемые микросекундами. Другой вопрос, насколько железо позволит исполнить такое, и если да, то насколько это будет экономично по ресурсам. Не помню даже, пытался ли я пользоваться этим системным вызовом, и если да, то с каким успехом (но если это и было, то в любом случае, на архитектуре i386).