SpaceMareen

А с чего ты взял что 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.

Данные с презентации АМД. Zen4 — 3.84 мм^2, Zen4c — 2.48 мм^2.
https://www.techpowerup.com/img/941Dqjfx8PVe4RUX.jpg

Ничего. Так как пока что 1024 ядер в одном процессоре AMD из-за физических ограничений произвести таки не может.

Zen4c не вдвое (на 100%) меньше, а всего на 35%. То есть на месте 2 Zen4 помещаются 3 Zen4c. У Интела на месте 2 Р помещаются 8 Е.

Утечка дорожной карты — это все-таки слух. Не все, что выдаётся за дорожную карту всегда оказывается таковой.

Zen5

Одноядерный буст не особо интересен. Если бы он по всем р-ядрам хотя бы 6.0 держал — другое дело.

А ещё авх-512, которого у этих процессоров нет.