Chrome перешел на Clang

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

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

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

</шутка>

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

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

Отсосун-ононим

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

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

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

sqr(Отсосун-ононим)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

религия.

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

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

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

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

/0

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

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

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

Да закройся ты уже, достал. http://article.gmane.org/gmane.comp.compilers.llvm.devel/72455

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Ну ладно, допустим второй файл 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

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

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

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

без проблем

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

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

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

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

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

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

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

How to install multiple versions of GCC

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

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

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

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

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

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

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

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

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

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

Если мне нужна таже версия гцц, но «как бы, отдельно» — она есть в репах. Если мне нужна сборка чего-либо, вплоть до самой системы, другой версией: 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 ?

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

На FreeBSD порт Chromium можно было выбирать, чем собирать: GCC или LLVM/Clang.

Как-то показывал отличия: http://www.opennet.ru/openforum/vsluhforumID3/87575.html#155

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ты бредишь.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

fixed :)

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

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

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

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

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

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

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