LINUX.ORG.RU

Chrome перешел на Clang

 ,


1

4

Начиная с Chrome 38, при сборке релизов для Linux разработчики стали использовать Clang вместо GCC.

Сообщается, что особых проблем (кроме невозможности запуска получившихся сборок в устаревших 32-разрядных дистрибутивах Debian) не возникло. Переход на Clang позволил сократить размер исполняемых файлов на 8% без потерь в производительности (слегка ускорился запуск браузера, в одних тестах наблюдается незначительный прирост производительности, в других — такое же незначительное ухудшение).

>>> Подробности

anonymous

Проверено: Shaman007 ()

Ответ на: комментарий от anonymous

все бы хорошо, но вот есть кусок кода который gcc векторизует с avx, а шланг даже sse не может подставить.

geks ()
Ответ на: комментарий от anonymous

вроде кусками впилили sanitizers в gcc. тем не менее у шланга вывод лучше

geks ()
Ответ на: комментарий от yoghurt

А как же Abaco? BTW, чем tcc лучше родного плановского компилера?

korvin_ ★★★★★ ()
Ответ на: комментарий от zh_v68

Почему меня, как пользователя программы, должны волновать

потому, что ты мох, пользователь, не способный сам написать нужный софт

anonymous ()
Ответ на: комментарий от Jills

Так вот почему он стал тормозить

в хромиуме попробуй сохранить >100-500 закладок в разных подкаталогах, или перемещать их по подкаталогам, и смотри на зависон всего браузера жрущего одно ядро на 100%

anonymous ()
Ответ на: комментарий от zh_v68

так бы и написал, что тебе ультимативно пригорело из-за высокоточного попадания

anonymous ()
Ответ на: комментарий от geks

У тебя скорее всего ручонки кривоваты.

anonymous ()
Ответ на: комментарий от goingUp

Интересно, появятся ли люди, перешедшие с арча на генту по этой причине?

Если им сказать, что Поттеринг приложил руку (или ногу, или любую другую часть тела) к клангу, то перейдут сразу же.

Deleted ()

Переход на шланг софта и ОСей хорош тем, что:
1. Clang имеет _правильную_базу_ - только на прочном архитектурном фундаменте имеет смысл развивать большие проекты. Антипример - Линупс, изживающий сам себя с каждым днём из-за изначально бестолково слепленной архитектуры. ДАЖЕ если шланг не даст и процента по скорости, всё равно имеет смысл адаптироваться именно на него - рано или поздно он всё-равно порвёт GCC, достаточно лишь перенести ГЦЦшные трюки в LLVM.
2. Шланг - это ещё и изрядный кусок LLVM, а это сразу +100 очков практически к любому языку - это значит, что можно строить целое семейство языков на едином бэкенде, т.е. сильно экономить на разработке. Если ОС имеет гармонично встроенный LLVM, разрастаться языками станет проще (FreeBSD).
3. Шланг проще развивать. Отдельный модуль всегда проще улучшать, чем разбираться в ГЦЦшной вермишели. Это признают даже те, кто действительно разбирается в ГЦЦ.

Так что новость - чистый, незамутнённый позитив! Особенно радует поддержка таким гигантом, как Гугля.

matumba ★★★★★ ()
Ответ на: комментарий от Deleted

Если им сказать, что Поттеринг приложил руку (или ногу, или любую другую часть тела) к клангу, то перейдут сразу же.

Эт точно! Примерно как «надо использовать git, потому что его писал Трольвадс».

matumba ★★★★★ ()

Сборку gcc 4.9 не будут фиксить?

lu4 ()
Ответ на: комментарий от matumba

рано или поздно он всё-равно порвёт GCC, достаточно лишь перенести ГЦЦшные трюки в LLVM

5 лет назад писали что он уже давно порвал, а через пару месяцев будето одно сплошное телевидениеLLVM.

Вопрос, сколько еще пятилеток вы будете кукарекать, пиаря аппловскую поделку?

anonymous ()
Ответ на: комментарий от anonymous

Ну так на ARM он пять лет назад еще и порвал.

anonymous ()
Ответ на: комментарий от geks

Строго говоря, шланг к этому отношения не имеет, векторизируется уже готовый байткод в ллвм

anonymous ()

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

спрашивается: и на хрена?

emulek ()
Ответ на: комментарий от Napilnik

вне зависимости от того, какая версия ГЦЦ на данный момент в каждом конкретном дистрибутиве считается кошерной. Меньше забот разработчикам.

ВНЕЗАПНО: clang он тоже разный бывает.

emulek ()
Ответ на: комментарий от matumba

Clang имеет _правильную_базу_

религия.

Шланг - это ещё и изрядный кусок LLVM, а это сразу +100 очков практически к любому языку - это значит, что можно строить целое семейство языков на едином бэкенде

единый бэкенд есть и внутри gcc.

Шланг проще развивать. Отдельный модуль всегда проще улучшать, чем разбираться в ГЦЦшной вермишели. Это признают даже те, кто действительно разбирается в ГЦЦ.

лишь перенести ГЦЦшные трюки в LLVM.

/0

emulek ()
Ответ на: комментарий от anonymous

Шланг - это ещё и изрядный кусок LLVM, а это сразу +100 очков практически к любому языку

Строго говоря, шланг к этому отношения не имеет, векторизируется уже готовый байткод в ллвм

/me задумался…

emulek ()
Ответ на: комментарий от matumba

1. Clang имеет _правильную_базу_ - только на прочном архитектурном фундаменте имеет смысл развивать большие проекты. Антипример - Линупс, изживающий сам себя с каждым днём из-за изначально бестолково слепленной архитектуры. ДАЖЕ если шланг не даст и процента по скорости, всё равно имеет смысл адаптироваться именно на него - рано или поздно он всё-равно порвёт GCC, достаточно лишь перенести ГЦЦшные трюки в LLVM.

Тут еже писали, что это принципиально невозможно?

Приходиться выбирать или правильная архитектура или трюки gcc.

anonymous ()

слегка ускорился запуск браузера, в одних тестах наблюдается незначительный прирост производительности, в других — такое же незначительное ухудшение

Короче говоря, ничего не изменилось. Вот так новость!

thesis ★★★★★ ()
Ответ на: комментарий от wayland_systemd

Если не ошибаюсь, единственная реально полезная фича, пока не поддерживаемая clang-ом — это OpenMP.

Deleted ()
Ответ на: комментарий от anonymous

Приходиться выбирать или правильная архитектура или трюки gcc

не вижу технического обоснования. туда ли ты зашёл?

anonymous ()

Задолбали со своей дуткой про шланг. Пока RedHat не перевёл Ведору на шланг, и Линус не стал им пользоваться как «основным компилятором», он не нужен. Как минимум один из них. А эти двое знают, что делают.

nexfwall ★★★★ ()

Внесите царя, чтоль .. а то тут срач про гцц, а его нет.

anonymous ()

А память по-прежнему жрёт как не в себя? Почему-то на тех же задачах 64-х битный Хром жрёт памяти даже не в два раза больше, чем 32-х битный, как можно бы было ожидать в пределе (при реальном ожидании в ~1.7 раза), а до 3-5(!) раз o_O

KRoN73 ★★★★★ ()
Ответ на: комментарий от emulek

ВНЕЗАПНО: clang он тоже разный бывает.

Так он же не системный компилятор, поэтому можно использовать большой диапазон версий без проблем. Вот если шланг станет системным, то тогда придётся придётся изобретать новый внесистемный компилятор, а если и его додумаются сделать системным... То - смотри выше.

Napilnik ★★★★★ ()
Ответ на: комментарий от Napilnik

Так он же не системный компилятор

поставь себе второй gcc, не вижу проблемы. Да и что такое «системный компилятор»? У меня вот компилятор совсем не той версии, чем у Патрика, и что?

emulek ()
Ответ на: комментарий от emulek

поставь себе второй gcc, не вижу проблемы.

Два бинарника gcc в /usr/bin использующие каждый свой набор либ в /usr/lib64 ?

Да и что такое «системный компилятор»?

На который система завязана. Попробуй вкорячить в дистр типа федоры сильно не ту версию gcc/ Очень не уверен что после этого соберутся все её src.rpm А вот fpc я могу поставить в систему почти любой версии и нормально собирать после этого программы. Более того, могу скопипастить в хомяк ещё несколько версий и нормально ими пользоваться почти не заботясь о номерах версий либ в /usr/lib64, потому что нормальный несистемный компилятор от них абстрагируется как только может. И от версий libc он тоже абстрагируется максимально возможным образом. Просто не используются глючные функции системных либ, а вот если собираешь какую-то большую программу на c++ через gcc, то особенности системы имеют огромное значение - там для абстрагирования от глючных/нестабильных функций libc и прочих почти ничего не сделано.

Napilnik ★★★★★ ()
Ответ на: комментарий от Napilnik

Два бинарника gcc в /usr/bin использующие каждый свой набор либ в /usr/lib64 ?

да, как в debian, gentoo или любом адекватном дистрибутве

anonymous ()
Ответ на: комментарий от anonymous

В нормальных дистрах уже разрешили в одном каталоге иметь 2 файла с одинаковым именем? Не знал, не знал. Ну ладно, допустим второй файл gcc можно обозвать gcc2, но пролема в том, что и gcc и gcc2 могут вызвать бинарь /usr/bin/hrenovina который для каждой версии компилятора нужен свой а его уже так просто не переименуешь в /usr/bin/hrenovina2 - gcc2 может об этом не догадаться. Поэтому для второго, очень не такого gcc придётся лепить в корень вторую систему в миниатюре.

Napilnik ★★★★★ ()
Ответ на: комментарий от Napilnik

Ну ладно, допустим второй файл gcc можно обозвать gcc2

gcc47 gcc48 gcc49

gcc и gcc2 могут вызвать бинарь /usr/bin/hrenovina который для каждой версии компилятора

bin/cpp49
bin/gcc-ranlib49
bin/gcc-ar49
lib/gcc49/include
lib/gcc49/libsupc++.a
libexec/gcc49/gcc

У меня две версии шланга и два гцц. Могу без проблем еще пару поставить. ЧЯДНТ? И что у вас за дистр такой интересный?

anonymous ()
Ответ на: комментарий от anonymous

у него комп на торсионном эфире, и не требует дистрибутивов

anonymous ()
Ответ на: комментарий от anonymous

У меня две версии шланга и два гцц. Могу без проблем еще пару поставить. ЧЯДНТ?

без проблем

То есть можешь поставить любую версию - взять собранный пакет основного компилятора из дистра на несколько версий меньше, или другого дистра, накатить в /usr/bin и все названия бинарей автоматически переименуются?

Napilnik ★★★★★ ()
Последнее исправление: Napilnik (всего исправлений: 1)
Ответ на: комментарий от Napilnik

основного компилятора из дистра на несколько версий меньше,

Основной компилятор один — он ведь на то и основной, не? ;) При надобности, я могу собрать себе другую «основную» версию - но зачем?

или другого дистра,

Зачем мне другой дистр?

Речь шла о возможности без проблем уставить несколько версий гцц на одной системе, а не о всяких извращениях ;).

Еще раз: есть основной гцц с gcc, g++, cpp, инклудами, либами и т.д - все остальные версиии «готовятся» отдельно, с пре/постфиксами. Вангую, что мейнтейнеры просто заглянули сюда: https://gcc.gnu.org/faq.html

How to install multiple versions of GCC
;)

anonymous ()
Ответ на: комментарий от anonymous

Основной компилятор один — он ведь на то и основной, не? ;) При надобности, я могу собрать себе другую «основную» версию - но зачем?

Затем, чтобы сделать из основного неосновной компилятор.

или другого дистра,

Зачем мне другой дистр?

А там собрали программы Х и Y и ты хочешь собрать их и у себя.

Речь шла о возможности без проблем уставить несколько версий гцц на одной системе, а не о всяких извращениях ;).

Ты так уверен что пользуясь гцц обойдёшься без извращений?)

все остальные версиии «готовятся» отдельно, с пре/постфиксами.

То есть нельзя взять и добавить кем-то когда-то и хрен знает как удачно собранную версию компилятора, и если программа в системе собирается не так как надо, это судьба:(

Napilnik ★★★★★ ()
Последнее исправление: Napilnik (всего исправлений: 1)
Ответ на: комментарий от Napilnik

Затем, чтобы сделать из основного неосновной компилятор.

Если мне нужна таже версия гцц, но «как бы, отдельно» — она есть в репах. Если мне нужна сборка чего-либо, вплоть до самой системы, другой версией: CC=gcc47 CXX=g++47 CPP=сpp47 make profit. Вообще-то, основной компилятор это как бы cc/c++.

Еще раз: основной гцц в репах - один. Т.е этой версией собирается софт в этой самой репе и именно сборка «всего и вся» с этой версией компилятора тестится и поддерживается в первую очередь. Держать сразу несколько «основных» версий конечно можно, но накладно - вплоть до того, что при проблемах вам вначале вежливо предложат не выделываться установить версию «как у всех». _Меня_ это вполне устраивает.

Но да, если я захочу себе другую версию гцц в «основные системные» и не захочу извращяться с ln -s — придется ее собирать самому. Бида, да. Или это такой тонкий намек был — «если нельзя вот так и этак, значит фигня и ненужно!»? :)

А там собрали программы Х и Y и ты хочешь собрать их и у себя.

Какие-то особые, сферические, сырцы которых есть только в репе этого дистра и для которых требуется особый, правильно приготовленный гцц, пакет с которым я почему-то могу поставить — но при этом религиозные убеждения не позволяют мне поставить сразу пакет с нужным софтом? :)

Ну, вообще-то, если уж на то пошло — chroot и виртуалки еще никто не отменял. Особенно для такого софта. И надеюсь, вопрос о том, можно ли взять и воткнуть (возможно, «неправильно» собранный) пакет из другого дистра в систему — и он обязан «правильно» заработмать (за счет темной магии?), был не в серьез?

То есть нельзя взять и добавить кем-то когда-то и хрен знает как удачно собранную версию компилятора

Случайно, не сферического? :) А так: chroot, виртуалка, не? И вообще, «добавлять» хрен знает кем и где собраный бинарник в систему — это знаете ли очччень на любителя, да.

и если программа в системе собирается не так как надо, это судьба:(

Oбычно там проблема не только и не столько в версии компилятора ;). Но: chroot, виртуалка, не?

Еще раз: речь как бы шла о

napilnik

emulek

поставь себе второй gcc, не вижу проблемы.

Два бинарника gcc в /usr/bin использующие каждый свой набор либ в /usr/lib64 ?

Повторюсь: УМВР. Я, кстати, не вижу связи между самой возможностью свободно установить несколько версий гцц — и приведенными вами сферическими _возможными_ проблемами. Или это как с мышами и кактусом лисой и виноградом :)?

anonymous ()
Ответ на: комментарий от anonymous

Какие-то особые, сферические, сырцы которых есть только в репе этого дистра и для которых требуется особый, правильно приготовленный гцц, пакет с которым я почему-то могу поставить — но при этом религиозные убеждения не позволяют мне поставить сразу пакет с нужным софтом? :)

В репах дистра чего-то может просто не быть, или местные ментейнеры не смогли собрать прогу с нужной фичей и отрубили её чтобы вообще как-то собралось. Ставь пакет и наслаждайся отсутствием присутствия или жди выхода новой версии дистрибутива, авось повезёт. Например, ты кеды в шестом центосе видел? Не смогли их нормально собрать из тех же исходников, их которых у красношапочников почему-то собиралось получше.

И надеюсь, вопрос о том, можно ли взять и воткнуть (возможно, «неправильно» собранный) пакет из другого дистра в систему — и он обязан «правильно» заработмать (за счет темной магии?), был не в серьез?

Ну почему же, время от времени втыкаю в нефедорах вот этот замечательный пакет bluecurve-cursor-theme-8.0.2-7.fc17.noarch.rpm Собрать его на месте из src.rpm - да ну нафиг, запаришься. Но готовый, в магее установился и заработал на 100% в альте правда, на 50%. Не знаю, есть ли в твоём дебиане такой пакет, и вдруг, допустим, понадобится поставить этот дистр в виртуалку, потыкался по репам и облом! Для таких случаев в генте можно установить rpm и спокойно ставить такие пакеты, а дебиановцы конвертируют собранные в федоре пакеты в deb - # alien имя_вашего_пакета.rpm

Napilnik ★★★★★ ()
Ответ на: комментарий от Napilnik

Два бинарника gcc в /usr/bin использующие каждый свой набор либ в /usr/lib64 ?

второй gcc можно поставить например в /usr/local/, или в /opt, или даже в свой юзерский $HOME.

зачем нужны другие либы — мне не понятно. Собери с теми же. Впрочем, другие тоже можно, это не проблема.

На который система завязана.

не на что она не «завязана».

Попробуй вкорячить в дистр типа федоры

федорапроблема.

Очень не уверен что после этого соберутся все её src.rpm А вот fpc я могу поставить в систему почти любой версии и нормально собирать после этого программы

почему ты gcc равняешь на src.rpm, а другой компилятор на простые исходники? Это не корректно.

Более того, могу скопипастить в хомяк ещё несколько версий и нормально ими пользоваться почти не заботясь о номерах версий либ в /usr/lib64, потому что нормальный несистемный компилятор от них абстрагируется как только может.

ты бредишь.

а вот если собираешь какую-то большую программу на c++ через gcc, то особенности системы имеют огромное значение

gcc тут абсолютно не при чём.

глючных/нестабильных функций libc

пример таких функций можно?

emulek ()
Ответ на: комментарий от Napilnik

В нормальных дистрах уже разрешили в одном каталоге иметь 2 файла с одинаковым именем?

почему «с одинаковым именем»? В слаке например два tar'а. Патрег новый tar не любит.

/usr/bin/hrenovina который для каждой версии компилятора нужен свой

а вот и нет. Когда ты собираешь старую(новую) версию gcc2, она собирается с текущей /usr/bin/hrenovina, а не с той, с которой оно собиралось 2 года назад(вперёд).

Поэтому для второго, очень не такого gcc придётся лепить в корень вторую систему в миниатюре.

не придётся. Попробуй сам.

emulek ()
Ответ на: комментарий от emulek

зачем нужны другие либы — мне не понятно. Собери с теми же. Впрочем, другие тоже можно, это не проблема.

Собери в федоре кинелерру/кинереллу, видеоредактор такой. Или авидемукс и т.д. так, чтобы он не падал во время работы в самый неудобный момент. Если ты всерьёз считаешь, что всем программам зашибись версии либ от системного пасьянса косынка, то подумай ещё раз.

федорапроблема.

Линуксопроблема. Тут а на есть, а на чём сидишь ты, линуксоидам сейчас фиолетово.

не на что она не «завязана».

Соведущим в спокойной ночи малыши уже устроился? Здесь твои сказки не по адресу.

Napilnik ★★★★★ ()

* В проекте участвуют работники нескольких корпораций, в том числе, Google и Apple. Исходный код доступен на условиях BSD-подобной лицензии. *

anonymous ()
Ответ на: комментарий от Napilnik

Собери в федоре

федорапроблема.

Линуксопроблема.

УМВР. Т.е. ты хочешь сказать, что Slackware не Linux, да?

а на чём сидишь ты, линуксоидам сейчас фиолетово.

а мне насрать на твоих мудазвонов-линуксоидов.

И на их проблемы тоже насрать. Мне вот что интересно: а тебе-то какой резон так переживать из-за проблем этих мудазвонов? Ну жуют они свой федора-кактус, тебе-то что с того?

emulek ()
Ответ на: комментарий от emulek

УМВР. Т.е. ты хочешь сказать, что Slackware не Linux, да?

Ничего не знаю, у меня линукс и определённые недостатки есть, а ты хрен знает на чём сидишь и про баги молчишь в тряпочку создавая картинку «а у меня багов нет и процессор выдаёт 400% мощности».

а мне насрать на твоих мудазвонов-линуксоидов.

Вот и сиди на своей винде, играй в лицензионные игры и не лезь грязными лапами в линукс.

Napilnik ★★★★★ ()
Ответ на: комментарий от Napilnik

местные ментейнеры не смогли собрать несколько пакетов гцц с нужной фичей

fixed :)

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

Ну почему же, время от времени втыкаю в нефедорах вот этот замечательный пакет bluecurve-cursor-theme-8.0.2-7.fc17.noarch.rpm

Переходи на темную сторону федорку, у нас нет нескольких версий гцца, зато крутые темки для курсора!11 :)

anonymous ()
Ответ на: комментарий от anonymous

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

Чтобы собрать программу так, как собирали её авторы и получить известные баги а не свои уникальные. Представь, каково авторам программы получать репорты о куче уникальных багов чужих дистрибутивов.

Переходи на темную сторону федорку, у нас нет нескольких версий гцца, зато крутые темки для курсора!11 :)

Так на федоре и сижу, а на фичи гсс покласть, как-то работает и сойдёт, но уже давно из поставки выбросили хорошие курсоры чтобы они в настроечной утилите не контрастировали по стилю с говняными новыми. Хорошо хоть в репах пакет есть, но когда грузишься с лайфдивиди, репы не помогают. Кроме пакета bluecurve-cursor-theme мне неизвестны нормальные темы курсоров содержащие и левые курсоры тоже.

Napilnik ★★★★★ ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.