Треды в линуксе

[Yougi]

 Прочитал тут невнятную статейку про мультитреды в линуксе, появились вопросы.
 В статейке вроде как написано, что треды выполняются параллельно и независимо.
 Так вот, если я сто операций умножения разнесу на четыре треда по двадцать пять операций в каждом, будут ли они выполняться в четыре раза быстрее?
 Сколько тредов я могу создать единовременно? Могу ли я прибить тред и запустить его с новой задачей?
 Там предлагается использовать какую-то левую библиотеку, насколько быстродействие определяется рукожопостью её создателя?

[Upliner]

Так вот, если я сто операций умножения разнесу на четыре треда по двадцать пять операций в каждом, будут ли они выполняться в четыре раза быстрее?
 Сколько тредов я могу создать единовременно? Могу ли я прибить тред и запустить его с новой задачей?

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

[Yougi]

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

Я, может, коряво выразился - мне нужно делать 100-150 плавучих умножений каждые 120 микросекунд, по прерыванию от АЦП. Как я понял, треды создадутся один раз, а дальше будут молотить параллельно.

[Upliner]

Я, может, коряво выразился - мне нужно делать 100-150 плавучих умножений каждые 120 микросекунд, по прерыванию от АЦП. Как я понял, треды создадутся один раз, а дальше будут молотить параллельно.

Вот тут честно говоря хз, наверное только экспериментальным путём можно выяснить, есть ли выгода.
И кстати, как прерывания ловятся? Через read() из девайса или через модуль ядра?

[Yougi]

 Придётся эксперимент ставить... В линуксе системный таймер с какой частотой молотит? И как до него доступиться?

И кстати, как прерывания ловятся?

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

[Upliner]

В линуксе системный таймер с какой частотой молотит?

Гугль говорит, что 250 герц по дефолту, у меня powertop показывает около 250 tick_sched_timer если нет активных задач, но если запущены тяжёлые задачи -- то падает до 100.

И как до него доступиться?

В смысле достучаться? Померить?

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

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

[Yougi]

Гугль говорит, что 250 герц по дефолту

пичалько... четыре миллисекунды - это офигительно много.
 Странно это как-то. В том же кодесисе под тем же линуксом системный тик - микросекунды.
 Что-то тут не то.

В смысле достучаться? Померить?

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

[Upliner]

Для таких задач есть ещё отдельно hrtimer-ы.

[Toman]

пичалько... четыре миллисекунды - это офигительно много.
 Странно это как-то. В том же кодесисе под тем же линуксом системный тик - микросекунды.

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