The OpenNET Project / Index page

[ новости /+++ | форум | wiki | теги | ]

Сборка Chrome для Windows переведена на использование Clang

06.03.2018 10:04

Компания Google перешла на использование свободного компилятора Clang при формировании сборок браузера Chrome для платформы Windows, вместо ранее применявшегося компилятора Microsoft's Visual C++ (MSVC). Таким образом, начиная с Chrome 64 компилятор 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.

В своё время перевод 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 производится быстрее.

Проект перевода Windows-сборок Chrome на Clang начался в 2013 году и привёл к существенному улучшению в Clang поддержки Windows. Ключевым мотивом перехода на Clang стало желание задействовать единый компилятор для всех поддерживаемых платформ и унифицировать сборочный инструментарий. Доводы в пользу единого компилятора:

  • Использование при разработке Chrome многочисленных сопутствующих инструментов (ASan, CFI, ClusterFuzz), которые поддерживаются в Clang, но не сочетаются с MSVC;
  • Возможность написания плагинов к Clang для добавления специфичных для кодовой базы Chromium проверок и предупреждений;
  • Возможность применения инструментов Clang для рефакторинга кода;
  • Включение в систему поиска по исходным текстам 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 и конструкции #import "foo.dll";
  • Наличие платной поддержки MSVC, в то время как патчи к Clang нужно писать самостоятельно или привлекать представителей из сообщества;
  • В Clang отсутствуют некоторые расширенные возможности отладки, такие как "Edit & Continue".


  1. Главная ссылка к новости (http://blog.llvm.org/2018/03/c...)
  2. OpenNews: Google перешел на Clang при формировании сборки Chrome для Linux
  3. OpenNews: Браузер Chrome переходит с GTK+ на собственный графический стек Aura
  4. OpenNews: Android NDK отказывается от GCC в пользу Clang
  5. OpenNews: Проект OpenBSD перешёл по умолчанию на Clang для платформ amd64 и i386
  6. OpenNews: Обеспечена возможность сборки ядер Linux 4.4 и 4.9 при помощи Clang
Лицензия: CC-BY
Тип: К сведению
Ключевые слова: chrome, clang, llvm
При перепечатке указание ссылки на opennet.ru обязательно
Обсуждение (86) Ajax | 1 уровень | Линейный | Раскрыть всё | RSS
  • 1.1, Ilya Indigo (ok), 11:30, 06/03/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • –10 +/
    Хочу увидеть новость в которой Mesa-у, хотя бы опционально и экспирементально, переведут на gcc, хотя бы просто для того чтобы сборочное окружение работало быстрее и не зависело от шланга.
     
     
  • 2.5, Аноним (-), 11:49, 06/03/2018 [^] [^^] [^^^] [ответить]  
  • –12 +/
    да ладно. gcc еще та помойка, которая постоянно ломает кодогенерацию.
     
     
  • 3.7, Ilya Indigo (ok), 11:56, 06/03/2018 [^] [^^] [^^^] [ответить]  
  • –4 +/
    > да ладно. gcc еще та помойка, которая постоянно ломает кодогенерацию.

    Не так уж и часто, по сравнению с пайтон.
    Переход от gcc6 к gcc7 ничто по сравнению с переходом от p2 к p3 который уже просочился во все щели и не завершился в openSUSE до сих пор, и каждый подобный патч на приложение как серпом по яйцам.
    И возвращаясь к теме шланга, шлангом можно уже даже ядро собрать, нет gcc-only приложений, а Mesa-drivers стало шланг-only. Очень не охота чтобы это стало заразным.

     
     
  • 4.23, Аноним (-), 14:08, 06/03/2018 [^] [^^] [^^^] [ответить]  
  • +/
    > Переход от gcc6 к gcc7 ничто по сравнению с переходом от p2 к p3 который уже просочился во все щели и не завершился

    Так ведь все знают, что разные версии компилятора мягче и фиолетовее разных версий языка.

     
  • 4.27, XoRe (ok), 14:44, 06/03/2018 [^] [^^] [^^^] [ответить]  
  • +3 +/
    >> да ладно. gcc еще та помойка, которая постоянно ломает кодогенерацию.
    > Не так уж и часто, по сравнению с пайтон.

    Боюсь, сравнение не корректное.
    Во первых, сравнивать компилируемые и интерпретируемые языки...
    Вот вторых, у питона разные версии *языка*, а gcc продолжает компилировать тот же язык.

     
     
  • 5.28, Ilya Indigo (ok), 14:49, 06/03/2018 [^] [^^] [^^^] [ответить]  
  • +/
    >>> да ладно. gcc еще та помойка, которая постоянно ломает кодогенерацию.
    >> Не так уж и часто, по сравнению с пайтон.
    > Боюсь, сравнение не корректное.
    > Во первых, сравнивать компилируемые и интерпретируемые языки...
    > Вот вторых, у питона разные версии *языка*, а gcc продолжает компилировать тот
    > же язык.

    Согласен, но называть gcc помойкой тем более не корректно.

     
     
  • 6.50, depeche (??), 19:42, 06/03/2018 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Ну так если согласны, то зачем такое написали?
     
  • 4.51, Нэээ (?), 20:22, 06/03/2018 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > нет gcc-only приложений

    Да много их. Virtualbox из того что сразу на ум приходит

     
  • 2.11, Аноним (-), 12:16, 06/03/2018 [^] [^^] [^^^] [ответить]  
  • +19 +/
    Сама меза как собиралась при помощи GCC, так и не прекращала. LLVM (не Clang) используется в Mesa при компиляции GLSL-шейдеров для выполнения на GPU, чего GCC никогда не умел.
     
     
  • 3.13, Ilya Indigo (ok), 12:24, 06/03/2018 [^] [^^] [^^^] [ответить]  
  • +5 +/
    > Сама меза как собиралась при помощи GCC, так и не прекращала. LLVM (не Clang) используется в Mesa при компиляции GLSL-шейдеров для выполнения на GPU, чего GCC никогда не умел.

    Благодарю за разъяснение.

     
  • 3.41, Аноним (-), 17:12, 06/03/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Меня интересуют OpenCL, OpenACC, причём, совсем не для графики. А там мне Шланг наx не впёрся.
     
     
  • 4.84, maxis11 (ok), 21:00, 07/03/2018 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Clang вперся, ибо, внезапно, является фронтендом для компиляции шейдеров Сейчас... текст свёрнут, показать
     
  • 3.52, axredneck (?), 21:36, 06/03/2018 [^] [^^] [^^^] [ответить]  
  • +1 +/
    В арче почему-то clang у mesa в make-depend'ах, хоть и собирается всё с помощью gcc. Надо будет разузнать, зачем.
     
     
  • 4.54, Аноним (-), 00:13, 07/03/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Посмотрел ебилд. Clang действительно присутствует в зависимостях мезы, но он нужен только для OpenCL на r600 и radeonsi. Собрать мезу без OpenCL можно в отсутствие clang, а без поддержки новых радеонов — и в отсутствие LLVM.
     
  • 3.60, Ordu (ok), 10:17, 07/03/2018 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Даже если gcc научится, то не факт, что проблемы кончатся. mesa распространяется под MIT лицензией, а gcc под gpl, соответственно объединить их в одном бинаре будет затруднительно уже только по этой причине.
     
  • 2.38, Аноним (-), 17:04, 06/03/2018 [^] [^^] [^^^] [ответить]  
  • +/
    >Хочу увидеть новость в которой Mesa-у, хотя бы опционально и экспирементально, переведут на gcc

    Брат, я тоже этого жду!

     
     
  • 3.39, Аноним (-), 17:06, 06/03/2018 [^] [^^] [^^^] [ответить]  
  • +/
    ...Ну или хотя бы чтобы Mesa форкнули.
     
  • 3.40, Ilya Indigo (ok), 17:11, 06/03/2018 [^] [^^] [^^^] [ответить]  
  • +1 +/
    >>Хочу увидеть новость в которой Mesa-у, хотя бы опционально и экспирементально, переведут на gcc
    > Брат, я тоже этого жду!

    Как я понял позже, для этого, как минимум, gcc должен научиться компилировать GLSL-шейдеры.

     
  • 2.59, Аноним (-), 06:53, 07/03/2018 [^] [^^] [^^^] [ответить]  
  • +/
    А я жду, когда последуют примеру бсд и выкинут гцц на помойку.
    Даешь меньше вирусной гнутой дряни, больше истинно свободных лицензий! (MIT, BSD)
     

  • 1.2, adolfus (ok), 11:34, 06/03/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • –3 +/
    Все думают, что этот шланг просто так ради интереса стартанули. Типа, чтобы gcc в одиночестве нескучно было. Не удивлюсь если их финансирует микрософт, которой необходимо переползти на другие архитектуры.
     
     
  • 2.12, Аноним (-), 12:22, 06/03/2018 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Учитвая, что в MS активно занялись развитием Шланга, а свой компилятор забросили...
     
     
  • 3.45, Аноним84701 (ok), 17:45, 06/03/2018 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Учитвая, что в MS активно занялись развитием Шланга, а свой компилятор забросили...

    Тот cамый МS, который активно проталкивал в стандарт С11 свои дополнения, при этом все еще не имея нормальной поддержки (и почти отрыто забив на нее) C99 в своем собственном компиляторе?
    Ну, с такими "друзьями-развивальщиками" никаких  врагов-конкурентов не надо :)

     
  • 2.14, Аноним (-), 12:28, 06/03/2018 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Его стартанули корпорасты-пермиссивщики. Зачем — надеюсь, не надо объяснять?
     
     
  • 3.21, Аноним (-), 13:59, 06/03/2018 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > Его стартанули корпорасты-пермиссивщики. Зачем — надеюсь, не надо объяснять?

    Надо. Зачем? Компилятор не определяет лицензию скомпилированного бинарника. А libc и libstd++ можно и подменить.

     
     
  • 4.22, Аноним (-), 14:08, 06/03/2018 [^] [^^] [^^^] [ответить]  
  • +2 +/
    У них на GPL аллергия.
     
  • 4.24, Аноним (-), 14:08, 06/03/2018 [^] [^^] [^^^] [ответить]  
  • +/
    точно? напомнить "забытое" исключение из gcc ? :)
    А то ведь получалось - компилируешь при помощи gcc, а тебе хрясь - отдай код под GPL v3 :)
     
     
  • 5.42, Аноним (-), 17:17, 06/03/2018 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Не живи прошлыми воспоминаниями, живи настоящим.

    PS То недоразумение поправили в следующей же минорной версии.

     
  • 4.29, Аноним (-), 14:54, 06/03/2018 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Если у вас нет своего бесплатного компилятора, то с одной стороны, вам может выкрутить яйца gcc, а с другой - содрать три шкуры другой проприетарщик за "корпоративные" лицензии.
     
  • 4.33, Аноним (-), 15:56, 06/03/2018 [^] [^^] [^^^] [ответить]  
  • +/
    > Надо. Зачем? Компилятор не определяет лицензию скомпилированного бинарника.

    А как же возможность продавать свой "более быстрый, оптимизированный" проприетарненький компилятор? gcc лохи уже не покупают.

     
  • 4.36, iZEN (ok), 16:01, 06/03/2018 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > Компилятор не определяет лицензию скомпилированного бинарника.

    Если в рантайме используется код библиотеки компилятора или ещё какой формат данных времени выполнения, то компилятор задаёт степень лицензионной чистоты выполняемого кода. Например, во FreeBSD до сих пор используется код времени выполнения внутри линковщика времени выполнения под лицензией GPL, несмотря на то, что система компилируется и собирается LLVM/Clang-5.0.1.

     
     
  • 5.44, Аноним (-), 17:32, 06/03/2018 [^] [^^] [^^^] [ответить]  
  • +/
    > до сих пор используется код времени выполнения внутри
    > линковщика времени выполнения под лицензией GPL, несмотря на то, что система
    > компилируется и собирается LLVM/Clang-5.0.1.

    Шланговый ld на tier1 уже довольно давно работает, ЕМНИП.

     
  • 3.32, iPony (?), 15:53, 06/03/2018 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Технические причины в том числе. Не всем нравятся танцы с гиппопотамами
    https://gcc.gnu.org/ml/gcc/2005-11/msg00918.html

    Но то такое. Обычно самые ратовали за "свободу" почему то против конкуренции причём от открытого продукта.

     
     
  • 4.34, Andrey Mitrofanov (?), 15:57, 06/03/2018 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Технические причины в том числе. Не всем нравятся танцы с гиппопотамами
    > https://gcc.gnu.org/ml/gcc/2005-11/msg00918.html

    " Unless I am mistaken about the LLVM, it has no such user community. "

    С 2005ого это поменялось.  #путькуспеху

     
  • 4.65, Аноним (-), 11:03, 07/03/2018 [^] [^^] [^^^] [ответить]  
  • +/
    > https://gcc.gnu.org/ml/gcc/2005-11/msg00918.html

    А что, еще более древнее сообщение не накопалось? :)

     
  • 3.55, Аноним (-), 00:26, 07/03/2018 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > Зачем — надеюсь, не надо объяснять?

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


     
  • 3.86, Аноним (-), 12:14, 08/03/2018 [^] [^^] [^^^] [ответить]  
  • +/
    >Его стартанули корпорасты-пермиссивщики

    Ты так об этом говоришь, будто это что-то плохое.

     
  • 2.62, Ordu (ok), 10:36, 07/03/2018 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Нет Не все так думают Я думаю иначе Шланг стартанули потому, что с gcc шным к... текст свёрнут, показать
     
     
  • 3.64, Andrey Mitrofanov (?), 10:44, 07/03/2018 [^] [^^] [^^^] [ответить]  
  • +1 +/
    >так ещё и код свой тебе придётся публиковать
    > под 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/

    > я вижу, продолжает демонстрировать неспособность к гибкому реагированию на изменения трендов.

    Да. Но Вы можете продолжать изгибвться, нагибаться, прогибаться... Гибко!

     
     
  • 4.66, Аноним (-), 11:04, 07/03/2018 [^] [^^] [^^^] [ответить]  
  • +/
    jit все-же не совсем то.
     
     
  • 5.68, Andrey Mitrofanov (?), 12:31, 07/03/2018 [^] [^^] [^^^] [ответить]  
  • +/
    > jit все-же не совсем то.

    Как и "продовать gcc без исходников" нисавсем "предоставлять готовую библиотеку для встраивания gcc в приложение".

    И?

     
  • 4.70, Ordu (ok), 12:42, 07/03/2018 [^] [^^] [^^^] [ответить]  
  • +/
    В смысле, что в gcc нет пропиетарных расширений, он сработал бесспорно Но план ... текст свёрнут, показать
     
     
  • 5.72, Andrey Mitrofanov (?), 13:05, 07/03/2018 [^] [^^] [^^^] [ответить]  
  • +/
    >>> В этом собственно и заключался план Столлмана, но он не сработал.
    >> План был, чтоб не было проприертарных расширений.
    >> Он "сработал".
    > В смысле, что в gcc нет пропиетарных расширений, он сработал бесспорно. Но
    > план Столлмана был шире -- он хотел зохватить мир своей GPL.

    Так свобода же -- Вы можете не приходить.

    > В частности gcc был ключевым проектом, потому что как завещал Маркс,

     
     
  • 6.80, Ordu (ok), 18:16, 07/03/2018 [^] [^^] [^^^] [ответить]  
  • +/
    >>>> В этом собственно и заключался план Столлмана, но он не сработал.
    >>> План был, чтоб не было проприертарных расширений.
    >>> Он "сработал".
    >> В смысле, что в gcc нет пропиетарных расширений, он сработал бесспорно. Но
    >> план Столлмана был шире -- он хотел зохватить мир своей GPL.
    > Так свобода же -- Вы можете не приходить.

    Проблема в том, что не только я могу не приходить. Может не придти никто.

     
  • 3.77, Аноним (-), 15:49, 07/03/2018 [^] [^^] [^^^] [ответить]  
  • +/
    > документация к шлангу тоже неидеальна

    Почему "тоже"? Документация — едва ли не единственное, и уж точно основное, в чём шланг сливает gcc по полной. У gcc есть полноценный мануал, у шланга — только разрозненный набор веб-страничек разной степени неактуальности и крайне неполные маны.

     
     
  • 4.79, Ordu (ok), 18:15, 07/03/2018 [^] [^^] [^^^] [ответить]  
  • +/
    >> документация к шлангу тоже неидеальна
    > Почему "тоже"? Документация — едва ли не единственное, и уж точно основное,
    > в чём шланг сливает gcc по полной. У gcc есть полноценный
    > мануал, у шланга — только разрозненный набор веб-страничек разной степени неактуальности
    > и крайне неполные маны.

    Ты сейчас ведь говоришь про документацию на компилятор, как command-line утилиту? Я немного о другом: попробуй написать фронтенд к gcc, и ты увидишь, что значит "качество" документации. Сейчас ситуация может и изменилась, но лет пять назад это был форменный кошмар.

     
     
  • 5.81, Аноним (-), 20:20, 07/03/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Да ладно? У GCC есть не только подробная документация по интерфейсам различных частей, но даже туториалы по созданию фронт/бэкендов (да, в рамках официальной документации!). Во времена четвертой ветки, когда мне пришлось ковырять GCC на предмет добавления туда одной фичи, которая требовала модификации всего стека - от лексера до генератора кода - мне хватило пары вечеров вдумчивого чтения документации, чтобы еще за день взять и запилить. У шланга до сих пор "суши весла". Все-таки GCC - это не clang. И это хорошо, ибо многие технические решения шланга - и в том числе его попытка быть в каждой бочке затычкой в ущерб общему качеству - весьма спорны.
     
     
  • 6.85, Ordu (ok), 21:21, 07/03/2018 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > Да ладно? У GCC есть не только подробная документация по интерфейсам различных
    > частей, но даже туториалы по созданию фронт/бэкендов (да, в рамках официальной
    > документации!). Во времена четвертой ветки, ...

    Хм. Видимо я каким-то образом прошёл мимо всего этого.

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

    Спорны они или нет, но проектов на базе gcc раз-два и обчёлся, а на llvm каждый второй хипстер пилит.

     
  • 3.93, vitalif (ok), 11:54, 11/03/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Да не поэтому. Шланг и LLVM создали потому, что у него архитектура более интересная, чем у других компиляторов.

    Просто при этом не выбрали GPL. Но создавали его не для того, чтобы урон открытому софту нанести.

     

  • 1.3, Аноним (-), 11:41, 06/03/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • –2 +/
    Я бы хотел уточнить, свободного или открытого (коньпелятора)?
     
     
  • 2.6, Аноним (-), 11:53, 06/03/2018 [^] [^^] [^^^] [ответить]  
  • –5 +/
    Тогда стоит уточнить, свободного в какой версии: разработчика, потребителя или конечного пользователя. Мне близки утверждения г-на Столлмана. Но и он не избежал игры слов. То, что он называет "свободой изучать, модифицировать и распространять" - не свобода, а право. В русском языке звучит обманчиво и популистически.
     
     
  • 3.17, Аноним (-), 12:57, 06/03/2018 [^] [^^] [^^^] [ответить]  
  • +/
    > не свобода, а право

    А вы тот ещё демагог и словесный эквилибрист.

    Право:
    3. Возможность действовать, поступать каким-нибудь образом.

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

    Есть лицензии, которые отражают всё вышеперечисленное (да, GPL в их число не входит).

    Источник: толковый словарь Ожегова.

     
     
  • 4.30, Аноним (-), 15:16, 06/03/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Бодро подытожили, спасибо. Даже как-то и дискутировать ни к чему.
     

  • 1.4, Аноним (-), 11:43, 06/03/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • +2 +/
    Ясень пень, что меньше. При компиляции MSVC свои зонды добавляет. А так только гугловские остаются.
     
     
  • 2.69, Аноним (-), 12:40, 07/03/2018 [^] [^^] [^^^] [ответить]  
  • –1 +/
    А GCC только GNUшные зонды?
     

  • 1.8, Аноним (-), 12:01, 06/03/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • –9 +/
    Сейчас бы в век терабайтных дисков считать проценты от мегабайтов
     
     
  • 2.9, Аноним (-), 12:07, 06/03/2018 [^] [^^] [^^^] [ответить]  
  • +5 +/
    Им надо по сети обновления накатывать, а там каждый лишний байт потенциально увеличивает время
     
  • 2.15, Аноним (-), 12:32, 06/03/2018 [^] [^^] [^^^] [ответить]  
  • +/
    А, ну можно не считать, правда, чего уж там.
     
  • 2.19, Диалектик (?), 13:15, 06/03/2018 [^] [^^] [^^^] [ответить]  
  • +7 +/
    То-то все кому не лень придумывают всякие там webp hevc opus.., зачем? Анон уже купил винт на терабайт!
     
  • 2.47, Гоги (?), 18:32, 06/03/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Согласен. Нет смысла в 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 мегабайт?!!

     
     
  • 3.56, Аноним (-), 02:15, 07/03/2018 [^] [^^] [^^^] [ответить]  
  • +/
    interactive_ui_tests.exe можете смело удалить.
    Как и
    nacl_irt_x86_64.nexe
    libGLESv2.dll
    libEGL.dll
    D3DCompiler_47.dll
    chrome_watcher.dll
    swiftshader
    ненужные locales
    Итого 150Мб
     
  • 3.63, Ordu (ok), 10:42, 07/03/2018 [^] [^^] [^^^] [ответить]  
  • –2 +/
    > Оставил только самое шедевральное. Кого-то до сих пор волнует 8% от 72
    > мегабайт?!!

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

     
     
  • 4.87, Гоги (?), 00:18, 09/03/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Нисколько не умаляя достоинства малых программ, замечу: у вас DLL-ка 72 мега - она ПО-ЛЮБОМУ не влезет в кэш! Да и сами компиляторы стали достаточно умные, чтобы генерить более-менее оптимальный код. Я к тому, что "выжимка процентов" не стоит своих усилий. Уменьшить в ДВА раза - да, остальное - от лукавого. Как и говорил, Хромому нужна модульность - разбить этот монолит на нормальные модули, причём с возможностью их удаления.
     
     
  • 5.90, Ordu (ok), 01:33, 09/03/2018 [^] [^^] [^^^] [ответить]  
  • +/
    А вовсе нет никакой нужды впихивать 72 мегабайта в кеш Если какой-то кусок кода... текст свёрнут, показать
     
  • 3.82, Аноним (-), 20:25, 07/03/2018 [^] [^^] [^^^] [ответить]  
  • +/
    > Оставил только самое шедевральное. Кого-то до сих пор волнует 8% от 72 мегабайт?!!

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

     
     
  • 4.88, Гоги (?), 00:21, 09/03/2018 [^] [^^] [^^^] [ответить]  
  • +/
    >...которые очень больно бъют по карману корпорации.

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

     
     
  • 5.91, Аноним (-), 12:05, 09/03/2018 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Рад за то, что у вас такой веселый кот, но Гугл - корпорация бабла. И если есть возможность сэкономить копейку - они это сделают.
     

  • 1.10, none_first (ok), 12:09, 06/03/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • –3 +/
    виндяцкие привязки очень портят жизнь разрабам хрома https://habrahabr.ru/company/infopulse/blog/350126/
     
     
  • 2.20, iPony (?), 13:38, 06/03/2018 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Не без этого. Но мне кажется, что линуксовая видеосистема им побольше посолила :)

    > Supporting GPU features on Linux is a nightmare (I know from dealing with the GPU sandbox). (c)

     
     
  • 3.49, none_first (ok), 18:56, 06/03/2018 [^] [^^] [^^^] [ответить]  
  • +/
    > Не без этого. Но мне кажется, что линуксовая видеосистема им побольше посолила
    > :)
    >> 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.

     
     
  • 4.58, iPony (?), 06:21, 07/03/2018 [^] [^^] [^^^] [ответить]  
  • +/
    > the difference resolved to NTFS being only about a factor of 2 slower that Linux

    Да ну ты брось :D Оказывается мамонтовая ФС из прошлого сливает какой-то сервер ориентированной? Не может быть :D
    К чему ты это сюда тащишь?

     
     
  • 5.67, none_first (ok), 11:52, 07/03/2018 [^] [^^] [^^^] [ответить]  
  • +1 +/
    >> the difference resolved to NTFS being only about a factor of 2 slower that Linux
    > Да ну ты брось :D Оказывается мамонтовая ФС из прошлого сливает какой-то
    > сервер ориентированной? Не может быть :D
    > К чему ты это сюда тащишь?

    К осознанию сложностей и мучений, кот. испытывают разрабы под виндузом, в частности - разрабы хрома,
    что виндуз не платформа для разработки (работы), а боль и печаль множества людей ;)

     

  • 1.16, Аноним (-), 12:39, 06/03/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Таки может соберут Qt WebEngine mingw-w64 даже ?
     
  • 1.25, Аноним (-), 14:13, 06/03/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • –2 +/
    Это как они на андроиде клангом собирают? На андроиде разве все приложения не java?
     
     
  • 2.35, Аноним (-), 15:58, 06/03/2018 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > На андроиде разве все приложения не java?

    Нет.

     
     
  • 3.92, рара Кен (?), 23:11, 09/03/2018 [^] [^^] [^^^] [ответить]  
  • +/
    нет там через jni Java native interface цепляет найтивный код. например в Qt программы на Си собираются вместе с классами java. стандартный набор для приложений под Android. все интересное пишется на Си и быстро работает от явы только обертка...
     

  • 1.26, ыы (?), 14:33, 06/03/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    > сократить размер исполняемого файла на 8%

    В этом месте вероятно надо начать истомно стонать ....

     
     
  • 2.31, ryoken (ok), 15:30, 06/03/2018 [^] [^^] [^^^] [ответить]  
  • +/
    > В этом месте вероятно надо начать истомно стонать ....

    Так что ж мешает-то..? :)

     
     
  • 3.43, Аноним (-), 17:24, 06/03/2018 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Так они же тогда, вероятно, и кончили от этого. Ачуметь, сократили бинарник на 8%, забыв, правда, про потерю производительности от худшей оптимизации.
     
     
  • 4.53, Аноним (-), 22:24, 06/03/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Ну осиль ещё пару предложений новости, напрягись. Я верю, ты сможешь.
     
  • 4.73, Аноним (-), 13:56, 07/03/2018 [^] [^^] [^^^] [ответить]  
  • +/
    > от худшей оптимизации

    Что несёшь? У clang лучше оптимизация даже чем у GCC. Что уж там про M$-дерьмо говорить.

     
     
  • 5.83, Аноним (-), 20:28, 07/03/2018 [^] [^^] [^^^] [ответить]  
  • +/
    > Что несёшь? У clang лучше оптимизация даже чем у GCC. Что уж
    > там про M$-дерьмо говорить.

    Все-таки GCC оптимизирует сильно лучше, чем шланг. И без глупых ошибок к тому же. Уступает он только icc.

     

  • 1.37, ПДК (?), 16:52, 06/03/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • –4 +/
    Почему не компилятор от Intel?
     
     
  • 2.74, Аноним (-), 13:57, 07/03/2018 [^] [^^] [^^^] [ответить]  
  • +/
    > Почему не компилятор от Intel?

    Потому что есть AMD и ARM, на коих венда так же имеется?

     

  • 1.46, Гоги (?), 18:22, 06/03/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • –3 +/
    > Из привлекательных сторон Clang... (по ср. с MSVC, прим. авт.) выделяется возможность сохранения совместимости с MSVC

    Мне одному это кажется клоунадой "Шланг ради Шланга"?

     
     
  • 2.78, Аноним (-), 15:52, 07/03/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Да.
     
     
  • 3.89, Гоги (?), 00:35, 09/03/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Нет.

     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



    Спонсоры:
    Слёрм
    Inferno Solutions
    Hosting by Ihor
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2019 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру