Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, aik, Вы писали:
aik>>Т.е. натурально, "эти 2 дима — для процессора #1, а эти — для процессора #2"?
AVK>Именно так.
Получается чтобы распараллелить потоки одного процесса на два процессора надо еще и данные копировать? Или один процесс нельзя выполнять на двух процессорах?
Здравствуйте, henson, Вы писали:
aik>>>Т.е. натурально, "эти 2 дима — для процессора #1, а эти — для процессора #2"? AVK>>Именно так. H>Получается чтобы распараллелить потоки одного процесса на два процессора надо еще и данные копировать? Или один процесс нельзя выполнять на двух процессорах?
Скорее, нельзя. Но и не надо, на таких машинах обычно _сильно_ больше одного процесса и параллелить на 2 процессора 1 процесс не нужно, а снизить нагрузку на шину памяти очень полезно.
Здравствуйте, henson, Вы писали:
H>Получается чтобы распараллелить потоки одного процесса на два процессора надо еще и данные копировать? Или один процесс нельзя выполнять на двух процессорах?
Все можно, только надо выбирать задачи для которых выполняются марковские условия, иначе разговор о возможности и необходимости параллировать процесс теряет смысл... НАХ
ЗЫ Вопросом распаралеливания потоков занимается OS, и стоит заметить она никак им не занимается, кроме как закрепления процесса за ядром или камнем, но прогресс не стоит на месте и в настоящее время существует несколько библиотек позволяющих планировать распараллеливание на уровне кода
ЗЫЫ А вообще если принять производительность ядра и камня одинаковыми, то два камня работать будут быстрее(им нечего делить кроме работы), но не сразу . Короткие задачи для которых время работы с шиной занимает время сравнимое с выполнением всей задачи быстее будут на двухядерном камне, большие вычислительные задачи на одноядерных камнях оставят конкурента далеко "в заде" но в мире одни архитектуры гибнут, другие становятся брендом маркетингового беспредела
>ЗЫ Вопросом распаралеливания потоков занимается OS, и стоит заметить она никак им не занимается, кроме как закрепления процесса за ядром или камнем, но прогресс не стоит на месте и в настоящее время существует несколько библиотек позволяющих планировать распараллеливание на уровне кода
бред какой-то, если честно... во всяком случае в приведенной форме
во1х, как раз таки ОС и занимается планированием потоков и это атнють не тупая привязка потока к ядру. Более того, есть мнение, что оптимальным в большинстве ситуаций является предоставить планировшику ОС полную свободу действий.
во2х, можно озвучить названия библиотек? даже интересно, неужели кому-то хватило мозгов изобретать велосипед для призявки к процессору в обход ОС (хотя без понятия, как это можно вообще реализовать), когда есть winapi-шные SetProcessAffinityMask, SetThreadAffinityMask, SetThreadIdealProcessor
В>во1х, как раз таки ОС и занимается планированием потоков и это атнють не тупая привязка потока к ядру. Более того, есть мнение, что оптимальным в большинстве ситуаций является предоставить планировшику ОС полную свободу действий.
Ограничим понятие ОС winXP, возьмем машину с двухядерным камнем(или несколькими одноядерными) и запустим что-нибудь "тяжеленькой" с кучей потоков. Пока один юнит надрывается, другой даже в ... ус не дует
Или натурный эксперемент не показатель?
С другими оськами не экспрементировал, если результат другой прошу поделиться
В>во2х, можно озвучить названия библиотек? даже интересно, неужели кому-то хватило мозгов изобретать велосипед для призявки к процессору в обход ОС (хотя без понятия, как это можно вообще реализовать), когда есть winapi-шные SetProcessAffinityMask, SetThreadAffinityMask, SetThreadIdealProcessor
я имел ввиду это . Надеюсь мы говорим об одном и том же >в обход ОС
Речь шла не об этом, а о подсказках OC кого куда и о правомерности этих действий.
Здравствуйте, tartilla, Вы писали:
T>Здравствуйте, Вумудщзук, Вы писали:
В>>во1х, как раз таки ОС и занимается планированием потоков и это атнють не тупая привязка потока к ядру. Более того, есть мнение, что оптимальным в большинстве ситуаций является предоставить планировшику ОС полную свободу действий. T>Ограничим понятие ОС winXP, возьмем машину с двухядерным камнем(или несколькими одноядерными) и запустим что-нибудь "тяжеленькой" с кучей потоков. Пока один юнит надрывается, другой даже в ... ус не дует T> Или натурный эксперемент не показатель? T>С другими оськами не экспрементировал, если результат другой прошу поделиться
А у меня на проге которая не умеет "кучу потоков" оба "юнита" загружены наполовину — и общий показатель в Win Task Manager — 50% для этой проги...
А вот ежели явно ей Affinity на "юнит" прописать — то тут уж она заданный "юнит" и грузит.
Многопоточные — молча занимают 70-80% "общего проца" — при этом в графиках загруженности каждого юнита все те же 70-80%.
T>Речь шла не об этом, а о подсказках OC кого куда и о правомерности этих действий.
Подозреваю у тебя aka "драйвер процессора" кривой или криво настроенный.
>Ограничим понятие ОС winXP, возьмем машину с двухядерным камнем(или несколькими одноядерными) и запустим что-нибудь "тяжеленькой" с кучей потоков. Пока один юнит надрывается, другой даже в ... ус не дует
эээ, запустим (вчера фото фиксил):
— Capture One Pro
— Neat Image из-под PS
— (ну и до кучи) WinRar
все 3 загружают проц (E6400) на 85-95%. При этом NI и WR не импортируют указанные функции винды, то есть винда сама раскидывает потоки по процессорам. Ещё вещьдоки нужны?
>я имел ввиду это . Надеюсь мы говорим об одном и том же
а, ну так есть ещё OpenMP в самой студии (правда, не юзал, деталей не знаю)...
В>все 3 загружают проц (E6400) на 85-95%. При этом NI и WR не импортируют указанные функции винды, то есть винда сама раскидывает потоки по процессорам. Ещё вещьдоки нужны?
Есть мнение о смешивание понятий потока и приложения .
ЗЫ Если бы винда не смогла раскидать процессы по ядрам, то это был бы крах маркетинговой политики Intel, или MS как ваятеля ОС .
>Есть мнение о смешивание понятий потока и приложения . >ЗЫ Если бы винда не смогла раскидать процессы по ядрам, то это был бы крах маркетинговой политики Intel, или MS как ваятеля ОС .
хде/какое смешение ? факт почти 100% проца говорит о том, что винда раскидала _потоки_ по ядрам, чего собственно от неё и ожидалось
В>хде/какое смешение ?
Позволю себе напомнить фразу В>все 3 загружают проц (E6400) на 85-95%.
Дык 3 потока или процесса?
Как только запуском одного приложения , в котором не используются приведенные выше по ветке расширения (типа "еще openMP" ), у вас получится загрузить ваш E6400 на 100% или хотябы на 60% обязательно расскажите.
ЗЫ можете сравнить быстродействие 4-х гиговового камня и вашего(2x2), забавные результаты должны получиться для одного, двух и трех приложений.(а при сравнении с результами элементарных подходов ТМО? , без применения хитрых дисциплин обслуживания на основе анализа предполагаемого времени выполнения задачи, что вообще невероятно для рассмативаемой конфигурации )
ЗЗЫ Корень проблемы в диспетчере задач, он "кванты" кому нарезает? процессу или потокам( = нитям = thread-ам)?
T>Дык 3 потока или процесса?
каждая из трёх указанных прог, будучи запущенной, загружает проц на 85-95%.
T>Как только запуском одного приложения , в котором не используются приведенные выше по ветке расширения (типа "еще openMP" ), у вас получится загрузить ваш E6400 на 100% или хотябы на 60% обязательно расскажите.
а какая разница, используется расширение или нет, если с точки зрения винды любой процесс — это лишь 1 или несколько потоков, которым нужно раздавать время?
но я попробую загрузить...
>ЗЗЫ Корень проблемы в диспетчере задач, он "кванты" кому нарезает? процессу или потокам( = нитям = thread-ам)?
выделяется-то потокам, хотя бы потому, что процесс — не исполняемая.. ммм... сущность.
Здравствуйте, henson, Вы писали:
H>Здравствуйте, AndrewVK, Вы писали:
AVK>>Здравствуйте, aik, Вы писали:
aik>>>Т.е. натурально, "эти 2 дима — для процессора #1, а эти — для процессора #2"?
AVK>>Именно так.
H>Получается чтобы распараллелить потоки одного процесса на два процессора надо еще и данные копировать? Или один процесс нельзя выполнять на двух процессорах?
Можно. Такие системы, как тут описаны — случай NUMA — доступ в память, которая ближе к другому процессору, возможен, но дороже (задействуется ещё какой-то промежуточный мост). Поэтому шедулер, заточенный под NUMA, в случае обнаружения такой конфигурации увеличивает коэффициент "притяжения" процесса к предыдущему процессору (чтобы процесс, раз возникнув на каком-то из процессоров, по возможности оставался на нём же), а при переезде — старается перенести (сразу или постепенно) память процесса в другой пул (который ближе к этому процессору).
В случае нескольких нитей одного процесса картина сложнее — эффективность немного теряется за счёт того, что исполнять приходится обоим процессорам, и второму надо немного "дальше" тянуться. Поэтому как только есть возможность загрузить другой процессор другим процессом (а не нитью) — шедулер старается сделать именно так.
Вот если бы вообще не было общей памяти между блоками (что типично для систем более чем на 64 процессора или для кластерных решений; хотя это и есть случай кластера) — тогда начинается уже совсем иное программирование, основанное на асинхронной передаче сообщений.
Здравствуйте, Вумудщзук, Вы писали:
В>каждая из трёх указанных прог, будучи запущенной, загружает проц на 85-95%.
Честно говоря, я слегка в растеренности . У меня ни одна "прога" больше 50 не жрет . С какой стороны копать даже и не придумаю.
В>любой процесс — это лишь 1 или несколько потоков В>выделяется-то потокам, хотя бы потому, что процесс — не исполняемая.. ммм... сущность.
т.е. чем больше в приложении потоков, тем больше процессорного времени ей перепадает? Или есть зависимость от принадлежности к процессу?
H>Получается чтобы распараллелить потоки одного процесса на два процессора надо еще и данные копировать? Или один процесс нельзя выполнять на двух процессорах?
Можно, никаких ограничений на это нет. И зачастую дает огромный выигрыш.
Я не буду тут распространяться всерьез о перформанс-оптимизации тяжелых по IO и процессору софтов, ибо это близко к собственно моей работе, а я на эти темы трепаться не люблю.
Скажу лишь — выигрыш от раскидывания работы на число ворк-айтемов, равное числу процессоров, в пределах одного процесса, бывает, и большой.
В>во1х, как раз таки ОС и занимается планированием потоков и это атнють не тупая привязка потока к ядру. Более того, есть мнение, что оптимальным в большинстве ситуаций является предоставить планировшику ОС полную свободу действий.
Ни в одной реально серьезной ситуации с высокими требованиями по производительности это не так. Подсказывать кернелу приходится очень активно, и приоритетами, и affinity, и подсказки меняются по ходу execution flow. Можно, конечно, этого не делать, получишь проигрыш в десятки процентов (до двух раз).
Кернел рассчитан на эдакие generic задачи, т.е. задачи без высоких требований к таковой производительности, где не надо выжимать максимум из имеющегося процессора и disk IO.
С задачей оптимальной загрузки процессоров при куче работающего софта, чтобы не получалось так, что ready queue выросла, а процессор(а) в idle — кернел как раз справляется сам, и хорошо.
Он не справляется без подсказок с оптимизацией на производительность одной конкретной задачи, сочетающей в себе disk IO (планирование disk IO вообще только в Висте появилось) и процессор, и все в больших количествах.
Если запущена 1 однотредовая программа, и она не простаивает на disk IO, то будет 50% на каждом из 2 ядер. Чтобы сделать "под сотню на каждом" — как минимум программа должна быть многотредовая.
T>ЗЗЫ Корень проблемы в диспетчере задач, он "кванты" кому нарезает? процессу или потокам( = нитям = thread-ам)?
Кванты работают только при 100% нагрузке процессора, если нить сама так и не отдала управление waitом за все протяжение кванта. Если загрузка меньше 100% — то работает семантика wait/signal, ибо quantum end не наступает никогда и ни у кого.
OpenMP — декларативная (#pragma) многонитевость и локи, портабельная между ОС. На винде реализована в виде автогенерации кода, который зовет нужные Win32 вызовы.
T>т.е. чем больше в приложении потоков, тем больше процессорного времени ей перепадает? Или есть зависимость от принадлежности к процессу?
Да не считает никто там с такой точностью, сколько времени выделить.
Квант — это _ограничение для самого худшего случая_, если нить так заработалась процессором, что так и не позвала никакой wait ни из какого контектса (например, из IopSynchronousServiceTail в ожидании завершения IRP_MJ_READ) за весь квант. Естественно, это 100% загрузки процессора.
Длина кванта (и приоритет тоже) увеличивается для нити, владеющей окном переднего плана в GUI, но только тогда, когда в контрол-панели стоит Optimize for: Applications (а не Background Services). Забыл, как это зовется в реестре — Win32PrioritySeparation, кажется.
Еще есть starvation prevention. Это означает — если нить была готова к исполнению в течение чего-то типа целой секунды, но так и не позвалась на процессор, ее туда зовут силой, даже пересиливая приоритеты. Перерисовка урывками нижележащих окон, когда программа-владелец вернего окна зациклилась — делается именно по этим "пинкам".
Что у нас есть в политике там. Есть приоритеты. При наличии нескольких нитей, ничего не ждущих и к исполнению готовых, зовется на процессор та, у кого приоритет выше. Остальные — голодают, пока приоритетная нить не начнет чего-то ждать, не завершится или пока не сработает starvation prevention, описанный выше.
Голодающие нити — это ready queue, ее видно perfmonом, если она сильно растет при 100% нагрузке на процессор(а) (особенно в SQLных серверах баз данных) — повод к апгрейду на новый камень/камни.
Еще есть ideal processor. При выборах нити на исполнение на процессор те нити, у которых явно задан идеальный процессор, и _это не наш процессор_ — получают пенальти.
Affinity — понятно, даже не пенальти, а вообще запрет бегать на таких-то процессорах.
Еще есть last used processor. Работает так же, как ideal, но эта оценка происходит уже после оценки по ideal. Цель — уменьшить засирание кэшей.
. С какой стороны копать даже и не придумаю.
