Все слышали понятие "база данных" - некоторая совокупность структурированных данных о каком-либо предмете. Кроме него есть другое понятие - "база знаний". В современной it терминологии есть двойственность: базами знаний называют как wiki - подобные справочные системы, так и то, чем они являлись изначально: хранилищами правил обработки информации. Предельное развитие таких баз знаний - экспертные системы.

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

Разработать экспертную систему относительно несложно, но очень трудозатратно.

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

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

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

Подобные системы позволяют делать многое, например работать ассистентом врача. Недобросовестное отношение при разработке может приводить к катастрофическим последствиям: достаточно вспомнить эпидемию опиатных смертей в США, которая произошла по причине сговора создателя экспертной системы и фарм-компании.

Eshu Marabo

Диссертационный проект - это ПО для микроскопа. Нужно на лету обрабатывать поток изображений, представленных в виде массивов чисел (double). Одно из потенциальных узких по производительности мест - скорость копирования данных из массива в массив.

Для того, чтобы определить оптимальный способ копирования, плюс померять некоторые другие параметры я использовал инструмент BenchmarkDotNet 0.12.1. На картинках представлены результаты замеров для массива размером 1000х2000.

По таблицам в иллюстрациях:
CreateNew - замер скорости создания массива
AllItemIter - замер скорости обхода всего массива с присвоением значений.
Clone - замер скорости копирования всего массива с сипользованием стандартного метода Clone()
CopyByItem - замер скорости копирования всех элементов в созданный пустой массив с автоопределением размеров массива
CopyByItemExistSizes -замер скорости копирования всех элементов в созданный пустой массив без автоопределения размеров массива

Недавно вышел релиз платформы .Net 5.0, проводил замеры для нее и прошлой версии - .Net Core 3.1.

Итого, результаты теста:
1. Клонирование массива - самый быстрый вариант. При переходе с .Net Core 3.1 на 5 версию его ускорили в 3(!) раза!
2. Автоопределение размеров массива с помощью метода GetUpperBound() - плохая идея, пустая трата вычислительных ресурсов.
3. При переходе на новую версию в принципе все действия над массивами были чуть ускорены.

Код бенчмарка прикладываю в файле ниже.
#csharp #диссер

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

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

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

Специалисты по анализу данных универсальны: математическая подготовка и используемые инструменты более-менее универсальны во всех областях. Сегодня дата-саентист работает с рентгеновскими снимками, завтра делает систему ориентирования робота в пространстве. А суперкомпьютеру, на котором он экспериментирует вообще все равно что считать.

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

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

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

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

Так что будущее мне видится в слиянии двух подходов — человеческого и машинного.

Eshu Marabo

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

Постараюсь выжать из шарпа по-максимуму, но пока вдалеке мне видится кошмарная глыба С++ надвигающаяся на меня.

О пользе нормального DevOps, точнее о вреде его отсутствия.

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

Если сообщение - пересланное (т.е. свойство ForwardFrom у него не пустое), вызываем функцию пересылки и пересылаем его. Добавил минуты за полторы. А потом началось веселье. Мои боты стоят на линукс сервере, там же PostgreSQL, к которой они цепляются. Ботов, которыми пользуются люди, как бы "прод", я обновляю простеньким скриптом для командной строки на 20 строчек.

В какой-то момент я утратил последнюю версию скрипта и откладывал это обновление три (!) недели, т.к. писать скрипт с нуля - часов 5 рабочего времени, накатывать обновление руками - вообще непонятно сколько, т.к. что-то обязательно забудешь, после чего последует долгое восстановление.

И вот нашелся скрипт и обновления и фиксы стали накатываться сразу после проверки локально. А не поленился бы я научиться настраивать CD/CI - например Github Actions - проблем бы не было вообще: все проверки и автодеплой запускались бы из моего аккаунта на Github.

Немного погрузился по работе в малость подзабытые нейросети. Оказалось, что за два года, которые прошли с момента, когда я изучал их, мои знания малость протухли.

Появилась новаях архитектура сетей - transformer. Буду разбираться.

Я конечно знаю, что IT развивается стремительно, но не настолько же. Как калейдоскоп фреймворков на js для фронтэнда блин.

​​Язык машины

Мы продолжаем писать о практических применениях машинного обучения и том, что скрыто под его "капотом".

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

Всё это относится к огромной дисциплине NLP Это natural language processing, то есть "обработка естественного языка", а вовсе не псевдонаучное "нейролингвистическое программирование".

NLP появилось примерно тогда же, когда первые ЭВМ: очень заманчиво отдавать команды компьютеру на родном языке. Даже в те лохматые времена уже были первые "алисы", способные корректно обработать абстракции и нелогичности в нашей речи. Однако, катастрофически не хватало вычислительных мощностей и математического аппарата, равно как его общедоступных реализаций.

Примерный путь был понятен чуть ли не с XIX века: словам с близкими значениями присваивать близкие численные аналоги, после чего естественный язык становится более-менее доступным для формального анализа.

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

Большой прорыв случился в 2013 году, когда никому неизвестный на тот момент чешский аспирант Томаш Миколов предложил новый подход к представлению слов в численном виде: учитывать не только значение самого слова, но и набор ближайших к нему слов. Мы видим к чему это привело через семь лет.

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

Для применения в каких-либо "общеязыковых" задачах и анализу текста на русском литературном языке всё готово. Открываем Google Colaboratory, скачиваем датасеты, открываем хабр и чувствуем себя настоящим специалистом по данным. А вот небольшой шажок в сторону — например анализ специфического сленга или терминов потребует существенно больше усилий.

Eshu Marabo

Ну чтож, продолжаю тему производительности диссертационного проекта.

Я пишу программу для записи изображений с микроскопа. Цель - иметь возможность писать поток в 2 мегапикселя в реальном времени (захват изображения камерой, несложные математические преобразования ™, вывод на экран).

Пока потолок - около 2-4 FPS на приличном компьютере. Цель - 25.

Упёрся в узкое место: скопипащенный кусок на С отрабатывает за 0.5 секунды минимум, а применять его нужно к каждой картинке.

Вывод: параллелить, а то и вообще выносить вычисления на видеокарту. На С я пока не готов к таким подвигам, потому для начала реализую алгоритм на c#, оптимизирую по максимуму и посмотрим, нужно ли будет что-то менять.

Соответственно, в следующем сообщении выложу статью с описанием алгоритма.

#диссер
#csharp

Herráez, M. A., Burton, D. R., Lalor, M. J., & Gdeisat, M. A. (2002). Fast two-dimensional phase-unwrapping algorithm based on sorting by reliability following a noncontinuous path. Applied Optics, 41(35), 7437. doi:10.1364/ao.41.007437

Нас ждёт увлекательное путешествие в мир векторных инструкций (SIMD, возможно - вставок ассемблера в С#, или, как крайняя мера - знакомство с CUDA или OpenGL).

Будет весело и страшно больно и познавательно, не переключайтесь.

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

P.S. Адские звуки на фоне - это кот, а не кристаллизация воды в бутылке.

Реализовал алгоритм из научной статьи на c#. Получилось далеко не сразу: на первый взгляд адекватное описание в статье оказалось сложнореализуемым и несколько расходилось с кодом, выложенным на гитхабе.

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

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

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

В оптимизации процедуры развертки фазы для микроскопа ч дошел до предела, который позволяет c# без использования магии: проигрыш в 2.7 раз относительно чистого с.

Для достижения этого результата мне пришлось убрать из постоянно использующегося кода конструкторы примитивных объектов для хранения данных. Отказ от создания объектов для хранения промежуточной информации в пользу их обновления дал почти двукратный (!) прирост производительности, сократив разрыв отставание от чистого С с 5 раз.

С чем связано сохранение такого разброса затрудняюсь сказать, чисто в теории скорости должны быть намного ближе. Языки программирования можно разделить на компилируемые и интерпретируемые. Компилируемые при сборке выдают сразу файл, напрямую исполняемый в ОС. В интерпретируемых языках код компилируется в набор команд для виртуальной машины, которая берет на себя взаимодействие с железом. Именно таким языком является C#.

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

С# в любом случае несет какие-то накладные расходы на функции, взятые из CLR (виртуальная машина платформы .Net). Кроме того, в C почти все манипуляции в коде осуществляются на уровне указателей.

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

У меня остается узкое место - сортировка здоровенного одномерного массива (примерно 4 млн элементов). Изначально, как в реализации на С, так и в методе, предлагаемым в для сортировки в С# используется алгоритм быстрой сортировки (quicksort), как один из наиболее шустрых. У меня на сортировку массива уходит до 40% всего времени.

Пришло время заменить его на хорошо распараллеливаемый алгоритм сортировки слиянием и начать распараллеливать вообще всё.

#csharp #диссер

Одна из важнейших научных новостей конца года - принято решение о слиянии двух ключевых фондов, осуществляющих финансирование российской науки: РНФ (Российский научный фонд) и РФФИ (Российский фонд фундаментальных исследований). Решение получило, мягко говоря, противоречивую оценку от научного сообщества.

Опишу в двух словах, как работает финансирование российской науки. Деньги могут прийти или от организации, в которой работают ученые, или от отраслевого министерства (Минсельхоз, Минобрауки, Минздрав) или от федерального фонда — РНФ или РФФИ. Деньгами на науку могут распоряжаться и другие организации, но на фоне вышеназванных это мелочи.

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

РНФ — только крутые команды, ценз на набор публикаций, необходимых для подачи заявки и отчетность, там совершенно конский. И только РФФИ занимается сбросом небольших "вертолетных" денег на российскую науку. Гранты у РФФИ небольшие, их не хватает на полноценное содержание научного коллектива и проведение исследований. Но получить их относительно просто, чтобы отчитаться достаточно просто что-то делать, прорывных успехов они не требуют.

Именно РФФИ позволяет не разбежаться коллективам, которые по каким-то причинам остались без постоянного источника денег. При слиянии обещают сохранить всё лучшее из того, что было, но зачем трогать то, что прекрасно работает и выполняет свою роль, сложившуюся исторически? Да и сомнительно, чтобы сброс "вертолетных денег" на науку относился к лучшим практикам по мнению министерства.

Eshu Marabo

Начал оптимизировать сортировку в своем диссертационном проекте, всплыла прекрасная иллюстрация такого понятия как вычислительная сложность алгоритма.

Тестовый массив - 4 миллиона элементов (классов, содержащих поле типа double, по которому и осуществляется сортировка).

Проверил четыре варианта сортировки массива:
1. Стандартный метод Array.Sort, предоставляемый c# из коробки (под капотом там quicksort O(n*log(n)), как писал выше). Результат - 2.2 секунды
2. Нагугленная реализация quicksort O(n*log(n)) для c#. Результат - 2.7 секунды
3. Нагугленная реализация сортировки вставками O(n^2) . Результат - бесконечность, за 45 минут не отсортировалась даже половина массива, я остановил тест.
4. Нагугленная реализация сортировки слиянием mergesort O(n*log(n)). Результат 4.08 секунды.

Уже из этих цифр видно различия в вычислительной сложности: n^2 по сравнению с n*log(n) начинает проигрывать просто феерически. И да, такой массив - это обыденность: по объему данных это примерно две картинки в full hd.

Выигрыш метода Array.Sort у простой реализации быстрой сортировки "в лоб" заслуживает отдельного внимания, обязательно залезу в исходный код .Net Core и расскажу чем он отличается.

#csharp #диссер

Продолжаю про оптимизацию сортировки массива в диссертационном проекте.

Более-менее успешно распараллелил сортировку: использовал нечто гибридное. Массив разделяется на несколько частей, каждая сортируется параллельно, после чего сливаются во едино функцией Merge из реализации сортировки слиянием из прошлого поста (п. 4).

Результаты меня несколько огорчили. Рост про производительности бесспорно есть. Время обработки сократилось с 2.2 секунд до 1.5 с использованием двух потоков. При этом, с ростом числа потоков, скорость растет на какие-то смешные значения, а то и падает за счёт того, что приходится ждать запаздывающие потоки.

Фантастический сюрприз поджидал меня далее. Я сортирую массив объектов по одному из полей с типом double. При этом используется стандартный инструмент для сравнения пользовательских типов данных внутри метода Array.Sort - реализация интерфейса IComparer. По сути, в сортировку передается функция, с помощью которой можно сравнивать экземпляры сортируемых классов.

Я решил посмотреть, сколько будет сортироваться массив моего размера (4млн) double. 0.08 секунды, почти в 25(!) раз быстрее. Теперь думаю, как по-ловчее перевести алгоритм на такую сортировку.

#csharp