Метка: программирование

Вот читаю я, допустим, статейку про проект uTensor — совместимую с TensorFlow реализацию нейросетей для ARM Cortex M3 или M4.

https://towardsdatascience.com/why-machine-learning-on-the-edge-92fac32105e6

Штука прикольная — пусть и на «топовых», но все-таки на недорогих и довольно доступных микроконтроллерах позволяет, например, распознавать рукописный ввод:

Ну, со специалистами по «обычному» машинному обучению все вроде бы понятно — трехмесячные курсы и вперед, можно даже других учить (я почти не шучу — во всяком случае, очень похоже, что вот такие популярные «курсы для начинающих» этими вот «трехмесячными специалистами» и сделаны). Но если задуматься — а что нужно, с точки зрения фундаментального образования, чтобы более-менее понимать каждый из элементов этой системы?

Ну, для начала — математика. Для понимания хотя бы MIT’овского учебника по Deep Learning желательно иметь представление о линейной алгебре, теории вероятностей, возможно, о каких-то началах функционального анализа. Да, некоторые отрывочные сведения из этих дисциплин приведены в первой части этого учебника (так часто делают в американских учебниках — так как нет гарантий, что слушатели курса по машинному обучению перед этим действительно прослушали несколько курсов по математике) — но их явно недостаточно. Если ориентироваться на программу мехмата, например — это 2-3 курс, если безжалостно ужимать — то все равно необходимо 3-4 семестра одной только математики.

Программирование тут не менее суровое. Даже если предположить, что с Python (в объеме, необходимом для TensorFlow) человек, умеющий немного программировать на C, сможет разобраться самостоятельно — все равно здесь, как и в любом проекте с использованием микроконтроллеров, требуется отличное знание C и даже немного — C++ (даже если говорить о нем, как о C with classes — все же нужно понимать «цену» тех или иных возможностей C++). Не знаю, стоит ли в обязательные общие требования к программисту включать знания классических алгоритмов — но в целом в критичных к производительности задачах это оказывается само собой разумеющимся требованием. Тут у нас нет многоядерного процессора и гигабайтов оперативки. В «профессиональном обучении» программиста это где-то год.

Дальше — микроконтроллерная специфика. Да, «входной порог» в программирование для микроконтроллеров сейчас (благодаря все той же ARM mbed) сводится «до уровня базовых знаний C/C++ и электроники в масштабе «подключить светодиод в нужной полярности»» (c) — но для понимания штук типа CMSIS-NN желательно уже иметь представление об архитектуре ARM, всякого рода оптимизациях, DSP-инструкциях (зря что ли мы берем Cortex-M4?) и прочей такой вот низкоуровневой ерунде — возможно, вплоть до программирования на ассемблере. Электроника, нужная для такого проекта, разумеется, тоже довольно далеко ушла от «подключить светодиод в нужной полярности».

В общем, если представить учебники по каждой из дисциплин — тут «вырисовывается» книжная полка с десятком книжек страниц по 300 каждая (это минимум — некоторые особенно «хорошие» учебники по некоторым разделам computer science приближаются к полутора тысячам страниц). Можно, конечно, возразить с аргументами в духе разделения труда — мол, не обязательно специалисту по deep learning знать нюансы архитектуры ARM, да и математика ему не особо нужна, и вместо одного «универсала» тут можно взять трех-четырех выпускников трехмесячных курсов. Но с другой стороны — над ними все равно должен быть какой-то руководитель — который должен иметь представление не только о технических аспектах, но еще и направлять процесс разработки.

И заметьте — все это только для того, чтобы можно было пальчиком провести по тачскрину, а на дисплее отобразилась бы введенная цифра. Но, конечно, всегда есть и более простой путь — «еще три года назад Антон был простым раздолбаем, а сегодня он Senior Developer в Luxoft» (c). Сеньер-формошлепом, наверное, быть неплохо :)

namespace std в C++ — это не сокращение standart, это сокращение sexually transmitted disease — заболевание, передаваемое половым путем.

Крайне рекомендую к внедрению в опенсорсных проектах:

https://github.com/unwireddevices/RIOT/blob/loralan-public-2018.07/CODE_OF_CONDUCT.md

UPD Не все понимают, чем он так хорош — смотрите в сравнении с «Code of Conduct курильщика».

А может, кто-нибудь подскажет такую штуку? Хочется работающий в онлайне «многопользовательский» (ну или «на двоих» — чтобы была возможность обсуждать маленькие, почти тривиальные примеры кода, используя для этого что-то поудобнее вконтактика) редактор и компилятор Java, соединенный с текстовым чатом, желательно бесплатный. Пока что нашел два с половиной сайта с близкой, но немного не устраивающей меня функциональностью.

Первый — https://codeinterview.io, он же https://www.remoteinterview.io. Платный, но для моих задач вроде как подходит и демо-версия. Довольно большой выбор языков программирования, есть unix shell и видеочат. Текстовый чат отсутствует. Платная версия дорогая — 500-1000 $ в год, или 5 $ за каждое «собеседование». Мне кажется, что «для двоих» можно завести одно такое «собеседование», заплатив 5 $ один раз, или же пользоваться бесконечно оформляемым на разные левые email-ы free trial.

Второй — https://codebunk.com, в отличие от предыдущего варианта, для интерпретируемых языков прикручено окошко с REPL, есть текстовый и видеочат. По-моему, демо-режим поддерживает только одного работающего пользователя. Заметно дешевле предыдущего варианта — 9 $ в месяц.

Гугл выдает еще https://coderpad.io/ — опять же, позиционируется, как инструмент для проведения программистских собеседований, есть компилятор и видеочат, стоит от 50 $ в месяц, free trial на 7 дней — но у меня заработало не во всех браузерах.

Что нибудь еще подобное есть?

Прикольно как — обработка одного и того же набора данных модными современными инструментами (Amazon EMR и mrjob) занимает 26 минут, а простыми средствами Unix shell — 12 секунд.

https://adamdrake.com/command-line-tools-can-be-235x-faster-than-your-hadoop-cluster.html

«Наивное» решение средствами все той же командной строки обрабатывает те же данные за 70 секунд — что уже вполне терпимо.

https://felixit.blog/2018/08/16/elita/

Все так.

PS Что делать, если не хочется получить по морде? Don’t call yourself a programmer.

А кто-нибудь в здравом уме (за исключением vitus_wagner) пользовался системой контроля версий fossil?

https://www.fossil-scm.org/

Мне очень нравится тамошняя идея объединить в одно «хранилище» код, документацию в викиобразном формате и тикеты — но можно ли это все использовать в реальной жизни?

Столкнулся с интересным поведением Linux при попытке изобразить TCP-соединение с помощью «сырых» сокетов (raw sockets), точнее, чего-то на них похожего. Как только на не открытый «явно» (с помощью bind() и listen()) TCP-порт прилетал какой-либо пакет, что-то в составе операционной системы кидало в ответ пакет с флагом RST. Лечится такое поведение двумя способами — можно либо «недосоздать» сокет (вызвать bind(), listen() и не вызывать accept()), либо добавить правило в iptables, не позволяющее отправлять пакеты с RST — что-нибудь в таком роде:

iptables -I OUTPUT -p tcp --tcp-flags RST RST -j DROP

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

CREATE TABLE measurements (
    measurementID int NOT NULL AUTO_INCREMENT,
    sensorID int NOT NULL,
    time datetime NOT NULL,
    value double NOT NULL,
    PRIMARY KEY (measurementID)
)

Это очевидно неправильно — имел удовольствие несколько лет подряд наблюдать за эволюцией небольшой SCADA-системы, где хранение данных организовали примерно так. Пока датчиков было немного — оно работало, но примерно на сотне-другой обновляющихся примерно раз в 5-10 секунд датчиков потребовало для работы некоторых костылей. Для начала — в БД перестали записывать «небольшие» изменения данных — скажем, меньше 5% (величина была выбрана довольно произвольно — не надо спрашивать, соответствует ли такой подход требованиям технического задания :) ) от предыдущего сохраненного значения. Затем — по мере накопления данных соорудили чудовищную систему из триггеров и хранимых процедур, которая автоматически создавала «архивные» таблицы сравнительно небольшого размера. Впоследствии, конечно же, выяснилось, что эта система временами глючит и иногда новую таблицу для архива надо создавать вручную.

Наконец, на одном из объектов в дополнение к привычным «медленным» газоанализаторам поставили два десятка акселерометров — и тут все повалилось уже серьезно. Во-первых… нет, для начала в нулевых. Не надо говорить мне, что datetime в SQL неспособен хранить данные с «разрешением» меньше секунды, а опрашиваемый раз в секунду акселерометр бесполезен — тут речь шла уже о том, чтобы записать в базу хоть что-то. А теперь во-первых — показания акселерометров меняются сравнительно быстро и под фильтр «небольших» изменений данных не подпадают, и во-вторых — отказы БД стали чуть ли не ежесуточными. Считайте сами — в сутках 86400 секунд, и при двух десятках пишущих что-то датчиков мы влегкую получаем 1,7 миллиона записей в сутки. Да, часть из них отфильтруется — но и миллиона строк хватит, чтобы популярные СУБД с SQL хорошо и надежно «легли».

Признаться, я списывал многое из этих проблем на невысокую квалификацию разработчиков этой системы, но после доклада Сергея Аксенова “Антипаттерны разработки программных комплексов для интернета вещей” на Inothings++ понял, насколько героические люди используют SQL для хранения такого рода данных. Про выбор СУБД в видео — с 4:28:

Идея понятна — реляционные СУБД расчитаны на количество строк порядка миллионов (десятков миллионов — если у вас поблизости есть грамотный администратор баз данных), а как легко посчитать — это всего лишь суточный архив сравнительно небольшой системы. Впрочем, случай «Стрижа» еще более-менее прост — частота опроса каких-нибудь ЖКХшных счетчиков относительно небольшая, всего несколько раз в сутки. А что делать, если хочется хранить, скажем, данные по 16 каналам АЦП с небольшой в общем-то частотой дискретизации в 16 тысяч выборок в секунду? Нет, я прекрасно представляю, как это сделать «на файлах», и это совсем не сложно — простенький формат хранения данных можно полностью реализовать за неделю неспешной работы (собственно, что-то наподобие edflib, но работающее на микроконтролере с сотней килобайт памяти я написал в прошлом году где-то за несколько дней):

Implementing EDF takes a week. EDF+ takes a few weeks but is better and more powerfull. If you still decide to start with EDF, it is wise to adopt the 12 simple additional EDF+ specs.

Не смотрите, что он предназначен для записи всяких физиологических данных — я в таком виде пробовал всякие обороты двигателя, расход воздуха и прочее время впрыска записывать, они в этот формат прекрасно вписываются :)

Еще из полезного чтения — статья Luca Deri о системе, названной им tsdb — построенной поверх Berkeley DB системе, обеспечивающей хранение миллионов (!) временнЫх рядов (time series — собственно, это общее название для такого рода данных). Решение не совсем подходящее для моего случая — но опять же содержащее несколько полезных идей.

Для начала — система, многократно превосходящая по производительности решения на основе SQL, реализована всего лишь в 1000 или около того строк кода на Си. Именно это и вдохновило меня на написание собственного решения — 1000 строк это совсем немного, а следовательно, должно быть довольно просто. Второе — данные желательно каким-либо образом объединять — если в tsdb это сделано довольно произвольным образом (в базе много редко обновляемых временных рядов), то в моем случае я просто решил писать «секундные» (или соответствующие какой-то доле секунды) записи, как в EDF.

В общем, осознав эти «три источника и три составные части», я взял пивка и засел за Visual Studio — и примерно за вечер написал прототип базы данных, оптимизированной под мои требования — десятки-сотни одновременно записываемых временных рядов с частотой дискретизации от единиц до тысяч Гц. Собственно, по факту получился тот же EDF, только записанный в Berkeley DB. Выбор довольно произвольный (прежде всего — ее используют в tsdb) — но эта, так сказать, «встраиваемая СУБД» поразила меня своей простотой. Немного не радует лицензия — хотя при желании могу выложить код на какой-нибудь гитхаб для очистки совести.

Что могу сказать? Не прилагая никаких усилий в части оптимизации, на собственном ноутбуке я «из коробки» получил скорость записи в базу данных около 40-50 Мбит/с (похоже, упираясь в производительность жесткого диска) — причем, судя по всему, падения производительности с ростом числа записей в БД не происходит. Например, в БД размером около 11,5 Гб — это чуть меньше 1,5 миллионов записей по 8 килобайт (в каждой из записей — по 4000 «точек», каждая из которых — двухбайтовое целое) никакого снижения скорости записи или чтения я не наблюдал (дальше просто стало жалко жесткий диск). Что забавно — тесты «на чтение» демонстрируют полезность кеширования — сначала 10 000 записей читаются за долгие 8 секунд, а затем, если повторить тот же тест «не отходя от кассы» — за 0,22 секунды. Не видел бы — не поверил.

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

PS А если вам все же нравится SQL — почитайте, как правильно организовывать хранение time series в реляционной БД:

https://blog.timescale.com/time-series-data-why-and-how-to-use-a-relational-database-instead-of-nosql-d0cd6975e87c

И все-таки хочу напомнить, что решение «на коленке» практически не уступает приведенному в статье по ссылке в плане производительности (и да, надо бы проверить его с четырехгигабайтным кешем :) ).