buildroot тоже не предполагает изменения собранного набора пакетов. Тем не менее, вы можете доставить туда opkg, настроить его, и устанавливать что душе угодно. Ну или там арч какой-нибудь поднять
Вполне работоспособно, разве что у вас FS будет readonly. Вернее, все изменения в рантайме вы в QSPI не запишете. А ещё на QSPI долго грузится прошивка. Прям сильно долго, я бы сказал. Думаю, полный образ (а это мегабайт 150) будет грузиться около часа
В следующей статье как раз буду писать, как разом собирать всё из buildroot. У него есть все настройки и для ATF и для U-Boot и для всего остального кроме FSBL и PMUFW.
Забавный момент, однако мы замечаем даже разницу между 0.2 и 0.4 мкс. Почему? Потому что таких задач много, и суммарно они дают очень хорошо видимые тормоза.
Кроме того, а про какие задачи речь? Калькулятор обычный? Наверно, конечно, если перейти обратно на дизайн сайтов эпохи web1.0, то их грузить будет гораздо проще, но это такое себе решение. В целом, современные браузеры представляют из себя структуру сложности уровня ядра ОС.
Современные задачи требуют больших мощностей, большой производительности на такт и высоких частот. Из-за большого объёма данных, которые надо обрабатывать в реальном времени. Самая распространенная задача такого рода - игры. Благодаря играм, высокопроизводительные процы являются распространенными, а соответственно дешёвыми, и я как радиоинженер могу позволить себе систему, которая считает модели за пару часов, а не за пару недель, и стоила она мне не несколько миллионов, а пару сотен тысяч.
К сожалению, плохо оптимизированный софт является прямым следствием дешёвого высокопроизводительного железа. Однако тут не новая архитектура нужна, а... Ну не знаю, ГОСТ какой-нибудь (не надо меня проклинать на годы диареи, пожалуйста, это просто шутка). И предлагаемая вами архитектура наоборот ухудшит ситуацию, так как писать код с высоким уровнем параллелизма тяжело, намного тяжелее эффективных околооднопоточных приложений - современная индустрия не простит вам кратного увеличения стоимости и(ли) времени разработки.
А кто будет раздавать задачи агентам и по какому критерию?
Как понять, нужны ли задаче FPU блоки, или предсказание переходов, например?
Кроме того, какой объем кэша должен быть у такого агента, будет ли он одинаковым у всех агентов или разным? Можно попробовать переложить задачу такого распределения на систему и ИИ какой-нибудь, однако, как мне кажется, такой подход только наоборот увеличит количество транзисторов у CPU, при этом с потерей в производительности. В целом, мне видится, что такая архитектура очень сильно упирается в скорость памяти и шин данных, а их ограничивает не техпроцесс, а физика длинных линий и скорость света.
К тому же стоит рассматривать верные сценарии использования - да, для браузера и офиса сойдёт и старенький i7-4xxx, или даже i5 (а мне его даже для разработки хватает), но как бы и в новых сериях есть аналоги. Какой-нибудь pentium последних поколений или ryzen3, особенно всяких U и HS серий (такие ставятся, например, в мини ПК). Однако обычно люди не запускают браузер и офис одновременно с играми. Почему некоторые люди для офиса покупают игровые процессоры - уже другой вопрос.
Эти процессы близки друг к другу, возможно даже используют какие-то общие переменные, да и выполняют они не что-то сложное, что имеет смысл разносить на разные ядра. Потому что разные ядра в связанных процессах сразу поднимают вопрос синхронизации памяти.
Вообще, кмк, если уж вы про эту проблему имели ввиду, то лучшим решением являются гетерогенные процессоры, где на "маленькие" ядра сгружается всякая бытовуха, и из довольно много (в новых интелах, вроде, 16 маленьких против 8 больших), а большие ядра работают редко но метко, так сказать - считают всякие фотошопы, физические модели и игры.
И даже так слишком увеличивать количество ядер неэффективно, так как у каждого ядра свой L1 кэш, а точный профиль даже простых задач нам до конца неизвестен.
Это уже решенное решение. К сожалению, оно не подходит для современных процессов. Дело в том, что каждая отдельная задача/поток совершают операции последовательно. Это буквально то, что им нужно делать, иначе никак — сначала нужно вычислить А, и из него вычислить Б; не получится делать это параллельно.
Те задачи, которые хорошо считаются параллельно, и при этом им не хватает SIMD возможностей CPU, уже давно считаются на GPU.
Сейчас bluepill с оригинальными stm32 найти тяжело, и даже клон там может оказаться "с особенностями". Так, мы недавно закупали с али 10шт таких, и приехавшие МК отваливаются в reset handler при отключении jtag пинов (у оригинальных такой проблемы нет, а отключение этих выводов "кубик" генерирует автоматически, если использовать SWD)
К тому же, я не просто так привел Nucleo - оригинальные в рублях стоят около 4000, и это при том, что их производится больше, и сам МК в них дешевле. Потому, я считаю, что с учётом того, что мдровские контроллеры дороже, и у этих плат, в отличие от китайских (да и даже от маленьких нуклео) грамотно сделана система питания и выведена периферия, цена вполне себе норм — не похоже, что они ставят большую наценку от себестоимости.
P.S. да, функционал данного контроллера не сильно отличается от f103 (хотя имеет пару необычных особенностей, мне понравилось)
Но, конечно, подороже, чем, например, STMовские Nucleo. С другой стороны, у ST объём производства и рынок больше, так что могут позволить себе меньшую стоимость.
Про китайский клон - это да. Сейчас с октября у них ещё какая-то партия хреновая, которая отваливается при отключении лишних jtag пинов (SWD_NOJTAG макрос из HAL), чего на старых клонах не происходило. Хотя возможно раньше оригинальные клали, или левые с того же производства
У каждой разные тайминги доступа со стороны процессора и со стороны DMA, разное кэширование, разное управление доступом
Управление памятью в этом смысле и вовсе не является задачей не только языка, но и программы в целом. Процессор просто не перейдёт к следующей инструкции, пока не закончится текущая (да, в конвейерной микроархитектуре это не совсем справедливо, однако даже в таком случае это не проблема программиста).
Если у вас больше 5 одновременных каналов DMA
Ну DMA - это тоже своего рода многопоточность. И её можно вполне использовать вместе с переключением контекста ОСРВ. Да, не получится с ней использовать, например, <threads>, однако у ОСРВ есть свои механизмы для этого, и использовать их вместе с плюсами, равно как и с любым другим языком - это вопросы архитектуры программы.
Ну моё руководство говорило, что у нас есть возможность заказать необходимое количество (около 1000), если мы на них перейдем. Да, с АлиЭкспресс не заказать по 150р как stm32f103 (Миландр идут по ~1200р за штуку, как я знаю), но заказать можно
В ОСРВ динамическое выделение памяти в целом является проблемой. Однако, например, FREERTOS имеет свои механизмы для этого, и можно либо использовать их либо модифицировать систему под свои нужды (если умеете)
SoM и отладочные платы вполне присутствуют даже на алиэкспресс
buildroot тоже не предполагает изменения собранного набора пакетов. Тем не менее, вы можете доставить туда opkg, настроить его, и устанавливать что душе угодно. Ну или там арч какой-нибудь поднять
Вполне работоспособно, разве что у вас FS будет readonly. Вернее, все изменения в рантайме вы в QSPI не запишете. А ещё на QSPI долго грузится прошивка. Прям сильно долго, я бы сказал. Думаю, полный образ (а это мегабайт 150) будет грузиться около часа
В следующей статье как раз буду писать, как разом собирать всё из buildroot. У него есть все настройки и для ATF и для U-Boot и для всего остального кроме FSBL и PMUFW.
Забавный момент, однако мы замечаем даже разницу между 0.2 и 0.4 мкс. Почему? Потому что таких задач много, и суммарно они дают очень хорошо видимые тормоза.
Кроме того, а про какие задачи речь? Калькулятор обычный? Наверно, конечно, если перейти обратно на дизайн сайтов эпохи web1.0, то их грузить будет гораздо проще, но это такое себе решение. В целом, современные браузеры представляют из себя структуру сложности уровня ядра ОС.
Современные задачи требуют больших мощностей, большой производительности на такт и высоких частот. Из-за большого объёма данных, которые надо обрабатывать в реальном времени. Самая распространенная задача такого рода - игры. Благодаря играм, высокопроизводительные процы являются распространенными, а соответственно дешёвыми, и я как радиоинженер могу позволить себе систему, которая считает модели за пару часов, а не за пару недель, и стоила она мне не несколько миллионов, а пару сотен тысяч.
К сожалению, плохо оптимизированный софт является прямым следствием дешёвого высокопроизводительного железа. Однако тут не новая архитектура нужна, а... Ну не знаю, ГОСТ какой-нибудь (не надо меня проклинать на годы диареи, пожалуйста, это просто шутка). И предлагаемая вами архитектура наоборот ухудшит ситуацию, так как писать код с высоким уровнем параллелизма тяжело, намного тяжелее эффективных околооднопоточных приложений - современная индустрия не простит вам кратного увеличения стоимости и(ли) времени разработки.
А кто будет раздавать задачи агентам и по какому критерию?
Как понять, нужны ли задаче FPU блоки, или предсказание переходов, например?
Кроме того, какой объем кэша должен быть у такого агента, будет ли он одинаковым у всех агентов или разным? Можно попробовать переложить задачу такого распределения на систему и ИИ какой-нибудь, однако, как мне кажется, такой подход только наоборот увеличит количество транзисторов у CPU, при этом с потерей в производительности. В целом, мне видится, что такая архитектура очень сильно упирается в скорость памяти и шин данных, а их ограничивает не техпроцесс, а физика длинных линий и скорость света.
К тому же стоит рассматривать верные сценарии использования - да, для браузера и офиса сойдёт и старенький i7-4xxx, или даже i5 (а мне его даже для разработки хватает), но как бы и в новых сериях есть аналоги. Какой-нибудь pentium последних поколений или ryzen3, особенно всяких U и HS серий (такие ставятся, например, в мини ПК). Однако обычно люди не запускают браузер и офис одновременно с играми. Почему некоторые люди для офиса покупают игровые процессоры - уже другой вопрос.
Эти процессы близки друг к другу, возможно даже используют какие-то общие переменные, да и выполняют они не что-то сложное, что имеет смысл разносить на разные ядра. Потому что разные ядра в связанных процессах сразу поднимают вопрос синхронизации памяти.
Вообще, кмк, если уж вы про эту проблему имели ввиду, то лучшим решением являются гетерогенные процессоры, где на "маленькие" ядра сгружается всякая бытовуха, и из довольно много (в новых интелах, вроде, 16 маленьких против 8 больших), а большие ядра работают редко но метко, так сказать - считают всякие фотошопы, физические модели и игры.
И даже так слишком увеличивать количество ядер неэффективно, так как у каждого ядра свой L1 кэш, а точный профиль даже простых задач нам до конца неизвестен.
Это уже решенное решение. К сожалению, оно не подходит для современных процессов. Дело в том, что каждая отдельная задача/поток совершают операции последовательно. Это буквально то, что им нужно делать, иначе никак — сначала нужно вычислить А, и из него вычислить Б; не получится делать это параллельно.
Те задачи, которые хорошо считаются параллельно, и при этом им не хватает SIMD возможностей CPU, уже давно считаются на GPU.
А для чего вы make от sudo запускаете?
Так вот из-за кого мне приходится вводить капчу по несколько раз на день
Ну я же написал "доступный", а не "дешёвый" ;)
Сейчас bluepill с оригинальными stm32 найти тяжело, и даже клон там может оказаться "с особенностями". Так, мы недавно закупали с али 10шт таких, и приехавшие МК отваливаются в reset handler при отключении jtag пинов (у оригинальных такой проблемы нет, а отключение этих выводов "кубик" генерирует автоматически, если использовать SWD)
К тому же, я не просто так привел Nucleo - оригинальные в рублях стоят около 4000, и это при том, что их производится больше, и сам МК в них дешевле. Потому, я считаю, что с учётом того, что мдровские контроллеры дороже, и у этих плат, в отличие от китайских (да и даже от маленьких нуклео) грамотно сделана система питания и выведена периферия, цена вполне себе норм — не похоже, что они ставят большую наценку от себестоимости.
P.S. да, функционал данного контроллера не сильно отличается от f103 (хотя имеет пару необычных особенностей, мне понравилось)
Я у миландра на сайте нашёл ссылку:
https://ldm-systems.ru/catalog/milandr
Вот эти вполне доступные и вроде как сейчас в наличии (если верить каталогу):
https://ldm-systems.ru/product/19036
https://ldm-systems.ru/product/19001
Но, конечно, подороже, чем, например, STMовские Nucleo. С другой стороны, у ST объём производства и рынок больше, так что могут позволить себе меньшую стоимость.
Есть дистрибьюторы. Мб есть на ЧиД, смдру или аймаксай
Про китайский клон - это да. Сейчас с октября у них ещё какая-то партия хреновая, которая отваливается при отключении лишних jtag пинов (SWD_NOJTAG макрос из HAL), чего на старых клонах не происходило. Хотя возможно раньше оригинальные клали, или левые с того же производства
Как и в целом с механизмами любого языка.
Управление памятью в этом смысле и вовсе не является задачей не только языка, но и программы в целом. Процессор просто не перейдёт к следующей инструкции, пока не закончится текущая (да, в конвейерной микроархитектуре это не совсем справедливо, однако даже в таком случае это не проблема программиста).
Ну DMA - это тоже своего рода многопоточность. И её можно вполне использовать вместе с переключением контекста ОСРВ. Да, не получится с ней использовать, например, <threads>, однако у ОСРВ есть свои механизмы для этого, и использовать их вместе с плюсами, равно как и с любым другим языком - это вопросы архитектуры программы.
Ну моё руководство говорило, что у нас есть возможность заказать необходимое количество (около 1000), если мы на них перейдем. Да, с АлиЭкспресс не заказать по 150р как stm32f103 (Миландр идут по ~1200р за штуку, как я знаю), но заказать можно
Можно сделать "свой vector", и заиметь при этом преимущество в виде деструктора
В ОСРВ динамическое выделение памяти в целом является проблемой. Однако, например, FREERTOS имеет свои механизмы для этого, и можно либо использовать их либо модифицировать систему под свои нужды (если умеете)
Они отключены - в CMakeLists это прописано.
Динамическая аллокация - не особенность плюсов, она есть и в си; и плюсы дают больше возможностей к её неиспользованию.
Ну так я не осуждаю же)
Просто вот что есть