SpaceMareen

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

Для нейронок есть тесты.
https://www.tomshardware.com/news/stable-diffusion-gpu-benchmarks

4060 это обычный ноутбучный середняк. Середняки всегда были слабее хх80/хх90.

Вполне игровой.

Не зря, у Интела речь именно о приоритете, а не о привязке ядер. SetThreadPriority, THREAD_PRIORITY_NORMAL. В той же таблице.
.
Хорошо, допустим Интел как-то печатает какие ядра гибридные а какие нет. Хотя примеров вывода на странице нет, это слегка настораживается. Потому что стандартный cpuid никаких потоков и ядер вообще не печатает, внизу страницы пример. Но хорошо, поверим Интелу.
https://learn.microsoft.com/en-us/cpp/intrinsics/cpuid-cpuidex?view=msvc-170
.
> Мы ведь можем сделать что-то подобное на C например?
Да, и у Майкрософта и по вашей ссылке примеры на С/С++. Только в Ubuntu CPUID по умолчанию вообще нет. Он устанавливается в одну строку, так что нестрашно, но все таки не часть ядра.
.
С выводом в целом согласен, но очень много проволочек, каждый раз переизобретать велосипед костыльными подсчетами cpuid неохота.
.
УПД. Посмотрел что залито Интелом по ссылке на гитхаб
https://github.com/GameTechDev/HybridDetect
Выглядит как уже готовая библиотека, в которой можно определять на какие ядра потоки определять. « Demonstrates split topology threadpools, as well as homogeneous/heterogeneous threadpool adaption. Rendering is done via the critical P-Cores and asteroid simulation is performed using E-Cores». Это то, о чем у меня шла речь — должна быть общедоступная библиотека с хорошим интерфейсом. Интел молодцы.

За час-другой в погребе будет такая же температура как на улице.

Ещё в степень двойки возведите, потому что помимо affinity есть ещё и priority. Интел в гайдах для игроделов больше о приоритетности потоков пишет, чем о привязке ядер. Чтобы не было голодания с просадками из-за того что у главного потока на 20 мс отняли хлеб и на это время ГП ничего не делает.
.
И это ещё накладывается на необходимость прикинуть на какие ядра делать affinity. Через что вы там их делать собрались? Не помню, что печатает CPUID, но помню, что по умолчанию он не везде установлен. По умолчанию доступны cat /proc/cpuinfo и lscpu. Которые количество ядер не печатают, они печатают количество потоков. Вот введёте вы lscpu и вам напечатает «у меня 13900к 32 ядра». Что дальше? Это 16+0 или 8+16 процессор? Как это понять? Вручную составлять таблицу, что ага, 13900к это 8+16? А если юзер отключит SMT и печататься будет 13900к 24 ядра? Еще по варианту учитывать? Умножаем количество рассматриваемых случаев на два.
.
Итого у нас 2 ОС * (affinity + priority) * SMT on/off = минимум 8 сценариев. Плюс нерешенная задача с физическими/логическими ядрами. Слишком много геморроя, если мы говорим о чем-то запущенном на больше чем паре компов. Короче говоря, проблема не в том что разработчики ленивые, а в том что это не их зона ответственности.

А с чего ты взял что 3 издание вообще будет? Они карты изначально собирались вообще каждый год выпускать. Но арки выпустили ещё в 2022, а о релизе второго издания ещё ни слуху ни духу.

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

> По моему всё ещё никто не запрещает привязать задачу к потоку через маску.
.
А кто разрешает? Это не стандартный функционал. То есть по умолчанию такого вообще не предполагается.
.
>Господи в х86 мы даже по сути не знаем какие инструкции он выполняет
.
«Мы» не знаем, а компиляторы знают. Компиляторы очень умные. Только им нужно сказать, под какой процессор компилировать. Но в случае гетерогенных архитектур с этим возникают большие проблемы.

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

> В одном приложении же, может быть > 1 задачи которую можно распараллелить. Т.е. может быть и другая работа.
.
Загуглите что такое закон Амдала. Кратко — если у нас можно распараллелить 50% работы, то программу невозможно ускорить больше чем в 2 раза, если можно распараллелить 75% работы, то не больше чем в 4 раза, и так далее.
.
> И вот я как бы не считаю что в интел дураки сидят…малые ядра позволяют масштабироваться в многопоточных задачах
.
Не сидят. На Ютубе висят лекции James Reinders из Intel 2014 года. На них он рассказывает про мелкоядерное масштабирование…на Xeon Phi. Там слайды прямо так называются — little cores vs big cores. Все украдено до нас!
.
Кстати там же мелкоядерное масштабирование задано формулой. Pollack’s Law, правило Поллака, можно либо потратить в 4 раза больше места и получить вдвое более производительное ядро, либо вместо имеющегося ядра расположить 4 маленьких и получить 4х больше производительности. Сам Поллак данное правило ещё в 2008 открыл, оказывается, но никто не говорил об этом до Р/Е ядер в Alder Lake, и даже сейчас имя Поллака редко вспоминают. Но это лирика.
.
Так вот, Джеймс рассказывает. К нему приходят разработчики и говорят «мы написали распараллелили задачу на 4 потоков, как она будет работать на Xeon Phi?», а он им отвечает «ужасно». Потому что пока разработчики не распутывали клубок зависимостей, чтобы параллелизм достигал 8-16-32 потоков, то мелкоядерная архитектура и низкие частоты потенциал многопоточности перекрывали. Что изменилось с тех пор? Ничего. А теперь возвращаемся к закону Амдала =)
.
Вот цитируемый отрывок, если интересно. 41:30 https://youtu.be/hACtH8NdeIk

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

Важно. Программы могут компилироваться (оптимизироваться) под конкретную микроархитектуру. В случае двух разных микроархитектур в одном процессоре этого достичь невозможно.

У АМД планировщик решает, какая задача на х3д ядрах, а какая на Х ядрах. И ядра бустятся неодинаково с незапамятных пор.

Под гетероядерную архитектуру никто софт затачивать не будет, за редкими исключениями. Многопоточность либо есть, либо её нет.
.
У Интела уже есть гайды для софтоделов. В трёх томах ))

> То о какой синхронизации речь?
Далеко не каждый компилятор далеко не для каждого языка программирования в принципе может генерировать многопоточный код без разработчика. Но допустим.
.
Берём параллелящуюся задачу. Поделили задачу поровну между четырьмя ядрами. Один из потоков закончил выполнять свою четверть работы раньше, чем остальные. Что он будет делать? Правильно, ждать всех остальных. Это синхронизация, это дополнительные затраты времени.
.
И это в идеальном случае. Даже не рассматривая примеры задач, требующих shared memory, как упомянуто выше.

Кодировщик на ядрах Атома необязательно (!!!) минус. Пока прочитаешь пару постов в интернете кодировщик и на е-ядрах справится. А так подвисаний в браузере нет. Но вряд ли нам в обозримом будущем дадут кастомные профили для подстройки этого на свой вкус.

> Да у Intel 56 ядер, но по цене самолёта, потому что огромный монолитный кристалл с ядрами
.
Sapphire Rapids делают из 4 чиплетов (плиток) по 15 ядер. И все-равно только 56.
https://www.ixbt.com/news/2021/06/12/56-intel-sapphire-rapids-15.html
А Интелу очень хотелось бы по 96, как у АМД, уж поверьте.

Экономических ограничений нет, крупные организации и 256, и 512 ядер раскупят, оттого АМД/Интел ядерность и пытаются нарастить. Здесь и сейчас это сделать нельзя, потому что 1024 ядер infinity fabric не выдержит. Как и кольцевая шина Интела от слишком большого количества ядер треснет, вот и заменяют р-ядра на кластеры е-ядер по 4.