В природе существуют два широкоизвестных метода ввода-вывода: блокирущий и неблокирующий. Отношение к блокирующему как правило пренебрежительное, мол, он для нубов, а серьезным людям использовать его не стоит.

В этой статье я разберу блокирующий, неблокирующий, а также квази-блокирующий методы. Примеры буду брать из приложений, которые разрабатывал в ходе собственной практики.

Так как микроконтроллеры предоставляют разработчику полную свободу во взаимодействии с железом, примеры я тоже буду давать для абстрактного усредненного микроконтроллера семейства stm32. Но и на прочих NXP философия примерно такая же.

В общем, хочу поделиться собственным опытом, но не откажусь и от совета в комментариях.

Мы решили на регулярной основе рассказывать вам о развитии нашей линейки контролов для Avalonia UI. За время, прошедшее с момента предыдущей публикации, появилось несколько интересных моментов и один новый компонент.

• выбор стека платы,
• документация от производителя процессора,
• трассировка полигонов питания,
• расчет волнового сопротивления.

Когда схожее техническое решение уже охраняется, то перед изобретателем встает выбор: договориться с правообладателем на лицензию или поискать способы обхода действующего патента.

В этой статье расскажу про правила обхода – когда это возможно, а когда – нет, и как сделать так, чтобы ваш собственный патент не обошли похожим образом.

Привет, Хабр!

К 2022 году о контейнеризации не слышал только ленивый. Большинство специалистов, так или иначе имеющих отношение к ИТ, хотя бы раз в жизни запускали программное обеспечение в контейнерах. Однако так ли эта технология проста и понятна? Давайте разбираться вместе!

Главная задача данной статьи – рассказать о контейнеризации, дать ключевые понятия для дальнейшего изучения и показать несколько простых практических приемов. По этой причине (а еще, безусловно, вследствие недостаточной квалификации автора) теоретический материал достаточно упрощен.

Для улучшения возможностей научных вычислений в C# я реализовал evaluator, способный вычислять любое математическое строковое выражение с исключительной производительностью. Он также поддерживает пользовательские переменные, операторы и функции. Библиотека .NET под названием MathEvaluator и её документация доступны на GitHub.

Для достижения высокой производительности при вычислении математических выражений используется сочетание современных возможностей .NET и эффективных алгоритмов.

Эта статья является логическим продолжением предыдущей статьи, описывающей метод кодирования пиктограмм для кнопок и панелей инструментов в виде строк, а также их декодирования обратно в изображения.

Битовые картинки имеют только два цвета - цвет фона, обычно, прозрачный, он задаётся в алгоритме декодера, и основной видимый цвет, который, как правило, передаётся в функцию декодера. Битовые изображения легко рисовать в редакторе, но главный недостаток - отсутствие плавности и смягчающих градиентов на изгибах линий, дуг, окружностей, из-за чего изображения могут смотреться немного грубо и угловато, становится видна их пиксельная структура.

Один метод - избегать изогнутых линий и контуров в пиктограммах при их создании в редакторе. Другой, более интересный вариант - применить процедурное сглаживание изображений, также известное как antialiasing. Далее в качестве примера приводится один из простых вариантов сглаживания, применяемый мной в разных проектах.

Продолжим нашу «антологию матричных расширений» текстом про независимое матричное расширение RISC-V от компании T-Head. 

Почему мы рассматриваем именно его? Интересно понять, что из себя представляет будущее стандартное матричное расширение RISC-V, попробовать реализовать алгоритм с его использованием, соотнести это со своим предыдущим опытом низкоуровневых оптимизаций. Кроме того, это интересная возможность попробовать написать программу для расширения, которого еще нет ни в одном процессоре, и запустить ее на эмуляторе.

А еще ISA этого расширения весьма минималистична и, на мой взгляд, идеально подходит для тех, кто никогда не использовал матричные расширения в своем коде, но хочет попробовать (или узнать, как это выглядит изнутри). Не переживайте, текст не требует опыта низкоуровневых оптимизаций математических библиотек: погружение в матрицу будет постепенным.

Статья о том, как легко делать графические кнопки для панелей инструментов, не таская за приложением гору бинарных ресурсов с картинками. Этот метод платформонезависимый и может быть использован в различных языках и средах, позволяющих работать с графикой и растровыми изображениями. Ниже приводятся примеры для C# (WinForms / WPF), JavaScript, Python.

При разработке приложений и утилит мне неоднократно приходилось сталкиваться с проблемой создания множества пиктограмм для панелей инструментов и кнопок. Маленькое графическое изображение гораздо удобнее, чем громоздкий текст на кнопке, который лишь неоправданно раздувает её размер. Проблема в том, что разрабатывая небольшую утилиту, часто нет желания возиться с рисованием полноцветных изображений, а потом таскать их по папкам проекта, добавлять в ресурсы, искать их в ресурсах, чтобы обновить или заменить.

Тогда возникла идея - рисовать одноцветные изображения, кодировать их в строку и хранить прямо в свойствах объекта (например - кнопки). Самый простой вид кодировки - когда шесть точек изображения превращаются в шестибитный код, соответствующий некоторому символу из ASCII таблицы с заданным базовым смещением...

3D-редактор

Доброго времени суток, харбачитатель.

Так начинается статья, которая представляет сообществу первый, опубликованный здесь, алгоритм интерполяции:

Не так давно все наблюдали блокировку Docker Hub в РФ, которая длилась с 30 мая по 3 июня. Хотя сейчас Docker Hub вновь доступен, я успел разработать некоторую автоматизацию для переноса всех своих проектов и решил ими поделиться (пускай и очень поздно). В этом посте я расскажу как жить с блокировкой и как быстро перевести текущие проекты, использующие Docker Hub.

Во время разработки игр объем данных, обрабатываемых игрой, увеличивается. Художники создают новые ресурсы, программисты пишут код, а геймдизайнеры добавляют больше конфигураций и настроек в игру. Когда размер этих конфигураций превышает десятки мегабайт, производительность даже самых тривиальных компонентов, таких как JSON-парсер конфигураций, становится критичной.

После того как я собрал систему на самом первом процессоре от Intel (4004), логичным, в каком-то смысле, шагом было перейти к Intel 8008. Концепция проекта та же - компилируем ассемблерный код на обычном ПК, отправляем скомпилированный бинарник на системную плату через USB, а современный микроконтроллер (stm32) эмулирует ПЗУ и ОЗУ для реального 50-летнего процессора, вставленного в DIP-сокет.

Вполне возможно собрать систему на аутентичных микросхемах, но такое решение проигрывает в удобстве использования - вместо запуска одной команды на ПК нужно будет постоянно перепрограммировать ПЗУ. Да и для меня основной интерес представляет сам процессор, а не его обвязка.

Так же как и в случае с 4004, моя плата эмулирует максимально возможный объем памяти, который нативно адресуется процессором. В данном случае, это 16Кб с некоторыми нюансами (об этом отдельно расскажу ниже).

И, конечно же, было занятно сравнить 4004 и 8008 в небольшой нишевой задачке. Да, сравнение весьма условное и какие-либо выводы по нему сделать сложно, но всё равно результаты вышли интересными.

Как-то мне пришла в голову мысль о том, насколько же быстрее современные процессоры по сравнению с ранними экземплярами. Да, можно размышлять об этом эмпирически - зная тактовую частоту и особенности микроархитектуры (как устроен конвейер, сколько есть ALU, и т.д.), можно прикинуть производительность Intel 4004. Пусть и не в FLOPS'ах, ибо нативная поддержка чисел с плавающей запятой появилась позже. Но это будет весьма грубая прикидка, так как у этого процессора есть несколько интересных черт: разрядность только 4 бита (а не 64, как у большинства современных машин), очень скудный набор инструкций (нет даже AND'a и XOR'a!) и ограничения переферии (в частности памяти не так уж и много).

Поэтому я решил исследовать вопрос на практике. В качестве бенчмарка выбор пал на вычисления числа π. В конце-то концов, даже ENIAC в дремучем 1949 году справился с этой задачей! [2]

Я бросил себе вызов: симулировать 1000000 (миллион) частиц на чистом Javascript на телефоне, используя только CPU и добившись 60 FPS.

Поехали.

Задача не особо сложна, если выполнять всю работу на GPU, но правило гласит, что нужно пользоваться только CPU, при этом работая на JS, так что никакого WASM.

Работа с файлами — неотъемлемая часть многих проектов. Простая запись логов, чтение конфигурационных файлов или обработка больших данных — все это является частью взаимодействовия с файловой системой.

В этой статье мы рассмотрим основы работы с файлами и потоками в C#.