Я не специалист в RTOS, но на прошлом месте работы, например, приходилось иметь дело с микропроцессором, у которого был выделенный небольшой подтип памяти ( www.synopsys.com/dw/ipdir.php?ds=arc-dsp-options ). И на данные микропроцессоры ставили RTOS.
Или, например, даже в аллокаторах общего назначения, пытаются использовать некоторые сведения из спецификации процессоров и реализации ОС, чтобы улучшить производительность, например, читают напрямую из регистра идентификатор потока github.com/microsoft/mimalloc/blob/6a744a8549263696ef8d620006a0de2249e59b46/include/mimalloc-internal.h#L618
Просто, мне казалось, что в RTOS сфере вообще должны активно использовать различные уловки, чтобы выжать максимум из производительности.
Действительно, интересно бы было посмотреть на сравнение на каких-то бенчмарках с другими аллокаторами. И еще интересно, а влияют ли некоторые детали реализации RTOS на эффективность применения? Кажется, что должны. Я вижу issue про эксперимент с NuttX, но возможно, было бы интересно посмотреть на применение и в других системах для сравнения. Интересно еще посмотреть бы было на влияние архитектуры процессора, потому что особенно у некоторых процессоров для RTOS должны быть свои особенности, которые позволили бы оптимизировать некоторые аспекты работы с памятью.
А в целом, спасибо, интересно, еще раз хорошо показывает, что нет «серебряной пули» и что нужно правильно выбирать аллокатор и настраивать его под конкретную специфику даже если говорить про обычные приложения, у того же популярного jemalloc, очень много опций при сборке, которые стоит подкрутить, чтобы получить результаты получше.
Смотря какой работы, если человек хочет работать и развиваться в определенной сфере, то может быть и не так много компаний могут предложить подобную работу. А Вы скорее говорите о случаях компаний, которые просто скорее всего не способны четко определить свои критерии для найма.
Речь шла про крупные компании с проектами мирового уровня. Все равно у каждого человека есть компании, куда бы он хотел попасть в первую очередь по разным причинам. Если, например, человек хочет заниматься беспилотными автомобилями, вряд ли он упустит возможность устроиться в Tesla и т.п.
Думаю, что тот же Google отверг немало хороших специалистов.
В принципе, это нормально что крупные компании пытаются формализовать процесс найма, введя какие-то критерии для первичного отсева. Просто потому что там поток кандидатов огромен, и у людей напрямую, связанных с проектом, не хватит времени собеседовать всех желающих. Потерять хорошего специалиста для них не так страшно, потому что он среди желающих не один обычно.
А вот тенденция, что небольшие фирмы копируют этот подход, конечно, вредит. Но это тоже нормальный процесс во всех сферах: при отсутствии понимания просто скопировать, так не только в ИТ. При этом адекватные руководители никогда не упирают на идеальные знания, скорее проверяются базовые знания и каким образом идут рассуждения.
В итоге, все равно, люди адаптируются и большинство понимает, что нужно освежить в памяти алгоритмы перед собеседованием.
Да, абсолютно верно, но мне как и некоторым другим людям из комментариев, не хватило вариантов совмещения нативной и кроссплатформенной разработки. Вроде здесь говорится вообще о разработке приложений в целом, а не только про UI и даются рекомендации по выбору технологического стека. Так что упомянуть другие варианты, как мне кажется, не лишнее.
Для полной картины сравнения нативной и гибридной разработки неплохо был бы добавить и Kotlin Multiplatform. Технология хоть и совсем новая, но зато позволяет создавать нативные для платформы приложения и иметь единую базу кода для основной логики.
Мне кажется, Вы путаете, построение AST, про которое в данной статье написано в разделе «Парсинг», относится к синтаксическому анализу, так в создании компиляторов называется данный этап, в том числе и на английском (в том же Dragon Book). «Парсинг» же это несколько другое понятие в разработке. Это не замечание про чистоту языка, а замечание про принятую терминологию в данной сфере.
Мне кажется, что в основном в классической литературе на русском языке про компиляторы (в том числе и переводимой) принято называть этап не «парсинг», а синтаксический анализ.
Да, это одна из известных техник, позволяющих предоставить компилятору больше контекста из-за чего, естественно, повышается эффективность оптимизаций, но интеллектуальности в этом не так уж много.
Я не спорю, что это сложная и отчасти творческая задача, но есть проблема, что и человеку сложно удержать в голове много мелких деталей, которые часто тоже влияют на общую картину. Иногда даже опытным инженерам нужно потратить много времени на понимание некоторых эффектов. Возможно, это должна быть в начале рекомендательная система, которая должна натолкнуть инженера при анализе или помочь собрать и визуализировать некоторые данные. Вариантов много. Начинать же с чего-то надо.
при всём при этом качество кода того же gcc приятно удивляет
Замечу только, что качество кода достаточно хорошее за счет того, что разработчики компиляторов сами на данный момент и занимаются настройками эвристик на большом количестве бенчмарков. Настраиваются различные числовые значения, от релиза к релизу может меняться порядок проходов. Поэтому для популярных платформ, естественно, компиляторы хорошо настроены. И этот процесс настройки во время разработки компилятора по большей части пока делается перебором значений хоть и в ограниченном диапазоне с анализом человеком (хотя возможно у некоторых компаний есть какие-то закрытые решения), от этого как раз и хотелось бы избавиться и переложить эту задачу на некоторую систему.
При этом если начинать рассматривать конфигурируемые процессоры, то там уже так однозначно настроить оптимизации куда сложнее, и пользователи компилятора периодически могли бы получать лучший код.
К тому же, если, например, говорить о LLVM, который используют для написания компиляторов для множества языков, то в самой документации LLVM написано, что оптимизации настроены для clang, и если вы пишете свой фронтенд для другого языка, стоит поднастроить оптимизации по-другому, потому что иначе компилятор будет не очень эффективен.
Информация
В рейтинге
Не участвует
Откуда
Санкт-Петербург, Санкт-Петербург и область, Россия
Или, например, даже в аллокаторах общего назначения, пытаются использовать некоторые сведения из спецификации процессоров и реализации ОС, чтобы улучшить производительность, например, читают напрямую из регистра идентификатор потока github.com/microsoft/mimalloc/blob/6a744a8549263696ef8d620006a0de2249e59b46/include/mimalloc-internal.h#L618
Просто, мне казалось, что в RTOS сфере вообще должны активно использовать различные уловки, чтобы выжать максимум из производительности.
А в целом, спасибо, интересно, еще раз хорошо показывает, что нет «серебряной пули» и что нужно правильно выбирать аллокатор и настраивать его под конкретную специфику даже если говорить про обычные приложения, у того же популярного jemalloc, очень много опций при сборке, которые стоит подкрутить, чтобы получить результаты получше.
Думаю, что тот же Google отверг немало хороших специалистов.
А вот тенденция, что небольшие фирмы копируют этот подход, конечно, вредит. Но это тоже нормальный процесс во всех сферах: при отсутствии понимания просто скопировать, так не только в ИТ. При этом адекватные руководители никогда не упирают на идеальные знания, скорее проверяются базовые знания и каким образом идут рассуждения.
В итоге, все равно, люди адаптируются и большинство понимает, что нужно освежить в памяти алгоритмы перед собеседованием.
И потом дальше по тексту буквально через одно предложение.
Просто как небольшое примечание.
Замечу только, что качество кода достаточно хорошее за счет того, что разработчики компиляторов сами на данный момент и занимаются настройками эвристик на большом количестве бенчмарков. Настраиваются различные числовые значения, от релиза к релизу может меняться порядок проходов. Поэтому для популярных платформ, естественно, компиляторы хорошо настроены. И этот процесс настройки во время разработки компилятора по большей части пока делается перебором значений хоть и в ограниченном диапазоне с анализом человеком (хотя возможно у некоторых компаний есть какие-то закрытые решения), от этого как раз и хотелось бы избавиться и переложить эту задачу на некоторую систему.
При этом если начинать рассматривать конфигурируемые процессоры, то там уже так однозначно настроить оптимизации куда сложнее, и пользователи компилятора периодически могли бы получать лучший код.
К тому же, если, например, говорить о LLVM, который используют для написания компиляторов для множества языков, то в самой документации LLVM написано, что оптимизации настроены для clang, и если вы пишете свой фронтенд для другого языка, стоит поднастроить оптимизации по-другому, потому что иначе компилятор будет не очень эффективен.