Небольшое уточнение к прошлому посту. В мои замеры прокралась ошибка, на самом деле среднее время сортировки массива из double-ов составляет 0.37 секунды.

Несмотря на это, шестикратная разница в скорости - это тоже неплохо.

Кроме того, у метода Array.Sort есть перегрузка, которая предлагает сортировать один массив относительно другого. Замерял её производительность, вынеся поле, по которому сортирую в отдельный массив. Результат - 1.1 секунды. Т.е. простой вынос поля, по которому осуществляется сортировка в отдельный массив и отказ от использования реализации IComparer там, где это не нужно, уже дает двукратный рост производительности.

Интересно, получится ли выдавить бОльший рост какими-либо другими манипуляциями?

#csharp

с новым годом :)

Итого подошла к концу эпопея с оптимизацией реализации алгоритма развертки фазы, написанного на с#. В качестве эталона используется реализация на чистом С, скопированная из репозитория библиотеки sklearn-image.

Итог оптимизации: производительность на С и С# практически сравнялась, теперь я отстаю примерно на
20% вместо 400% в начале пути.

Произведенные манипуляции:
1. Обновление классов вместо их пересоздания. Подробнее - тут

2. Использование встраиваемых функций. Встраивание - процедура, обратная разбиению кода на отдельные функции для повышения читаемости. Такие функции я пометил как встраиваемые (inline), чтобы компилятор вставил их содержимое в байт-код вместо простого вызова. Подробнее - тут, 7й раздел.

3. Правильное использование сортировки. Узким местом в алгоритме являлась сортировка массива, размером равного удвоенному числу пикселей.

После долгих экспериментов с сортировкой, я сделал две вещи:
А) вынес поле сортируемых классов в отдельных массив и использовал сорировку "по ключу" - т.е. сортировал один массив по данным из другого.
Б) Раскопав код коробочного метода сортировки я обнаружил, что он отлично работает на массивах с повторяющимися значениями. Потому я округлил используемый мной параметр до третьего знака (задача позволяет), в результате чего выгадал ещё процентов 30 скорости сортировки. Про эту реализацию Быстрой сортировки напишу отдельно.

Итого, я разогнал FPS своего приложения до 8 на 2 мега пикселях. Немного поколдовать над интеграцией с Arduino и им можно пользоваться. SIMD и другие оптимизационные шаманства оказались неприменимы, единственное, откуда я могу получить рост производительности - распараллеливание.

Я уже получил levelup и кучу экспиренса, но задача - преобразование картинки в реальном времени - не решена. Я алгоритм конечно распараллелю, но появилась новая вводная - 5 мегапикселей, потому следующий большой пункт назначения - CUDA.

#csharp #диссер

Обещанный пост о вариации быстрой сортировки, использующейся в c# в коробочном методе Array.Sort.

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

Над половинками рекурсивно проводится та же операция, до тех пор, пока массив не отсортируется.

Нашел реализацию в репозитории Майкрософт с прошлой версией .Net. Ниже прикладываю вырванный оттуда рабочий кусок кода.

На первый взгляд он выглядит диковато: каскад из двух операторов do... while и двух простых while являются антитезой понятия "читаемый и понятный код".

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

Программисты Microsoft таки едят хлеб недаром.

#csharp

Хотел бы внести корректировку к ранее опубликованными цифрам по FPS в моем приложении. У меня была ошибка в счётчике кадров в секунду.

Реальные значения FPS сейчас что с использованием С, что с использованием новонаписанного кода на С# колеблется в диапазоне от 1.05 до 1.25 кадров в секунду.

Сортировка на массиве случайных чисел выполняется около секунды + выполняется несколько других операций. То есть FPS 1 и выше кажется невозможным в теории. В реальности массив у меня частично отсортированный, потому сортировка занимает 0.2-0.3с, что и делает возможным обрабатывать один кадр в секунду.

Кроме того, целевое значение FPS у меня не 25, а 6-8, т.к. одно изображение у меня получается из 3 или 4 кадров с камеры.

Перепроверил и остальные цифры, публикуемые мной в канале, там все четко.

#csharp #диссер

Наткнулся сегодня на интересную особенность работы .Net на разных процессорах.

Один из самых простых способов параллелизовать операцию над последовательностью - использовать библиотеку Parallel, метод For. Операция будет выполнена, как и в обычном for, но параллельно, в разных потоках. Балансировкой нагрузки занимается сама CLR.

У меня было:
1. Операция над массивом из 4млн элементов, с глубоким путешествием по полям классов, составляющих массив. То есть что-то типа elements[i].inner_field.field.value. Выпоняю сложение и округление.

2. Три процессора:
Core i3 (3.6 гГц, 4 ядра)
AMD Ryzen (3.6 гГц, 6 ядер)
Core i9 (8 ядер, 3.6 гГц)

Результаты при параллельном запуске:
i3: 0.08с
AMD: 0.4с
i9: 0.03с

При запуске в один поток, на всех процессорах время примерно одинаковое - около 0.35 с.

Что за чертовщина, с чего AMD проигрывает i3 в 5 раз - не понятно. Буду искать объяснение или решение (отличное от "забить"), если найду - поделюсь.

#csharp

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

А если серьезно - создатели Libgen очень круты. И их полная открытость (код приложения, код сервера, все бэкапы и весь контент в свободном доступе) - это мега круто.

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

Дожили.

Я однажды отправлял в Италию титановую болванку, чтобы нам станок на ней испытали после сборки.
Выбрали цилиндрическую болванку, подготовили доки, отправили, приходит ответ от ФТС: "не пропускать - похоже на заготовку для изготовления оружия", делайте её не цилиндрической
Поставили болванку на станок, стесали лыски, стала квадратная в сечении. Таможня опять не пропустила с тем же результатом.
Короч пока мы эту болванку по форме не превратили в нечто, похожее на фантазии Малевича, таможня писала "а может из этого итальянцы сделают пушку, и будут ею в нас стреляти?"

Летом я думал: c# я в принципе знаю, наверное надо учить Go, он модный, молодежный и параллельный. Не сложилось.

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

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

Вот использование ассемблерных команды из c# - для меня пока слишком.

Ещё разобрался с запуском вычислений на видеокарте из c# - с проектом ManagedCUDA. Главная моя надежда - что не придется писать код для CUDA на специфическом диалекте C не оправдалась, но средствами Visual Studio разработка и запуск проекта на двух языках осуществляется довольно удобно.

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

В поисках готовой реализации двумерного фурье преобразования, я нашел проект AForge - реализации различного матана на c#. Проект, хоть и написан по какую-то допотопную версию .Net крут: вырванный копипастой кусок, относящийся с Фурье преобразованию, просто взял и заработал. Время отработки на картинке 1024х2048 - около 1 секунды. Вырванная реализация работает только на картинках с размером, кратным степени двойки.

Теперь мне предстоит переварить копипасту: разобраться в принципе работы алгоритма, выкинуть лишнее, оптимизировать оставшееся. Появилась идея со временем выкинуть весь матан, как на c#, так и на CUDA в отдельный проект и в NuGet пакет (стандартное средство распространения готовых модулей и библиотек для c#) в свободный доступ, глядишь кому пригодится.

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

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

Использование массива с размерами, кратными степени двойки - один из основных читов, которые используются, чтобы получить результат максимально быстро. Что интересно - в одной из научных статей, посвященных фазовой микроскопии, все тесты алгоритмов, основанных на FFT2 проводились на картинках размером 1024x2048.

#диссер #csharp

​​В диссертационной работе мне нужно записывать картинки с микроскопа с помощью цифровой камеры. Изначально отладка и сборка прибора проводилась с помощью веб камеры за 500 рублей, кое-как приделанной к прибору.

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

Следующим этапом была испытана камера производителя dcm. После долгих мучений с неработающими и конфликтующими драйверами обнаружилось, что работает она только с довольно убогим штатным ПО, исходный код которого разумеется недоступен.
Как с ней работать - не очень понятно. Нашел на гитхабе один проект, где люди как-то работают с такой камерой, но он на питоне, а я пишу на c#. Переписывать код по-обезьяньи — дело не слишком благодарное, в общем отказался от неё.

Сегодня попробовал камеру от производителя toupcam. К камере прилагается штатная прога, несколько уже скомпилированных .dll-ок под разные системы и папочка Samples, где приведены примеры забора изображения с помощью разных языков программирования. Открываешь пример через среду разработки, подкидываешь .dll-ку под свою систему, запускаешь и оно РАБОТАЕТ. Вот, что значит - SDK (инструменты разработчика) здорового человека.

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

Eshu Marabo

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

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

Повторить процедуру выделения лимфоцитов по готовому описанию - непросто. А за составленным "протоколом" - тем самым описанием - многие человекогоды лабораторной практики.

Часть реагентов нужна чтобы кровь не свернулась, часть - чтобы клетки не растворились в непривычной среде. На центрифуге правильно отработанная кровь расслаивается по фракциям: эритроциты, лимфоциты и т.д.

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

Только после таких манипуляций можно собрать в пипетку несколько микролитров лимфоцитов. И ведь можно ещё их красить, добавлять флуоресцентные маркеры или вообще сортировать на виды лимфоцитов.

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

Eshu Marabo