Раньше Intel расчитывал на свой компилятор, который проверял: если Intel процессор, то исполняется код использующий инструкции векторизации, а иначе обычный код. Но по-моему тема заглохла. Разработчики могут откомпилировать два исполняемых файлы: под Intel отдельно, под AMD отдельно.
Разработчики бенча работают на потерю интереса к их программе.
У адекватных пользователей, которые заинтересованы в выборе лучшего процессора и платформы для себя, всегда есть возможность посмотреть на результаты тестирования процессоров в тех программах, которые пользователь будет исполнять. Попугаи синтетических бенчмарок только для обзоров каких-то мега рекламщиков, которым нужно подтвердить что угодно чем угодно.
Современные игры получают бенефит от 8 ядер. Если пользователь играет, то ему интересна многоядерная производительность.
Если же приложение столь старое и не поддерживаемое, что поддержки многоядерности нет, то скорее всего эта программа будет отлично исполняться и на очень старых процессорах без многоядерности и высокой частоты. Кому интересен результат: в 20 раз больше чем достаточно для одной нитке самого быстрого Intel?
Когда же речь о вычислительных задачах исполняемых днями/неделями/месяцами, то все они неизбежно оптимизируются под любое имеющееся количество ядер, и тут многоядерность важнее любой производительности одного ядра.
Стоит только в склепе с проектором одёрнуть затемняющую занавеску, и контраст падает до 10:1. То есть о 16М цветов придётся мечтать, а 1B цветов типичный для OLED и HDR/HDR+ TFT LED — это не достижимо для проекторов.
400 Вт·ч/кг
Это 3,5% от энергии килограмма керосина. Притом что современная авиационная турбина может использовать 29% (КПД) этой энергии. Таким образом керосин даже в таком случае будет в 8+ раз эффективней по отношению энергии к массе.
Huawei будет работать в судах других стран, чтобы продукция нарушающая их американские патенты не могла продаваться нигде кроме США, так как по-умолчанию патенты США признаются многими странами, а значит патентные права не будут соблюдаться только в США. Ну и кто пострадает, если оборудование 5G от американских компаний будет продаваться только в США?
Разве 16 битные приложения не работают? Режим эмуляции x86 вроде до сих пор может исполнять древний как мамонт Prince Of Persia времён 80286. В реальном режиме x86 процессор видимо до сих пор стартует при начальной загрузке, чтобы подготовить процессор для перехода в защищённый режим, но приложения в нём не работают — чисто поддержка POST.
Линейный алгоритм рано или поздно начинает исполняться снова. Значит линейные вычисления можно конвейеризовать. Распараллеливать можно не только по данным, но и по командам.
Может люди есть, но никто не ставит цель разработать многопоточные алгоритмы. Цель — создать программный продукт, который удовлетворяет требованиям заказчика. И если так случилось, что ПО удовлетворяет требованиям без распараллеливания, то никто даже заморачиваться не будет, так как многопоточное ПО имеет другой уровень сложности ошибок, на который нужно потратить гораздо больше времени на тестирование. А это иной бюджет, срывы сроков, и т.п.
Многопоточные приложения нацеленные на увеличение производительности пишутся когда точно всё плохо. А приложения, в которых несколько сотен потоков, из которых все кроме одного чего-то ждут — это уже давно обыденность.
x86-64 поддерживает 32 разрядные процессы нативно в 64 разрядной ОС. Накладные расходы на кодирование 32-х разрядных инструкций в 64 разрядных приложениях.
В вашем примере нанометры могут совсем не влиять, так как микроархитектура ядер настолько разная, что медленная работа процессора объясняется именно неказистой архитектурой. А может даже виноват конкретный блок в микроархитектуре — например предсказатель ветвлений сделанный без глубоких исследований, и наобум может убить производительность в разы.
Плотность транзисторов не только от тех.процесса зависит, но и от целевых частот работы микросхемы, и от целевого потребления. Для более высоких частот нужны транзисторы большего объёма, что для плоской структуры чипа обычно выливается в схему с меньшим числом транзисторов на мм2. Для низкого потребления лучше подходят транзисторы меньшего размера которые можно расположить плотнее.
Таким образом мобильные процессоры должны иметь маленькие транзисторы в схемах, но при этом имеют меньшие частоты, и плохо гонятся. Десктоп/сервер процессоры должны иметь транзисторы большего размера на критических путях схемы, что даёт высокие частоты, но с высоким потреблением.
Интел захотел сделать Десктоп/сервер процессоры с транзисторами занимающими меньшую площадь. Для этого им пришлось бы придумать, как сделать транзистор большего объёма на меньшей площади.
TSMC с плотностью ~130 млн. на 5 nm сможет обеспечить такую плотность только для кэш памяти, и не факт, что работающую с высокой частотой — типа мобильную кэш память. А более высокочастотные схемы с произвольной логикой, длинными критическими путями распространения сигнала придётся делать транзисторами большего размера, что уменьшит реальную плотность до 50-70 млн. транзисторов на мм2 в лучшем случае.
Скорее дело в операционке, которая не ожидает, что следующую инструкцию OS будет исполнять на другом процессоре. А в ядре куча системных регистров по управлению конкретным процессором. Операционки для VM должны специально точиться. Либо не придумывать гетерогенные среды исполнения. Всё равно виртуалку нельзя перенести с x86_64 на POWR8. Так почему должен работать перенос с Intel на AMD и обратно?
Зря Интел так упирается в 100 млн. транзисторов на кв.мм. У Apple процессор на 7 nm не имеет такой плотности при частотах заметно меньше, чем на desktop процессорах Интел. А высоким частотам нужны проводники и транзисторы большого сечения. Понятно, что если хочется уменьшить размеры проводников на плоскости XY подложки, чтобы размеры элементов скалировались вместе с уменьшением тех.процесса, то сохранение площади сечения проводников потребует _роста_ высоты проводников. То есть если ширина проводника уменьшается в 1.4 раза при переходе на 10 nm, то высота проводника должна вырасти в 1.4 раза. То же с транзисторами.
Причём если они считают, что пропустили несколько поколений скалирования транзисторов, то их высота должна вырасти не в 1.4 раза, а видимо раза в 4-5.6. Это должно усложнять работу с масками, а результат такого нагромождения не очевиден. Фактически на кристалле нужно сделать из нано-домиков FinFET нано-небоскребы не очевидной структуры.
Штангист Фёдор прочитал статью физиков-ядерщиков об их достижениях в работе над термоядерным реактором. Реактор выдаёт чуть меньше энергии, чем получает извне. Фёдор подключил свою штангу к розетке, и превзошёл физиков-ядерщиков, так как получил ровно то же количество энергии, которое было затрачено.
У адекватных пользователей, которые заинтересованы в выборе лучшего процессора и платформы для себя, всегда есть возможность посмотреть на результаты тестирования процессоров в тех программах, которые пользователь будет исполнять. Попугаи синтетических бенчмарок только для обзоров каких-то мега рекламщиков, которым нужно подтвердить что угодно чем угодно.
Современные игры получают бенефит от 8 ядер. Если пользователь играет, то ему интересна многоядерная производительность.
Если же приложение столь старое и не поддерживаемое, что поддержки многоядерности нет, то скорее всего эта программа будет отлично исполняться и на очень старых процессорах без многоядерности и высокой частоты. Кому интересен результат: в 20 раз больше чем достаточно для одной нитке самого быстрого Intel?
Когда же речь о вычислительных задачах исполняемых днями/неделями/месяцами, то все они неизбежно оптимизируются под любое имеющееся количество ядер, и тут многоядерность важнее любой производительности одного ядра.
Вы кем туда хотите?
Это 3,5% от энергии килограмма керосина. Притом что современная авиационная турбина может использовать 29% (КПД) этой энергии. Таким образом керосин даже в таком случае будет в 8+ раз эффективней по отношению энергии к массе.
https://youtu.be/8xzynb62t5c
Многопоточные приложения нацеленные на увеличение производительности пишутся когда точно всё плохо. А приложения, в которых несколько сотен потоков, из которых все кроме одного чего-то ждут — это уже давно обыденность.
Таким образом мобильные процессоры должны иметь маленькие транзисторы в схемах, но при этом имеют меньшие частоты, и плохо гонятся. Десктоп/сервер процессоры должны иметь транзисторы большего размера на критических путях схемы, что даёт высокие частоты, но с высоким потреблением.
Интел захотел сделать Десктоп/сервер процессоры с транзисторами занимающими меньшую площадь. Для этого им пришлось бы придумать, как сделать транзистор большего объёма на меньшей площади.
TSMC с плотностью ~130 млн. на 5 nm сможет обеспечить такую плотность только для кэш памяти, и не факт, что работающую с высокой частотой — типа мобильную кэш память. А более высокочастотные схемы с произвольной логикой, длинными критическими путями распространения сигнала придётся делать транзисторами большего размера, что уменьшит реальную плотность до 50-70 млн. транзисторов на мм2 в лучшем случае.
Причём если они считают, что пропустили несколько поколений скалирования транзисторов, то их высота должна вырасти не в 1.4 раза, а видимо раза в 4-5.6. Это должно усложнять работу с масками, а результат такого нагромождения не очевиден. Фактически на кристалле нужно сделать из нано-домиков FinFET нано-небоскребы не очевидной структуры.