Достаточно сложно найти стартап, у которого хватит ресурсов сделать конкурентноспособный (и не узкоспециализированный) процессор. Обычно их сразу скупают, как тот же soft machines. Сейчас достаточно сложно найти ноутбук/телефон на процессоре от какого-нибудь из стартапов (отчасти из-за гигантских расценок на производство). Поэтому, обычно, если хватил сил на разработку и выпуск, то лицензию купить не проблема. А большим компаниям, очевидно, из-за той самой кодовой базы выгоднее делать cpu на арме
Ну, компилятор не сам «по волшебству» добавляет инструкции. Поддержка векторизации для отдельной архитектуры - это большая работа. Если «накидать» оптимизации по схожим паттернам не так сложно, то писать их индивидуально под RISC-V требует несколько лет работы. В данном случае ARM лучше тем, что многое уже готово
На самом деле, даже в приложенном здесь исследовании есть неоднозначные моменты. Во-первых, немного странное решение о взятии среднего результата по нескольким достаточно большим проектам. В разных случаях компилятор может делать/не делать loop unrolling, векторизировать код и тд. Тут возможна ситуация, в которой несколько неудачных в плане размера оптимизаций перекрывают собой всё остальное. Было бы интересно посмотреть на статистику по каждому проекту. Во-вторых, тут автор ставит опцию -О3, а не -Оs. Возникает вопрос, что лучше в контексте этой ветки комментариев. На мой взгляд однозначного ответа тут нет, но опять же, было бы интересно глянуть. В-третьих, из личного опыта могу сказать, что оптимизации на размер кода в современных компиляторах работают так себе. Gcc в арме, например, зачастую использует очень нехорошие паттерны load/store. Прогоняя это дело через определенные версии llvm bolt, лично я получал прирост до 2% на бенчмарках (не знаю, насколько там уменьшился размер кода, этот вопрос тогда не исследовал). И наконец, даже отметая все раннее сказанное, можно увидеть заметно меньшее количество инструкций в арме, при том, что да, средний размер инструкции в risc-v ожидаемо меньше. Что важнее: размер кода или количество инструкций - сложно сказать. Затраты на декодирование и кеширование в данном случае могут различаться для разных процессоров. Так что, даже на таких тестах все не совсем однозначно.
P.s. насчет NEON вы правы, разумеется. RISC-V extension V все-таки правильнее сравнивать с SVE. Но при этом мои слова про резкое возрастание сложности архитектуры с добавлением расширений остаются в силе.
Еще раз хочу сказать: я не утверждаю, что risc-v плох. Наоборот, в нем есть множество достойных моментов. Но утверждение автора, что он с высокой вероятностью заменит все остальные архитектуры считаю гиперболизированным.
Даже принимая в рассмотрение GC extensions, ситуация кардинально не меняется. Ассемблер risc-v достаточно многословен и использование compressed инструкций не всегда спасает положение. Вполне реальна ситуация, когда инструкция на арме (32 бита) заменяет несколько сжатых инструкций risc-v (16 бит каждая). В итоге размер кода растет и code cache, шины и прочее страдают. Что важнее, с добавлением extensions возникают другие проблемы. Во-первых, не всегда имеется поддержка со стороны компилятора (с той же векторизацией все компиляторы справляются поголовно плохо). Понятное дело, что и на арме ситуация схожая, но там это в некоторой степени сглаживается меньшим количеством расширений и изначальным наличием большего количества инструкций в ISA. Ведь разработчику проще взять инструкцию, которая точно в наличии без поиска более быстрых альтернатив в куче расширений. Во-вторых, расширения risc-v уводят его от того изначального минимализма. В итоге отличий от арма становится не так уж и много. Достаточно посмотреть на векторный extension, который кратно увеличивает количество инструкций базовой ISA. В итоге, например, в случае с векторами назревает вопрос: «а чем это лучше NEON к которому все привыкли»?
Вы опять смешиваете встроенные и мобильные/десктопные платформы. Чип для телевизора (3я ссылка) - это далеко не то же самое, что телефон и ноутбук. Задачи и требуемая производительность совершенно разные. В остальных двух статьях также речь про embedded. Я же в своем комментарии пишу про телефоны и ноутбуки.
Здесь я скорее говорю не про векторные расширения, которые есть и у ARM, и у RISC-V, а, например, про более специализирванные инструкции load/store. Минимализм RISC-V в данном случае является и плюсом, и минусом по сравнению с подходом того же ARM. Наклепать различных расширений можно, и это делается вполне успешно, но базовая ISA остается той же самой со своими недостатками. В любом случае, в нынешнем состоянии ARM-A вполне успешно справляется и apple, qualcomm, huawei и прочим гигантам
переделывать свои процессоры на RISC-V просто невыгодно
Итак, пожалуй, напишу по пунктам: 1. В своем комментарии вы ставите вместе микроконтроллерные, десктопные и мобильные архитектуры. Это не совсем правильно. Например, ARM для микроконтроллеров (ARM-M) и ARM для телефонов/ноутбуков (ARM-A) достаточно сильно различаются. И популярны они в своих сферах по разным причинам. 2. Как я и написал ранее, RISC-V действительно хорош в сфере микроконтроллеров. Там он имеет громадные преимущества над остальными архитектурами (например, малое количество инструкций и открытость). 3. Про х86 также соглашусь: intel мало чего делает в последнее время для улучшения своих процессоров (да и в самом интеле сейчас большие проблемы). К тому же, переход apple и всех потянувшихся следом на ARM сильно повлиял на популярность х86. 4. Насчет мобильных систем, таких как смартфоны и ноутбуки: в этом сегменте RISC-V пока достаточно сильно уступает арму. На то есть весомые причины, как, например более специализированные инструкции арма, которые, как не крути, будут выполнять задачу быстрее, чем несколько инструкций RISC-V. По энергоэффективности сильного различия пока не наблюдается. Нет особого смысла здесь про это говорить, тк существует огромное множество статей, в которых авторы досконально анализируют различия. Куча софта написанного под арм и не всегда портируемого тоже усложняет переход. Да, собственно, и зачем переходить, когда у арма сейчас нет существенных проблем, как у x86. Архитектура на данный момент хорошо развивается и справляется с требуемыми задачами. В общем, как я и сказал, в этом сегменте вряд ли ARM будет вытеснен RISC-V в ближайшее время.
С большой долей вероятности x86 и ARM подвинутся с рынка, потому что они дорогие и устаревшие.
Весьма спорное утверждение, на мой взгляд. Да, х86 очень сильно мешает легаси, это так. Но вот насчет арма… из личного опыта могу сказать, что пока арм в подавляющем количестве случаев имеет сильное преимущество над RISC-V в плане скорости. Безусловно, RISC-V очень хорош для embedded systems, мест, где нужен open source и тд. Но по-моему, маловероятно, что он в ближайшем будущем заменит собой AArch64, особенно теперь, когда ноутбучный сегмент потихоньку переезжает с х86 на арм.
Достаточно сложно найти стартап, у которого хватит ресурсов сделать конкурентноспособный (и не узкоспециализированный) процессор. Обычно их сразу скупают, как тот же soft machines. Сейчас достаточно сложно найти ноутбук/телефон на процессоре от какого-нибудь из стартапов (отчасти из-за гигантских расценок на производство). Поэтому, обычно, если хватил сил на разработку и выпуск, то лицензию купить не проблема. А большим компаниям, очевидно, из-за той самой кодовой базы выгоднее делать cpu на арме
Ну, компилятор не сам «по волшебству» добавляет инструкции. Поддержка векторизации для отдельной архитектуры - это большая работа. Если «накидать» оптимизации по схожим паттернам не так сложно, то писать их индивидуально под RISC-V требует несколько лет работы. В данном случае ARM лучше тем, что многое уже готово
На самом деле, даже в приложенном здесь исследовании есть неоднозначные моменты. Во-первых, немного странное решение о взятии среднего результата по нескольким достаточно большим проектам. В разных случаях компилятор может делать/не делать loop unrolling, векторизировать код и тд. Тут возможна ситуация, в которой несколько неудачных в плане размера оптимизаций перекрывают собой всё остальное. Было бы интересно посмотреть на статистику по каждому проекту. Во-вторых, тут автор ставит опцию -О3, а не -Оs. Возникает вопрос, что лучше в контексте этой ветки комментариев. На мой взгляд однозначного ответа тут нет, но опять же, было бы интересно глянуть. В-третьих, из личного опыта могу сказать, что оптимизации на размер кода в современных компиляторах работают так себе. Gcc в арме, например, зачастую использует очень нехорошие паттерны load/store. Прогоняя это дело через определенные версии llvm bolt, лично я получал прирост до 2% на бенчмарках (не знаю, насколько там уменьшился размер кода, этот вопрос тогда не исследовал). И наконец, даже отметая все раннее сказанное, можно увидеть заметно меньшее количество инструкций в арме, при том, что да, средний размер инструкции в risc-v ожидаемо меньше. Что важнее: размер кода или количество инструкций - сложно сказать. Затраты на декодирование и кеширование в данном случае могут различаться для разных процессоров. Так что, даже на таких тестах все не совсем однозначно.
P.s. насчет NEON вы правы, разумеется. RISC-V extension V все-таки правильнее сравнивать с SVE. Но при этом мои слова про резкое возрастание сложности архитектуры с добавлением расширений остаются в силе.
Еще раз хочу сказать: я не утверждаю, что risc-v плох. Наоборот, в нем есть множество достойных моментов. Но утверждение автора, что он с высокой вероятностью заменит все остальные архитектуры считаю гиперболизированным.
Даже принимая в рассмотрение GC extensions, ситуация кардинально не меняется. Ассемблер risc-v достаточно многословен и использование compressed инструкций не всегда спасает положение. Вполне реальна ситуация, когда инструкция на арме (32 бита) заменяет несколько сжатых инструкций risc-v (16 бит каждая). В итоге размер кода растет и code cache, шины и прочее страдают. Что важнее, с добавлением extensions возникают другие проблемы. Во-первых, не всегда имеется поддержка со стороны компилятора (с той же векторизацией все компиляторы справляются поголовно плохо). Понятное дело, что и на арме ситуация схожая, но там это в некоторой степени сглаживается меньшим количеством расширений и изначальным наличием большего количества инструкций в ISA. Ведь разработчику проще взять инструкцию, которая точно в наличии без поиска более быстрых альтернатив в куче расширений. Во-вторых, расширения risc-v уводят его от того изначального минимализма. В итоге отличий от арма становится не так уж и много. Достаточно посмотреть на векторный extension, который кратно увеличивает количество инструкций базовой ISA. В итоге, например, в случае с векторами назревает вопрос: «а чем это лучше NEON к которому все привыкли»?
Вы опять смешиваете встроенные и мобильные/десктопные платформы. Чип для телевизора (3я ссылка) - это далеко не то же самое, что телефон и ноутбук. Задачи и требуемая производительность совершенно разные. В остальных двух статьях также речь про embedded. Я же в своем комментарии пишу про телефоны и ноутбуки.
Здесь я скорее говорю не про векторные расширения, которые есть и у ARM, и у RISC-V, а, например, про более специализирванные инструкции load/store. Минимализм RISC-V в данном случае является и плюсом, и минусом по сравнению с подходом того же ARM. Наклепать различных расширений можно, и это делается вполне успешно, но базовая ISA остается той же самой со своими недостатками. В любом случае, в нынешнем состоянии ARM-A вполне успешно справляется и apple, qualcomm, huawei и прочим гигантам
переделывать свои процессоры на RISC-V просто невыгодно
Итак, пожалуй, напишу по пунктам:
1. В своем комментарии вы ставите вместе микроконтроллерные, десктопные и мобильные архитектуры. Это не совсем правильно. Например, ARM для микроконтроллеров (ARM-M) и ARM для телефонов/ноутбуков (ARM-A) достаточно сильно различаются. И популярны они в своих сферах по разным причинам.
2. Как я и написал ранее, RISC-V действительно хорош в сфере микроконтроллеров. Там он имеет громадные преимущества над остальными архитектурами (например, малое количество инструкций и открытость).
3. Про х86 также соглашусь: intel мало чего делает в последнее время для улучшения своих процессоров (да и в самом интеле сейчас большие проблемы). К тому же, переход apple и всех потянувшихся следом на ARM сильно повлиял на популярность х86.
4. Насчет мобильных систем, таких как смартфоны и ноутбуки: в этом сегменте RISC-V пока достаточно сильно уступает арму. На то есть весомые причины, как, например более специализированные инструкции арма, которые, как не крути, будут выполнять задачу быстрее, чем несколько инструкций RISC-V. По энергоэффективности сильного различия пока не наблюдается. Нет особого смысла здесь про это говорить, тк существует огромное множество статей, в которых авторы досконально анализируют различия. Куча софта написанного под арм и не всегда портируемого тоже усложняет переход. Да, собственно, и зачем переходить, когда у арма сейчас нет существенных проблем, как у x86. Архитектура на данный момент хорошо развивается и справляется с требуемыми задачами. В общем, как я и сказал, в этом сегменте вряд ли ARM будет вытеснен RISC-V в ближайшее время.
Весьма спорное утверждение, на мой взгляд. Да, х86 очень сильно мешает легаси, это так. Но вот насчет арма… из личного опыта могу сказать, что пока арм в подавляющем количестве случаев имеет сильное преимущество над RISC-V в плане скорости. Безусловно, RISC-V очень хорош для embedded systems, мест, где нужен open source и тд. Но по-моему, маловероятно, что он в ближайшем будущем заменит собой AArch64, особенно теперь, когда ноутбучный сегмент потихоньку переезжает с х86 на арм.