А вот вы зря сюда вкидываете priority. Мы же можем его вообще не трогать. Для того, что бы игра не запускалась на тех же малых ядрах понятное дело.
А с вопросом на какие, давайте разбираться.
https://www.intel.com/content/www/us/en/developer/articles/guide/12th-gen-intel-core-processor-gamedev-guide.html
Кроссплатформенно мы можем обратиться только к CPUID по идее.
Обратившись к флагу типа ядра. Предварительно можно посмотреть на флаг гибридный ли процессор.
По идее готово.
И по идее теперь можно написать приложение, которое привяжет нужный процесс, например игру, через affinity, к P ядрам процессора, на основе флага CPUID.
Мы ведь можем сделать что-то подобное на C например? Это к слову о стандартных способах и кросплатформенности.
Так что как по мне сценарий в общем 1. Который нужно реализовать под 2 OC.
И для того, что бы например игра не фризила из за малых ядер условно. Нам же не нужно выставлять приоритет, нам не нужно думать о SMT. Нужно просто привязать данный процесс к большим ядрам. И это хватит. Остальное за нас автоматически сделает планировщик же. Ну эт если со стороны пользователя. Да здравствую варварские методы :)
Конечно для разработчика приложения это такой себе вариант. Д
ля разработчика игры, точнее его движка, не всё так плохо, т.к. имеем несколько разных нагрузок же. Т.е. часть задач, мы можем таки отдать на откуп малым ядрам. Т.е. draw call'ы на большие ядра, а допустим декомпрессию на малые.
И по идее, я описываю лишь вершину айсберга. Т.е. достаточно глобальные вещи, допустим макроуровень, которые не дадут нам большой выигрыш. А если спустится на микроуровень и попытаться выжать всё.
То тут да, практически реально придётся писать для приложения свой планировщик, с микроменджментом и куртизанками xD
Это явно очень сложная задача же.
P.s. Надеюсь мне удалось хоть немного передать идею. А то по ощущениям справился я так себе.
affinity есть и под другими ОС.
Вот например под линукс
https://manned.org/taskset.1
или
https://manned.org/sched_setaffinity.2
Из того что ещё удалось найти
https://www.gnu.org/software/libc/manual/html_node/CPU-Affinity.html
.
В принципе да не очень-то и удобно. Но в данном случае, у нас всего 2 ОС и пара команд. Что позволит решить, вот прям здесь и сейчас проблему малых ядер, которые делают что-то не то.
«псевдо 2d» ха-ха-ха. Т.е. вот сложно признать, что игра таки 3дшная да? И что это нифига не друге.
Оо пошли выкручивания. «Если убрать все лишнее» то давай превратим не «псевдо 2д» игры " требующие такие же системные требования как"
ну например в tomb raider 1996
Или в один из первых medal of honor 2002?
Или в The Elder Scrolls III: Morrowind.
Которые " аналогичный по концепции" один адвенчурник, один FPS, одна RPG.
Но главное все выше упомянутые игры по своему культовые. И им «не нужны ни текстуры высокой четкости, ни куча полигонов»
А эти ваши титан квесты вообще ньюфаги.
Так падажи, хватит тут мешать всё в кучу. Где шла речь про 40 или не 40 линейку. Формулировка была такая
" Карты Nvidia… а вспоминая статистику по всем знакомым, — но и горят чаще."
Где ты тут видишь 40 линейку?
«AMD в % на ремонте больше, чем у них доля рынка»
Жду пруфов билли. Где будет не бабка нашептала, не роскозни блогеров, не вот тебе 1.5 ремонтника что-то там перескажут.
А статистика RMA к примеру. С хорошей выборкой. Или исследования специализированных компаний же. Т.е. объективные и релевантные данные.
Я например могу найти какую никакую статистику 2020
https://docs.google.com/spreadsheets/d/e/2PACX-1vQbqvpHU0z6oK9HaCRbDPhkEoq5OA32mRGysyDZYhFsAk2kwKie-DaKplFyco7vwlw3ansFpjNstrpG/pubhtml
Это раскрытая статистика RMA майнд фактори.
И вот эти вот ваши ломались массово.
5000 поколение 50,440 видюх % возрата 3.22%. Ммм этот запах массовости по утру.
У нвидиа за 2000 поколение
122,210 видюх и 2.47%
Как видим всё в пределах нормы.
А если уж смотреть в частности.
2080 Ti 9530 5,17
5700 XT 32470 3,51
Т.е. 2080TI ломалась чаще, нежели вот эти массовые, глючные 5700XT.
P.s. нормальный % брака который закладывают это 5% и ниже.
Иная? ИНАЯ? С каких пор изометрия приравнялась к 2D?
Где ты тут видишь 2х мерную графику? Тут не вооружённым глазом видно что это 3D игра. Если уж вообще не бум бум, открой источник там есть видео. И внимааательно смотри на болванчиков.
А теперь открой какой-нибудь капхед, ори, исака
Далее вот прежде чем что то булькнуть, не мешало бы подумать. Насрать на изометрический вид. Не от него зависит потребление памяти. А от сцены. Т.е. от того, что мы собственно рендерим. От ассетов по сути.
И да это вот «2 мерная бродилка» на ультрах загрузила 6700хт так, что та выдала 38,6 FPS. Т.е. в игре оказывается есть графика, которую надо считать.
Кстати о птичках. Ещё одна свежая игра, которой нафиг не упёрлась куча врам.
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.
А с вопросом на какие, давайте разбираться.
https://www.intel.com/content/www/us/en/developer/articles/guide/12th-gen-intel-core-processor-gamedev-guide.html
Кроссплатформенно мы можем обратиться только к CPUID по идее.
Обратившись к флагу типа ядра. Предварительно можно посмотреть на флаг гибридный ли процессор.
По идее готово.
И по идее теперь можно написать приложение, которое привяжет нужный процесс, например игру, через affinity, к P ядрам процессора, на основе флага CPUID.
Мы ведь можем сделать что-то подобное на C например? Это к слову о стандартных способах и кросплатформенности.
Так что как по мне сценарий в общем 1. Который нужно реализовать под 2 OC.
И для того, что бы например игра не фризила из за малых ядер условно. Нам же не нужно выставлять приоритет, нам не нужно думать о SMT. Нужно просто привязать данный процесс к большим ядрам. И это хватит. Остальное за нас автоматически сделает планировщик же. Ну эт если со стороны пользователя. Да здравствую варварские методы :)
Конечно для разработчика приложения это такой себе вариант. Д
ля разработчика игры, точнее его движка, не всё так плохо, т.к. имеем несколько разных нагрузок же. Т.е. часть задач, мы можем таки отдать на откуп малым ядрам. Т.е. draw call'ы на большие ядра, а допустим декомпрессию на малые.
И по идее, я описываю лишь вершину айсберга. Т.е. достаточно глобальные вещи, допустим макроуровень, которые не дадут нам большой выигрыш. А если спустится на микроуровень и попытаться выжать всё.
То тут да, практически реально придётся писать для приложения свой планировщик, с микроменджментом и куртизанками xD
Это явно очень сложная задача же.
P.s. Надеюсь мне удалось хоть немного передать идею. А то по ощущениям справился я так себе.
Вот например под линукс
https://manned.org/taskset.1
или
https://manned.org/sched_setaffinity.2
Из того что ещё удалось найти
https://www.gnu.org/software/libc/manual/html_node/CPU-Affinity.html
.
В принципе да не очень-то и удобно. Но в данном случае, у нас всего 2 ОС и пара команд. Что позволит решить, вот прям здесь и сейчас проблему малых ядер, которые делают что-то не то.
Оо пошли выкручивания. «Если убрать все лишнее» то давай превратим не «псевдо 2д» игры " требующие такие же системные требования как"
ну например в tomb raider 1996
Или в один из первых medal of honor 2002?
Или в The Elder Scrolls III: Morrowind.
Которые " аналогичный по концепции" один адвенчурник, один FPS, одна RPG.
Но главное все выше упомянутые игры по своему культовые. И им «не нужны ни текстуры высокой четкости, ни куча полигонов»
А эти ваши титан квесты вообще ньюфаги.
" Карты Nvidia… а вспоминая статистику по всем знакомым, — но и горят чаще."
Где ты тут видишь 40 линейку?
«AMD в % на ремонте больше, чем у них доля рынка»
Жду пруфов билли. Где будет не бабка нашептала, не роскозни блогеров, не вот тебе 1.5 ремонтника что-то там перескажут.
А статистика RMA к примеру. С хорошей выборкой. Или исследования специализированных компаний же. Т.е. объективные и релевантные данные.
Я например могу найти какую никакую статистику 2020
https://docs.google.com/spreadsheets/d/e/2PACX-1vQbqvpHU0z6oK9HaCRbDPhkEoq5OA32mRGysyDZYhFsAk2kwKie-DaKplFyco7vwlw3ansFpjNstrpG/pubhtml
Это раскрытая статистика RMA майнд фактори.
И вот эти вот ваши ломались массово.
5000 поколение 50,440 видюх % возрата 3.22%. Ммм этот запах массовости по утру.
У нвидиа за 2000 поколение
122,210 видюх и 2.47%
Как видим всё в пределах нормы.
А если уж смотреть в частности.
2080 Ti 9530 5,17
5700 XT 32470 3,51
Т.е. 2080TI ломалась чаще, нежели вот эти массовые, глючные 5700XT.
P.s. нормальный % брака который закладывают это 5% и ниже.
Где ты тут видишь 2х мерную графику? Тут не вооружённым глазом видно что это 3D игра. Если уж вообще не бум бум, открой источник там есть видео. И внимааательно смотри на болванчиков.
А теперь открой какой-нибудь капхед, ори, исака
Далее вот прежде чем что то булькнуть, не мешало бы подумать. Насрать на изометрический вид. Не от него зависит потребление памяти. А от сцены. Т.е. от того, что мы собственно рендерим. От ассетов по сути.
И да это вот «2 мерная бродилка» на ультрах загрузила 6700хт так, что та выдала 38,6 FPS. Т.е. в игре оказывается есть графика, которую надо считать.
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.