Находился тут по разным семинарам от Intel
И возник вопрос
вроде как все в той или иной степени используют многопоточное программирование
а вопросами привязки к конкретному процессу кто нибудь озадачивался или
все отдаете на откуп операционной системе?
И еще как по вашему опыту дает ли ручная привязка результат или нет?

Здравствуйте, ioni, Вы писали:

I>Находился тут по разным семинарам от Intel
I>И возник вопрос
I>вроде как все в той или иной степени используют многопоточное программирование

кто это все? это все-все-все? а что такое в той или иной? или использование многопоточного при числе потоков == 1 это в той, а >1 это в иной степени?

I>а вопросами привязки к конкретному процессу кто нибудь озадачивался или

видимо мало ходили, т.к. привязывают к процессору, а не к процессу.

I>все отдаете на откуп операционной системе?

лично я отдаю

I>И еще как по вашему опыту дает ли ручная привязка результат или нет?

ИМХО только хуже. (если процессоры одинаковые ).

Здравствуйте, Сергей Мухин, Вы писали:

I>>вроде как все в той или иной степени используют многопоточное программирование
СМ>кто это все? это все-все-все?
Ну не все, некоторые только начинают... (см. результаты каких-нить бенчмарков на >1 ядерных/процессорных системах)

I>>все отдаете на откуп операционной системе?
СМ>лично я отдаю
кто как
если не хочется отдавать — см. SetProcessAffinityMask и sched_setaffinity

I>>И еще как по вашему опыту дает ли ручная привязка результат или нет?
СМ>ИМХО только хуже. (если процессоры одинаковые ).
а вот и не факт. иначе бы никто и не использовал

Здравствуйте, Antikrot, Вы писали:

A>Здравствуйте, Сергей Мухин, Вы писали:

I>>>вроде как все в той или иной степени используют многопоточное программирование
СМ>>кто это все? это все-все-все?
A>Ну не все, некоторые только начинают... (см. результаты каких-нить бенчмарков на >1 ядерных/процессорных системах)

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


I>>>все отдаете на откуп операционной системе?
СМ>>лично я отдаю
A>кто как
A>если не хочется отдавать — см. SetProcessAffinityMask и sched_setaffinity

I>>>И еще как по вашему опыту дает ли ручная привязка результат или нет?
СМ>>ИМХО только хуже. (если процессоры одинаковые ).
A>а вот и не факт. иначе бы никто и не использовал

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

Здравствуйте, Сергей Мухин, Вы писали:


I>>>>все отдаете на откуп операционной системе?
СМ>>>лично я отдаю
A>>кто как
A>>если не хочется отдавать — см. SetProcessAffinityMask и sched_setaffinity
есть еще SetThreadAffinity

I>>>>И еще как по вашему опыту дает ли ручная привязка результат или нет?
СМ>>>ИМХО только хуже. (если процессоры одинаковые ).
A>>а вот и не факт. иначе бы никто и не использовал

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

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

Здравствуйте, ioni, Вы писали:

I>Находился тут по разным семинарам от Intel
I>И возник вопрос
I>вроде как все в той или иной степени используют многопоточное программирование
I>а вопросами привязки к конкретному процессу кто нибудь озадачивался или
I>все отдаете на откуп операционной системе?
I>И еще как по вашему опыту дает ли ручная привязка результат или нет?

Разработчики ОС этим вопросом задавались, просто по той простой причине что есть NUMA а там это важно.

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

И чего вы этим хотите добиться?

Здравствуйте, ioni, Вы писали:


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

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

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

Здравствуйте, Аноним, Вы писали:

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

А>И чего вы этим хотите добиться?

добиться... наиболее эффективного, с точки зрения быстродействия, выполнения программы
раньше никогда не пользовался и не задумывался о таких вещах как привязка конкретного потока
к определннумо процессору.
Но в последнее время количество мултипроцессорных машин будет возрастать и
вот я хочу понять стоит ли делать привязку в моей конкретной многопотоковой программе
потоков к процессору.
Интересно мнение тех кто уже решал для себя этот вопрос к чему пришли и почему.
C теорией все понятно, привязав поток к конкретному процессору я целиком завишу от этого процессора
и если он занят то мой поток будет ждать, даже если другие процессоры свободны.
Но с другой стороны если грамотно сделать привязку то производительность возрастет.
Классический пример MS SQL server который очень эффективно разделяет свою работу
между наличествующими процессорамами. Я хочу писать настолько же эффективные программы

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

Здравствуйте, ioni, Вы писали:

I>вроде как все в той или иной степени используют многопоточное программирование
Использую многопоточное программирование только там где это абсолютно необходимо. Вероятность появления багов во могопоточных программах на порядок выше. Баги эти качественно отличные от того, что бывает в однопоточной программе. Отлаживать — иногда на порядок, а то и два труднее (не всегда, если потоки не взаимодействуют друг с другом активно — не сильно усложняется). Практически все проблемы из-за которых иногда приходится убивать какой-либо процесс — так или иначе связанны с многопоточностью. Всегда удивляюсь многочисленным господам, которые еле-еле умея программировать (извечный вопрос — "а почему компилятор жалуется на передачу (нестатической) функции-члена моего класса в функцию создания потока?") тут же начинают творить многопоточно (часто — без особой надобности, но ведь "куто" же) и молю бога чтобы не дал столкнуться на практике с их творениями. Справедливости ради должен отметить, что про то как пользоватся дебаггером такие господа часто не имееют ни малейшего представления, поэтому вопросы усложнения отладки для них неактуальны.
I>а вопросами привязки к конкретному процессу кто нибудь озадачивался или
Нет.
I>все отдаете на откуп операционной системе?
Да. Или ёе админу.
I>И еще как по вашему опыту дает ли ручная привязка результат или нет?
В редчайших случаях, ИМХО — если в какой-то из выполняющихся программ что-то не так. Или если админ многопроцессорного сервера конфигурирует его в соотств. с какими-то специфическими пожеланиями.


ИМХО: привязка к процессорам и повышение приоритетов — дело админа конкретного компьютера, а не програмера.

Здравствуйте, Аноним, Вы писали:

А>ОС сама привязывает потоки так чтобы максимадбно симметричнно разнести нагрузку между процессорами, и зря не перебрасывает поток с процессора на процессор если текущий процессор не перегружен другими потоками.

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

Здравствуйте, Аноним, Вы писали:

А>Здравствуйте, ioni, Вы писали:

I>>вроде как все в той или иной степени используют многопоточное программирование
А>Использую многопоточное программирование только там где это абсолютно необходимо. Вероятность появления багов во могопоточных программах на порядок выше. Баги эти качественно отличные от того, что бывает в однопоточной программе. Отлаживать — иногда на порядок, а то и два труднее (не всегда, если потоки не взаимодействуют друг с другом активно — не сильно усложняется). Практически все проблемы из-за которых иногда приходится убивать какой-либо процесс — так или иначе связанны с многопоточностью. Всегда удивляюсь многочисленным господам, которые еле-еле умея программировать (извечный вопрос — "а почему компилятор жалуется на передачу (нестатической) функции-члена моего класса в функцию создания потока?") тут же начинают творить многопоточно (часто — без особой надобности, но ведь "куто" же) и молю бога чтобы не дал столкнуться на практике с их творениями. Справедливости ради должен отметить, что про то как пользоватся дебаггером такие господа часто не имееют ни малейшего представления, поэтому вопросы усложнения отладки для них неактуальны.

Совершенно с вами согласен
использовать множество потоков просто потому, что это "круто", не наш метод

А>ИМХО: привязка к процессорам и повышение приоритетов — дело админа конкретного компьютера, а не програмера.

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

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

Просто для того чтобы некая программа делала нечто быстрее на многопроцессорных машинах надо чтобы она умела делать это одновременно в нескольких потоках. Те распараллеливалась. Чего не умеют большинcтво современных программ, включая тесты. А уже заниматься привязкой конкретных потоков на конкретные процессоры — проблемы ОС. А если программа создает только один поток который делает все вычисления, то естественно быстрее на многопроцессорных машинах он работать не станет, на какие процессоры ты его не сажай

Ради понтов потоки использовать конечно же глупо. Но не надо впадать в крайности. Не глупо их использовать когда они приносят реальную пользу — увеличение быстродействия программы (это становится актуальным все больше и больше и актуальность эта будет расти экспоненциально) и/или упрощение общей архитектуры программы. При этом для избежания багов с синхронизацией в архитектуре многопоточной программы надо следовать всего лишь трем правиламам (если использовать ООП):
1) Вся многопоточность должна быть инкапсулирована объектом и не выходить за его пределы
2) А все паблик методы должны быть thread-safe. Public методы объекта не должны вызываться самим объектом т.е. должны быть thread-safe интерфейсом для других.
3) Архитектура связей в программе должна представлять собой нормальное дерево, обратные связи в этом дереве (но улчше без них) должны быть асинхронными (те работать через некий общий механизм передачи асинхронных сообщений).

Архитектура основанная на макаронах просто несовместима с многопоточностью.

Что касается дебаггера — им вообще обычно только простейшие баги ловятся. Такие баги assert'ами и unit-test'ами в нормальных проектах контролируются автоматически.

Всё описанное не гарантирует отсутствия главного бича многопоточных программ — deadlock-ов. Вы когда-нибудь видели на практике чтобы их отсутствие доказывалось с использованием каких-либо объективных методик (напр. сети Петри)? Я — нет (зато deadlock-и вижу через день). Всё отдаётся на откуп человеческому фактору, но человек тут может только гадать, пытаться и надеяться.

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