LINUX.ORG.RU

Мысли про архитектуру Alder Lake

 , ,


1

1

Чего-то чем далее, тем более оно странно выглядит. Запишу-ка на память.

1) Это как надо было упороться, чтобы разным ядрам (производительным и энергоэффективным) дать разные CPUID, ну вот зачем, чтобы жизнь медом не казалась? Оно кажется логичным только с первого взгляда, но CPUID - это до сих пор был идентификатор устройства а не ядра в нем. Отсюда уже пошли приколы в некоторых приложениях.

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

С другой стороны, учитывая, что ряд инструкций не доступен на E-cores и эту ситуацию надо как-то учитывать ... В общем дурдом.

2) Планировщик задач. Если подумать, сложно представить, как вообще должен работать тут правильный планировщик, потому что в зависимости от сценария использования и ОС и приложения могут быть разные подходы. Сейчас юзеры жалуются, что можно запустить что-то тяжелое, например рендеринг, переключиться на браузер и планировщик (виндовый) вытолкает рендеринг на слабое ядро, хотя логично было бы наоборот. Но планировщику не известно как правильно, хотя бы потому что браузер тоже может жрать ресурсы и по другой логике его таки правильно определить на P-Core.

3) До сих пор что-то не особо выходит компенсировать аппаратные усложнения правильным софтописательством. Или получается, но для ограниченного круга задач, обычно серверных решений.

★★★★★

Разуется, у меня нет никаких знаний матчасти чтоб иметь аргументированное мнение по теме.

Но у меня вопрос: Ты правда думаешь, что понимаешь все это лучше, чем те десятки и сотни специалистов интела, что их проектировали?

dk__
()

Мя как-то не замечал, были уже истории успеха среди лоровцев? Разного рода желтушные сайты пишут, что линь на сабже работает на +всрат, а на себе проверять вообще неохота.

izzholtik ★★★
()

Вообще, судя по направлению движения шифера, ждём от интела ARM с парой x86 ядер для легаси-задач. Это будет занятно.

izzholtik ★★★
()
Последнее исправление: izzholtik (всего исправлений: 1)

Все правильно сделано. Разные процессоры – разные CPUID.

Вообще, это все – тлетворное влияние Apple. Насколько я понимаю, в Xeon-ax такого разврата не будет.

i586 ★★★★★
()
Ответ на: комментарий от dk__

Но у меня вопрос: Ты правда думаешь, что понимаешь все это лучше, чем те десятки и сотни специалистов интела, что их проектировали?

С одной стороны - так, с другой - реально это скорее всего решение одного-двух человек. Причем оба решения имеют минусы.

praseodim ★★★★★
() автор топика
Ответ на: комментарий от i586

Все правильно сделано. Разные процессоры – разные CPUID.

Процессор - таки один, вот в чем штука. Поэтому части софта уже кажется, что оно работает на разных физических устройствах.

praseodim ★★★★★
() автор топика
Ответ на: комментарий от izzholtik

Разного рода желтушные сайты пишут, что линь на сабже работает на +всрат

Как я понял, сейчас планировщик задач в лине (и вообще где-либо кроме винды 11-й и может новейших патчей 10-й) не в курсе про P и E - Cores. Это только в 5.17 появится.

praseodim ★★★★★
() автор топика

> До сих пор что-то не особо выходит компенсировать аппаратные усложнения правильным софтописательством

Не первый раз уже. Pentium IV, Core2Quad.

ZenitharChampion ★★★★★
()

Штеуд решил в bigLITTLE :) в арме подобная(ые) инструкция не доступна юзерспейсу - ядро её эмулирует где собственно и исключает несовместимые расширения. Волосы гладкие и шелковистые...

anonymous
()

У джетсона tx2 четыре обычных арм ядра. И ещё парочка специфических денвера. Типа арм, но внутре совсем не они. причем тут эти денверы по умолчанию в шедулере забанены. Делаешь разбан, туда прилетает тяжёлая задача и сразу пропуск кадров. Только ручное назначение - только хардкор.

yax123 ★★★★★
()
Последнее исправление: yax123 (всего исправлений: 1)
Ответ на: комментарий от i586

Там ведь даже не NUMA.

Там хуюма с точки зрения софтописателей =) Программа, которая может начать исполняться на ядре с одним набором инструкций, а на другом - оно уже Invalid Opcode. В принципе, планировщик как-то должен не допускать такого, может перехватывает эксепшен и кидает на другое ядро? Я этого пока не понял.

praseodim ★★★★★
() автор топика
Последнее исправление: praseodim (всего исправлений: 1)
Ответ на: комментарий от praseodim

Как я понял, сейчас планировщик задач в лине (и вообще где-либо кроме винды 11-й и может новейших патчей 10-й) не в курсе про P и E - Cores. Это только в 5.17 появится.

Что-то я сильно сомневаюсь, что ядро 5.17 сможет адекватно рулить этими ядрами. Тут целый микрософт вместе с интелом толком не могут разобраться, а надеяться что Линус на коленке это сможет сделать как-то наивно.

А вот процы без е-ядер думаю самое то будет. Я так надеюсь. Ибо планирую обновить железяку на что-то из разряда 12400/12300.

Chord ★★★★
()
Последнее исправление: Chord (всего исправлений: 1)
Ответ на: комментарий от Chord

Что-то я сильно сомневаюсь, что ядро 5.17 сможет адекватно рулить этими ядрами. Тут целый микрософт вместе с интелом толком не могут разобраться, а надеяться что Линус на коленке это сможет сделать как-то наивно.

Так Intel, как я понял, как раз и коммитит сейчас в ядро свой планировщик. Еще вопрос чем это обернется в итоге.

praseodim ★★★★★
() автор топика

но CPUID - это до сих пор был идентификатор устройства а не ядра в нем

Нет, конечно. У, например, i5-4200u и i7-4510u cpuid одинаковый, и в целом ядро он и обозначает. Не совсем, да, у сокетного haswell он будет другим, а у маков, у которых немного другая встроенная графика - ещё каким-то третьим.


С остальным, в принципе, согласен, зачем эта наркомания с разными ядрами, тем более на десктопах - решительно непонятно. Посмотрим что в ноутах будет.

UPD в ноутах эти наркоманы решили ещё помимо U- и Н- линейки ввести какую-то новую P

shalom_ ★★
()
Последнее исправление: shalom_ (всего исправлений: 2)

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

bhfq ★★★★★
()
Ответ на: комментарий от yax123

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

bhfq ★★★★★
()

А на швятом арме bigLITTLE надо понимать ЭТО ДРУГОЕ?

anonymous
()
Ответ на: комментарий от izzholtik

с парой x86 ядер для легаси-задач

Даже старую gta5 не потянет.

anonymous
()
Ответ на: комментарий от i586

Как раз для зивони это и полезнее всего, там вообще можно 64мелких ядра и пара больших.

anonymous
()

Это попытка вынести легаси софт и железо. Последующие ОС будут строиться с учетом возможного наличия двух типов ядер.

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

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

anonymous
()

переключиться на браузер и планировщик (виндовый) вытолкает рендеринг на слабое ядро

Это логично и правильно. Фоновые задачи должны идти в лес при первой возможности.
У Маков это дополнительно управляется метками QoS и приоритета приложений, от которых уже пляшет планировщик.

CPUID - это до сих пор был идентификатор устройства

Это всегда был идентификатор возможностей ядра, для которого эта инструкция вызывается. Для каждого ядра в многоядерной системе cpuid мог отличаться, хотя на х86 этого _ранее_ в живой природе не встречалось.

devl547 ★★★★★
()
Ответ на: комментарий от praseodim

Еще вопрос чем это обернется в итоге.

Выносом Шиндовс10 с рынка, запланированным. И подкидышем плановой работы прикладным погроммистам, + вынос с рыношка васянов, которые 10 лет для винды писали, в Дельфи .. што там вместо него сейчас, какой VStudio...

anonymous
()
Ответ на: комментарий от bhfq

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

Самые производительные ядра маркируются еще на заводе, если что.

devl547 ★★★★★
()
Ответ на: комментарий от devl547

Это логично и правильно.

4.2 Рендеринг тут основная задача, а браузер запущен, чтоб скоротать время, пока идёт рендеринг.

anonymous
()
Ответ на: комментарий от devl547

Подозреваю что грош цена таким маркировкам после разгонов/андервольтингов/ подключение лучшего охлаждение с лучшей площадью соприкосновения к крышке cpu. AMD до сих пор не может наладить производство процессоров что работали бы из коробки без шаманства (пример отзывы и темы на железных форумах про 5600X).

bhfq ★★★★★
()
Ответ на: комментарий от devl547

Не перестала. Это тупая венда так считает, а самые ресурсоёмкие задачи, которые как раз приходится ждать все неинтерактивные == фоновые.

anonymous
()
Ответ на: комментарий от anonymous

которые как раз приходится ждать

Значит они не критичны к задержкам, следовательно идут лесом и считаются bulk.
А браузер, который юзер вот прямо сейчас тыкает и в котором не должны тормозить гифки с котиками, это вполне себе интерактивная нагрузка, которую нужно исполнять всеми доступными ресурсами.

devl547 ★★★★★
()
Ответ на: комментарий от devl547

Так режется же bandwidth капитально, а не только задержки.

anonymous
()

ряд инструкций не доступен на E-cores

Вроде же убрали AVX-512 поэтому в больших ядрах. Теперь у больших и малых ядер один и тот же набор инструкций. Потому что это не реально чтобы приложение это учитывало. Система может процессы по ядрам как угодно кидать, в любой момент времени, а приложения лишь вначале высчитывают константы какие инструкции доступны, и на основе этих констант вызывают соответствующие функции. Если разные инструкции были бы на ядрах, то всё приложения падали бы постоянно.

fsb4000 ★★★★★
()

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

sehellion ★★★★★
()
Ответ на: комментарий от sehellion

у эппла нет еще

У эппла как раз есть в м1, да и вообще в арм это давно. Тема, видимо, рабочая, раз много лет используется, и эффективнее чем просто снижать частоту. А может тупо экономия, «медленные» ядра выходят дешевле и с меньшим браком, чем «быстрые»

Также есть вариант что интел хотела банально нарастить кодичество ядер для многопоточных задач, и потом лепить красивые графики как процы стали быстрее на 30%.

shalom_ ★★
()
Ответ на: комментарий от shalom_

В пользу моей последней теории -https://cpu.userbenchmark.com/Compare/Intel-Core-i7-12700KF-vs-Intel-Core-i7-...

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

shalom_ ★★
()
Ответ на: комментарий от sehellion

чисто нотбучная тема

Там процы за 250вт переваливают в стоке, точно уверен что чисто ноутбучная?

anonymous
()
Ответ на: комментарий от shalom_

нарастить кодичество ядер для многопоточных задач, и потом лепить красивые графики как процы стали быстрее на 30%

Ну, то есть, перенимает тактику амд)))

anonymous
()

А для пользователя какой профит от энергоэффективных ядер на десктопе или сервере? Что их получается больше количественно воткнуть в тот же объём?

От HT они таки отказались?

filosofia
()
Последнее исправление: filosofia (всего исправлений: 1)
Ответ на: комментарий от filosofia

А для пользователя какой профит от энергоэффективных ядер на десктопе или сервере

Никакого. Десктоп обязан быть производительным, а не энергоэффективным.

sfedosenko
()
Ответ на: комментарий от anonymous

Как будто что-то плохое.

Сами же постоянно ноете, что х86 - сборище костыльного легаси, а как чутка поменяли не особо нужный обычному софту ID, так сразу плакать.

izzholtik ★★★
()
Ответ на: комментарий от bhfq

В линуксе пишешь стартовый скрипт в котором указываешь чего и на чем запускать и все. Работает всегда.

yax123 ★★★★★
()
Ответ на: комментарий от devl547

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

Да, но при этом браузеру (совсем точно - его пользователю) было бы достаточно и слабого ядра.

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

praseodim ★★★★★
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.