Почему ядра не загружены равномерно?

 
1 2 3 4 5 6
IL TheFreeMan #10.01.2012 23:58  @Mishka#10.01.2012 23:50
+
-
edit
 

TheFreeMan

втянувшийся

TheFreeMan>> Scheduler Windows (и Linux тоже) не делает разницы между релаьными и виртуальными ядрами.
Mishka> И, как выяснили, делает....

Я имел ввиду "не делает разницы" == "различает", в смысле может определить, а он решает кто главный.

Я теперь понял откуда "непонятка" пошла, я когда говорю софт, то имею ввиду не applications в OS.
 16.0.912.7516.0.912.75
IL TheFreeMan #11.01.2012 00:03  @Mishka#10.01.2012 23:54
+
-
edit
 

TheFreeMan

втянувшийся

Mishka> Кстати, вопрос. А они точно равнозначны?
Да, абсолютно.
Например входной поток комманд на одном из HT более "удобный" для out-of-order, тогда будет создаваться впечатление что один немного быстрее.
 16.0.912.7516.0.912.75
IL TheFreeMan #11.01.2012 00:10  @TheFreeMan#11.01.2012 00:03
+
-
edit
 

TheFreeMan

втянувшийся

Да, и кстати. Совет. :-)

Если не занимаетесь чем то специфическим, оптимизированным под многопотоковые вычисления, включать HT на 4-х ядрах не рекомендую, нету смысла.
 16.0.912.7516.0.912.75
US Сергей-4030 #11.01.2012 00:14  @TheFreeMan#11.01.2012 00:10
+
-
edit
 

Сергей-4030

исключающий третье
★★
TheFreeMan> Да, и кстати. Совет. :-)
TheFreeMan> Если не занимаетесь чем то специфическим, оптимизированным под многопотоковые вычисления, включать HT на 4-х ядрах не рекомендую, нету смысла.

Обоснуете? Я не вижу, почему это так. У меня обычно выполняется около 1000 - 1200 потоков. Я не думаю, что все они сильно interlocked. Не вижу существенных причин, почему поток, принадлежащий калькулятору не пустить на один виртуальный процессор, а поток, принадлежащий ноутпаду - на второй. Переключение контекстов все равно делать надо, а HT сделает его быстрее, чем ОС.
 16.0.912.7516.0.912.75
IL TheFreeMan #11.01.2012 00:27  @Сергей-4030#10.01.2012 23:45
+
-
edit
 

TheFreeMan

втянувшийся

Сергей-4030> Ну, в данном случае она ничего и не должна делать. Переключение контекста на уровне ОС медленнее, чем на уровне HT, а знать, что процессы будут очень сильно interlocked ОС не может.

Лет двадцать наверное была поддержка в CPU для task switch.
Почти никак не используется. :/
 16.0.912.7516.0.912.75
US Mishka #11.01.2012 00:30  @Сергей-4030#11.01.2012 00:14
+
-
edit
 

Mishka

модератор
★★★
Сергей-4030> Обоснуете? Я не вижу, почему это так. У меня обычно выполняется около 1000 - 1200 потоков. Я не думаю, что все они сильно interlocked. Не вижу существенных причин, почему поток, принадлежащий калькулятору не пустить на один виртуальный процессор, а поток, принадлежащий ноутпаду - на второй. Переключение контекстов все равно делать надо, а HT сделает его быстрее, чем ОС.

HT делает переключение нити (и внутреннего контекста) только при работающем потоке. Да и переключение контекста там своеобразное — в идеале всё идёт в параллель и конкуренции нет. А под нагрузкой — просто доступ к общему ресурсу, т.е. какая-то синхронизация на обе нити. А у тебя куча задач лежит в ОСи, либо ожидающих ввода (калькулятор, ноутпад), либо не готовых. Т.е. на HT не главную нитку ничего и не идёт, т.к. главная нитка не загружена. Т.е. все не главные нитки вошли в режим Idle по команде hlt и там сидят.

Что TheFreeMan хочет сказать, что на 4-х ядернике практически не добиться ситуации, когда все 4 ядра (при отключённом HT) будут загружены на 100% очень трудно. Т.е. для обыного человека смысла нет.

Тут ещё один вопрос возникает. Обычно за синхронизацию надо платить. На самом проце, я думаю тоже. Но для программ обычно есть специально скомпилированные отдельно однонитиевые и отдельно многонитиевые. А как там в проце при отключении HT? Другой микрокод?
 7.0.17.0.1
US Mishka #11.01.2012 00:32  @TheFreeMan#11.01.2012 00:27
+
-
edit
 

Mishka

модератор
★★★
TheFreeMan> Лет двадцать наверное была поддержка в CPU для task switch.
TheFreeMan> Почти никак не используется. :/
Это немножко другое. Это аппаратная помощь ОСи на переключение задач. Просто сейчас во многих ОСях есть light threads, у которых контекст сильно меньше. А командочка осталась та же. Ну и количество информации при переключении то же самое, что и 20 лет назад, а в ОСях сильно всё поменялось. Потому и не используется.
 7.0.17.0.1
IL TheFreeMan #11.01.2012 00:32  @Сергей-4030#11.01.2012 00:14
+
-
edit
 

TheFreeMan

втянувшийся

Сергей-4030> Обоснуете? Я не вижу, почему это так. У меня обычно выполняется около 1000 - 1200 потоков. Я не думаю, что все они сильно interlocked.

А что обычно показывает Task Manager ? На сколько утилизирован CPU ?

Сергей-4030> все равно делать надо, а HT сделает его быстрее, чем ОС.

Нет, HT не делает context switch.
От того что код на двух HT попытается одновремнно пропистаь ЕАХ регистер, транзисторов в CPU больше не станет, комманды станут в очередь....
 16.0.912.7516.0.912.75
RU Balancer #11.01.2012 00:34  @TheFreeMan#10.01.2012 22:34
+
-
edit
 

Balancer

администратор
★★★★★
TheFreeMan> На самом деле непонятно зачем... (если CPU idle)...

Я же писал выше — для равномерного тепловыделения (насколько я в курсе). Чтобы не было ситуации, когда одно ядро раскалено, а рядом — холодное.
 
IL TheFreeMan #11.01.2012 00:38  @Mishka#11.01.2012 00:30
+
-
edit
 

TheFreeMan

втянувшийся

Mishka> HT делает переключение нити (и внутреннего контекста) только при работающем потоке.
Нет, HT не делает context switch (в классическом смысле).
Mishka> Что TheFreeMan хочет сказать, ...
ППКС. :-)
Mishka> А как там в проце при отключении HT? Другой микрокод?
No comments. NDA. :-)
 16.0.912.7516.0.912.75
US Mishka #11.01.2012 00:41  @TheFreeMan#11.01.2012 00:38
+
-
edit
 

Mishka

модератор
★★★
TheFreeMan> Нет, HT не делает context switch (в классическом смысле).

Да, я понимаю. Просто, если борятся за одну и ту же аппаратуру, то загрузить в ту аппаратуру своё всё равно надо. Хоть и после ожидания в очереди. Только в этом смылсе. :)

TheFreeMan> No comments. NDA. :-)
Вот ведь же, только дошли до самого интересного. :F

Ладно, руки будут свободны, надо будет код сварганить — простенький. Запусить молотилку на реальном проце, а потом на одном виртуальном — без всякой ОСи. Если разница будет, значит другой микрокод. :F
 7.0.17.0.1
RU Balancer #11.01.2012 00:43  @TheFreeMan#11.01.2012 00:10
+
-
edit
 

Balancer

администратор
★★★★★
TheFreeMan> Если не занимаетесь чем то специфическим, оптимизированным под многопотоковые вычисления, включать HT на 4-х ядрах не рекомендую, нету смысла.

Да и на двух (на обычном десктопе) смысла нет. Только урезать пиковую производительность.
 
US Сергей-4030 #11.01.2012 00:47  @TheFreeMan#11.01.2012 00:32
+
-
edit
 

Сергей-4030

исключающий третье
★★
TheFreeMan> А что обычно показывает Task Manager ? На сколько утилизирован CPU ?

Несколько процентов.
 16.0.912.7516.0.912.75
EE Татарин #11.01.2012 00:47  @TheFreeMan#11.01.2012 00:32
+
-
edit
 

Татарин

координатор
★★★★☆
TheFreeMan> Нет, HT не делает context switch.
Ему и не надо. "Виртуальные процессоры" имеют свой набор физических регистров.
То есть, если имеем 8 одновременно исполняемых процессов (или потоков), то 4 ядра + НТ при разумном шедулере и прочих равных даст выигрыш против 4-х "однопоточных" ядер. Не нужно менять контекст.

TheFreeMan> От того что код на двух HT попытается одновремнно пропистаь ЕАХ регистер, транзисторов в CPU больше не станет, комманды станут в очередь....
Это если весь код в двух потоках - одинаков и вдоль и поперёк. :) А поскольку код таки по мере исполнения меняется (команды разные там одна за другой следуют), то два потока на разной стадии исполнения одного и того же кода могут задействовать разные исполняющие устройства.

Проигрыш НТ начинает давать если идёт код, тяжёло загружающий одни и те же блоки (сильная арифметика, например). А это всё-таки код специфичный.
Так что какой резон отключать НТ обычному пользователю?
Пользы от него немного, тут согласен. Ну а вред какой?
...А неубитые медведи делили чьи-то шкуры с шумом. Боюсь, мы поздно осознали, к чему всё это приведёт.  9.0.19.0.1
IL TheFreeMan #11.01.2012 01:00  @Mishka#11.01.2012 00:41
+
-
edit
 

TheFreeMan

втянувшийся

Mishka> Ладно, руки будут свободны, надо будет код сварганить ... Если разница будет, значит другой микрокод. :F

На ассемблере без ОС, на одном "потоке", одинаково будет что с HT что без.
Адназначна ! :D
 16.0.912.7516.0.912.75
IL TheFreeMan #11.01.2012 01:10  @Татарин#11.01.2012 00:47
+
-
edit
 

TheFreeMan

втянувшийся

Татарин> Это если весь код в двух потоках - одинаков и вдоль и поперёк. :) А поскольку код таки по мере исполнения меняется (команды разные там одна за другой следуют),

А какой по вашему мнению в основном исполняется код, когда утилизaция CPU в 8-ми процессорной системе несколько процентов ?
Грубо говоря имеем намного больше context switches per core. А context switch ето в основном перегрузка GPRs. HT здесь сильно не поможет.

Татарин> Пользы от него немного, тут согласен. Ну а вред какой?
Никакого, я про вред ничего не говорил.
Хотя если придраться, то с включенным HT будет больше потребление энергии (больше context switches) :D
 16.0.912.7516.0.912.75
US Сергей-4030 #11.01.2012 01:19  @TheFreeMan#11.01.2012 01:10
+
-
edit
 

Сергей-4030

исключающий третье
★★
Татарин>> Это если весь код в двух потоках - одинаков и вдоль и поперёк. :) А поскольку код таки по мере исполнения меняется (команды разные там одна за другой следуют),
TheFreeMan> А какой по вашему мнению в основном исполняется код, когда утилизaция CPU в 8-ми процессорной системе несколько процентов ?

Как-то у нас градус поднялся. :) Я вовсе не жаловался на недостаточную производительность моего компьютера. Худо-бедно, но распаковать mp3/отобразить страничку/раскомпилировать пару сотен java-файлов он может без особого напряга. Мне просто было интересно, почем так.
 16.0.912.7516.0.912.75
US Mishka #11.01.2012 01:25  @Татарин#11.01.2012 00:47
+
-
edit
 

Mishka

модератор
★★★
Татарин> Ему и не надо. "Виртуальные процессоры" имеют свой набор физических регистров.
Татарин> То есть, если имеем 8 одновременно исполняемых процессов (или потоков), то 4 ядра + НТ при разумном шедулере и прочих равных даст выигрыш против 4-х "однопоточных" ядер. Не нужно менять контекст.

Не, не так. Если у тебя не постоянное использование проца (affinity) или timeslice не очень длинные, то в общем, задача или нить уходит в другую очередь и контекств переключается всё-равно. Soft affinity, как раз и состоит в том, что ОС пытается сохранить тот же проц для задачи. В лине с ядром 2.4 было просто плохо с этим, а вот в 2.5 уже хорошо и 2.6 унаследовал это хорошо. Т.е. ОС даже пытается отследить, ЕМНИП, что последдний раз была та же задача и даже избежать переключение контекста, но эта ситуация редка. Поэтому включённый НТ не даст выигрыша (практически). Понятно, что можно подобрать специальные условия. Но ОС поддерживающая НТ, и не знающая ничего об избыточной аппаратуре внутри проца просто предпочитает загружать один из двух всегда. Т.е. выигрыша нет и поэтому тоже.

Татарин> Пользы от него немного, тут согласен. Ну а вред какой?
Тут соглашусь.
 7.0.17.0.1
IL TheFreeMan #11.01.2012 01:31  @Сергей-4030#11.01.2012 01:19
+
-
edit
 

TheFreeMan

втянувшийся

Сергей-4030> Как-то у нас градус поднялся. :) Я вовсе не жаловался на недостаточную производительность моего компьютера.

Я вовсе ничего такого не имел ввиду. Пардон если чо.

Сергей-4030> Худо-бедно, но распаковать mp3/отобразить страничку/раскомпилировать пару сотен java-файлов он может без особого напряга. Мне просто было интересно, почем так.

О, это уже интересней. страничку и mp3, аппликации мнгопотоковые ? CPU (без HT) при этом загружен на > 80% ?
Вот компиляция это хорошо, если компилирует паралельно на всех CPU и грузит их под завязку, тут будет выигрыш (зависит также от RAM и HD)
 16.0.912.7516.0.912.75

AXT

инженер вольнодумец
★☆
Mishka> Поэтому включённый НТ не даст выигрыша (практически).

Ты забываешь про задержки чтения из памяти. Как только программа превращается в pointer chase (а это типично для программ обработки данных, использующих стандартные контейнеры), сразу после того, как данные перестают помещаться в L1, начинаются затыки с ожиданием получения данных из L2/L3/внешней памяти.
И вот тут возможность запустить на том же ядре вторую нитку, пока первая ждёт данных — приносит профит.
... так пускай наступает на нас холодным рассветом новый день ...  8.0.18.0.1
US Сергей-4030 #11.01.2012 01:38  @TheFreeMan#11.01.2012 01:31
+
-
edit
 

Сергей-4030

исключающий третье
★★
Сергей-4030>> Худо-бедно, но распаковать mp3/отобразить страничку/раскомпилировать пару сотен java-файлов он может без особого напряга. Мне просто было интересно, почем так.
TheFreeMan> О, это уже интересней. страничку и mp3, аппликации мнгопотоковые ? CPU (без HT) при этом загружен на > 80% ?

Не, то, что было показано в начале - это с загруженным Skyrim. Это очень редко бывает, обычно процессор вовсе ничего не делает - ну, mp3 играет, Eclipse загружен, и все. Несколько процентов. При компиляции чуть поднимается, но на моих домашних делах полная перекомпиляция происходит редко, а так - ну, сто модулей прокомпилируются, это несколько секунд. И опять тишина.

TheFreeMan> Вот компиляция это хорошо, если компилирует паралельно на всех CPU и грузит их под завязку, тут будет выигрыш (зависит также от RAM и HD)

Если компиляция серьезная - да. А в моем нынешнем домашнем проекте (караоке) всего-то три с небольшим тысячи модулей, даже если полностью перекомпилировать, занимает секунды. Выигрыш смешной.
 16.0.912.7516.0.912.75
IL TheFreeMan #11.01.2012 01:42  @Сергей-4030#11.01.2012 01:38
+
-
edit
 

TheFreeMan

втянувшийся

Mishka> Что TheFreeMan хочет сказать, что на 4-х ядернике практически не добиться ситуации, когда все 4 ядра (при отключённом HT) будут загружены на 100% очень трудно. Т.е. для обыного человека смысла нет.

:D
 16.0.912.7516.0.912.75

Mishka

модератор
★★★
AXT> И вот тут возможность запустить на том же ядре вторую нитку, пока первая ждёт данных — приносит профит.

Да, можно. Но, если задачи все такие, то пофигу. Бо все ждут. Мы же про среднего человека говорим.
 7.0.17.0.1
RU Balancer #11.01.2012 04:33  @TheFreeMan#11.01.2012 01:00
+
-
edit
 

Balancer

администратор
★★★★★
TheFreeMan> На ассемблере без ОС, на одном "потоке", одинаково будет что с HT что без.

На P4 при работе в HT под Linux пиковая производительность одного процесса падает ровно вдвое. Собственно, оно и понятно — на то и два виртуальных ядра, чтобы один процесс всё не сожрал и оставался постоянный резерв для новых процессов, скажем, того же GUI.

Неужели на более новых подход изменили? Точно не измерял, но мне показалось, что, например, на двухядерном i3 однопоточная упаковка архива в HT под Windows идёт медленнее, чем без HT. Надо бы в Linux посмотреть, там нагляднее будет.
 
+
-
edit
 

Mishka

модератор
★★★
Balancer> Неужели на более новых подход изменили? Точно не измерял, но мне показалось, что, например, на двухядерном i3 однопоточная упаковка архива в HT под Windows идёт медленнее, чем без HT. Надо бы в Linux посмотреть, там нагляднее будет.
Многопоточная упаковка — очень плохой случай, т.к. конкуренция идёт за одни ресурсы. Возьми однопоточную и одновременно что-то другое.
 7.0.17.0.1
1 2 3 4 5 6

в начало страницы | новое
 
1918: С Днём советской армии и военно-морского флота! (100 лет).
Поиск
Настройки
Твиттер сайта
Статистика
Рейтинг@Mail.ru