Семейство процессоров Intel Raptor Lake будет включать 24-ядерные модели

Обсуждение статей и новостей сайта
Автор
Сообщение
Alligator
Member
Аватара пользователя
Откуда: Николаев

Сообщение

warp 37: 10.06.2021 11:38 Хорошо, хоть системные требования к процессорам не растут, а то глазки-то горят уже.
На что горят? Это как раз тот случай когда Ваши 8 ядер могут оказаться производительней 24 (8+16) рапротовских :gigi:
NiTr0
Member

Сообщение

ruiite: 10.06.2021 10:13 Maxhope
ну вроде у м1 все в порядке при этом там энергоэффективные ядра явно дают прирост , что видно по мультиядерным тестам.
прирост в бенчмарках-числодробильнях, масштабируемых на 100500 ядер?

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

ну и да, в винде планировщик по-моему так и не осилил держать ресурсоемкий процесс (поток) на одном ядре, не перекидывая его хаотически по соседям "просто так"...
Dreamy
Member
Аватара пользователя

Сообщение

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

Сообщение

IvanCh: 10.06.2021 14:34
ruiite: 10.06.2021 10:13 Maxhope
ну вроде у м1 все в порядке при этом там энергоэффективные ядра явно дают прирост , что видно по мультиядерным тестам.
там інша архітектура. яка якби відстояна і давно вже якби це вміє робити. А тут франкінштейн зроблений в поспіхах щоб стати на коліна і благати Apple не уходити з інтелю

І загалом НАГАДУЮ. В арм набори команд в потужних та енергоефетивних ядрах ОДНАКОВІ.

ТУТ же в Sunny Cove та Gracemont мають РІЗНІ НАБОРИ команд.

А це вже означає ДУЖЕ багато проблем.
Шо за разные наборы команд? Обычные х86 команды и там и там.
IvanCh
Member
Аватара пользователя
Откуда: Київ

Сообщение

Salatik: 10.06.2021 18:50 Шо за разные наборы команд? Обычные х86 команды и там и там.
ось так різна. х86 це не набір команд, а ціле семейство сімейств і розширень,
ось тих же наборів AVX мабуть до 20-ки вже є.
Dreamy
Саме так в гібридному моді, який доречі через біос буде вибиратись(зручно чо),
будуть відключатися в потужних ядрах всякі AVX, інструкції для віртуалізації і решта що жре багато .

Але є один нюанс саме ці інструкції що будуть відключатись є найбльшими присколювачами систетичних тестів на основі
яких Intel гордо і голосно рапортує прирости IPC останіх років 5.
Dreamy
Member
Аватара пользователя

Сообщение

IvanCh
512, TSX, FP16.
прирости IPC
Cудя по over tiger lake в инсайде и скромных частот суперфинок очередные +5% к дестопному скайлейку?
tablestikus
Member
Аватара пользователя
Откуда: Киев

Сообщение

Maxhope: 10.06.2021 09:52 Почему нет 8+0 , зачем мне платить за недоядра :-/
Ну так не плати. В чем проблема то?
Scoffer
Member
Аватара пользователя

Сообщение

Maxhope: 10.06.2021 09:52Почему нет 8+0 , зачем мне платить за недоядра
А з чого ти взагалі вирішив, що за 8+0 ти заплатиш менше? :laugh:
manbearboar
Member

Сообщение

NiTr0:
ну и да, в винде планировщик по-моему так и не осилил держать ресурсоемкий процесс (поток) на одном ядре, не перекидывая его хаотически по соседям "просто так"...
Если не перекидывать, это одно ядро нагреется и просядет по бусту.
Да и оно "перескакивает" только по вашим субъективным ощущениям. В масштабе гигагерц потоки целую вечность сидят на одном ядре.
Виндовые ноутбуки живут стабильно дольше линуксячьих, так что тут мимо.
Для планировщика большим вызовом будет что ядра с разными наборами комманд.
Хотя это вроде как собираются пофиксить в рапторе.
VRoman
Junior
Откуда: Albuquerque, NM, USA

Сообщение

Nikoliasik_Zeus: 10.06.2021 09:56 новый планировщик выкатят - посмотрим :rotate: стоило того или нет
8 ядер играм или под работу и 16 ядер винде на её скрытые сервисы? Какое-то совершенно нелогичное распределение ядер на кристалле. Тут даже до испытания планировщика можно сказать что это - бред.

ЗЫ. Не забываем, что у довесков будет не только ослабленая архитектура, а так же будет отрезана многопоточность и ополовинены максимальные частоты. Так что эти недоярдра мало чего дадут в плане производительности. Будь их там хоть 8, хоть 16, хоть сразу 1024. Толку в реальных приложениях от них будет чуть больше чем "кот наплакал"
ruiite
Member
Откуда: Харьков

Сообщение

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

Сообщение

manbearboar: 10.06.2021 23:22 Если не перекидывать, это одно ядро нагреется и просядет по бусту.
бред же. затраты на переезд процесса на другое ядро - тысячи, а то и десятки тысяч тактов. умножьте это на частоту переездов (сотни раз в секунду) - и окажется, что значительную часть времени проц занят тем, что перекидывает потоки между ядрами вместо того чтобы работать.

про то, что ядо из спячки выводится далеко не мгновенно, и частота тоже меняется не мгновенно - думаю, и говорить не стоит (энергосбережение например на высоконагруженных серверах, где вожно быстродействие, вообще нафиг отключают).
manbearboar: 10.06.2021 23:22 Да и оно "перескакивает" только по вашим субъективным ощущениям. В масштабе гигагерц потоки целую вечность сидят на одном ядре.
запускаете однопоточный бенч. открываете диспетчер задач - и, о чудо, все ядра (включая виртуальные гипертриперные) нагружены равномерно, процесс прыгает козлом по всем ядрам, вымывая кеш.
manbearboar: 10.06.2021 23:22 Виндовые ноутбуки живут стабильно дольше линуксячьих, так что тут мимо.
что "мимо"? что производительность под виндой по факту намного ниже? :)
AndyObserver
Member

Сообщение

NiTr0: 11.06.2021 20:37запускаете однопоточный бенч. открываете диспетчер задач - и, о чудо, все ядра (включая виртуальные гипертриперные) нагружены равномерно, процесс прыгает козлом по всем ядрам, вымывая кеш.
Надо будет попообовать. ;)
l-m
Member

Сообщение

Creature4O: 10.06.2021 11:47 а intel выпускает ЦП с арм ядрами.
там будуть ядра не арм, а х86-64, просто повільні, урізані та економні
manbearboar
Member

Сообщение

NiTr0: 11.06.2021 20:37 бред же. затраты на переезд процесса на другое ядро - тысячи, а то и десятки тысяч тактов. умножьте это на частоту переездов (сотни раз в секунду) - и окажется
А потом вспомните, что Ггц - это 9 нулей и поделите на 4 000 000 000 тактов в эту секунду.
Частота переезда, если он занимает 10к тактов и это происходит "сотню раз в секунду", это примерно как если бы у вас переезд со всеми пожитками занимал 1 сутки, и это бы происходило бы каждые 10 лет.
Не очень соответствует описанию "перескакивает козлом", поэтому профита от баловства с аффинити чаще всего не удаётся достичь.
NiTr0
Member

Сообщение

manbearboar: 12.06.2021 10:04
NiTr0: 11.06.2021 20:37 бред же. затраты на переезд процесса на другое ядро - тысячи, а то и десятки тысяч тактов. умножьте это на частоту переездов (сотни раз в секунду) - и окажется
А потом вспомните, что Ггц - это 9 нулей и поделите на 4 000 000 000 тактов в эту секунду.
Частота переезда, если он занимает 10к тактов и это происходит "сотню раз в секунду", это примерно как если бы у вас переезд со всеми пожитками занимал 1 сутки, и это бы происходило бы каждые 10 лет.
Не очень соответствует описанию "перескакивает козлом", поэтому профита от баловства с аффинити чаще всего не удаётся достичь.
это - сам переезд (перенос контекста процесса - всех регистров, включая SSE/AVX/FPU и т.п.), не считая того, что на новом ядре L1-кеш будет содержать старый неактуальный мусор, и L2-кеш тоже - все придется тянуть с общего L3-кеша, в который оно еще должно попасть со старого ядра (да-да, L2 кеш ни у интела, ни у амд не инклюзивный).

потому, повторюсь, никакого профита от скачущего козлом по всем ядрам процесса нет. ни по воображаемому перегреву отдельного ядра из-за трупобуста (ну нет перегрева там, нет, ессно при нормальном состоянии термоинтерфейса под крышкой - пересохшую дерьмопасту на старых корках в расчет не берем, иначе процы бы вообще не гнались даже до частот трупобуста под водой), ни по прочим причинам. есть только лишние накладные расходы из-за того, что кто-то не смог в нормальный планировщик.
Scoffer
Member
Аватара пользователя

Сообщение

NiTr0
Ти трішки не розумієш як працює витискальна багатозадачність. Вся її суть в тому, що процеси формують чергу довжиною квант часу процесора і в порядку цієї самої черги виконуються на вільних потужностях. Прибивати цвяхами процес до ядра, м'яко кажучи, не варто. Більш того, ніхто так не робить. В тому числі нікси.
Це по-перше.

По-друге L1 на кожному кванті часу проца вичищається в нуль без залежності хоч той же самий процес туди потрапив, хоч інший.
По-третє єдиний більш-менш адекватний метод боротьби з атаками по стороннім каналам це вичищати ще й L2 :laugh:
По-четверте квант часу в ніксах по дефолту довший за квант часу в віндах і складає 100 мілісекунд проти 10-15 мілісекунд в десктопних віндах, що призводить до рідших перемикань процесів, що в свою чергу призводить до деякого росту продуктивності деяких завдань ціною вдесятеро тугішого відгуку системи, що годиться для серваків, але ніяк не для десктопного, як модно зараз казати, юзер експірієнсу. В серверних віндах штатно стоїть 120, до речі.
По-п'яте квант часу в обох ОС при великому бажанні можна змінити.
По-шосте в віндах присутня ціла матриця налаштувань квантування для отримання того чи іншого результату, якщо у адміна руки, а не лапки. Десктопна вінда штатно адекватно налаштована під десктопні потреби.
По-сьоме в лінуксі на відміну від вінди і важких юніксів, справедливий планувальник з тими ж самими алгоритмами що й у згаданих ОС, сто років як намагаються завезти ті, хто хоче з нього зробити десктопну або хоча б багатокористувацьку ОС з прийнятним відгуком, але їм перешкождають ті у кого мускуль почне тупити :laugh: Не знаю чим та епопея закінчилась і чи закінчилась взагалі.

Відправлено через 34 хвилини 8 секунд:
Я от не розумію, ви всі реально думаєте що в MS на мільярдних бюджетах сидять якісь тупі розробники, котрі не можуть скопіювати супер-секретні алгоритми роботи планувальника з лінукса? :D
В вінді є діякі політичні проблеми зі свистоперділками, але в нутрощах там все в порядку. Особливо з ядром і ядерною обв'язкою. Там де сидять реальні інженери, а не дизайнери з шилом в дупі. Якщо там щось зроблено так, а не інакше, то на те є якась важлива причина.
gehka3
Катярко
Аватара пользователя
Откуда: Днепр

Сообщение

Scoffer: 12.06.2021 23:24Якщо там щось зроблено так, а не інакше, то на те є якась важлива причина
Само собой, и первая важнейшая - лень, с оправданием: "раз работает - то и так сойдёт" :)
BonBon
Member

Сообщение

Scoffer: 12.06.2021 23:24 Я от не розумію, ви всі реально думаєте що в MS на мільярдних бюджетах сидять якісь тупі розробники, котрі не можуть скопіювати супер-секретні алгоритми роботи планувальника з лінукса? :D
Лет десять назад один чувак написал линукс планировщик(совпадение) ориентированный на скорость работы. И его не принимали в основное ядро потому что типа "и так работает у корпоратов все ок ну и ладно", там чуть ли не войны были. И это в линуксе с его моделью разработки.
Насчет многомиллионных бюджетов - не стоит так сильно обращать внимания на цифры, хорошо разжиревшая структура может пережевать астрономические суммы без сколь нибудь заметной отдачи.
Scoffer
Member
Аватара пользователя

Сообщение

BonBon: 13.06.2021 08:34Лет десять назад один чувак написал линукс планировщик(совпадение) ориентированный на скорость работы.
Немає такого поняття. Вони всі швидкі.
Для лінукса було написано декілька планувальників помимо звичайного тупого O(1): Completely Fair Scheduler (котрий насправді не зовсім Completely для <16 ядер :D ), справедливий реального часу (назву котрого я забув), ряд клонів планувальника з BSD і кілька варіантів з нуля, направлених на покращення відгуку системи, типу MuQSS.
Так от, останню категорію в основну гілку не пускають тому, що це завжди про вибір між відгуком системи на процеси і продуктивністю самих процесів. Срібної кулі не існує.
Враховуючи переважну направленість сучасних систем на базі лінуксу на сугубо серверні завданні (з тих хто платить гроші і замовляє музику розробникам), це логічно.
Тільки це по-перше не варіант для вінд, де збирають як прийдеться, впритул до сервера терміналок з сервером БД і пасьянсом для босса на одній системі :horror: по-друге все одно лінукс доведуть до душевного стану важких юніксів і через 5-10 років на виході отримаємо ту ж саму неповоротку систему. Процес вже давно почався з сістемд і успішно продовжується, охопивши інші підсистеми.
Гугла недаремно мріє звалити для своїх відроїдів на фуксію. Потреби відроїда трішечки розходяться з потребами говносайтиків в контейнерах.
Різні завдання - різні алгоритми роботи ОС.
Ответить