Насколько я понял из статьи, эти алгоритмы не дают никакого улучшения для общего случая, т.е. когда все элементы различны.
Ну и для таких случаев обычный алгоритм будет как правило оптимизирован в техническом плане: будут учтены кэши памяти, предзагрузка, порядок элементов. Алгоритмы же, нарушающие последовательный доступ, на практике будут только снижать производительность, иногда весьма значительно.
Здесь сборка, по одному файлу на операцию (компиляцию), который влазит в кэш. Так что никакой когерентности нет, если считать с момента после препроцессинга.
Вы не учли, что как раз здесь нагрузка вполне себе подходящая, при отсутствии ограничения сверху по тепловыделению все ядра были бы загружены полностью - это гарантированно, ведь даже на 96-ти ядрах без ограничений проект собирается 16 минут.
Дело в том, что, насколько я успел ознакомиться с архитектурой этого решения, память там:
Многоканальная
Используется экстремально широкая шина данных
К тому же проц имеет гигантские кэши (в подходе SMP они локальны для каждого ядра), в которые обычные файлы исходников помещаются целиком. Хотя я согласен, кончено, что доступ к памяти в подавляющем большинстве приложений - более узкое место, чем числомолотилка.
У меня возникло ощущение, что автор как-то смешивает части MVC и бизнес-логику - ошибка, которую я допустил на 2-м курсе ИТ-факультета. В одном предложении у него и MVC, и бизнес-логика. Тут не надо смешивать. MVC (и подобные), вместе с V и C - полностью про ui, бизнес-логики там вообще нет. Так что просмотрел дальше по диагонали, что-то намешано разного в кучу - такое впечатление складывается.
Да, судя по всему именно на памяти они и экономят, всё остальное стандартно К слову, libbionic тоже изначально на минимум памяти рассчитывал, но сейчас у них там вроде компромиссный аллокатор в тренде (согласно Википедии).
Хм, вообще-то проблема не в том, что версии не совпадают, а в том, что программа сыпется. Какие бы версии либ там ни были, падать не стоит. Не совпадает версия - ну не загрузили и всё. Собственно так и было задумано: либа грузится с помощью dlopen, динамически, и если не загрузится - мы пробуем другую (libQt6Core.so). Но такой расчёт не принял во внимание бажность самого загрузчика, да он и сам от себя такого не ожидал - я же писал, что он не определил, что находится в невалидном состоянии. ПС когда так ведёт себя ядро мы видим, что происходит: бесконечные синие экраны смерти порядком надоедали в старых версиях винды (98-я, например, да и Хр). Да и линуксы с кернел паник тоже не радовали. Нормальный софт почти любую ситуацию долженразруливать корректно.
Как по мне, вообще удивительно, что резолвинг хоста как-то зависит от выбора стандартной библиотеки. По-моему, сетевых операций в либси не должно быть в принципе. Это отдельный стек, который не всегда востребован приложениями.
Исторически так сложилось, что я обитаю на федоре, и меня вполне устраивает за некоторыми исключениями. Для разработки до последнего времени также подходила, даже без регулярных апгрейдов. Да, тут есть конфликт необходимости новшеств для разработки и стабильности для обычной домашней системы. До сих пор это удавалось как-то решать с помощью виртуалок.
Я вот посмотрел сейчас более подробно на musl. Судя по всему он более современный и менее совместимый с приложениями-старичками. Тут таблица сравнения. Допустим мы ей верим. Тогда
Из неё видно, что например однобайтовые локали плохо мюсли поддерживаются, зато utf-8 свой родной. Ну и хрен бы, честно говоря, с этими старыми локалями. Линукс и все более-менее развивающиеся проекты давно перешли на utf-8, и правильно сделали. И то, что в glibc это работает медленно совсем не в её пользу.
Также лучшая обработка внештатных ситуаций, о чём собственно статья.
Вопреки тому, что утверждает @Apoheliy, ссылаясь на википедию, поддержка платформы PC-x64 вполне на уровне.
Очевидные недостатки: страдает regexp, и возможно, не хватает POSIX localedef; нет отладки, т.е. я не смогу лог добыть как сделал в данном случае. Хотя в случае glibc это пока что мало помогло.
В моём случае Хром собрал две обвязки для Qt5 и Qt6 (упомянутая out/default/libqt5_shim.so и libqt6_shim.so) с использованием локально поставленного в каталог исходников корня системы Дебиан, указав при сборке путь до этого корня (--sysroot=../../build/linux/debian_bullseye_amd64-sysroot). Т.е. сборка именно libqt*_shim.so была выполнена относительно выкачанной дебиановской системы. При этом основная сборка вроде всё-таки на системные либы полагалась, там где не собирала своё (а в хроме своих локальных версий много).
В том то и дело, что если ограничиться проверкой только входных данных, то внутреннее состояние не контролируется. Это работает, если либа идеальна и без ошибок. Но такого не бывает. Так хоть бы определяли ошибки на более раннем этапе. Я ведь так и не выяснил, где же был баг в загрузчике. Удовлетворился пока тем, что в версии 2.32 работает (но это не точно, вернее не точно, что всегда).
Насчёт systemd-nspawn, не уверен, что есть в федоре. Хотя вот есть некий systemd-container. Пока что я запустился в чруте с федора-33, не знаю, насколько это будет стабильно для хрома. Да и в самой 28-й системе вроде можно теперь запустить, если убрать причину сбоя - удалить libqt5_shim.so.
Насколько я понял из статьи, эти алгоритмы не дают никакого улучшения для общего случая, т.е. когда все элементы различны.
Ну и для таких случаев обычный алгоритм будет как правило оптимизирован в техническом плане: будут учтены кэши памяти, предзагрузка, порядок элементов. Алгоритмы же, нарушающие последовательный доступ, на практике будут только снижать производительность, иногда весьма значительно.
Здесь сборка, по одному файлу на операцию (компиляцию), который влазит в кэш. Так что никакой когерентности нет, если считать с момента после препроцессинга.
Вы не учли, что как раз здесь нагрузка вполне себе подходящая, при отсутствии ограничения сверху по тепловыделению все ядра были бы загружены полностью - это гарантированно, ведь даже на 96-ти ядрах без ограничений проект собирается 16 минут.
Дело в том, что, насколько я успел ознакомиться с архитектурой этого решения, память там:
Многоканальная
Используется экстремально широкая шина данных
К тому же проц имеет гигантские кэши (в подходе SMP они локальны для каждого ядра), в которые обычные файлы исходников помещаются целиком.
Хотя я согласен, кончено, что доступ к памяти в подавляющем большинстве приложений - более узкое место, чем числомолотилка.
Для проектов размера и типа Хрома - прирост почти линейный, если система позволяет. И видео по ссылке это в конце концов доказывает.
То есть вы предлагаете рендеринг делать быстро, а при сборке можно и двое суток по-вашему потерпеть?
У меня возникло ощущение, что автор как-то смешивает части MVC и бизнес-логику - ошибка, которую я допустил на 2-м курсе ИТ-факультета. В одном предложении у него и MVC, и бизнес-логика. Тут не надо смешивать. MVC (и подобные), вместе с V и C - полностью про ui, бизнес-логики там вообще нет. Так что просмотрел дальше по диагонали, что-то намешано разного в кучу - такое впечатление складывается.
Да, судя по всему именно на памяти они и экономят, всё остальное стандартно
К слову, libbionic тоже изначально на минимум памяти рассчитывал, но сейчас у них там вроде компромиссный аллокатор в тренде (согласно Википедии).
википедия в помощь
Хм, вообще-то проблема не в том, что версии не совпадают, а в том, что программа сыпется. Какие бы версии либ там ни были, падать не стоит. Не совпадает версия - ну не загрузили и всё. Собственно так и было задумано: либа грузится с помощью dlopen, динамически, и если не загрузится - мы пробуем другую (libQt6Core.so). Но такой расчёт не принял во внимание бажность самого загрузчика, да он и сам от себя такого не ожидал - я же писал, что он не определил, что находится в невалидном состоянии.
ПС когда так ведёт себя ядро мы видим, что происходит: бесконечные синие экраны смерти порядком надоедали в старых версиях винды (98-я, например, да и Хр). Да и линуксы с кернел паник тоже не радовали. Нормальный софт почти любую ситуацию должен разруливать корректно.
Как по мне, вообще удивительно, что резолвинг хоста как-то зависит от выбора стандартной библиотеки. По-моему, сетевых операций в либси не должно быть в принципе. Это отдельный стек, который не всегда востребован приложениями.
Исторически так сложилось, что я обитаю на федоре, и меня вполне устраивает за некоторыми исключениями. Для разработки до последнего времени также подходила, даже без регулярных апгрейдов.
Да, тут есть конфликт необходимости новшеств для разработки и стабильности для обычной домашней системы. До сих пор это удавалось как-то решать с помощью виртуалок.
Ну такая уж у меня система, полмесяца назад вообще была f24
Я вот посмотрел сейчас более подробно на musl. Судя по всему он более современный и менее совместимый с приложениями-старичками.
Тут таблица сравнения. Допустим мы ей верим. Тогда
Из неё видно, что например однобайтовые локали плохо мюсли поддерживаются, зато utf-8 свой родной. Ну и хрен бы, честно говоря, с этими старыми локалями. Линукс и все более-менее развивающиеся проекты давно перешли на utf-8, и правильно сделали. И то, что в glibc это работает медленно совсем не в её пользу.
Также лучшая обработка внештатных ситуаций, о чём собственно статья.
Вопреки тому, что утверждает @Apoheliy, ссылаясь на википедию, поддержка платформы PC-x64 вполне на уровне.
Очевидные недостатки: страдает regexp, и возможно, не хватает POSIX localedef; нет отладки, т.е. я не смогу лог добыть как сделал в данном случае. Хотя в случае glibc это пока что мало помогло.
В моём случае Хром собрал две обвязки для Qt5 и Qt6 (упомянутая out/default/libqt5_shim.so и libqt6_shim.so) с использованием локально поставленного в каталог исходников корня системы Дебиан, указав при сборке путь до этого корня (--sysroot=../../build/linux/debian_bullseye_amd64-sysroot). Т.е. сборка именно libqt*_shim.so была выполнена относительно выкачанной дебиановской системы.
При этом основная сборка вроде всё-таки на системные либы полагалась, там где не собирала своё (а в хроме своих локальных версий много).
В том то и дело, что если ограничиться проверкой только входных данных, то внутреннее состояние не контролируется. Это работает, если либа идеальна и без ошибок. Но такого не бывает. Так хоть бы определяли ошибки на более раннем этапе. Я ведь так и не выяснил, где же был баг в загрузчике. Удовлетворился пока тем, что в версии 2.32 работает (но это не точно, вернее не точно, что всегда).
аналогично
Тут есть нюансы.
Мне нужен именно свой хром, буду его ковырять. Хотя неофициальные образы тоже есть
Мне на период разработки всё-таки желательно с графикой чтоб было
Насчёт systemd-nspawn, не уверен, что есть в федоре. Хотя вот есть некий systemd-container.
Пока что я запустился в чруте с федора-33, не знаю, насколько это будет стабильно для хрома.
Да и в самой 28-й системе вроде можно теперь запустить, если убрать причину сбоя - удалить libqt5_shim.so.
А тут, между прочим, ещё один пример последствий отсутсвия проверок
Кстати, по поводу альтернатив Хабр тут вовремя предложил статью-сравнение мюсли и гну
https://habr.com/ru/articles/520920/