Обеспечение работы прикладного ПО
Три статьи я собирал файл и отдавал его эмулятору, ни разу в него не заглянув. Заглянул. Внутри два разных описания одних и тех же байтов, ответ на вопрос, откуда взялся адрес 0x80000000, и поле, которое я заполнял зря.
В прошлый раз я писал про потерянное пробуждение и получил в комментариях справедливое замечание, что примитив там классический. Так и есть. Сегодня про место, где классики меньше: как в моём ядре устроено переключение контекста, и почему ассемблер там знает смещение поля в структуре Rust.
Это неприятная связь. Ассемблеру нужен байтовый доступ к сохранённым регистрам, а раскладку структуры определяет компилятор. Если эти двое разойдутся во мнениях, вы не получите ошибку компиляции. Вы получите ядро, которое пишет регистры мимо и падает где-то далеко от места ошибки.
Я пишу ядро операционной системы на Rust. Не потому что собираюсь заменить Linux, а потому что мне интересно, что получится, если закладывать безопасность в архитектуру с нуля, а не встраивать в готовое.
Довольно быстро выяснилась вещь, о которой в разговорах про Rust в системном программировании говорят реже, чем стоило бы. Язык закрывает один класс ошибок и оставляет другой нетронутым. И второй класс ловится куда хуже первого.
Расскажу про конкретный баг, который я ловил дольше всего.
В мае на конференциях C++ Russia и HolyJS мы предложили участникам оценить технологии, инструменты и инженерные практики, с которыми они работают или за которыми следят. Так появились данные для двух технических радаров: по экосистеме C++ и по JavaScript.
Сырые цифры сами по себе рассказывают немного, поэтому мы отдали результаты на разбор эксперту. Виктор Новиков, руководитель группы разработки в «Лаборатории Касперского», посмотрел на распределения голосов и поделился своим мнением, почему CMake уверенно побеждает, а PostgreSQL раскалывает аудиторию пополам. В этой статье — его анализ C++-части исследования. Про техрадар JavaScript мы расскажем в другой статье.
Посмотреть радар и принять участие в голосовании можно на странице проекта.
Скрипт, который упал, вы почините за пять минут. Скрипт, который отработал молча и выдал неправильный ответ, вы не почините никогда, потому что не узнаете, что он сломан.
В работе с FASTA и FASTQ таких мест неприлично много. Почти все они когда‑то были задуманы как удобство.
Вот три, с которыми я сталкивался чаще всего.
Первое. Инструмент пишет FASTQ, а качества у записи нет. Вместо ошибки он подставляет строку из I. Файл получается валидный, парсер доволен, а фильтр по качеству дальше по пайплайну видит идеальные риды и пропускает всё подряд.
Второе. R1 и R2 разъехались: один файл отфильтровали, второй забыли. На выходе абсолютно корректный FASTQ, просто риды спарены не с теми. Формат не нарушен ни в одном байте. Ни один валидатор не возразит.
Третье. Определение Phred‑кодировки по образцу, который одинаково хорошо подходит и под Phred+33, и под Phred+64. Инструмент молча выбирает вариант. Иногда правильный.
Общее у всех трёх одно: вместо ошибки вы получаете правдоподобный результат. И это худший из возможных исходов, потому что ошибку вы бы заметили.
Полгода назад я начал писать fastx, библиотеку и CLI для FASTA/FASTQ на Rust. Основное решение в ней сформулировано так: там, где можно либо угадать, либо признать неоднозначность, признавать неоднозначность.
Если в современных реалиях у разработчика возникает необходимость собрать надежное решение для обработки G‑кода, он обычно смотрит в сторону готовых вариантов (GRBL/FluidNC/Linux‑CNC), либо пишет свой кастомный парсер на С/С++ или Rust и для таких проектов вариант реализации на.NET даже не рассматривается ввиду того, что платформа является управляемой и потому недостаточно надежной (заслуженно или нет — разберем далее).
Написал рекурсию тем же приёмом, что во второй статье, и программа повисла навсегда: возвращаться ей было некуда. Чиню, завожу стек и по дороге выясняю, что регистра sp в наборе команд нет вовсе. А потом урезаю стек до 128 байт, и сборка об этом не говорит ни слова.
Это статья про разновидность языка Си с русским и оригинальным английским синтаксисом, работающими одновременно. «Если» и «if» работают как синонимы. Это не интерпретатор. Это компилятор, который способен собрать себя сам. Это даже не транспилятор русского в английский - оба набора слов работают равноценно. Код можно посмотреть https://кодыч.рф/administrator/rusi.
В этой рубрике мы уже рассказывали про Кена Томпсона и Денниса Ритчи, соавторов Unix, UTF-8 и операционной системы Plan 9. Они практически всю жизнь работали вместе в Bell Labs (AT&T, потом Lucent) как коллеги и единомышленники. Так вот, третьим членом их коллектива был Роб Пайк.
Кроме соавторства Unix и нескольких учебников по программированию, он известен как создатель языка программирования Go. Этот язык родился из философии простоты в программировании, которую Пайк пропагандирует всю жизнь.
Без библиотек, без обвязок, без операционной системы под ногами. Реальный код на реальном железе — ну, почти реальном.
Пустая эмулируемая машина RISC-V, десяток строк ассемблера, и в терминале:
Сначала думал вывести «hello», как все.
Пусть будет «Привет, мир!»
Как разработать собственную ОС в одиночку, если заниматься проектом можно только в свободное время? Рассказываю, как ИИ помог мне пройти путь от изучения AArch64 до работающего ядра с вытесняющим планировщиком, userspace, ELF-программами и shell — и почему ответственность инженера при этом никуда не исчезает.
Всем привет! Меня зовут Тимур, я работаю в YADRO, и уже больше двух месяцев мой системный компилятор — gcc16. В новом стандарте добавили очень много, и сегодня я расскажу вам о некоторых обновлениях. В основном о рефлексии, но также будет немного и о контрактах.
Рефлексия в программировании — это способность программы работать со своим исходным кодом. Например, пройтись в цикле по всем полям класса и узнать их названия и типы. Работа с json — это очень хороший пример для изучения возможностей рефлексии. Я поигрался с ней, мне очень понравилось, и этой радостью я хочу поделиться с сообществом.
На Хабре периодически появляются статьи с анализом феномена Python - как один из самых медленных языков программирования стал королём нейросетей, и ответ всегда один: за счёт простого синтаксиса и развитой экосистемы. Но экосистема у C++ значительно больше и богаче, значит, дело не в ней и остаётся только синтаксис. А если проблема действительно в синтаксисе, тогда должен быть ответ и на другой вопрос: почему C++ не стал основой для исследований в этой (или любой другой) области?
Раньше я уже подходил к вопросу об эмпирической оценке сложности синтаксиса языков программирования, что называется «в лоб»: взять исходный код компилятора и посмотреть, сколько строк в нём занимает синтаксический анализатор. Ведь чем сложнее синтаксис, тем больше кода нужно, чтобы его распознать. И сотни тысяч строк кода только на анализ синтаксиса C++ - это измеримое свидетельство того, в какого монстра превратился C++ за сорок лет развития.
Но есть и другой способ оценить то же самое - причём гораздо проще, доступнее и без единой строчки анализа кодовой базы. И этот способ даёт неожиданно точный ответ на вопрос, почему именно Python в машинном обучении, несмотря на его репутацию «медленного» языка, стал стандартом.
Блендинг считает функцию для всех элементов и сохраняет только нужные. Для дешевых функций это оптимально, но на pow проигрывает в несколько раз. Можно сжать подходящие элементы, посчитать только их и разжать обратно. Разбираемся, где граница, и делаем адаптивный алгоритм.
С весны на собесах стабильно спрашивают про Green Tea. И ответ, который я слышу в девяти случаях из десяти, звучит так: «ну, он на 40% быстрее». Дальше начинаешь уточнять — быстрее что? — и человек плывёт. Проценты там действительно есть.
Просто относятся они не к тому, о чём все думают.
Некоторые альбомы должны звучать как один длинный трек. Рассказываю, как это устроено в Kalinka Player.
Профайлер показывает write() и worker файлового логгера среди верхних стеков. Однако системный профайлер не знает, какая из тысяч строк вывода в лог породила нагрузку. Отключать логирование совсем — ужасное решение. Как же связать файловый ввод-вывод с конкретными строками вывода в лог, каналами и backend?
Я заменил std::deque на boost::circular_buffer в надежде получить прирост производительности. В реальности получил загрузку процессора в 25% вместо 2%.
Производство пожаловалось: модуль WB-MGE v.3 на ESP32 шьётся слишком долго — 42 секунды на устройство. Что начиналось как простое «склеить вызовы esptool в один», превратилось в копание в исходниках загрузчиков на Си и Расте, патч прошивальщика, разгон системной шины, физику NOR-флеша (туннелирование Фаулера–Нордхайма — теперь я знаю что это такое), и в итоге ускорение почти в четыре с половиной раза. И да, совы оказались совсем не тем, чем казались.
О гиперавтоматизации обычно говорят как о способе быстро сократить издержки и избавиться от рутины. Это подход к автоматизации, сочетающий в себе набор технологий, включая RPA и AI. На презентациях все выглядит просто: выбрали процесс, настроили робота c ИИ, получили экономический эффект.
На практике все оказывается сложнее — многие проекты заканчиваются успешным пилотом, но дальше автоматизация не масштабируется. Меня зовут Мирза, я руководитель проектов ROBIN компании SL Soft и за время работы я сопровождал десятки инициатив, в которых RPA использовалась вместе с ИИ, поэтому сегодня я поделюсь с вами самыми распространенными ошибками внедрения, из‑за которых гиперавтоматизация не оправдывает ожиданий.