Для работы проектов iXBT.com нужны файлы cookie и сервисы аналитики.
Продолжая посещать сайты проектов вы соглашаетесь с нашей
Политикой в отношении файлов cookie
Кстати о птичках. Ещё одна свежая игра, которой нафиг не упёрлась куча врам.
VRAM-Anforderungen
Jagged Alliance 3 benötigt kaum Grafikkarten-Speicher. Selbst ein Modell mit 8 GB VRAM ist noch mehr als genug für Ultra HD, auch mit 6 GB sollte es zu keinen Einschränkungen in hohen Auflösungen kommen. Und für Full HD bei maximalen Texturdetails genügt sogar ein 4-GB-Exemplar.
«Где горят?»
Я вот чот тоже хз. Я вот чот не припомню, что б карты в последнее время прям горели.
«их у ремонтников нет почти.»
А вот это враньё, нвидивских карт в ремонтах всегда хватало. И не потому, что они ломаются в разы чаще. А потому что их на рынке в разы больше.
С АМД ситуация та же, но в обратную сторону.
Собственно на том всё.
«А кто разрешает? Это не стандартный функционал.»
Windows же фактически. Т.к. мы сообщаем её планировщику, на каком потоке выполнять задачу.
https://learn.microsoft.com/en-us/windows/win32/api/winbase/nf-winbase-setthreadaffinitymask
Они же сами добавили такой функционал и не запрещают им пользоваться. Вот не пойму о каком не стандартном функционале речь то тогда. Мы же не вручную, в обход системы костылим привязку.
Мало того, мы можем сделать это стандартными средствами самой виндоус, через диспетчер задач же.
«Ну так это было ещё при 2000 Рязани.»
А вот оно что.
В целом адекватная позиция. Я бы глобально был бы не против иметь допусти ядра так 4 маленьких в IO райзенов. На них скинем ОС + браузер. + Такие мелочи как разные плееры, блокноты, вероятно ворд, всякий софт типа управлений подсветками, мессенджеры, стимы, райзен мастеры, модули драйвера (у амд же в драйвере кучу всякой мелочи), мониторинги, ну и всякие там простые микшеры и фильтры для микрофона.
Крч кучу мелких типичных задач, которым не нужно много производительности, но они весят в фоне и кушают системные ресурсы.
(так как нельзя предсказать) А нафига предсказывать? По моему всё ещё никто не запрещает привязать задачу к потоку через маску.
А так вообще где окажется задача, отвечают планировщики. Т.е. автоматика.
И некоторое профилирование думаю доступно, через определённые инструкции же, думаю через CPUID < по моему там команды к тред директору.
Т.е. оптимизация таки возможна. Через профилирование же. В прочем как и всегда.
(С оговоркой симметричности инструкций же. иначе жопа )
Как бы ядра/потоки и так имеют разную производительность. Просто теперь разброс выше.
Ведь очевидно что SMT практически и не даёт нам +100%. + пара ядер имеет лучшую вольт частотную кривую, следственно бустится лучше.
В случае с райзенами, есть ещё чиплеты. Где лучше лишний раз не гонять информацию меж чиплетами. У райзенов теперь есть 1 чиплет х3д с низкими частотами и 1 чиплет с высокими. И со всем этим работает планировщик винды. Вроде особо не жалуемся же.
" оптимизируется количественной производительностью. "
Про это вообще все топовые архитектуры так то. Просто потому, что мы не управляем внутрянкой процессора, в отличии от явного программирования VLIW.
Господи в х86 мы даже по сути не знаем какие инструкции он выполняет. Т.к. один фиг, те инструкции что мы даём, декодируются во внутренние инструкции же.
Ииии по правде говоря, мудохаться с микро менеджментом ресурсов явно никто не хочет. Все как раз хотят писать говнокод, проще и дешевле. И крыть разницу именно за счёт количественной производительности.
Но реальность конечно жестокая штука. Прогресс требует более низкоуровневой оптимизации. Просто вспомним про низкоуровневые графические API. И как «погромисты» сталкнулись с мучением в виде вулкана.
Ну и тем не менее, стратегия Интел вполне жизнеспособна. Ибо таки они выжали дополнительную производительность. Думаю они не смогли бы сделать ту же производительность, при прочих равных, исключительно на больших ядрах. Скорее всего интел бы выдал нам полукиловатные печки с золотыми ядрами.
Но мне всё ещё нравится стратегия жирных ядер с большим IPC. Т.к. ИМХО ядер то хватает. А частоты задирать не хочется, слишком много жрать начинает.
При том, если заведомо не задирать частоты, можно использовать тех. процессы по плотнее и с низкими токами утечек.
Мне в принципе нравятся спец. ускорители для типовых задач.
А много много ядер с некоторой универсальностью, можно уж отдать на откуп программируемым шейдерам (до определённой степени).
Услышал. Но не сказал бы, что частоты прямо низкие. Там частоты в режиме турбо под 4ГГц. Базовые конечно никакие. Но в реале они на базовых и не работают особо. Т.к. бустимся пока есть куда. Что в прочем актуально вообще для всех ядер что интел, что АМД.
Кстати всё что вы пишите, логично даже на бытовом уровне.
2 землекопа не будут копать в двое быстрее :)
Природа конечно немного иная, но всё равно забавно.
Ну и так, один фиг накладные расходы, не позволят ускорится даже в двое.
И тем не менее, человек прав. График показывает историю.
А этот ваш «анализ», это экстраполяция.
Всё что нужно понимать про экстраполяцию ↓
https://ru.algorithmica.org/cs/algebra/img/extrapolation.png
При этом, японский хайтек может в литографы. А американский нет. Как и химию почему-то используют японскую.
Как и не видно американских матриц аналогичных сони.
При этом Японский хайтек вполне себе конкурирует с Американским. Например на рынке NAND памяти. Где у насесть американский микрон и японская тошиба (kioxia).
Ну или на рынке аккумуляторов. Например LTO.
И тут у нас какие-нибудь Toshiba с Altairnano.
Я уж молчу о противостоянии консолей в лице сони и Майкрософт. Где американцы проигрывают.
Противостояние может быть не равным, но тем менее делят одну нишу.
И таких примеров если поискать можно найти кучу.
Так что о каком урезании и безопасных размерах то? Учитывая что Японцы одни из немногих у которых вообще есть свои процессоры. От телевизоров Сони. До суперкомпьютера фугаку, на ядрах от фуджитсу a64fx.
У европейцев я так на вскидку ничего подобного и не вспомню.
Мало того, ещё TSMC строят свои фабы не только в USA, но и в Японии же.
Что то не похоже, на обирание рынков, урезание и безопасных размеров.
По факту японцы просто попали в ловушку среднего дохода. Вот в среднем экономика и стагнирует.
Неа. Processor N100 это именно наименование. Переводить точно не нужно, мы же не переводим
CPU Intel Core I5,.как CPU Intel ядро I5.
И претензии с тавтологией тоже к Интелу.
Я уже понял. Не стал отвечать, т.к. полез копать что там в технической документации интела.
И тут как минимум у нас все же есть OS. Которая распоряжается системными ресурсами же. И для этого использует маски прерывания, диспетчер объектов.
Без планировщика все же куда.
Ну и так, всё же мы не можем обрабатывать исключительно одну задачу же. У нас всегда есть фоновые процессы.
При том думаю мы можем себе представить какой-нибудь перебор хешей. Где задачу можно разбить на подмножества, в случае если одно ядро закончило раньше, оно преспокойно может начать перебирать следующие значения.
В одном приложении же, может быть > 1 задачи которую можно распараллелить. Т.е. может быть и другая работа.
И вот мы лезем в дебри, а какая же у нас задача.
Нет конечно есть ещё всякие нюансы, в виде атомарных операций. У интел для этого есть свои инструкции же Remote Atomic Operation (RAO).
По мимо существования какого-нибудь Intel Resource Director Technology (RDT)
Плюс Intel Thread Director < аппаратная часть, для планировщика OS по сути.
Т.е. куча аппаратных фич, позволяющая мониторить и управлять ресурсами процессора.
В конце концов. У нас все процессоры многоядерные, так ещё и с SMT. Т.е. один фиг придётся реализовывать данные алгоритмы.
И снова всё сводиться к тому, а как у нас ложиться задача на наше железо.
И вот я как бы не считаю что в интел дураки сидят. Раз уж инженеры провели исследование и говорят, что малые ядра позволяют им лучше масштабироваться в многопоточных задачах, значит так оно и есть.
Другое дело, что это вот здесь и сейчас может не работать.
Ну не будет и не будет, значит ждёт судьба IA64. Ну либо Интел придётся свалить задачу на аппаратную часть. В целом выбор интел это второе.
Вообще если уж справились с разработкой и предсказателем переходов, то и тут со временем допилят.
" в играх "
А в играх оно не нужно отродясь. Там вообще много ядер нафиг не нужны.
8 ядер более чем оптимально. И 6 ядер в прочем хватает, вон даже 6 ядерный х3д выпускают.
Глобально игры пример задач где рулит производительность на ядро. + Игры любят размер кешей.
Загрузка прочих ядер в игре, это постольку-поскольку.
И тут вопрос оптимизации (под малые ядра). Вероятно этим никто не занимался.
Ибо тут надо draw call'ы обрабатывать большими ядрами 100%.
А вот например декомпрессию данных проводить на малых ядрах. < Это будет эффективно, т.к. те же майки пилят свой direct storage с декомпрессией на GPU. Т.е. этот процесс параллелится.
Вообще игры это такая смешанная нагрузка на CPU. Где вероятно какая-нибудь физика в общем и не параллелится толком. Как параллелится например анимация или ИИшка не знаю. И где доля того, что хорошо параллелится не велико, иначе есть смысл выполнять её на GPU.
«как камень для стриминга»
При 8 ядрах то? Не ну это бред. Стрим это на оборот задача, где больше ядер лучше.
Куда логичней был бы 3950х. При необходимости с привязкой кодировщика через affinity mask, например игра на 1 чиплете, стрим на 2. Тоже актуально и для малых ядер.
«нужны инструкции avx512»
Ну собственно так же есть задачи, где много ядер = збс. По мимо синтетики это какие-нибудь рендереры.
Есть ещё архивация. Упомянутое кодирование/перекодирование видео. Компиляция. Ну и на худой конец рейтрейсинг. По последнему даже скажу где это применяется. В CADах, при физической симуляции теплового излучения.
Вопрос лишь в том, задача оптимизирована под малые ядра или нет. Если нет, не покупайте. Можно покупать если задача уже работает и когда будет работать.
Всё не совсем так. «но им же ещё нужно синхронизироваться» ?????
У вас все ядра синхронизированы «часами».
Если речь про задачу. То о какой синхронизации речь? У нас для того есть компиляторы + планировщики как аппаратные так и в ОС. Вообще не вижу никакой проблемы. Многопоточность с нами уже давно.
По факту же работает оно так. Задача либо параллелится, либо нет.
Если она параллелится куча малых ядер приоритетнее. Что и показывает GPU.
Если нет, то приоритетнее производительность одного ядра.
Это конечно не в даваться в подробности, как оно ложиться на микроархитектуру.
Боже упаси такую колабу. Ведь х86 ядро они не разработают. А значит придётся использовать ARM архитектуру. И это АД похуже малых ядер интел. Меня бы ещё улыбнуло, если бы прикрутили аппаратный транслятор х86 в ARM для малых ядер.
А вообще у АМД был например Opteron A1100.
«что не придушены сверху.»
Физически такого быть не может. Малые ядра тут и там обрезаны же. Вот то, что обрезано и не жрёт энергию собственно.
«Так что нет здесь никакого понижения потребления энергии»
Да? А на чём сделаны выводы? У нас есть 2 процессора интел с идентичной производительностью где 1 с большими ядрами другой с малыми?
" на примере ВСЕХ линеек интел"
Т.е. не было бы малых ядер интел бы получил ту же производительность, с меньшим жором? Ой как сомневаюсь.
«Жруть тока в путь. )))» Потому, что производительный тех. процесс интел. Вот он и жрёт как не в себя.
Вон те же AMD хоть и используют тех. процессы TSMC которые более энергоэффективны нежели у интел. Хоть и перешли на 5нм. Даже IO перевели с 12нм GF, на 6нм TSMC. Т.е. прирост энергоэффективности приятный должен быть
Но таки лимиты подняли до 170ВТ TDP и 230ВТ PPT.
Вот именно потому 300Вт. А есть же ещё здоровенные видюхи (в плане кристаллов) на 450Вт.
Я очень слабо представляю как рассеять под 750Вт тепла, особенно летом, на солнце в жару, в комнате. Welcome to hell
Да как раз нет. Не хейчу, оно объективно так. Давайте на пальцах.
Есть у нас АМД. В лучшем случае их отдел занятый CPU, в половину Интела.
И какой ряд задач. Разрабатывать архитектуру, микроархитектуру, софтверную прокладку (микрокод, компиляторы и т.д.), разрабатывать IO, чипсет, физический дизайн данных продуктов, так же как нужно разработать дизайн например подложки. Иногда нужно разработать тот же сокет. Нужен референсный дизайн плат.
При том на разработку у нас минимум 3 года. Когда процессоры выходят ~ 1 раз в год.
Т.е. все эти процессы ведутся 3 командами параллельно. Т.е. в разработке 3 микроархитектуры параллельно.
И это я не беру ни менеджеров. Ни инженеров которые работают над полу заказными решениями. Ни тех инженеров которые работают в месте с теми же TSMC ради интеграции.
И тут нам нужна ещё одна микроархитектура. И это жесть.
Т.к. нам нужно откуда-то из воздуха. Взять так же 3 команды (минимум) на разработку микроархитектуры. + команды для разработки физ дизайна. На них же возложим тестирование на отказ.
Что бы поставить работу на поток и укладываться не в 5 лет, а в 3 года.
Придётся добавить людей, которые будут работать над софтверной прокладкой. Т.к. работы станет больше.
Придётся как минимум удвоить отдел занимающийся работой над софтом. Кто-то же должен работать над кучей прикладного софта. Разработчики приложений же, не хотят тратиться на внедрение этих вот малых ядер. На этих же людей возложим обучение людей в виде семинаров, видео и т.д.
И мягко говоря, у АМД всё и так не очень круто с развитием стороннего софта. Относительно конкурентов же. Те по идее пишут больше программ/библиотек и т.п.
Ладно придётся таки тронуть менеджмент. Его таки станет больше. Т.к. больше людей, больше менеджмента, больше бюрократии. Это проблемы практически любой крупной компании.
Суммируя это всё. Вы реально думаете, что АМД потянут разработку и продвижение ещё одной микроархитектуры? Без ущерба, прочим направлениям?
Это фундаментальная работа. И её мягко говоря до черта.
И всегда держим в голове, что АМД всегда меньше конкурентов и их доля рынка тоже меньше.
Так что да АМД не могут. Но им вроде и не горит. И уж говоря по факту их работы, как например с ядром Zen, уже показывает, что они понимают как лучше распределить свои ресурсы(деньги, люди, кони :) ), что бы выпустить свой конкурентный продукт.
Понимаете да? Тратя грубо говоря в 2 меньше, они выдают что-то конкурентное, при том порой ещё и умудряются в эту конкуренцию выиграть.
VRAM-Anforderungen
Jagged Alliance 3 benötigt kaum Grafikkarten-Speicher. Selbst ein Modell mit 8 GB VRAM ist noch mehr als genug für Ultra HD, auch mit 6 GB sollte es zu keinen Einschränkungen in hohen Auflösungen kommen. Und für Full HD bei maximalen Texturdetails genügt sogar ein 4-GB-Exemplar.
Я вот чот тоже хз. Я вот чот не припомню, что б карты в последнее время прям горели.
«их у ремонтников нет почти.»
А вот это враньё, нвидивских карт в ремонтах всегда хватало. И не потому, что они ломаются в разы чаще. А потому что их на рынке в разы больше.
С АМД ситуация та же, но в обратную сторону.
Собственно на том всё.
Windows же фактически. Т.к. мы сообщаем её планировщику, на каком потоке выполнять задачу.
https://learn.microsoft.com/en-us/windows/win32/api/winbase/nf-winbase-setthreadaffinitymask
Они же сами добавили такой функционал и не запрещают им пользоваться. Вот не пойму о каком не стандартном функционале речь то тогда. Мы же не вручную, в обход системы костылим привязку.
Мало того, мы можем сделать это стандартными средствами самой виндоус, через диспетчер задач же.
А вот оно что.
В целом адекватная позиция. Я бы глобально был бы не против иметь допусти ядра так 4 маленьких в IO райзенов. На них скинем ОС + браузер. + Такие мелочи как разные плееры, блокноты, вероятно ворд, всякий софт типа управлений подсветками, мессенджеры, стимы, райзен мастеры, модули драйвера (у амд же в драйвере кучу всякой мелочи), мониторинги, ну и всякие там простые микшеры и фильтры для микрофона.
Крч кучу мелких типичных задач, которым не нужно много производительности, но они весят в фоне и кушают системные ресурсы.
Может даже доживу до подобного.
А так вообще где окажется задача, отвечают планировщики. Т.е. автоматика.
И некоторое профилирование думаю доступно, через определённые инструкции же, думаю через CPUID < по моему там команды к тред директору.
Т.е. оптимизация таки возможна. Через профилирование же. В прочем как и всегда.
(С оговоркой симметричности инструкций же. иначе жопа )
Как бы ядра/потоки и так имеют разную производительность. Просто теперь разброс выше.
Ведь очевидно что SMT практически и не даёт нам +100%. + пара ядер имеет лучшую вольт частотную кривую, следственно бустится лучше.
В случае с райзенами, есть ещё чиплеты. Где лучше лишний раз не гонять информацию меж чиплетами. У райзенов теперь есть 1 чиплет х3д с низкими частотами и 1 чиплет с высокими. И со всем этим работает планировщик винды. Вроде особо не жалуемся же.
" оптимизируется количественной производительностью. "
Про это вообще все топовые архитектуры так то. Просто потому, что мы не управляем внутрянкой процессора, в отличии от явного программирования VLIW.
Господи в х86 мы даже по сути не знаем какие инструкции он выполняет. Т.к. один фиг, те инструкции что мы даём, декодируются во внутренние инструкции же.
Ииии по правде говоря, мудохаться с микро менеджментом ресурсов явно никто не хочет. Все как раз хотят писать говнокод, проще и дешевле. И крыть разницу именно за счёт количественной производительности.
Но реальность конечно жестокая штука. Прогресс требует более низкоуровневой оптимизации. Просто вспомним про низкоуровневые графические API. И как «погромисты» сталкнулись с мучением в виде вулкана.
Ну и тем не менее, стратегия Интел вполне жизнеспособна. Ибо таки они выжали дополнительную производительность. Думаю они не смогли бы сделать ту же производительность, при прочих равных, исключительно на больших ядрах. Скорее всего интел бы выдал нам полукиловатные печки с золотыми ядрами.
Но мне всё ещё нравится стратегия жирных ядер с большим IPC. Т.к. ИМХО ядер то хватает. А частоты задирать не хочется, слишком много жрать начинает.
При том, если заведомо не задирать частоты, можно использовать тех. процессы по плотнее и с низкими токами утечек.
Мне в принципе нравятся спец. ускорители для типовых задач.
А много много ядер с некоторой универсальностью, можно уж отдать на откуп программируемым шейдерам (до определённой степени).
Кстати всё что вы пишите, логично даже на бытовом уровне.
2 землекопа не будут копать в двое быстрее :)
Природа конечно немного иная, но всё равно забавно.
Ну и так, один фиг накладные расходы, не позволят ускорится даже в двое.
А видео гляну на досуге.
А этот ваш «анализ», это экстраполяция.
Всё что нужно понимать про экстраполяцию ↓
https://ru.algorithmica.org/cs/algebra/img/extrapolation.png
Как и не видно американских матриц аналогичных сони.
При этом Японский хайтек вполне себе конкурирует с Американским. Например на рынке NAND памяти. Где у насесть американский микрон и японская тошиба (kioxia).
Ну или на рынке аккумуляторов. Например LTO.
И тут у нас какие-нибудь Toshiba с Altairnano.
Я уж молчу о противостоянии консолей в лице сони и Майкрософт. Где американцы проигрывают.
Противостояние может быть не равным, но тем менее делят одну нишу.
И таких примеров если поискать можно найти кучу.
Так что о каком урезании и безопасных размерах то? Учитывая что Японцы одни из немногих у которых вообще есть свои процессоры. От телевизоров Сони. До суперкомпьютера фугаку, на ядрах от фуджитсу a64fx.
У европейцев я так на вскидку ничего подобного и не вспомню.
Мало того, ещё TSMC строят свои фабы не только в USA, но и в Японии же.
Что то не похоже, на обирание рынков, урезание и безопасных размеров.
По факту японцы просто попали в ловушку среднего дохода. Вот в среднем экономика и стагнирует.
CPU Intel Core I5,.как CPU Intel ядро I5.
И претензии с тавтологией тоже к Интелу.
И тут как минимум у нас все же есть OS. Которая распоряжается системными ресурсами же. И для этого использует маски прерывания, диспетчер объектов.
Без планировщика все же куда.
Ну и так, всё же мы не можем обрабатывать исключительно одну задачу же. У нас всегда есть фоновые процессы.
При том думаю мы можем себе представить какой-нибудь перебор хешей. Где задачу можно разбить на подмножества, в случае если одно ядро закончило раньше, оно преспокойно может начать перебирать следующие значения.
В одном приложении же, может быть > 1 задачи которую можно распараллелить. Т.е. может быть и другая работа.
И вот мы лезем в дебри, а какая же у нас задача.
Нет конечно есть ещё всякие нюансы, в виде атомарных операций. У интел для этого есть свои инструкции же Remote Atomic Operation (RAO).
По мимо существования какого-нибудь Intel Resource Director Technology (RDT)
Плюс Intel Thread Director < аппаратная часть, для планировщика OS по сути.
Т.е. куча аппаратных фич, позволяющая мониторить и управлять ресурсами процессора.
В конце концов. У нас все процессоры многоядерные, так ещё и с SMT. Т.е. один фиг придётся реализовывать данные алгоритмы.
И снова всё сводиться к тому, а как у нас ложиться задача на наше железо.
И вот я как бы не считаю что в интел дураки сидят. Раз уж инженеры провели исследование и говорят, что малые ядра позволяют им лучше масштабироваться в многопоточных задачах, значит так оно и есть.
Другое дело, что это вот здесь и сейчас может не работать.
Вообще если уж справились с разработкой и предсказателем переходов, то и тут со временем допилят.
А в играх оно не нужно отродясь. Там вообще много ядер нафиг не нужны.
8 ядер более чем оптимально. И 6 ядер в прочем хватает, вон даже 6 ядерный х3д выпускают.
Глобально игры пример задач где рулит производительность на ядро. + Игры любят размер кешей.
Загрузка прочих ядер в игре, это постольку-поскольку.
И тут вопрос оптимизации (под малые ядра). Вероятно этим никто не занимался.
Ибо тут надо draw call'ы обрабатывать большими ядрами 100%.
А вот например декомпрессию данных проводить на малых ядрах. < Это будет эффективно, т.к. те же майки пилят свой direct storage с декомпрессией на GPU. Т.е. этот процесс параллелится.
Вообще игры это такая смешанная нагрузка на CPU. Где вероятно какая-нибудь физика в общем и не параллелится толком. Как параллелится например анимация или ИИшка не знаю. И где доля того, что хорошо параллелится не велико, иначе есть смысл выполнять её на GPU.
«как камень для стриминга»
При 8 ядрах то? Не ну это бред. Стрим это на оборот задача, где больше ядер лучше.
Куда логичней был бы 3950х. При необходимости с привязкой кодировщика через affinity mask, например игра на 1 чиплете, стрим на 2. Тоже актуально и для малых ядер.
«нужны инструкции avx512»
Ну собственно так же есть задачи, где много ядер = збс. По мимо синтетики это какие-нибудь рендереры.
Есть ещё архивация. Упомянутое кодирование/перекодирование видео. Компиляция. Ну и на худой конец рейтрейсинг. По последнему даже скажу где это применяется. В CADах, при физической симуляции теплового излучения.
Вопрос лишь в том, задача оптимизирована под малые ядра или нет. Если нет, не покупайте. Можно покупать если задача уже работает и когда будет работать.
У вас все ядра синхронизированы «часами».
Если речь про задачу. То о какой синхронизации речь? У нас для того есть компиляторы + планировщики как аппаратные так и в ОС. Вообще не вижу никакой проблемы. Многопоточность с нами уже давно.
По факту же работает оно так. Задача либо параллелится, либо нет.
Если она параллелится куча малых ядер приоритетнее. Что и показывает GPU.
Если нет, то приоритетнее производительность одного ядра.
Это конечно не в даваться в подробности, как оно ложиться на микроархитектуру.
А вообще у АМД был например Opteron A1100.
Физически такого быть не может. Малые ядра тут и там обрезаны же. Вот то, что обрезано и не жрёт энергию собственно.
«Так что нет здесь никакого понижения потребления энергии»
Да? А на чём сделаны выводы? У нас есть 2 процессора интел с идентичной производительностью где 1 с большими ядрами другой с малыми?
" на примере ВСЕХ линеек интел"
Т.е. не было бы малых ядер интел бы получил ту же производительность, с меньшим жором? Ой как сомневаюсь.
«Жруть тока в путь. )))» Потому, что производительный тех. процесс интел. Вот он и жрёт как не в себя.
Вон те же AMD хоть и используют тех. процессы TSMC которые более энергоэффективны нежели у интел. Хоть и перешли на 5нм. Даже IO перевели с 12нм GF, на 6нм TSMC. Т.е. прирост энергоэффективности приятный должен быть
Но таки лимиты подняли до 170ВТ TDP и 230ВТ PPT.
Я очень слабо представляю как рассеять под 750Вт тепла, особенно летом, на солнце в жару, в комнате. Welcome to hell
Усиливает? Усиливает!
«удержании энергопотребления хоть в каких то рамках,»
Удерживает? Удерживает!
И что тут не нормального? За те же деньги (хотя б в рамках размеров кристаллов), за ту же мощность (Вт), мы получаем больше вычислений же.
При том для любой малопоточки есть большие ядра до 8шт. Чего более чем.
Есть у нас АМД. В лучшем случае их отдел занятый CPU, в половину Интела.
И какой ряд задач. Разрабатывать архитектуру, микроархитектуру, софтверную прокладку (микрокод, компиляторы и т.д.), разрабатывать IO, чипсет, физический дизайн данных продуктов, так же как нужно разработать дизайн например подложки. Иногда нужно разработать тот же сокет. Нужен референсный дизайн плат.
При том на разработку у нас минимум 3 года. Когда процессоры выходят ~ 1 раз в год.
Т.е. все эти процессы ведутся 3 командами параллельно. Т.е. в разработке 3 микроархитектуры параллельно.
И это я не беру ни менеджеров. Ни инженеров которые работают над полу заказными решениями. Ни тех инженеров которые работают в месте с теми же TSMC ради интеграции.
И тут нам нужна ещё одна микроархитектура. И это жесть.
Т.к. нам нужно откуда-то из воздуха. Взять так же 3 команды (минимум) на разработку микроархитектуры. + команды для разработки физ дизайна. На них же возложим тестирование на отказ.
Что бы поставить работу на поток и укладываться не в 5 лет, а в 3 года.
Придётся добавить людей, которые будут работать над софтверной прокладкой. Т.к. работы станет больше.
Придётся как минимум удвоить отдел занимающийся работой над софтом. Кто-то же должен работать над кучей прикладного софта. Разработчики приложений же, не хотят тратиться на внедрение этих вот малых ядер. На этих же людей возложим обучение людей в виде семинаров, видео и т.д.
И мягко говоря, у АМД всё и так не очень круто с развитием стороннего софта. Относительно конкурентов же. Те по идее пишут больше программ/библиотек и т.п.
Ладно придётся таки тронуть менеджмент. Его таки станет больше. Т.к. больше людей, больше менеджмента, больше бюрократии. Это проблемы практически любой крупной компании.
Суммируя это всё. Вы реально думаете, что АМД потянут разработку и продвижение ещё одной микроархитектуры? Без ущерба, прочим направлениям?
Это фундаментальная работа. И её мягко говоря до черта.
И всегда держим в голове, что АМД всегда меньше конкурентов и их доля рынка тоже меньше.
Так что да АМД не могут. Но им вроде и не горит. И уж говоря по факту их работы, как например с ядром Zen, уже показывает, что они понимают как лучше распределить свои ресурсы(деньги, люди, кони :) ), что бы выпустить свой конкурентный продукт.
Понимаете да? Тратя грубо говоря в 2 меньше, они выдают что-то конкурентное, при том порой ещё и умудряются в эту конкуренцию выиграть.