Закон Хартли

Нетрудно свести лошадь к воде. Но если вы заставите ее плавать на спине — вот это значит, что вы чего-то добились!

— У тебя организм нормально реагирует на укус ос? ...

Разработчики openSUSE представили Uyuni, форк платформы Spacewalk
Sat, 26 May 2018 21:39:06 +0300

Анонимный благотворитель намерен пожертвовать миллион долларов проекту GNOME
Sat, 26 May 2018 08:44:57 +0300

Budgie Desktop возвращается в Solus и пересматривает планы миграции c GTK на Qt
Thu, 24 May 2018 09:32:35 +0300

Открыт код классического почтового клиента Eudora
Wed, 23 May 2018 09:09:46 +0300

Kubuntu прекращает подготовку сборок для 32-разрядных систем x86
Mon, 21 May 2018 12:24:33 +0300

Компания Tesla частично опубликовала GPL-код для формирования системного окружения
Mon, 21 May 2018 08:31:05 +0300

Lubuntu переходит на пользовательское окружение LXQt
Sat, 19 May 2018 09:24:55 +0300

Представлена вторая версия протокола Git
Fri, 18 May 2018 21:50:53 +0300

В Chrome изменится индикация безопасных соединений
Thu, 17 May 2018 22:24:42 +0300

Сенат США проголосовал за отмену решения FCC, касающегося сетевого нейтралитета
Thu, 17 May 2018 10:53:01 +0300

Прекращена разработка дистрибутива Korora
Wed, 16 May 2018 23:20:47 +0300

Компания Canonical опубликовала заявление, связанное с вредоносным ПО в Snap Store
Tue, 15 May 2018 23:33:17 +0300

Фонд свободного ПО сертифицировал программатор Zerocat Chipflasher
Tue, 15 May 2018 22:37:05 +0300

Из файлового менеджера GNOME будет удалена возможность запуска исполняемых файлов
Tue, 15 May 2018 21:41:05 +0300

В openSUSE Leap появится поддержка атомарного обновления системы
Tue, 15 May 2018 11:27:56 +0300

Новости OPENNET
Новости

Компания 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".

61.6659 72.1183 0.5634 9.6513

НОВОСТИ: Выпуск Wine 3.9 Fri, 25 May 2018 23:44:38 +0300

Состоялся экспериментальный выпуск открытой реализации Win32 API - Wine 3.9. С момента выпуска версии 3.8 было закрыто 33 отчёта об ошибках и внесено 230 изменений.

???????@Mail.ru Opera Firefox INFOBOX - хостинг Google Chrome