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

A>А я не вижу зачем вообще это надо на десктопе.

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

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

rm2>потому что когда там фпс 300 или 450 — пофиг, а вот то что температура градусов на 20 больше стала — то заметно стало

Ну и логика у тебя. Фпс стал выше — пофиг, зато греется сильнее — это вроде как лучше стало

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

A>А я не вижу зачем вообще это надо на десктопе.

PS я просто офигеваю от здешней публики. Ругают PE ядра за все те же недостатки что есть и у HT, но при этом хвалят HT. Более того — не понимают, что у HT есть серьезные недостатки, которых у PE нет.

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

A>>А ты думаешь, такой планировщик сможет работать на 100% эффективно? Не допуская, даже временно, выделения требовательному потоку эконом-ядра?

Ф>Ну а почему нет!? Может работать на 100% эффективно, если будет считать нетребовательными потоки, которые более трёх квантов подряд отработали не использовали более чем на четверть, или уже 10 минут подряд висят на мьютексе или спин-локе.

Звучит красиво, только в реальности есть, допустим, 4+4 ядра и этак с тысячу потоков. И они, собаки, в твои простые эвристики не укладываются. Закончится всё, как на картинке:



Главное, ещё раз, зачем даже в принципе иметь возможность просадки производительности, если у тебя комп работает от розетки? Экономичное ядро разве будет дешевле?

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

A>>А я не вижу зачем вообще это надо на десктопе.

C>Добавочная скорость в многопотоке при том же транзисторном и тепловом бюджете, а избавление от гипертрединга улучшает однопоток и латентность.

Гипертрединг и экономичные ядра — это взаимоисключающие вещи? Или тебе просто настолько нравится слово "гипетрединг", что ты его вставляешь в каждый пост?

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

A>Гипертрединг и экономичные ядра — это взаимоисключающие вещи?

Если очень любишь проблемы — то нет, не взаимоисключающие.

A>Или тебе просто настолько нравится слово "гипетрединг", что ты его вставляешь в каждый пост?

Пц. Больше не нашел, к чему придраться?

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

A>Главное, ещё раз, зачем даже в принципе иметь возможность просадки производительности, если у тебя комп работает от розетки?

Значит, гипертрединг не нужен.

A>Экономичное ядро разве будет дешевле?

Да, вычислительная мощность в такой форме дешевле. В этом весь смысл.
Все еще не дошло?

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

A>Главное, ещё раз, зачем даже в принципе иметь возможность просадки производительности, если у тебя комп работает от розетки? Экономичное ядро разве будет дешевле?

Не знаю, сделали ли это конкретно у Intel и AMD, но да, экономичное ядро можно сделать дешевле с точки зрения финальных затрат энергии на одну операцию, и методы для этого известны уже лет 40, со времён разделения CMOS и n-MOS. Или 60, если считать от появления ЭСЛ.
И это если не считать ещё игр по множеству параметров типа размеров кэшей и длины конвейера OoO, где есть множество затрат, которые растут сверхлинейно с ростом производительности.

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

Pzz>Нету внятной модели, чтобы этим заморачиваться. Я, например, как разработчик, не знаю, что выгоднее, прокрутить ту или иную активность по-быстрому на быстром ядре или на большее время занять медленное ядро. Как мне понять, в каком случае я потрачу меньше электричества? И не изменится ли выбор на следующей модели процессора?

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

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

_>с моего дивана видится, что должна быть некая прагма компилятора, типа поток емкий/лайтовый/фоновый/критический и т.п. И компилятор уже спец командами это объяснит процессору, под который идет сборка.

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

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

A>>Здравым смыслом

C>То есть, ответа у тебя нет.

Ответ у меня очевидный — "Нахрена?". То что ты не желаешь его воспринимать — твои проблемы.

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

_>с моего дивана видится, что должна быть некая прагма компилятора, типа поток емкий/лайтовый/фоновый/критический и т.п. И компилятор уже спец командами это объяснит процессору, под который идет сборка.

Не процессору, а операционной системе, и сдаётся мне, что рулить этим всем придётся всё-таки руками:

	пример руления (копипаста из MSDN'а
	THREAD_POWER_THROTTLING_STATE PowerThrottling; ZeroMemory(&PowerThrottling, sizeof(PowerThrottling)); PowerThrottling.Version = THREAD_POWER_THROTTLING_CURRENT_VERSION; // // EcoQoS // Turn EXECUTION_SPEED throttling on. // ControlMask selects the mechanism and StateMask declares which mechanism should be on or off. // PowerThrottling.ControlMask = THREAD_POWER_THROTTLING_EXECUTION_SPEED; PowerThrottling.StateMask = THREAD_POWER_THROTTLING_EXECUTION_SPEED; SetThreadInformation(GetCurrentThread(), ThreadPowerThrottling, &PowerThrottling, sizeof(PowerThrottling)); // // HighQoS // Turn EXECUTION_SPEED throttling off. // ControlMask selects the mechanism and StateMask is set to zero as mechanisms should be turned off. // PowerThrottling.ControlMask = THREAD_POWER_THROTTLING_EXECUTION_SPEED; PowerThrottling.StateMask = 0; SetThreadInformation(GetCurrentThread(), ThreadPowerThrottling, &PowerThrottling, sizeof(PowerThrottling)); // // Let system manage all power throttling. ControlMask is set to 0 as we don’t want // to control any mechanisms. // PowerThrottling.ControlMask = 0; PowerThrottling.StateMask = 0; SetThreadInformation(GetCurrentThread(), ThreadPowerThrottling, &PowerThrottling, sizeof(PowerThrottling));

Очевидно же, что для программы может меняться требованияк скорости вычислителя для потока. Так же очевидно, что поток — объект ядра, и создавать его очень дорого — нужно реиспользовать уже созданные.

The Quality of Service (QoS) associated with a thread is used to indicate the desired performance and power efficiency. Each thread is assigned to a QoS level. While scheduling priority remains the main metric by which the system determines which thread to schedule next, QoS can influence core selection and processor power management. On platforms with heterogeneous processors, the QoS of a thread may restrict scheduling to a subset of processors, or indicate a preference for a particular class of processor.

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

A>>Здравым смыслом

Ф>Здравый смысл как раз таки подсказывает, что правильная: дофига софта лупят в один поток. Например, мой "горячо любимый" WinDbg c расширениями типа SoS именно такой, а провести там можно весь день, а потом он ещё ночь (всю) он будет GCRoot выводить.

И чё? Зачем тут нужны хилые "экономичные" ядра? Почему их нельзя заменить одним нормальным ядром?

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

A>И чё? Зачем тут нужны хилые "экономичные" ядра? Почему их нельзя заменить одним нормальным ядром?

Чтобы на них упала некритичная фоновая нагрузка, очевидно же, что ядра "экономичные" — электричество экономят т.е.

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


A>>И чё? Зачем тут нужны хилые "экономичные" ядра? Почему их нельзя заменить одним нормальным ядром?

Ф>Чтобы на них упала некритичная фоновая нагрузка, очевидно же, что ядра "экономичные" — электричество экономят т.е.

Ну и как они его экономят-то? Просто медленно работают? Ну пусть нормальные ядра тоже медленно работают.
Чудес же не бывает. Если нужно сложить два числа, то их нужно сложить.

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

A>>Главное, ещё раз, зачем даже в принципе иметь возможность просадки производительности, если у тебя комп работает от розетки? Экономичное ядро разве будет дешевле?

N>дешевле с точки зрения финальных затрат энергии на одну операцию

Я, если что, говорил про деньги.

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

A>Ну и как они его экономят-то? Просто медленно работают? Ну пусть нормальные ядра тоже медленно работают.
A>Чудес же не бывает. Если нужно сложить два числа, то их нужно сложить.


Твоё "сложить 2 числа" по огромному конвейеру проходит, пока наконец исполнится. От длинны и сложности этого конвейера, от блоков на этом конвейере и зависит то как быстро оно исполнится и сколько энергии потребует в конечном счёте.

Смотри:
Прежде чем сложить 2 числа, нужно сначала взять инструкцию из память (The Fetch/Decode Unit), потом распознать инструкцию задействовав там же Instruction Decoder или Simple Instruction Decoder, потом обратиться к таблице алиасов регистров (Register Alias Table), потом загнать эту инструкццию в Reorder Buffer, и только потом Retirement Unit может взять оттуда микрооперации и загнать их Integer Unit, который наконец-то сможет сложить два числа. А потом ещё вопрос, что с результатом делать — всё осложняет Register Alias Table.
Это самый-самый минимум, который я выдрал из спецификации к Pentium Pro, притом не всё оттуда переписал. Т.е. не просто так сложить. Это для тебя это выглядит как

add eax, ebx

под капотом всё немного сложнее.

Из того, что я намеренно пропустил в тут — Dispatch/Execute Unit. Это именно та штука, которая выбирает из буфера перестановок микрооперации. Он может быть очень сильно разным, как и колличество исполнительных блоков. Например, в NetBurst этот блок в мануале уже называется "The out-of-order execution core" и он уже содержит несколько буферов переупорядочивания . В Pentium Pro (во всей P6) 5 исполнительных блоков: 2 целочисленных юнита, 2 плавающей точки и один memory-interface юнит. NetBurst уже за так умеет 6 операций диспатчить, притом его 3 АЛУ работают на удвоенной частоте ядра.
Очевидно, что колличество исполнительных блоков может быть сильно разным и работать они могут очень по разному, и устроены могут быть по-разному: могут быть отдельно целочисленные юниты и юниты плавающей точки, а могут быть обобщённые ALU, которые в добавок элементарные целочисленные операции за половину такта выполняют.

А кроме есть, есть ещё много много всякого, в котором я до конца не разобрался и где подробностей не знаю, однако они тоже участвуют в исполнении, тоже влияют на скорость исполнения и в конечном счёте на сожранную в процессе энергию. Это например целевые буферы ветвлений (B ranch Target Buffers), кэши трассировки и блок предсказания переходов (в документации — branch prediction hardware). И ещё много-много чего, что пролетело мимо моего внимания, просто потому что я разбирался только с оптимизацией кода, а не процессор проектировал. Всё это учавствует в "сложить 2 числа".

ЗЫ: У меня слегка подгорает, когда прогер с оргомным опытом говорит про "просто ложить 2 числа"....

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

A>Ответ у меня очевидный — "Нахрена?".

Мой ответ — больше производительности за те же деньги.

A>То что ты не желаешь его воспринимать — твои проблемы.

Нет, проблемы с восприятием здесь только у тебя.

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

Ф>ЗЫ: У меня слегка подгорает, когда прогер с оргомным опытом говорит про "просто ложить 2 числа"....

У некоторых людей, это всего лишь один год опыта повторенный много раз.

Еще один важный фактор — потребление энергии растет с ростом частоты намного быстрее, чем линейно. То ли по квадрату то ли по кубу, не помню точно.

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

A>>Ну и как они его экономят-то? Просто медленно работают? Ну пусть нормальные ядра тоже медленно работают.
A>>Чудес же не бывает. Если нужно сложить два числа, то их нужно сложить.


Ф>Твоё "сложить 2 числа" по огромному конвейеру проходит, пока наконец исполнится. От длинны и сложности этого конвейера, от блоков на этом конвейере и зависит то как быстро оно исполнится и сколько энергии потребует в конечном счёте.

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

Ф>ЗЫ: У меня слегка подгорает, когда прогер с оргомным опытом говорит про "просто ложить 2 числа"....

Я не говорил, что нужно "просто сложить два числа". Я сказал, что работа должна быть сделана.
Работа всех этих конвейеров должна быть сделана.

PS.
Наш процессор в экономичном режиме не занимался переупорядочиванием инструкций (и всякой другой фигнёй),
а просто замирал до тех пор, пока данные не приходили из памяти.
При этом не тратил ни одного лишнего такта на лишнюю работу.
И что мешало то же самое сделать Интелу?