Юристы у квалкома зубастые, пободаются. Очевидно, что Майкрософту, Гуглу да и остальным вендорам, такая упоротость ARM не понравится.
RISC-V не заменит ARM по той же причине, что ARM десятилетиями пробивается в сегмент х86 - это софт и инфраструктура. Теперь на ARM есть серверы, суперкомпьютеры, Windows / macOS ноутбуки и рабочие станции.
Опять же, комитет RISC-V это такие интересные люди с идеологическими загонами,
которые ставят в приоритет не эффективность, а чистоту веры :)
X-Elite очень сильно задержался, потому что ядро Phoenix делалось под сервер, потом Qualcomm купил разработчика и ядро переделывали под смартфон/ноут -> Oryon.
Потом была судебная тяжба с ARM, которая существование проекта X-E поставила под вопрос.
По-сути Oryon был сделан по перф-таргетам 2020г. Пройдёт ещё 1-2 поколения со спорными результатами, прежде чем они смогут компенсировать отставание.
Только Apple не сидит сложа голову.
Арм просто холоднее и экономичнее.
Архитектура влияет на последние 5% (условно). Остальные 95% это микроархитектурная работа, которая по большей части одинакова для разных архитектур.
А риск-5 - это по факту архитектура будущего
Определённо нет. Это академическая архитектура, со своими костылями.
R5 это лоскутное одеяло и какое-либо отсутствие вменяемой стандартизации,
что мешает созданию стандартных дистрибутивов и понятной и устойчивой программной инфраструктуры.
Идеологически они сейчас там, где ARM был в начале нулевых.
Тем более нужен потактовый эмулятор, потому что результат может меняться в зависимости от того, на каком такте команды вы запишете данные в регистр железки (или в память).
Ко мне? Это ВЫ заявили. Я не знаю что у вас в голове - телепатии не обучен.
Или вам просто нравится применять уничижительные прозвища по отношению к x86?
Чего? Я вообще не упоминал х86 в своём сообщении, кроме прямой цитаты.
Огромное количество людей тестируют процессоры на кодировании и декодировании (проигрывании) видео
Эти ускорители имеются в любом современном x86 SoC. Более того, Интел как раз и упирает на них в своих рекламных материалах (проигрывание видео 100500 часов).
Но истина дороже, как говорится.
Совершенно не похоже чтобы вас волновала истина.
Ладно, это риторические вопросы, т.к. я прекрасно понимаю, что требую невозможного от оппонетна на хабре - просто обосновать свои голословные утверждения ¯\_(ツ)_/¯
Так ARM в ноутбуках все урезанные если вам нравится такая терминология.
Урезанные кем и в чём?
Еще очень любят сравнивать на тех задачах, которые на ARM выполняются на специализированном сопроцессоре, а в x86 на основных ядрах. Наличие специализированных блоков - это конечно преимущество, но оно ничего не говорит о достоинствах/преимуществах архитектуры основных ядер.
** Фейспалм **
На каких "специализированных" блоках запускается компиляция или рендеринг?
Оставьте этот бред про "асики" геймерским или околоит-шным форумам. Вы хоть понимаете, что компилятор вам не раскидает код по "специализированным блокам" (кстати каким?), а их нужно поддерживать через API?
Это я к тому, что не очень умный гражданин, когда видит рядом два айфона за 1 и 1000 дензнаков, с большой вероятностью выбирает первый
Кто тут умный ещё надо посмотреть. Одно дело единовременная крупная покупка, а другое - малозаметная сумма, которая никак не скажется на качестве жизни. То что заплатишь чуть больше, имеет значение только при полном отсутствии дохода. Ну и традиционное "44% of Americans can’t pay an unexpected $1,000 expense from savings." :) https://www.cnbc.com/2024/01/24/many-americans-cannot-pay-for-an-unexpected-1000-expense-heres-why.html
Напоминаю, что "чугунок", это лишь предсказатель токенов.
Вам самому не смешно от того, что вы предлагаете на него взвалить?
"Когда этот тостер приготовит обед на 400 персон с уровнем блюд Мишленовского ресторана, и чтобы блюда не повторялись, тогда я перестану варить пельмени и уйду в лес."
С исключениями C++ десять тысяч итераций с n=15 выполняются за 7,7 мс. Со значениями возврата std::expected они выполняются за 37 мс — почти пятикратный рост времени исполнения! Можете убедиться сами: Quick Bench
Ну туфта же.
Человек убил всю производительность использованием std::expected<>
Простая замена на C-style код ускоряет его в 25(!) раз относительно "с++" и 4.3 раза относительно версии с исключениями.
11) What is the sampling rate of your physics model?
360 Hz, is the short answer. But we calculate forces twice per update step, so we do player tire force calculations at least 4x2x360 = 2880 times per second. More if some of the tires are contacting multiple surfaces (i.e. curbs). We use IEEE floats.
использование таких операндов приводило к тяжеловесным ассемблерным инструкциям приведения типов от одного к другому.
О каких тяжеловесных инструкциях идёт речь?
Таких инструкций просто не существует, т.к. делать ничего не нужно.
Есть только инструкции расширения знака (extsb,extsh,extsw). Двухтактовые, как и любые простые ALU операции.
Единственный косяк PPE в этом плане был в том, что знаковая загрузка из памяти с расширением знака (lha, lwa) делалась микрокодом, который блокировал конвейер на пару десятков тактов, поэтому компилятор пихал пары lwz / extsw.
А что вас смушает? Я Rust не знаю, но выглядит как оптимальный вариант с точки зрения компилятора. Все опкоды заинлайнены в один большой цикл (что и видно в дизасме). Хочешь таблицу адресов делай, хочешь таблицу переходов, ну или двоичный поиск. Собственно тут ручками и делается то, что должен был сделать компилятор.
В M1-M3 он является недокументированным, и разработчикам предлагается использовать фреймворки. Но это не мешает его программировать напрямую, если захочется (для себя).
>> У вас в команде работает хотя бы один инженер из "оригинальной" Sun Microsystems?
Sun работал в России с 1992г, когда был основан Moscow Center of SPARC Technology,
так же известный как МЦСТ.
https://halfhill.com/byte/1992-11_sun-expands.html
Cерверной(?) и мобильной Java (j2me) занимались в Питерском офисе.
Upd: На сайте написано 15 лет.
Над вашими задачами работают профессионалы Java™, которые уже более 15 лет занимаются её разработкой.
Юристы у квалкома зубастые, пободаются. Очевидно, что Майкрософту, Гуглу да и остальным вендорам, такая упоротость ARM не понравится.
RISC-V не заменит ARM по той же причине, что ARM десятилетиями пробивается в сегмент х86 - это софт и инфраструктура. Теперь на ARM есть серверы, суперкомпьютеры, Windows / macOS ноутбуки и рабочие станции.
Опять же, комитет RISC-V это такие интересные люди с идеологическими загонами,
которые ставят в приоритет не эффективность, а чистоту веры :)
Такая же история. И возраст такой же. Новые знания забываются на раз-два. Но благо долговременная память работает хорошо.
*программный инструмент -> программный интерфейс
Кого, M4? X-E и рядом не лежал.
X-Elite очень сильно задержался, потому что ядро Phoenix делалось под сервер, потом Qualcomm купил разработчика и ядро переделывали под смартфон/ноут -> Oryon.
Потом была судебная тяжба с ARM, которая существование проекта X-E поставила под вопрос.
По-сути Oryon был сделан по перф-таргетам 2020г. Пройдёт ещё 1-2 поколения со спорными результатами, прежде чем они смогут компенсировать отставание.
Только Apple не сидит сложа голову.
Архитектура влияет на последние 5% (условно). Остальные 95% это микроархитектурная работа, которая по большей части одинакова для разных архитектур.
Определённо нет. Это академическая архитектура, со своими костылями.
R5 это лоскутное одеяло и какое-либо отсутствие вменяемой стандартизации,
что мешает созданию стандартных дистрибутивов и понятной и устойчивой программной инфраструктуры.
Идеологически они сейчас там, где ARM был в начале нулевых.
Любой высокопроизводительный ОоО процессор зависит от тех процесса.
ARM, x86 или RISC-V - это просто разный программный инструмент к более-менее одинаковому ядру.
Уже превышают 4ГГц (iPhone 16)
Макбук на M4 хотя бы догоните в однопотоке =)
Не нужно думать, что вы умнее всех остальных разработчиков эмуляторов.
Switch/case это самое оптимальное решение, как раз потому, что код сложен в одном месте.
Компилятор превращает switch/case в таблицу автоматически.
Рекомендую ознакомиться с этим проектом (потактовый эмулятор 6502)
https://github.com/floooh/chips/blob/master/chips/m6502.h
Легко читать, легко понять.
Тем более нужен потактовый эмулятор, потому что результат может меняться в зависимости от того, на каком такте команды вы запишете данные в регистр железки (или в память).
Ну вот, вы даже язык опознали. В чём вопрос?
Форкните и добавьте ваш любимый язык.
Ко мне? Это ВЫ заявили. Я не знаю что у вас в голове - телепатии не обучен.
Чего? Я вообще не упоминал х86 в своём сообщении, кроме прямой цитаты.
Эти ускорители имеются в любом современном x86 SoC. Более того, Интел как раз и упирает на них в своих рекламных материалах (проигрывание видео 100500 часов).
Совершенно не похоже чтобы вас волновала истина.
Ладно, это риторические вопросы, т.к. я прекрасно понимаю, что требую невозможного от оппонетна на хабре - просто обосновать свои голословные утверждения ¯\_(ツ)_/¯
Урезанные кем и в чём?
** Фейспалм **
На каких "специализированных" блоках запускается компиляция или рендеринг?
Оставьте этот бред про "асики" геймерским или околоит-шным форумам. Вы хоть понимаете, что компилятор вам не раскидает код по "специализированным блокам" (кстати каким?), а их нужно поддерживать через API?
Нужно не только иметь инструмент, но и уметь им пользоваться.
По сути, deep learning стал доступен только 10 лет назад.
>> в начале 2000-х
Что могли сделать в начале 2000-х на обычном компе с имеющимися тогда скромными мощностями? Тогда даже пискельных шейдеров не было на GPU.
А так мне ещё в середине 90-х попала в руки книжечка по нейросетям.
Вот только про то, как их применить, я тогда не знал, а то бы обязательно дочитал до конца ;) Это был какой-то далёкий "забавный рисёрч", бесполезный.
Кто тут умный ещё надо посмотреть. Одно дело единовременная крупная покупка, а другое - малозаметная сумма, которая никак не скажется на качестве жизни. То что заплатишь чуть больше, имеет значение только при полном отсутствии дохода.
Ну и традиционное
"44% of Americans can’t pay an unexpected $1,000 expense from savings." :)
https://www.cnbc.com/2024/01/24/many-americans-cannot-pay-for-an-unexpected-1000-expense-heres-why.html
Напоминаю, что "чугунок", это лишь предсказатель токенов.
Вам самому не смешно от того, что вы предлагаете на него взвалить?
"Когда этот тостер приготовит обед на 400 персон с уровнем блюд Мишленовского ресторана, и чтобы блюда не повторялись, тогда я перестану варить пельмени и уйду в лес."
Ну туфта же.
Человек убил всю производительность использованием std::expected<>
Простая замена на C-style код ускоряет его в 25(!) раз относительно "с++" и 4.3 раза относительно версии с исключениями.
https://quick-bench.com/q/LFPzMwd58xhaPBasnz3oUDKhgiM
Чего? Сейчас самые тепличные и зажратые времена, которые когда либо были на планете Земля.
Потому что они отказывались от поддержки относительно свежих чипов, которые поддерживают упомянутые тут расширения.
Это список игр, которые портированы на Эльбрус и запускаются там нативно.
О чём написано крупным шрифтом на первой же картинке.
Если вы уговорите открыть исходники GTA5 и других игр, думаю люди с удовольствием их портируют.
С чего бы? Вы тёплое с мягким не путайте. Речь о физике автосимуляторов, а не о PhysX.
Физику 300-400Hz легко тащит jaguar на превген консолях. И ничего там не тормозит.
Assetta Corsa - 333Hz
Forza Motorsport 8 - 360Hz
Colin McRae: Dirt - 1000Hz (игра 2007г)
iRacing
https://www.iracing.com/physics-modeling-ntm-v7-info-plus/
11) What is the sampling rate of your physics model?
360 Hz, is the short answer. But we calculate forces twice per update step, so we do player tire force calculations at least 4x2x360 = 2880 times per second. More if some of the tires are contacting multiple surfaces (i.e. curbs). We use IEEE floats.
func_signed_signed(int): # @func_signed_signed(int)
mov eax, 10
ret
func_unsigned_signed(int): # @func_unsigned_signed(int)
xor ecx, ecx
cmp edi, -10
mov eax, 10
cmovae eax, ecx
ret
Ваш цикл кстати превращается в... ничто.
О каких тяжеловесных инструкциях идёт речь?
Таких инструкций просто не существует, т.к. делать ничего не нужно.
Есть только инструкции расширения знака (extsb,extsh,extsw). Двухтактовые, как и любые простые ALU операции.
Единственный косяк PPE в этом плане был в том, что знаковая загрузка из памяти с расширением знака (lha, lwa) делалась микрокодом, который блокировал конвейер на пару десятков тактов, поэтому компилятор пихал пары lwz / extsw.
А что вас смушает? Я Rust не знаю, но выглядит как оптимальный вариант с точки зрения компилятора. Все опкоды заинлайнены в один большой цикл (что и видно в дизасме). Хочешь таблицу адресов делай, хочешь таблицу переходов, ну или двоичный поиск. Собственно тут ручками и делается то, что должен был сделать компилятор.
Я не терял. Не могу залезть к вам в мысли, чтобы понять, что вы хотели сказать.
Потому что сказали вы другое:
яблочные M1-M4 полностью закрыты, документации нет.
И это является ложью.
В M4 сопроцессор AMX выведен в виде SME.
Документация открыта на сайте ARM.
Вы ведь проигнорировали ссылку в статье?
https://github.com/tzakharko/m4-sme-exploration
В M1-M3 он является недокументированным, и разработчикам предлагается использовать фреймворки. Но это не мешает его программировать напрямую, если захочется (для себя).
Документация на AMX легко доступна в 1 клик.
https://github.com/corsix/amx
https://gist.github.com/dougallj/7cba721da1a94da725ee37c1e9cd1f21
Вот так вот информация "закрыта" чуть более чем полностью(с)
Пассаж про GPGPU тем более не ясен. Всё открыто в презентациях и документации Apple.