Новости Отчёт mj за сентябрь по разработке и интеграциям

Тема в разделе "Новости", создана пользователем Mr. Pickles, 23 окт 2021.

  1. Mr. Pickles

    Команда форума Модератор Редактор

    Регистрация:
    11 сен 2017
    Сообщения:
    995
    Симпатии:
    249
    Уважаемое сообщество!

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

    Я занимался обычным исправлением CI, а также провёл несколько минимальных оценочных анализов. Но я уверен, что самой яркой работой месяца станет моя обновлённая страница по отслеживанию состояния, опубликованная по этому адресу: http://cryptog.hopto.org/monero/health. Я потратил какое-то время на добавление отсутствующих точек данных, чистку данных в тех местах, где что-то шло не так, как запланировано. В результате были получены более значимые кривые. Мною также был изменён скрипт строк кода (LOC), и теперь отображается количество строк заголовка относительно исходных строк. Чем меньше отношение, тем короче (пере)компиляция, а также объём памяти, необходимый для компиляции. Последнее очень важно для SoC устройств с небольшим объёмом RAM. Это связано с моей работой с пользователями RPi, пожелавшим скомпилировать Monero для своей любимой платформы.

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

    1.jpg

    А теперь, пожалуйста, взгляните на два приведённых ниже графика применения инструментов: LOC и заголовки служат двумя вводными и должны повлиять на время компиляции и объём необходимой памяти (на два результата). Рефакторинг заголовков всегда будет приводить к снижению вводных графиков. А значит, самые «медленные» заголовки, если они будут правильными, согласно отчёту CBTA, будут подвергнуты рефакторингу, и теоретически время компиляции и объём необходимой памяти снизятся. Вот вводные графики:

    2.jpg

    3.jpg

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

    4.jpg

    5.jpg

    Как видно, практически* как только я начал производить рефакторинг заголовков, оба показателя начали снижаться (практически*, потому что у меня не было доступа к отчёту CBTA с самого начала). Но затем снова, поскольку соответствующие ветви перестали объединяться, в результатах можно наблюдать не только стагнацию, но даже регрессию, что коррелирует с регрессией вводных. У меня по-прежнему имеются открытые ветви (6934 и 6932), ожидающие анализа и слияния. И даже несмотря на то, что задача, связанная с анализом, не представляется относительно сложной, такой вид улучшений, к сожалению, в данном случае откладывается. Со своей стороны я бы мог предложить ещё много таких улучшений, но в данный момент это только переполнит список ветвей. И поэтому я не стану открывать их до тех пор, пока не произойдёт слияния двух указанных выше ветвей.

    Есть ещё пара вещей, которых следует коснуться, когда речь заходит о графике памяти. Существует две пары последовательностей: одна касается выходного кода с тестированием, а другая — без тестирования. Поскольку ограничения, связанные с объёмом памяти, как правило, сильнее ударяют по пользователям SoC, их будет больше волновать выходной код и определённо не тесты, так как они не захотят, чтобы их машины использовались для разработки, что ведёт к разделению. Видно, что тестирование подразумевает наличие более высоких требований, и сам по себе выходной код не сильно отстаёт в этом плане. Если взглянуть на максимальный показатель потребления RAM (который, по сути, является средним показателем для 4 самых больших файлов — см. здесь), видно, что объём по-прежнему настолько велик, что уже компиляция кода на одном ядре (из 4 файлов) 2 Гб Rpi4 приведёт к некоторой задержке в подкачке. Другие пользователи подтвердили на IRC, что компиляция может «подвесить» их операционные системы, если при этом использовать все ядра. Я также добавил средний показатель потребления RAM, поэтому любая оптимизация RAM будет отражаться, по крайней мере, на графике среднего потребления, если оптимизация не будет влиять на любой из 4 самых больших файлов.

    Ветви

    Ниже приводится обычное краткое описание объединённых и новых ветвей.

    Новые ветви
    • Rpi4: целевая версия rpi для NO_AES rpi4-64bit. @ArqTras были проведены некоторые исследования по возможности компиляции Monero для RPi с 64-битной операционной системой. После анализа и тестирования мне пришлось открыть собственный запрос PR, чтобы избежать некоторых вопросов этого автора.
    • Rpi4: распределение двоичных файлов без использования AES в случае с 64-битными операционными системами. Рабочая концепция компиляции вышеуказанного варианта на нашем CI и попытка распределить вариант любых других официально поддерживаемых выполняемых файлов. После довольно долгого обсуждения @hyc предложил создать специализированную 64-битную проверку RPi (для AES), которая бы делала эти действия избыточными. Я полностью согласен с тем, что в текущих обстоятельствах это было бы хорошим решением.
    • Документация: построение gtest на базе Debian и Ubuntu. Обновление документации от @ralphmapper, а также её редакция и внесение исправлений мной. Мне пришлось открыть собственный PR точно по тем же причинам, что и в случае с первой ветвью.
    • CI: переменные общие настройки ccache и чистка apt. Существовал набор настроек ccache, задаваемых посредством env vars и командной строки. Данный PR унифицирует эти настройки и позволяет повторно использовать их в качестве переменной. Также проведена небольшая чистка настроек apt.
    • CMake: Добавление отсутствовавшей опции SANITIZE. Пытаясь помочь @selsta с воспроизведением ошибки памяти, я заметил, что опция SANITIZE не появляется во внешнем пользовательском интерфейсе CMake, как ccmake или cmake-qt. К сожалению, мне не удалось воспроизвести оригинальную ошибку. Возможно, это была специфичная для Mac ошибка.
    Обновления
    • Ledger: членский 'режим' заслонял режим базового класса. Мною был проведён надлежащий статистический анализ, который позволил понять, не приведёт ли моя «чистка» к каким-либо побочным эффектам, а также подготовлен PR для публичного ознакомления.
    Заключительные слова по данному периоду

    Мне хотелось бы поблагодарить всех за отзывы, сотрудничество и финансирование. Как было написано в самом начале, мне придётся продлить рабочий период по причинам, связанным с реальной жизнью. Они завершены только наполовину, поэтому мне придётся сделать перерыв в этом месяце и в ноябре, и я искренне надеюсь снова полноценно заняться работой, начиная с декабря. До тех пор я буду выполнять свои обязанности и поддерживать свои ветви, отвечая рецензентам и постоянно публикуя отчёты о собственном здоровье. Последнее более не потребует от меня особых усилий после той работы, которая была мной проделана в этом отношении, и я буду делать (что?), пока у вас не будет особых возражений :) Спасибо за всё,

    mj

    ---

    Источник: Dev report Sep. 2021

    Перевод:
    Mr. Pickles (@v1docq47)
    Редактирование:
    Agent LvM (@LvMi4)
    Коррекция:
    Kukima (@Kukima)
     
  • О нас

    Наш сайт является одним из уникальных мест, где русскоязычное сообщество Monero может свободно общаться на темы, связанные с этой криптовалютой. Мы стараемся публиковать полезные мануалы и статьи (как собственные, так и переводы с английского) о криптовалюте Monero. Если вы хорошо владеете английским (или можете писать собственные статьи/мануалы) и хотите помочь в переводах и общем развитии Monero для русскоязычной аудитории - свяжитесь с одним из администраторов.