-
![[image]](https://www.balancer.ru/cache/sites/ru/3d/3dnews/assets/external/illustrations/2020/07/07/1015091/128x128-crop/pokemon_01.jpg)
Почему ядра не загружены равномерно?
Теги:
TheFreeMan
TheFreeMan>> Scheduler Windows (и Linux тоже) не делает разницы между релаьными и виртуальными ядрами.
Mishka> И, как выяснили, делает....
Я имел ввиду "не делает разницы" == "различает", в смысле может определить, а он решает кто главный.
Я теперь понял откуда "непонятка" пошла, я когда говорю софт, то имею ввиду не applications в OS.
Mishka> И, как выяснили, делает....
Я имел ввиду "не делает разницы" == "различает", в смысле может определить, а он решает кто главный.
Я теперь понял откуда "непонятка" пошла, я когда говорю софт, то имею ввиду не applications в OS.
инфо
инструменты
Mishka> Кстати, вопрос. А они точно равнозначны?
Да, абсолютно.
Например входной поток комманд на одном из HT более "удобный" для out-of-order, тогда будет создаваться впечатление что один немного быстрее.
Да, абсолютно.
Например входной поток комманд на одном из HT более "удобный" для out-of-order, тогда будет создаваться впечатление что один немного быстрее.
Да, и кстати. Совет. 
Если не занимаетесь чем то специфическим, оптимизированным под многопотоковые вычисления, включать HT на 4-х ядрах не рекомендую, нету смысла.
Если не занимаетесь чем то специфическим, оптимизированным под многопотоковые вычисления, включать HT на 4-х ядрах не рекомендую, нету смысла.
Сергей-4030
TheFreeMan> Да, и кстати. Совет.
TheFreeMan> Если не занимаетесь чем то специфическим, оптимизированным под многопотоковые вычисления, включать HT на 4-х ядрах не рекомендую, нету смысла.
Обоснуете? Я не вижу, почему это так. У меня обычно выполняется около 1000 - 1200 потоков. Я не думаю, что все они сильно interlocked. Не вижу существенных причин, почему поток, принадлежащий калькулятору не пустить на один виртуальный процессор, а поток, принадлежащий ноутпаду - на второй. Переключение контекстов все равно делать надо, а HT сделает его быстрее, чем ОС.
TheFreeMan> Если не занимаетесь чем то специфическим, оптимизированным под многопотоковые вычисления, включать HT на 4-х ядрах не рекомендую, нету смысла.
Обоснуете? Я не вижу, почему это так. У меня обычно выполняется около 1000 - 1200 потоков. Я не думаю, что все они сильно interlocked. Не вижу существенных причин, почему поток, принадлежащий калькулятору не пустить на один виртуальный процессор, а поток, принадлежащий ноутпаду - на второй. Переключение контекстов все равно делать надо, а HT сделает его быстрее, чем ОС.
Сергей-4030> Ну, в данном случае она ничего и не должна делать. Переключение контекста на уровне ОС медленнее, чем на уровне HT, а знать, что процессы будут очень сильно interlocked ОС не может.
Лет двадцать наверное была поддержка в CPU для task switch.
Почти никак не используется. :/
Лет двадцать наверное была поддержка в CPU для task switch.
Почти никак не используется. :/
Сергей-4030> Обоснуете? Я не вижу, почему это так. У меня обычно выполняется около 1000 - 1200 потоков. Я не думаю, что все они сильно interlocked. Не вижу существенных причин, почему поток, принадлежащий калькулятору не пустить на один виртуальный процессор, а поток, принадлежащий ноутпаду - на второй. Переключение контекстов все равно делать надо, а HT сделает его быстрее, чем ОС.
HT делает переключение нити (и внутреннего контекста) только при работающем потоке. Да и переключение контекста там своеобразное — в идеале всё идёт в параллель и конкуренции нет. А под нагрузкой — просто доступ к общему ресурсу, т.е. какая-то синхронизация на обе нити. А у тебя куча задач лежит в ОСи, либо ожидающих ввода (калькулятор, ноутпад), либо не готовых. Т.е. на HT не главную нитку ничего и не идёт, т.к. главная нитка не загружена. Т.е. все не главные нитки вошли в режим Idle по команде hlt и там сидят.
Что TheFreeMan хочет сказать, что на 4-х ядернике практически не добиться ситуации, когда все 4 ядра (при отключённом HT) будут загружены на 100% очень трудно. Т.е. для обыного человека смысла нет.
Тут ещё один вопрос возникает. Обычно за синхронизацию надо платить. На самом проце, я думаю тоже. Но для программ обычно есть специально скомпилированные отдельно однонитиевые и отдельно многонитиевые. А как там в проце при отключении HT? Другой микрокод?
HT делает переключение нити (и внутреннего контекста) только при работающем потоке. Да и переключение контекста там своеобразное — в идеале всё идёт в параллель и конкуренции нет. А под нагрузкой — просто доступ к общему ресурсу, т.е. какая-то синхронизация на обе нити. А у тебя куча задач лежит в ОСи, либо ожидающих ввода (калькулятор, ноутпад), либо не готовых. Т.е. на HT не главную нитку ничего и не идёт, т.к. главная нитка не загружена. Т.е. все не главные нитки вошли в режим Idle по команде hlt и там сидят.
Что TheFreeMan хочет сказать, что на 4-х ядернике практически не добиться ситуации, когда все 4 ядра (при отключённом HT) будут загружены на 100% очень трудно. Т.е. для обыного человека смысла нет.
Тут ещё один вопрос возникает. Обычно за синхронизацию надо платить. На самом проце, я думаю тоже. Но для программ обычно есть специально скомпилированные отдельно однонитиевые и отдельно многонитиевые. А как там в проце при отключении HT? Другой микрокод?
TheFreeMan> Лет двадцать наверное была поддержка в CPU для task switch.
TheFreeMan> Почти никак не используется. :/
Это немножко другое. Это аппаратная помощь ОСи на переключение задач. Просто сейчас во многих ОСях есть light threads, у которых контекст сильно меньше. А командочка осталась та же. Ну и количество информации при переключении то же самое, что и 20 лет назад, а в ОСях сильно всё поменялось. Потому и не используется.
TheFreeMan> Почти никак не используется. :/
Это немножко другое. Это аппаратная помощь ОСи на переключение задач. Просто сейчас во многих ОСях есть light threads, у которых контекст сильно меньше. А командочка осталась та же. Ну и количество информации при переключении то же самое, что и 20 лет назад, а в ОСях сильно всё поменялось. Потому и не используется.
Сергей-4030> Обоснуете? Я не вижу, почему это так. У меня обычно выполняется около 1000 - 1200 потоков. Я не думаю, что все они сильно interlocked.
А что обычно показывает Task Manager ? На сколько утилизирован CPU ?
Сергей-4030> все равно делать надо, а HT сделает его быстрее, чем ОС.
Нет, HT не делает context switch.
От того что код на двух HT попытается одновремнно пропистаь ЕАХ регистер, транзисторов в CPU больше не станет, комманды станут в очередь....
А что обычно показывает Task Manager ? На сколько утилизирован CPU ?
Сергей-4030> все равно делать надо, а HT сделает его быстрее, чем ОС.
Нет, HT не делает context switch.
От того что код на двух HT попытается одновремнно пропистаь ЕАХ регистер, транзисторов в CPU больше не станет, комманды станут в очередь....
Balancer
TheFreeMan> На самом деле непонятно зачем... (если CPU idle)...
Я же писал выше — для равномерного тепловыделения (насколько я в курсе). Чтобы не было ситуации, когда одно ядро раскалено, а рядом — холодное.
Я же писал выше — для равномерного тепловыделения (насколько я в курсе). Чтобы не было ситуации, когда одно ядро раскалено, а рядом — холодное.
Mishka> HT делает переключение нити (и внутреннего контекста) только при работающем потоке.
Нет, HT не делает context switch (в классическом смысле).
Mishka> Что TheFreeMan хочет сказать, ...
ППКС.
Mishka> А как там в проце при отключении HT? Другой микрокод?
No comments. NDA.
Нет, HT не делает context switch (в классическом смысле).
Mishka> Что TheFreeMan хочет сказать, ...
ППКС.
Mishka> А как там в проце при отключении HT? Другой микрокод?
No comments. NDA.
TheFreeMan> Нет, HT не делает context switch (в классическом смысле).
Да, я понимаю. Просто, если борятся за одну и ту же аппаратуру, то загрузить в ту аппаратуру своё всё равно надо. Хоть и после ожидания в очереди. Только в этом смылсе.
TheFreeMan> No comments. NDA.
Вот ведь же, только дошли до самого интересного.
Ладно, руки будут свободны, надо будет код сварганить — простенький. Запусить молотилку на реальном проце, а потом на одном виртуальном — без всякой ОСи. Если разница будет, значит другой микрокод.
Да, я понимаю. Просто, если борятся за одну и ту же аппаратуру, то загрузить в ту аппаратуру своё всё равно надо. Хоть и после ожидания в очереди. Только в этом смылсе.
TheFreeMan> No comments. NDA.
Вот ведь же, только дошли до самого интересного.
Ладно, руки будут свободны, надо будет код сварганить — простенький. Запусить молотилку на реальном проце, а потом на одном виртуальном — без всякой ОСи. Если разница будет, значит другой микрокод.
TheFreeMan> Если не занимаетесь чем то специфическим, оптимизированным под многопотоковые вычисления, включать HT на 4-х ядрах не рекомендую, нету смысла.
Да и на двух (на обычном десктопе) смысла нет. Только урезать пиковую производительность.
Да и на двух (на обычном десктопе) смысла нет. Только урезать пиковую производительность.
TheFreeMan> А что обычно показывает Task Manager ? На сколько утилизирован CPU ?
Несколько процентов.
Несколько процентов.
Татарин
TheFreeMan> Нет, HT не делает context switch.
Ему и не надо. "Виртуальные процессоры" имеют свой набор физических регистров.
То есть, если имеем 8 одновременно исполняемых процессов (или потоков), то 4 ядра + НТ при разумном шедулере и прочих равных даст выигрыш против 4-х "однопоточных" ядер. Не нужно менять контекст.
TheFreeMan> От того что код на двух HT попытается одновремнно пропистаь ЕАХ регистер, транзисторов в CPU больше не станет, комманды станут в очередь....
Это если весь код в двух потоках - одинаков и вдоль и поперёк. А поскольку код таки по мере исполнения меняется (команды разные там одна за другой следуют), то два потока на разной стадии исполнения одного и того же кода могут задействовать разные исполняющие устройства.
Проигрыш НТ начинает давать если идёт код, тяжёло загружающий одни и те же блоки (сильная арифметика, например). А это всё-таки код специфичный.
Так что какой резон отключать НТ обычному пользователю?
Пользы от него немного, тут согласен. Ну а вред какой?
Ему и не надо. "Виртуальные процессоры" имеют свой набор физических регистров.
То есть, если имеем 8 одновременно исполняемых процессов (или потоков), то 4 ядра + НТ при разумном шедулере и прочих равных даст выигрыш против 4-х "однопоточных" ядер. Не нужно менять контекст.
TheFreeMan> От того что код на двух HT попытается одновремнно пропистаь ЕАХ регистер, транзисторов в CPU больше не станет, комманды станут в очередь....
Это если весь код в двух потоках - одинаков и вдоль и поперёк.
А поскольку код таки по мере исполнения меняется (команды разные там одна за другой следуют), то два потока на разной стадии исполнения одного и того же кода могут задействовать разные исполняющие устройства.Проигрыш НТ начинает давать если идёт код, тяжёло загружающий одни и те же блоки (сильная арифметика, например). А это всё-таки код специфичный.
Так что какой резон отключать НТ обычному пользователю?
Пользы от него немного, тут согласен. Ну а вред какой?
Mishka> Ладно, руки будут свободны, надо будет код сварганить ... Если разница будет, значит другой микрокод.
На ассемблере без ОС, на одном "потоке", одинаково будет что с HT что без.
Адназначна !
На ассемблере без ОС, на одном "потоке", одинаково будет что с HT что без.
Адназначна !
Татарин> Это если весь код в двух потоках - одинаков и вдоль и поперёк. А поскольку код таки по мере исполнения меняется (команды разные там одна за другой следуют),
А какой по вашему мнению в основном исполняется код, когда утилизaция CPU в 8-ми процессорной системе несколько процентов ?
Грубо говоря имеем намного больше context switches per core. А context switch ето в основном перегрузка GPRs. HT здесь сильно не поможет.
Татарин> Пользы от него немного, тут согласен. Ну а вред какой?
Никакого, я про вред ничего не говорил.
Хотя если придраться, то с включенным HT будет больше потребление энергии (больше context switches)
А поскольку код таки по мере исполнения меняется (команды разные там одна за другой следуют), А какой по вашему мнению в основном исполняется код, когда утилизaция CPU в 8-ми процессорной системе несколько процентов ?
Грубо говоря имеем намного больше context switches per core. А context switch ето в основном перегрузка GPRs. HT здесь сильно не поможет.
Татарин> Пользы от него немного, тут согласен. Ну а вред какой?
Никакого, я про вред ничего не говорил.
Хотя если придраться, то с включенным HT будет больше потребление энергии (больше context switches)
Татарин>> Это если весь код в двух потоках - одинаков и вдоль и поперёк. А поскольку код таки по мере исполнения меняется (команды разные там одна за другой следуют),
TheFreeMan> А какой по вашему мнению в основном исполняется код, когда утилизaция CPU в 8-ми процессорной системе несколько процентов ?
Как-то у нас градус поднялся. Я вовсе не жаловался на недостаточную производительность моего компьютера. Худо-бедно, но распаковать mp3/отобразить страничку/раскомпилировать пару сотен java-файлов он может без особого напряга. Мне просто было интересно, почем так.
А поскольку код таки по мере исполнения меняется (команды разные там одна за другой следуют), TheFreeMan> А какой по вашему мнению в основном исполняется код, когда утилизaция CPU в 8-ми процессорной системе несколько процентов ?
Как-то у нас градус поднялся.
Я вовсе не жаловался на недостаточную производительность моего компьютера. Худо-бедно, но распаковать mp3/отобразить страничку/раскомпилировать пару сотен java-файлов он может без особого напряга. Мне просто было интересно, почем так.
Татарин> Ему и не надо. "Виртуальные процессоры" имеют свой набор физических регистров.
Татарин> То есть, если имеем 8 одновременно исполняемых процессов (или потоков), то 4 ядра + НТ при разумном шедулере и прочих равных даст выигрыш против 4-х "однопоточных" ядер. Не нужно менять контекст.
Не, не так. Если у тебя не постоянное использование проца (affinity) или timeslice не очень длинные, то в общем, задача или нить уходит в другую очередь и контекств переключается всё-равно. Soft affinity, как раз и состоит в том, что ОС пытается сохранить тот же проц для задачи. В лине с ядром 2.4 было просто плохо с этим, а вот в 2.5 уже хорошо и 2.6 унаследовал это хорошо. Т.е. ОС даже пытается отследить, ЕМНИП, что последдний раз была та же задача и даже избежать переключение контекста, но эта ситуация редка. Поэтому включённый НТ не даст выигрыша (практически). Понятно, что можно подобрать специальные условия. Но ОС поддерживающая НТ, и не знающая ничего об избыточной аппаратуре внутри проца просто предпочитает загружать один из двух всегда. Т.е. выигрыша нет и поэтому тоже.
Татарин> Пользы от него немного, тут согласен. Ну а вред какой?
Тут соглашусь.
Татарин> То есть, если имеем 8 одновременно исполняемых процессов (или потоков), то 4 ядра + НТ при разумном шедулере и прочих равных даст выигрыш против 4-х "однопоточных" ядер. Не нужно менять контекст.
Не, не так. Если у тебя не постоянное использование проца (affinity) или timeslice не очень длинные, то в общем, задача или нить уходит в другую очередь и контекств переключается всё-равно. Soft affinity, как раз и состоит в том, что ОС пытается сохранить тот же проц для задачи. В лине с ядром 2.4 было просто плохо с этим, а вот в 2.5 уже хорошо и 2.6 унаследовал это хорошо. Т.е. ОС даже пытается отследить, ЕМНИП, что последдний раз была та же задача и даже избежать переключение контекста, но эта ситуация редка. Поэтому включённый НТ не даст выигрыша (практически). Понятно, что можно подобрать специальные условия. Но ОС поддерживающая НТ, и не знающая ничего об избыточной аппаратуре внутри проца просто предпочитает загружать один из двух всегда. Т.е. выигрыша нет и поэтому тоже.
Татарин> Пользы от него немного, тут согласен. Ну а вред какой?
Тут соглашусь.
Сергей-4030> Как-то у нас градус поднялся. Я вовсе не жаловался на недостаточную производительность моего компьютера.
Я вовсе ничего такого не имел ввиду. Пардон если чо.
Сергей-4030> Худо-бедно, но распаковать mp3/отобразить страничку/раскомпилировать пару сотен java-файлов он может без особого напряга. Мне просто было интересно, почем так.
О, это уже интересней. страничку и mp3, аппликации мнгопотоковые ? CPU (без HT) при этом загружен на > 80% ?
Вот компиляция это хорошо, если компилирует паралельно на всех CPU и грузит их под завязку, тут будет выигрыш (зависит также от RAM и HD)
Я вовсе не жаловался на недостаточную производительность моего компьютера. Я вовсе ничего такого не имел ввиду. Пардон если чо.
Сергей-4030> Худо-бедно, но распаковать mp3/отобразить страничку/раскомпилировать пару сотен java-файлов он может без особого напряга. Мне просто было интересно, почем так.
О, это уже интересней. страничку и mp3, аппликации мнгопотоковые ? CPU (без HT) при этом загружен на > 80% ?
Вот компиляция это хорошо, если компилирует паралельно на всех CPU и грузит их под завязку, тут будет выигрыш (зависит также от RAM и HD)
Mishka> Поэтому включённый НТ не даст выигрыша (практически).
Ты забываешь про задержки чтения из памяти. Как только программа превращается в pointer chase (а это типично для программ обработки данных, использующих стандартные контейнеры), сразу после того, как данные перестают помещаться в L1, начинаются затыки с ожиданием получения данных из L2/L3/внешней памяти.
И вот тут возможность запустить на том же ядре вторую нитку, пока первая ждёт данных — приносит профит.
Ты забываешь про задержки чтения из памяти. Как только программа превращается в pointer chase (а это типично для программ обработки данных, использующих стандартные контейнеры), сразу после того, как данные перестают помещаться в L1, начинаются затыки с ожиданием получения данных из L2/L3/внешней памяти.
И вот тут возможность запустить на том же ядре вторую нитку, пока первая ждёт данных — приносит профит.
Сергей-4030>> Худо-бедно, но распаковать mp3/отобразить страничку/раскомпилировать пару сотен java-файлов он может без особого напряга. Мне просто было интересно, почем так.
TheFreeMan> О, это уже интересней. страничку и mp3, аппликации мнгопотоковые ? CPU (без HT) при этом загружен на > 80% ?
Не, то, что было показано в начале - это с загруженным Skyrim. Это очень редко бывает, обычно процессор вовсе ничего не делает - ну, mp3 играет, Eclipse загружен, и все. Несколько процентов. При компиляции чуть поднимается, но на моих домашних делах полная перекомпиляция происходит редко, а так - ну, сто модулей прокомпилируются, это несколько секунд. И опять тишина.
TheFreeMan> Вот компиляция это хорошо, если компилирует паралельно на всех CPU и грузит их под завязку, тут будет выигрыш (зависит также от RAM и HD)
Если компиляция серьезная - да. А в моем нынешнем домашнем проекте (караоке) всего-то три с небольшим тысячи модулей, даже если полностью перекомпилировать, занимает секунды. Выигрыш смешной.
TheFreeMan> О, это уже интересней. страничку и mp3, аппликации мнгопотоковые ? CPU (без HT) при этом загружен на > 80% ?
Не, то, что было показано в начале - это с загруженным Skyrim. Это очень редко бывает, обычно процессор вовсе ничего не делает - ну, mp3 играет, Eclipse загружен, и все. Несколько процентов. При компиляции чуть поднимается, но на моих домашних делах полная перекомпиляция происходит редко, а так - ну, сто модулей прокомпилируются, это несколько секунд. И опять тишина.
TheFreeMan> Вот компиляция это хорошо, если компилирует паралельно на всех CPU и грузит их под завязку, тут будет выигрыш (зависит также от RAM и HD)
Если компиляция серьезная - да. А в моем нынешнем домашнем проекте (караоке) всего-то три с небольшим тысячи модулей, даже если полностью перекомпилировать, занимает секунды. Выигрыш смешной.
Mishka> Что TheFreeMan хочет сказать, что на 4-х ядернике практически не добиться ситуации, когда все 4 ядра (при отключённом HT) будут загружены на 100% очень трудно. Т.е. для обыного человека смысла нет.
AXT> И вот тут возможность запустить на том же ядре вторую нитку, пока первая ждёт данных — приносит профит.
Да, можно. Но, если задачи все такие, то пофигу. Бо все ждут. Мы же про среднего человека говорим.
Да, можно. Но, если задачи все такие, то пофигу. Бо все ждут. Мы же про среднего человека говорим.
TheFreeMan> На ассемблере без ОС, на одном "потоке", одинаково будет что с HT что без.
На P4 при работе в HT под Linux пиковая производительность одного процесса падает ровно вдвое. Собственно, оно и понятно — на то и два виртуальных ядра, чтобы один процесс всё не сожрал и оставался постоянный резерв для новых процессов, скажем, того же GUI.
Неужели на более новых подход изменили? Точно не измерял, но мне показалось, что, например, на двухядерном i3 однопоточная упаковка архива в HT под Windows идёт медленнее, чем без HT. Надо бы в Linux посмотреть, там нагляднее будет.
На P4 при работе в HT под Linux пиковая производительность одного процесса падает ровно вдвое. Собственно, оно и понятно — на то и два виртуальных ядра, чтобы один процесс всё не сожрал и оставался постоянный резерв для новых процессов, скажем, того же GUI.
Неужели на более новых подход изменили? Точно не измерял, но мне показалось, что, например, на двухядерном i3 однопоточная упаковка архива в HT под Windows идёт медленнее, чем без HT. Надо бы в Linux посмотреть, там нагляднее будет.
Balancer> Неужели на более новых подход изменили? Точно не измерял, но мне показалось, что, например, на двухядерном i3 однопоточная упаковка архива в HT под Windows идёт медленнее, чем без HT. Надо бы в Linux посмотреть, там нагляднее будет.
Многопоточная упаковка — очень плохой случай, т.к. конкуренция идёт за одни ресурсы. Возьми однопоточную и одновременно что-то другое.
Многопоточная упаковка — очень плохой случай, т.к. конкуренция идёт за одни ресурсы. Возьми однопоточную и одновременно что-то другое.
Copyright © Balancer 1997..2020
Создано 08.01.2012
Связь с владельцами и администрацией сайта: anonisimov@gmail.com, rwasp1957@yandex.ru и admin@balancer.ru.
Создано 08.01.2012
Связь с владельцами и администрацией сайта: anonisimov@gmail.com, rwasp1957@yandex.ru и admin@balancer.ru.
