Компания Google перешла (http://blog.llvm.org/2018/03/clang-is-now-used-to-build-chro... на использование свободного компилятора Clang при формировании сборок браузера Chrome для платформы Windows, вместо ранее применявшегося компилятора Microsoft's Visual C++ (MSVC). Таким образом, начиная с Chrome 64 (https://www.opennet.me/opennews/art.shtml?num=47904) компилятор Clang теперь применяется для всех поддерживаемых платформ - macOS, iOS, Linux, Chrome OS, Android и Windows.
Из привлекательных сторон Clang для сборки Windows-приложений выделяется возможность сохранения совместимости с MSVC на уровне ABI, что позволяет собрать какую-то часть программы при помощи
MSVC, а другую часть при помощи Clang и затем скомпоновать их в один исполняемый файл при помощи компоновщика MSVC или LLD. Что касается сборки Chrome, то данный процесс полностью не избавлен от зависимости от Visual Studio и даже после перехода на Clang продолжает использовать заголовочные файлы и библиотеки Microsoft, а также применяет некоторые утилиты из SDK, такие как midl.exe и mc.exe. Также сохранена возможность разработки и отладки кода Chrome в среде Visual Studio IDE.В своё время перевод (https://www.opennet.me/opennews/art.shtml?num=41072) Linux-сборок Chrome на Clang в 2014 году позволил сократить размер исполняемого файла на 8% при сохранении производительности на том же уровне. Перевод Windows-сборок на Clang отразился в снижении размера установщика для 64-разрядных систем на 6.33%, но размер 32-разрядных сборок немного увеличился (на 0.04%). Например, итоговый размер mini_installer.exe для 64-разрядных систем при сборке при помощи Clang составил 46.27 MB, а при сборке в MSVC - 49.4 MB. При сборке в Clang размер chrome.dll уменьшился на 5.1%, а chrome.exe на 1.2%, но размер chrome_child.dll увеличился на 10.8%.
При включении оптимизаций на этапе генерации кода (LTCG) и учёта данных профилирования (PGO), Clang генерировал код немного большего размера для 64-разрядных систем при установке режима оптимизации "/O2". При выборе режиме "/Os" наоборот, код Clang получался более компактным, чем MSVC. При этом результат сборки в Clang лучше поддавался сжатию LZMA. При измерении производительности код, собранный в Clang и MSVC, показал примерно одинаковые результаты. В отдельных тестах наблюдалось расхождение на уровне 5%, где-то выигрывал Clang, а где-то MSVC.Так как режимы оптимизации LTCG и PGO использовались MSVC, но пока не используются при сборке релизов Chrome в Clang, имеется определённый задел для дальнейшего улучшения сборок на базе Clang. Различий в стабильности работы сборок в Clang и MSVC не выявлено. По времени локальной сборки Clang отстаёт от MSVC примерно на 15%, но сборка с отладочной информацией в распределённом сборочном сервисе Goma (https://chromium.googlesource.com/infra/goma/client/) производится быстрее.
Проект перевода Windows-сборок Chrome на Clang начался в 2013 году и привёл к существенному улучшению в Clang поддержки Windows. Ключевым мотивом перехода на Clang стало желание задействовать единый компилятор для всех поддерживаемых платформ и унифицировать сборочный инструментарий. Доводы в пользу единого компилятора:
- Использование при разработке Chrome многочисленных сопутствующих инструментов (ASan, CFI, ClusterFuzz), которые поддерживаются в Clang, но не сочетаются с MSVC;
- Возможность написания плагинов к Clang для добавления специфичных для кодовой базы Chromium проверок и предупреждений;
- Возможность применения инструментов (https://chromium.googlesource.com/chromium/src/+/lkcr/docs/c... Clang для рефакторинга кода;
- Включение в систему поиска (https://cs.chromium.org/) по исходным текстам Chromium кода, специфичного для Windiows;
- Желание использовать открытый инструментарий для сборки открытого проекта Chromium;
- Унификация сборочного инструментария, Chrome поддерживает 6 платформ, но большинство разработчиков знакомы с 1-3 платформами, что может создавать проблемы с компиляцией патчей на незнакомых платформах и воспроизведением специфичных для иных сборочных инструментариев ошибок в своём окружении;- Возможность использования специфичных для компилятора микро-оптимизаций для всех платформ;
- Упрощение кросс-компиляции - работая в Linux, можно работать с кодом, специфичным для Windows;
- Оперативное выявление проблем через обеспечение непрерывных сборок текущей экспериментальной ветки Chrome при помощи текущей экспериментельной ветки (trunk) Clang. Использование нерерывных сборок позволяет быстро переходить на новые версии компилятора, в то время как переход на новую версию MSVC занимал год или больше из-за длительного процесса выявления регрессий и согласования исправления выявленных в компиляторе ошибок;
- Трудность перехода на новые версии стандарта C++ при применении разных компиляторов;
- Возможность приоритетного развития определённых возможностей в компиляторе, не дожидаясь когда эти возможности будут готовы реализовать разработчики MSVC.
Плюсы использования Clang вместо Visual C++:- Поддержка 64-разрядных ассемблерных inline-вставок в Clang, которые активно используется в коде библиотеки libyuv для оптимизации декодирования форматов видео;
- Возможность применения единого компилятора на разных платформах. Сборка разными компиляторами может способствовать выявлению дополнительных ошибок, но по мнению разработчиков Chrome средств диагностики Clang достаточно для выявления большинства проблем, а если появятся новые методы диагностики, то их можно перенести в Clang;
- Возможность использования Address Sanitizer для выявления проблем при работе с памятью;
- Clang может генерировать более быстрый код, если не используются оптимизации LTCG и PGO;
- Широкие средства диагностики в Clang с рекомендациями по устранению ошибок.Минусы перевода проектов на Clang:
- Отсутствие в Clang поддержки расширений C++/CX (https://en.wikipedia.org/wiki/C%2B%2B/CX) и конструкции #import "foo.dll";
- Наличие платной поддержки MSVC, в то время как патчи к Clang нужно писать самостоятельно или привлекать представителей из сообщества;
- В Clang отсутствуют некоторые расширенные возможности отладки, такие как "Edit & Continue".URL: http://blog.llvm.org/2018/03/clang-is-now-used-to-build-chro...
Новость: https://www.opennet.me/opennews/art.shtml?num=48209
Хочу увидеть новость в которой Mesa-у, хотя бы опционально и экспирементально, переведут на gcc, хотя бы просто для того чтобы сборочное окружение работало быстрее и не зависело от шланга.
да ладно. gcc еще та помойка, которая постоянно ломает кодогенерацию.
> да ладно. gcc еще та помойка, которая постоянно ломает кодогенерацию.Не так уж и часто, по сравнению с пайтон.
Переход от gcc6 к gcc7 ничто по сравнению с переходом от p2 к p3 который уже просочился во все щели и не завершился в openSUSE до сих пор, и каждый подобный патч на приложение как серпом по яйцам.
И возвращаясь к теме шланга, шлангом можно уже даже ядро собрать, нет gcc-only приложений, а Mesa-drivers стало шланг-only. Очень не охота чтобы это стало заразным.
> Переход от gcc6 к gcc7 ничто по сравнению с переходом от p2 к p3 который уже просочился во все щели и не завершилсяТак ведь все знают, что разные версии компилятора мягче и фиолетовее разных версий языка.
>> да ладно. gcc еще та помойка, которая постоянно ломает кодогенерацию.
> Не так уж и часто, по сравнению с пайтон.Боюсь, сравнение не корректное.
Во первых, сравнивать компилируемые и интерпретируемые языки...
Вот вторых, у питона разные версии *языка*, а gcc продолжает компилировать тот же язык.
>>> да ладно. gcc еще та помойка, которая постоянно ломает кодогенерацию.
>> Не так уж и часто, по сравнению с пайтон.
> Боюсь, сравнение не корректное.
> Во первых, сравнивать компилируемые и интерпретируемые языки...
> Вот вторых, у питона разные версии *языка*, а gcc продолжает компилировать тот
> же язык.Согласен, но называть gcc помойкой тем более не корректно.
Ну так если согласны, то зачем такое написали?
> нет gcc-only приложенийДа много их. Virtualbox из того что сразу на ум приходит
Сама меза как собиралась при помощи GCC, так и не прекращала. LLVM (не Clang) используется в Mesa при компиляции GLSL-шейдеров для выполнения на GPU, чего GCC никогда не умел.
> Сама меза как собиралась при помощи GCC, так и не прекращала. LLVM (не Clang) используется в Mesa при компиляции GLSL-шейдеров для выполнения на GPU, чего GCC никогда не умел.Благодарю за разъяснение.
Меня интересуют OpenCL, OpenACC, причём, совсем не для графики. А там мне Шланг наx не впёрся.
Clang вперся, ибо, внезапно, является фронтендом для компиляции шейдеров. Сейчас уже нету никакой разницы между графикой и GPGPU со стороны железа. И GLSL и CL генерируется в LLVM байт-код, который с помощью бэкенда (nvptx, amdgpu) генерерит уже AMD IL, HSA IL, PTX, и.т.д. Свой компилятор имеет проприетарный nvidia'вский и amd'шный драйвер (благо amd работает над переходом в сторону llvm, про nvidia не могу сказать).P.S: И да, как первый нытик, что поднял ветку, так и Вы, не хотите разбираться в разнице между llvm, clang, gcc; что такое бэкенд/фронтенд в llvm; экосистему gcc, llvm; почему так легко под llvm писать свои компиляторы (фронтенды) с кастомными архитектурами железа (бэкенды) (не обязательно под CPU); архитектуре современных GPU (конвейер, память) и как устроено выполнение кода на железе (если бы понимали, сразу стало понятно что графику и GPGPU он выполняет все теми же ядрами). Зато поныть на opennet'е сразу все горазды.
В арче почему-то clang у mesa в make-depend'ах, хоть и собирается всё с помощью gcc. Надо будет разузнать, зачем.
Посмотрел ебилд. Clang действительно присутствует в зависимостях мезы, но он нужен только для OpenCL на r600 и radeonsi. Собрать мезу без OpenCL можно в отсутствие clang, а без поддержки новых радеонов — и в отсутствие LLVM.
Даже если gcc научится, то не факт, что проблемы кончатся. mesa распространяется под MIT лицензией, а gcc под gpl, соответственно объединить их в одном бинаре будет затруднительно уже только по этой причине.
>Хочу увидеть новость в которой Mesa-у, хотя бы опционально и экспирементально, переведут на gccБрат, я тоже этого жду!
...Ну или хотя бы чтобы Mesa форкнули.
>>Хочу увидеть новость в которой Mesa-у, хотя бы опционально и экспирементально, переведут на gcc
> Брат, я тоже этого жду!Как я понял позже, для этого, как минимум, gcc должен научиться компилировать GLSL-шейдеры.
А я жду, когда последуют примеру бсд и выкинут гцц на помойку.
Даешь меньше вирусной гнутой дряни, больше истинно свободных лицензий! (MIT, BSD)
Все думают, что этот шланг просто так ради интереса стартанули. Типа, чтобы gcc в одиночестве нескучно было. Не удивлюсь если их финансирует микрософт, которой необходимо переползти на другие архитектуры.
Учитвая, что в MS активно занялись развитием Шланга, а свой компилятор забросили...
> Учитвая, что в MS активно занялись развитием Шланга, а свой компилятор забросили...Тот cамый МS, который активно проталкивал в стандарт С11 свои дополнения, при этом все еще не имея нормальной поддержки (и почти отрыто забив на нее) C99 в своем собственном компиляторе?
Ну, с такими "друзьями-развивальщиками" никаких врагов-конкурентов не надо :)
Его стартанули корпорасты-пермиссивщики. Зачем — надеюсь, не надо объяснять?
> Его стартанули корпорасты-пермиссивщики. Зачем — надеюсь, не надо объяснять?Надо. Зачем? Компилятор не определяет лицензию скомпилированного бинарника. А libc и libstd++ можно и подменить.
У них на GPL аллергия.
точно? напомнить "забытое" исключение из gcc ? :)
А то ведь получалось - компилируешь при помощи gcc, а тебе хрясь - отдай код под GPL v3 :)
Не живи прошлыми воспоминаниями, живи настоящим.PS То недоразумение поправили в следующей же минорной версии.
Если у вас нет своего бесплатного компилятора, то с одной стороны, вам может выкрутить яйца gcc, а с другой - содрать три шкуры другой проприетарщик за "корпоративные" лицензии.
> Надо. Зачем? Компилятор не определяет лицензию скомпилированного бинарника.А как же возможность продавать свой "более быстрый, оптимизированный" проприетарненький компилятор? gcc лохи уже не покупают.
> Компилятор не определяет лицензию скомпилированного бинарника.Если в рантайме используется код библиотеки компилятора или ещё какой формат данных времени выполнения, то компилятор задаёт степень лицензионной чистоты выполняемого кода. Например, во FreeBSD до сих пор используется код времени выполнения внутри линковщика времени выполнения под лицензией GPL, несмотря на то, что система компилируется и собирается LLVM/Clang-5.0.1.
> до сих пор используется код времени выполнения внутри
> линковщика времени выполнения под лицензией GPL, несмотря на то, что система
> компилируется и собирается LLVM/Clang-5.0.1.Шланговый ld на tier1 уже довольно давно работает, ЕМНИП.
Технические причины в том числе. Не всем нравятся танцы с гиппопотамами
https://gcc.gnu.org/ml/gcc/2005-11/msg00918.htmlНо то такое. Обычно самые ратовали за "свободу" почему то против конкуренции причём от открытого продукта.
> Технические причины в том числе. Не всем нравятся танцы с гиппопотамами
> https://gcc.gnu.org/ml/gcc/2005-11/msg00918.html" Unless I am mistaken about the LLVM, it has no such user community. "
С 2005ого это поменялось. #путькуспеху
> https://gcc.gnu.org/ml/gcc/2005-11/msg00918.htmlА что, еще более древнее сообщение не накопалось? :)
> Зачем — надеюсь, не надо объяснять?Хотели показать, что в компиляторе можно сделать более человекочитаемый вывод об ошибках, как и продвинутые предупреждения. Сработало - разработчики GCC клюнули и улучшили GCC.
Но вот зачем шланг продолжили развивать - ума не приложу!
>Его стартанули корпорасты-пермиссивщикиТы так об этом говоришь, будто это что-то плохое.
> Все думают, что этот шланг просто так ради интереса стартанули. Типа, чтобы
> gcc в одиночестве нескучно было.Нет. Не все так думают. Я думаю иначе. Шланг стартанули потому, что с gcc'шным кодом может компоноваться только GPL-код. Если тебе приспичит сделать какой-нибудь препроцессор к C или статический анализатор, или движок подсветки синтаксиса и автодополнения к текстовому редактору, которые будут работать не на регекспах, но полностью парсить сорец, и тебе захочется найти библиотеку, которая займётся парсингом, чтобы получать сразу синтаксическое дерево разбора, то мало того, что с gcc ты замучаешься это делать (он не предназначен для работы в виде библиотеки), так ещё и код свой тебе придётся публиковать под GPL.
В этом собственно и заключался план Столлмана, но он не сработал. Может быть если бы gcc больше бы заботился о документации себя на всех уровнях, и о том, чтобы предоставлять готовую библиотеку для встраивания gcc в приложение, может быть в этом случае что-нибудь и вышло бы. Но gcc развивался сам в себя. Поэтому когда появился шланг, вокруг шланга моментально собралось множество разработчиков. Штольман прощёлкал клювом это изменение мира, и не успел переориентировать развитие gcc. Не поспел за хипстерами. Теперь ему остаётся только догонять, а вот здесь GPL ему уже конкретно мешает.
Ситуация не безнадёжна -- документация к шлангу тоже неидеальна. Можно сделать лучше, гораздо лучше. Но с другой стороны есть stackoverflow, а gcc, насколько я вижу, продолжает демонстрировать неспособность к гибкому реагированию на изменения трендов. Он продолжает заниматься повышением качества поддержки стандартов и глубины оптимизации, а вот создать инфраструктуру для GPL кода, который хочет использовать gcc в виде библиотеки -- это им как-то не очень интересно. Штольман постарел и закоснел, а у остальных революционного запала нет и идеологическая подкованность заканчивается на умении вербально воспроизводить лозунги Столлмана. Это, может быть, удел любой революции. А может это удел любой революции, которая строится вокруг одной личности-идеолога.
>так ещё и код свой тебе придётся публиковать
> под GPL.
> В этом собственно и заключался план Столлмана, но он не сработал.План был, чтоб не было проприертарных расширений.
Он "сработал".
> быть если бы gcc больше бы заботился о документации себя на
> всех уровнях, и о том, чтобы предоставлять готовую библиотеку для встраивания
> gcc в приложение,Выделил для ограниченных возможностями:
"" libgccjit
This document describes libgccjit, an API [U] for embedding GCC inside programs [/U] and libraries. "" --https://gcc.gnu.org/onlinedocs/gcc-7.3.0/jit/
> я вижу, продолжает демонстрировать неспособность к гибкому реагированию на изменения трендов.
Да. Но Вы можете продолжать изгибвться, нагибаться, прогибаться... Гибко!
jit все-же не совсем то.
> jit все-же не совсем то.Как и "продовать gcc без исходников" нисавсем "предоставлять готовую библиотеку для встраивания gcc в приложение".
И?
>>так ещё и код свой тебе придётся публиковать
>> под GPL.
>> В этом собственно и заключался план Столлмана, но он не сработал.
> План был, чтоб не было проприертарных расширений.
> Он "сработал".В смысле, что в gcc нет пропиетарных расширений, он сработал бесспорно. Но план Столлмана был шире -- он хотел зохватить мир своей GPL. В частности gcc был ключевым проектом, потому что как завещал Маркс, инструменты производства должны принадлежать пролеториату, то есть тому, кто пользуется этими инструментами, иначе дело кончится эксплуатацией. И вот на этом gcc сфейлился. И видимо уже непоправимо, llvm тихой сапой вытеснит gcc отовсюду, потому что программисту llvm зело удобнее. Одна штука на все кейсы, когда нужен парсер, работа с ast, или генерация машинного кода.
llvm позволяет строить более сложные системы. Так же как systemd проводя унификацию позволяет строить более сложные системы. Рост сложности систем неизбежен, поэтому всему тому, что не может подстроиться под этот тренд, уже заготовлено местечко в музее компьютерной истории.
>> быть если бы gcc больше бы заботился о документации себя на
>> всех уровнях, и о том, чтобы предоставлять готовую библиотеку для встраивания
>> gcc в приложение,
> Выделил для ограниченных возможностями:
> "" libgccjit
> This document describes libgccjit, an API [U] for embedding GCC inside programs
> [/U] and libraries. "" --https://gcc.gnu.org/onlinedocs/gcc-7.3.0/jit/
>> я вижу, продолжает демонстрировать неспособность к гибкому реагированию на изменения трендов.
> Да. Но Вы можете продолжать изгибвться, нагибаться, прогибаться... Гибко!О, точно. Я ведь слышал про эту штуку. То есть, таки Столлман тоже демонстрирует способность прогибаться под изменчивый мир? Но, всё же, недостаточно. Initial release этого gccjit в 2013 году, то есть тогда, когда llvm и clang уже вовсю были доступны. И, кроме того, я, полистав документацию, так и не понял, пригоден ли этот gccjit для чего-нибудь, кроме jit. Подсветку синтаксиса на нём можно запилить? Статический анализатор кода? Вон, Торвальдс, когда ему понадобился статический анализатор кода, писал свой собственный парсер C, но это было задолго до появления gccjit и тогда ещё clang не взлетел. А сейчас есть ли шансы у Торвальдса пересесть на gcc'шные библиотеки? Можно ли через gccjit организовать рефакторинг кода? Мне тут когда понадобилось, я пользовался llvm, и что-то мне подсказывает, что gccjit мне бы был совершенно бесполезен для этих целей, даже несмотря на то, что мне совершенно фиолетова была лицензия: я писал одноразовый код для внутреннего использования.
Но документация реально приятнее, чем у clang/llvm. Если бы ещё функциональность была бы на схожем уровне, тогда может чего-нибудь и вышло бы. Но тоже вряд ли: время упущено, и убедить теперь кого-нибудь, что надо ради хорошей документации выбирать GPL лицензию, вряд ли удастся. И уж точно не удастся перевести mesa на GPL, чтобы линковать её с этим libgccjit.
>>> В этом собственно и заключался план Столлмана, но он не сработал.
>> План был, чтоб не было проприертарных расширений.
>> Он "сработал".
> В смысле, что в gcc нет пропиетарных расширений, он сработал бесспорно. Но
> план Столлмана был шире -- он хотел зохватить мир своей GPL.Так свобода же -- Вы можете не приходить.
> В частности gcc был ключевым проектом, потому что как завещал Маркс,
>>>> В этом собственно и заключался план Столлмана, но он не сработал.
>>> План был, чтоб не было проприертарных расширений.
>>> Он "сработал".
>> В смысле, что в gcc нет пропиетарных расширений, он сработал бесспорно. Но
>> план Столлмана был шире -- он хотел зохватить мир своей GPL.
> Так свобода же -- Вы можете не приходить.Проблема в том, что не только я могу не приходить. Может не придти никто.
> документация к шлангу тоже неидеальнаПочему "тоже"? Документация — едва ли не единственное, и уж точно основное, в чём шланг сливает gcc по полной. У gcc есть полноценный мануал, у шланга — только разрозненный набор веб-страничек разной степени неактуальности и крайне неполные маны.
>> документация к шлангу тоже неидеальна
> Почему "тоже"? Документация — едва ли не единственное, и уж точно основное,
> в чём шланг сливает gcc по полной. У gcc есть полноценный
> мануал, у шланга — только разрозненный набор веб-страничек разной степени неактуальности
> и крайне неполные маны.Ты сейчас ведь говоришь про документацию на компилятор, как command-line утилиту? Я немного о другом: попробуй написать фронтенд к gcc, и ты увидишь, что значит "качество" документации. Сейчас ситуация может и изменилась, но лет пять назад это был форменный кошмар.
Да ладно? У GCC есть не только подробная документация по интерфейсам различных частей, но даже туториалы по созданию фронт/бэкендов (да, в рамках официальной документации!). Во времена четвертой ветки, когда мне пришлось ковырять GCC на предмет добавления туда одной фичи, которая требовала модификации всего стека - от лексера до генератора кода - мне хватило пары вечеров вдумчивого чтения документации, чтобы еще за день взять и запилить. У шланга до сих пор "суши весла". Все-таки GCC - это не clang. И это хорошо, ибо многие технические решения шланга - и в том числе его попытка быть в каждой бочке затычкой в ущерб общему качеству - весьма спорны.
> Да ладно? У GCC есть не только подробная документация по интерфейсам различных
> частей, но даже туториалы по созданию фронт/бэкендов (да, в рамках официальной
> документации!). Во времена четвертой ветки, ...Хм. Видимо я каким-то образом прошёл мимо всего этого.
> И это хорошо, ибо многие технические решения шланга - и в
> том числе его попытка быть в каждой бочке затычкой в ущерб
> общему качеству - весьма спорны.Спорны они или нет, но проектов на базе gcc раз-два и обчёлся, а на llvm каждый второй хипстер пилит.
Да не поэтому. Шланг и LLVM создали потому, что у него архитектура более интересная, чем у других компиляторов.Просто при этом не выбрали GPL. Но создавали его не для того, чтобы урон открытому софту нанести.
Я бы хотел уточнить, свободного или открытого (коньпелятора)?
Тогда стоит уточнить, свободного в какой версии: разработчика, потребителя или конечного пользователя. Мне близки утверждения г-на Столлмана. Но и он не избежал игры слов. То, что он называет "свободой изучать, модифицировать и распространять" - не свобода, а право. В русском языке звучит обманчиво и популистически.
> не свобода, а правоА вы тот ещё демагог и словесный эквилибрист.
Право:
3. Возможность действовать, поступать каким-нибудь образом.Свобода:
2. Отсутствие стеснений и ограничений, связывающих общественно-политическую жизнь и деятельность какого-нибудь класса, всего общества или его членов.
3. Вообще отсутствие каких-нибудь ограничений, стеснений в чём-нибудь Дать детям больше свободы.Есть лицензии, которые отражают всё вышеперечисленное (да, GPL в их число не входит).
Источник: толковый словарь Ожегова.
Бодро подытожили, спасибо. Даже как-то и дискутировать ни к чему.
Ясень пень, что меньше. При компиляции MSVC свои зонды добавляет. А так только гугловские остаются.
А GCC только GNUшные зонды?
Сейчас бы в век терабайтных дисков считать проценты от мегабайтов
Им надо по сети обновления накатывать, а там каждый лишний байт потенциально увеличивает время
А, ну можно не считать, правда, чего уж там.
То-то все кому не лень придумывают всякие там webp hevc opus.., зачем? Анон уже купил винт на терабайт!
Согласен. Нет смысла в 300(!!!) мегабайтном дистре экономить пару мег - всё равно Хром настолько монолитное чучело, что отправкой двух новых DLL ничего не обновить - нужно перекачивать всю эту приблуду.2018/01/10 23:46 51 957 760 chrome.dll
2018/01/10 23:51 72 485 376 chrome_child.dll
2017/12/15 00:19 10 171 248 icudtl.dat
2018/01/10 23:53 110 347 776 interactive_ui_tests.exeОставил только самое шедевральное. Кого-то до сих пор волнует 8% от 72 мегабайт?!!
interactive_ui_tests.exe можете смело удалить.
Как и
nacl_irt_x86_64.nexe
libGLESv2.dll
libEGL.dll
D3DCompiler_47.dll
chrome_watcher.dll
swiftshader
ненужные locales
Итого 150Мб
> Оставил только самое шедевральное. Кого-то до сих пор волнует 8% от 72
> мегабайт?!!8% волнуют процессор. Процессору весь этот код приходится многократно читать из RAM в кеши. Чем больше этот код, тем больше времени на это уходит. Во время выполнения программы причём. Не любые 8% сокращения размера кода заметно скажутся на производительности, но в некоторых ситуациях и 1% сокращения может дать заметные результаты. Поэтому стремление уменьшать размер кода -- это полезное стремление.
Нисколько не умаляя достоинства малых программ, замечу: у вас DLL-ка 72 мега - она ПО-ЛЮБОМУ не влезет в кэш! Да и сами компиляторы стали достаточно умные, чтобы генерить более-менее оптимальный код. Я к тому, что "выжимка процентов" не стоит своих усилий. Уменьшить в ДВА раза - да, остальное - от лукавого. Как и говорил, Хромому нужна модульность - разбить этот монолит на нормальные модули, причём с возможностью их удаления.
> Нисколько не умаляя достоинства малых программ, замечу: у вас DLL-ка 72 мега
> - она ПО-ЛЮБОМУ не влезет в кэш!А вовсе нет никакой нужды впихивать 72 мегабайта в кеш. Если какой-то кусок кода выполняется один раз в сутки, то загрузка его в кеш практически никак не повлияет на производительность. Даже если этот кусок в своп будет выпадать за сутки -- это слабо скажется на производительности. В худшем случае будет небольшой лаг. Раз в сутки.
Производительность определяется скоростью работы циклов, и вот тут важно, чтобы код цикла поместился бы в кеш. Если цикл выполняется 10k раз, и на каждой итерации его код загружается в кеш, то это скажется на производительности. Если при этом итерация цикла выполняется за 50 тактов процессора, и ещё десяток тактов тратится на загрузку тела цикла в кеш, то это замедление цикла на 20%.
Если мы код уменьшили на 8% равномерно везде, то все циклы тоже стали на 8% меньше, а это значит, что есть неплохие шансы на то, что какой-то из них не влезал в кеш, а теперь влез.Ну, это понятно, упрощённая картина: в кеше не только код лежит, ещё и данные, и по сути надо говорить не о том, что код часто грузится, а о том, сколько кеша остаётся свободным для манипуляции с данными после загрузки тела цикла в кеш. С учётом этого я вообще не вижу никакого способа оценить возможные бонусы к производительности в общем случае. Но, тем не менее, пренебрегать этим я бы не стал. 8% объёма -- это круто, это 1/12 часть.
> Да и сами компиляторы
> стали достаточно умные, чтобы генерить более-менее оптимальный код. Я к тому,
> что "выжимка процентов" не стоит своих усилий.Это если сидеть и вручную писать на ассемблере, тратя на порядок-два больше времени на написание того же кода, тогда действительно не стоит. А если для сокращения кода на 8% надо единожды довести сорцы до совместимости с другим компилятором, и потом придерживаться более строгих гайдлайнов к вновь написанному коду, то в чём проблемы?
А если ещё вспомнить, что подобные преобразования кода положительно сказываются на его качестве, так сам бог велел. Я бы даже сказал, что если код несовместим с другим компилятором, то это самодостаточный повод для того, чтобы заняться совместимостью, не ради производительности или размера, а ради уменьшения количества багов.> Уменьшить в ДВА раза - да, остальное - от лукавого.
Если раз десять уменьшить время выполнения на 8%, то в сумме выйдет сокращение на 50%.
Если забивать на эти проценты, то в результате получится тормозное нечто. И не только потому, что проценты накопятся, а ещё и потому, что разработчики, не выискивая проценты, потеряют нюх и способность писать быстрый код. Чтобы понимать где и как программа тратит время, надо заниматься оптимизациями. Оптимизации такая штука, что подчастую заранее не знаешь, сколько ты процентов получишь. На скорость выполнения кода влияет очень много чего, и учесть эти факторы все практически невозможно. Очень часто самый простой способ проверить -- переписать код так, как кажется будет лучше, и сравнить. То есть крайне сложно исследовать, где программа проводит время, не совершая попытки оптимизировать по скорости. А не зная, где программа тормозит, невозможно писать не тормозную программу.
Говорить о том, что проценты не важны -- это то же самое, что говорить "производительность не важна".
> Оставил только самое шедевральное. Кого-то до сих пор волнует 8% от 72 мегабайт?!!Гугол волнует. Для них эти единицы процентов выливаются в сотни терабайт трафика при обновлении хромого, которые очень больно бъют по карману корпорации. Они экономят на каждой спичке. Не от доброты душевной они, например, занялись разработкой и внедрением новых форматов видео и аудио.
>...которые очень больно бъют по карману корпорации.У меня на вас даже кот заржал!! :))) бьют по карману... :))) Так и вижу Брина - вышел такой в обед за хотдогом, посмотрел на трафик: ё-моё, ещё терабайт скачали! Так и быть, беру булочку без сосиски! :))))))))))
Рад за то, что у вас такой веселый кот, но Гугл - корпорация бабла. И если есть возможность сэкономить копейку - они это сделают.
виндяцкие привязки очень портят жизнь разрабам хрома https://habrahabr.ru/company/infopulse/blog/350126/
Не без этого. Но мне кажется, что линуксовая видеосистема им побольше посолила :)> Supporting GPU features on Linux is a nightmare (I know from dealing with the GPU sandbox). (c)
> Не без этого. Но мне кажется, что линуксовая видеосистема им побольше посолила
> :)
>> Supporting GPU features on Linux is a nightmare (I know from dealing with the GPU sandbox). (c)по постам в оригинальной статье
> When comparing direct Windows I/o calls with Linux I/O on the same hardware, the difference resolved to NTFS being only about a factor of 2 slower that Linux (ext4 IIRC).
и еще
> Few months later, I decided to test another scenario. I booted the same Windows computer from an Ubuntu flash stick and tested the archive there. Even though NTFS filesystem was mounted with FUSE-based ntfs-3g (as opposed to native Windows NTFS driver), the problem went away! I rechecked the archive several times in a row, and it was always successful. wtf.
> the difference resolved to NTFS being only about a factor of 2 slower that LinuxДа ну ты брось :D Оказывается мамонтовая ФС из прошлого сливает какой-то сервер ориентированной? Не может быть :D
К чему ты это сюда тащишь?
>> the difference resolved to NTFS being only about a factor of 2 slower that Linux
> Да ну ты брось :D Оказывается мамонтовая ФС из прошлого сливает какой-то
> сервер ориентированной? Не может быть :D
> К чему ты это сюда тащишь?К осознанию сложностей и мучений, кот. испытывают разрабы под виндузом, в частности - разрабы хрома,
что виндуз не платформа для разработки (работы), а боль и печаль множества людей ;)
Таки может соберут Qt WebEngine mingw-w64 даже ?
Это как они на андроиде клангом собирают? На андроиде разве все приложения не java?
> На андроиде разве все приложения не java?Нет.
нет там через jni Java native interface цепляет найтивный код. например в Qt программы на Си собираются вместе с классами java. стандартный набор для приложений под Android. все интересное пишется на Си и быстро работает от явы только обертка...
> сократить размер исполняемого файла на 8%В этом месте вероятно надо начать истомно стонать ....
> В этом месте вероятно надо начать истомно стонать ....Так что ж мешает-то..? :)
Так они же тогда, вероятно, и кончили от этого. Ачуметь, сократили бинарник на 8%, забыв, правда, про потерю производительности от худшей оптимизации.
Ну осиль ещё пару предложений новости, напрягись. Я верю, ты сможешь.
> от худшей оптимизацииЧто несёшь? У clang лучше оптимизация даже чем у GCC. Что уж там про M$-дерьмо говорить.
> Что несёшь? У clang лучше оптимизация даже чем у GCC. Что уж
> там про M$-дерьмо говорить.Все-таки GCC оптимизирует сильно лучше, чем шланг. И без глупых ошибок к тому же. Уступает он только icc.
Почему не компилятор от Intel?
> Почему не компилятор от Intel?Потому что есть AMD и ARM, на коих венда так же имеется?
> Из привлекательных сторон Clang... (по ср. с MSVC, прим. авт.) выделяется возможность сохранения совместимости с MSVCМне одному это кажется клоунадой "Шланг ради Шланга"?
Да.
Нет.