The OpenNET Project / Index page

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



Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Режим отображения отдельной подветви беседы [ Отслеживать ]

Оглавление

В DNS-сервере BIND устранен серьёзный сбой, возникший из-за ..., opennews (ok), 13-Июн-14, (0) [смотреть все]

Сообщения [Сортировка по времени | RSS]


46. "В DNS-сервере BIND устранен серьёзный сбой, возникший из-за ..."  –3 +/
Сообщение от Vkni (ok), 13-Июн-14, 16:59 
> Вот последнюю проверку компилятор вполне имеет право удалить

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

Ответить | Правка | Наверх | Cообщить модератору

53. "В DNS-сервере BIND устранен серьёзный сбой, возникший из-за ..."  +2 +/
Сообщение от 0xd34df00d (??), 13-Июн-14, 17:21 
> В мире эльфов - да. Всё-таки, вера в то, что компилятору не
> придётся обрабатывать код с ошибками, в высшей степени наивна.

Есть баланс между толерантностью к ошибкам и качеством оптимизации. Включаешь оптимизатор — будь готов к тому, что кривой код он не простит.

Ну и статический анализ специально для этого придумали. clang'овский static-analyzer такие вещи отлично находит.

Ответить | Правка | Наверх | Cообщить модератору

58. "В DNS-сервере BIND устранен серьёзный сбой, возникший из-за ..."  –1 +/
Сообщение от Vkni (ok), 13-Июн-14, 18:53 
> Есть баланс между толерантностью к ошибкам и качеством оптимизации. Включаешь оптимизатор — будь готов к тому, что кривой код он не простит.

Ну так -O3 уже никто и не включает. Или пацаны хотят добиться, что и -O2 включать не будут?

Баланс, разумеется есть, но gcc регулярно шагает за баланс в сторону оптимизации. Нижеприведённый код qsort в стандарт был введён в 1999 году, а на C писали и до этого года. Т.е. оптимизация ярковыраженно ломает нормальный код, написанный 20 лет назад.

Причём, как это обычно у gccшников, без объявления войны. Хотя бы предупреждения о выбрасывании кода можно было выкинуть. Ну, типа unreachable code.

Ответить | Правка | Наверх | Cообщить модератору

59. "В DNS-сервере BIND устранен серьёзный сбой, возникший из-за ..."  +3 +/
Сообщение от 0xd34df00d (??), 13-Июн-14, 19:00 
>> Есть баланс между толерантностью к ошибкам и качеством оптимизации. Включаешь оптимизатор — будь готов к тому, что кривой код он не простит.
> Ну так -O3 уже никто и не включает. Или пацаны хотят добиться,
> что и -O2 включать не будут?

Включаю -O3 в продакшене на корректно написанном коде, брат жив.

> Баланс, разумеется есть, но gcc регулярно шагает за баланс в сторону оптимизации.

Есть у меня один знакомый, который как раз поэтому gcc и обожает, что там код работает на 5-10% быстрее, чем в clang, как правило.

> Нижеприведённый код qsort в стандарт был введён в 1999 году, а
> на C писали и до этого года. Т.е. оптимизация ярковыраженно ломает
> нормальный код, написанный 20 лет назад.

-std=c90 или подобное никто не запрещает передавать. Если при этом gcc откуда-то возьмёт требование к ненулёвости соответствующего аргумента qsort — вот тогда это проблема и баг в gcc. А если авторы пишут на C до 99 года, а передают ключи, соответствующие более свежему стандарту — ну, чо, ССЗБ.

> Причём, как это обычно у gccшников, без объявления войны. Хотя бы предупреждения
> о выбрасывании кода можно было выкинуть. Ну, типа unreachable code.

Unreachable code в этом случае выкидывать — это либо прокидывать какой коллбек из optimization pass в морду, что, вполне возможно, с текущей архитектурой gcc фиг сделаешь, либо делать полноценный статический анализ на этапе разбора кода, а это на времени компиляции скажется не очень позитивно.

Да и вообще, на этапе оптимизации, как правило, довольно много кода может выкидываться, передвигаться, и так далее. На всё это ворнингами плеваться — их столько появится, что никто эту простыню читать не будет.

А вообще, за хорошим анализом кода при обычной компиляции и предупреждениями — это к clang :)

Ответить | Правка | Наверх | Cообщить модератору

60. "В DNS-сервере BIND устранен серьёзный сбой, возникший из-за ..."  –2 +/
Сообщение от Vkni (ok), 13-Июн-14, 19:12 
> Включаю -O3 в продакшене на корректно написанном коде, брат жив.

Я очень рад за вас и вашего брата. Но таки вы - исключение. Стандартные флаги оптимизации в дистрибутивах (т.е. в 99% открытого софта) - O2.

> Есть у меня один знакомый, который как раз поэтому gcc и обожает,
> что там код работает на 5-10% быстрее, чем в clang, как
> правило.

Про clang пока даже речи не было. Совершенно неизвестно, что тамошние бравые парни наворотили. Есть отдельные места - http://clang.llvm.org/doxygen/ToolChains_8cpp_source.html
которые заставляют несколько усомниться в их квалификации.

> Да и вообще, на этапе оптимизации, как правило, довольно много кода может
> выкидываться, передвигаться, и так далее. На всё это ворнингами плеваться —
> их столько появится, что никто эту простыню читать не будет.

Есть такое. Но если место столь неприятно опасное, то стоило бы.

> А вообще, за хорошим анализом кода при обычной компиляции и предупреждениями —
> это к clang :)

Он совершенно никакого сравнения с PVS-кой не выдерживает.

Ответить | Правка | Наверх | Cообщить модератору

61. "В DNS-сервере BIND устранен серьёзный сбой, возникший из-за ..."  +/
Сообщение от 0xd34df00d (??), 13-Июн-14, 19:17 
>> Включаю -O3 в продакшене на корректно написанном коде, брат жив.
> Я очень рад за вас и вашего брата. Но таки вы -
> исключение. Стандартные флаги оптимизации в дистрибутивах (т.е. в 99% открытого софта)
> - O2.

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

>> Есть у меня один знакомый, который как раз поэтому gcc и обожает,
>> что там код работает на 5-10% быстрее, чем в clang, как
>> правило.
> Про clang пока даже речи не было. Совершенно неизвестно, что тамошние бравые
> парни наворотили. Есть отдельные места - http://clang.llvm.org/doxygen/ToolChains_8cpp_source.html

Какой-то файл с костылями, честное слово.

> которые заставляют несколько усомниться в их квалификации.

Да, там тоже есть свои проблемы. Но, по опыту, для кода, написанного по стандартам, а не по gcc, clang лучше себя ведёт.

>> А вообще, за хорошим анализом кода при обычной компиляции и предупреждениями —
>> это к clang :)
> Он совершенно никакого сравнения с PVS-кой не выдерживает.

У меня совершенно обратный опыт. Гонял один товарищ PVS по кое-чему из моего кода, ни единого сообщения по делу. В основном ругается на 32 и прочие подобные константы, считая это хардкодом битности машины, в коде вроде

auto pixmap = icon.pixmap (32, 32);

Ну и местами предлагает T на const T& заменить, не всегда по делу. Итого, сложилось впечатление, что это какая-то мешанина на регекспах, а не статический анализатор кода на плюсах.

clang'овский static-analyzer же, в свою очередь, несколько действительно проблемных мест мне нашёл.

Ответить | Правка | Наверх | Cообщить модератору

62. "В DNS-сервере BIND устранен серьёзный сбой, возникший из-за ..."  –1 +/
Сообщение от Vkni (ok), 13-Июн-14, 19:31 
> Ну, это дело другое, и я бы на самом деле поспорил, что
> дело именно в ломающем код оптимизаторе. Впрочем, это оффтопик.

А в чём ещё? Какой смысл ставить -O2, если -O3 быстрее и не ломает код?

> Какой-то файл с костылями, честное слово.

Ну достаточно элементарного понимания, что такое дистрибутивы Linux'а, чтобы не писать подобных скриптов не просто на C++, а даже на bash'е. Достаточно же одной символьной ссылки на gcc или макроса с расположением gcc в коде, поставленного мейнтейнером пакета clang.

> Ну и местами предлагает T на const T& заменить, не всегда по
> делу. Итого, сложилось впечатление, что это какая-то мешанина на регекспах, а
> не статический анализатор кода на плюсах.

Да, отчасти на регекспах, отчасти стат. анализатор. Много положительных срабатываний.

> clang'овский static-analyzer же, в свою очередь, несколько действительно проблемных мест
> мне нашёл.

У меня - ни одного.

Ответить | Правка | Наверх | Cообщить модератору

63. "В DNS-сервере BIND устранен серьёзный сбой, возникший из-за ..."  +1 +/
Сообщение от 0xd34df00d (??), 13-Июн-14, 19:37 
> А в чём ещё? Какой смысл ставить -O2, если -O3 быстрее и
> не ломает код?

Не всегда быстрее. Например, слишком агрессивное развёртывание циклов или инлайнинг может привести к тому, что меньше полезного кода будет помещаться в кеш со всеми вытекающими. А в рамках всей системы — так немного (а иногда и существенно) большие бинари могут привести к лишнему своппингу.

>> clang'овский static-analyzer же, в свою очередь, несколько действительно проблемных мест
>> мне нашёл.
> У меня - ни одного.

Ну вот это PVS'ом не нашлось, например: https://github.com/0xd34df00d/leechcraft/commit/8b8156678474... , а кланг после вот этого вот я прямо зауважал. Хотя дело под год назад было, да.
Да и PVS очень плохо относился к C++11, было суммарно с дюжину файлов, где он упал. clang сдох всего на двух.

Ответить | Правка | Наверх | Cообщить модератору

96. "В DNS-сервере BIND устранен серьёзный сбой, возникший из-за ..."  –2 +/
Сообщение от pv47 (ok), 13-Июн-14, 22:31 
> Есть у меня один знакомый, который как раз поэтому gcc и обожает,
> что там код работает на 5-10% быстрее, чем в clang, как
> правило.

если код твоего знакомого работает на 10% быстрее в gcc, чем в шланге, за счёт таких оптимизаций, то у меня для него плохие новости: у него в коде куча лишних проверок, которые он почему-то не выкинул сам. наверное, это как раз тот случай, когда компилятор умнее человека.

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

Ответить | Правка | К родителю #59 | Наверх | Cообщить модератору

98. "В DNS-сервере BIND устранен серьёзный сбой, возникший из-за ..."  +/
Сообщение от 0xd34df00d (??), 13-Июн-14, 22:33 
>> Есть у меня один знакомый, который как раз поэтому gcc и обожает,
>> что там код работает на 5-10% быстрее, чем в clang, как
>> правило.
> если код твоего знакомого работает на 10% быстрее в gcc, чем в
> шланге, за счёт таких оптимизаций, то у меня для него плохие
> новости: у него в коде куча лишних проверок, которые он почему-то
> не выкинул сам. наверное, это как раз тот случай, когда компилятор
> умнее человека.

Не код моего знакомого. Он всякими там povray бенчмаркает.

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

Нечем тут гордиться. И не гордиться, впрочем, тоже.

Ответить | Правка | Наверх | Cообщить модератору

118. "В DNS-сервере BIND устранен серьёзный сбой, возникший..."  +/
Сообщение от arisu (ok), 14-Июн-14, 13:36 
> у него в коде куча лишних проверок, которые он почему-то не выкинул сам.

вышепроцитированное — реакция школоты на assert()'ы, например.

Ответить | Правка | К родителю #96 | Наверх | Cообщить модератору

131. "В DNS-сервере BIND устранен серьёзный сбой, возникший из-за ..."  –1 +/
Сообщение от Reinar (ok), 14-Июн-14, 16:36 
> если код твоего знакомого работает на 10% быстрее в gcc, чем в шланге, за счёт таких оптимизаций, то у меня для него плохие новости: у него в коде куча лишних проверок

Если код работает на 10% быстрее после выкидывания "лишних" проверок, то этот код практически целиком состоит из проверок.

Ответить | Правка | К родителю #96 | Наверх | Cообщить модератору

245. "В DNS-сервере BIND устранен серьёзный сбой, возникший из-за ..."  +/
Сообщение от Demo (??), 14-Июн-14, 23:54 
$ traceroute 0xd34df00d
traceroute to 0xd34df00d (211.77.240.13) 211-77-240-13.adsl.fetnet.net
...
10  h33-192-72-155.seed.net.tw (192.72.155.33)  320.941 ms
...
Ответить | Правка | К родителю #59 | Наверх | Cообщить модератору

247. "В DNS-сервере BIND устранен серьёзный сбой, возникший из-за ..."  +/
Сообщение от 0xd34df00d (??), 15-Июн-14, 00:00 
> $ traceroute 0xd34df00d
> traceroute to 0xd34df00d (211.77.240.13) 211-77-240-13.adsl.fetnet.net
> ...
> 10  h33-192-72-155.seed.net.tw (192.72.155.33)  320.941 ms
> ...

0xd34df00d.me трейсить надо.

Ответить | Правка | Наверх | Cообщить модератору

117. "В DNS-сервере BIND устранен серьёзный сбой, возникший..."  +/
Сообщение от arisu (ok), 14-Июн-14, 13:32 
> Ну так -O3 уже никто и не включает. Или пацаны хотят добиться,
> что и -O2 включать не будут?

пацаны хотят, чтобы говнокодеры документацию читали сначала.

уж от тебя-то я не ожидал такой позиции.

Ответить | Правка | К родителю #58 | Наверх | Cообщить модератору

266. "В DNS-сервере BIND устранен серьёзный сбой, возникший из-за ..."  +1 +/
Сообщение от Аноним (-), 15-Июн-14, 16:08 
> Причём, как это обычно у gccшников, без объявления войны. Хотя бы предупреждения
> о выбрасывании кода можно было выкинуть. Ну, типа unreachable code.

Release Notes к gcc 4.9 почитайте. И Porting to, если вам мало.

Ответить | Правка | К родителю #58 | Наверх | Cообщить модератору

109. "В DNS-сервере BIND устранен серьёзный сбой, возникший из-за ..."  +/
Сообщение от Anonym2 (?), 14-Июн-14, 01:46 
>> Вот последнюю проверку компилятор вполне имеет право удалить
> В мире эльфов - да. Всё-таки, вера в то, что компилятору не
> придётся обрабатывать код с ошибками, в высшей степени наивна.

И разработчики GCC вряд ли страдают этой верой.
Кстати, foo->bar компилятор тоже вправе удалить... >:-)

Ответить | Правка | К родителю #46 | Наверх | Cообщить модератору

116. "В DNS-сервере BIND устранен серьёзный сбой, возникший..."  +2 +/
Сообщение от arisu (ok), 14-Июн-14, 13:31 
>> Вот последнюю проверку компилятор вполне имеет право удалить
> В мире эльфов - да. Всё-таки, вера в то, что компилятору не
> придётся обрабатывать код с ошибками, в высшей степени наивна.

для идиотов есть режим -O0. в документации по gcc ясно написано, что корректность выхлопа оптимизатора гарантируется *только* для корректных программ. если авторы подсунули компилятору говнокод, то они сами и виноваты.

Ответить | Правка | К родителю #46 | Наверх | Cообщить модератору

296. "В DNS-сервере BIND устранен серьёзный сбой, возникший..."  –1 +/
Сообщение от КО (?), 16-Июн-14, 11:44 
> корректность выхлопа оптимизатора гарантируется *только* для корректных программ

if (a) {
   mtx.lock();
    if (a) {  // явно же лишняя проверка - только что проверили.

Ответить | Правка | Наверх | Cообщить модератору

298. "В DNS-сервере BIND устранен серьёзный сбой, возникший..."  +2 +/
Сообщение от arisu (ok), 16-Июн-14, 11:53 
>> корректность выхлопа оптимизатора гарантируется *только* для корректных программ
>  if (a) {
>    mtx.lock();
>     if (a) {  // явно же лишняя
> проверка - только что проверили.

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

такие дела.

Ответить | Правка | Наверх | Cообщить модератору

305. "В DNS-сервере BIND устранен серьёзный сбой, возникший..."  +/
Сообщение от 0xd34df00d (ok), 16-Июн-14, 17:40 
>>> корректность выхлопа оптимизатора гарантируется *только* для корректных программ
>>  if (a) {
>>    mtx.lock();
>>     if (a) {  // явно же лишняя
>> проверка - только что проверили.
> конечно, лишняя. если ты меняешь переменную из разных потоков и не объявил
> её volatile — ты идиот, а твой код говно.

Не всё так просто, см. страницу 7 здесь: http://www.aristeia.com/Papers/DDJ_Jul_Aug_2004_revised.pdf

Правда, то в приложении к синглтонам.

Ответить | Правка | Наверх | Cообщить модератору

307. "В DNS-сервере BIND устранен серьёзный сбой, возникший..."  +/
Сообщение от arisu (ok), 16-Июн-14, 20:43 
да, я в курсе, что volatile — не такая уж простая и лёгкая штука. ну, и welcome в область нестандартного — read and write barriers в gcc, например…
Ответить | Правка | Наверх | Cообщить модератору

299. "В DNS-сервере BIND устранен серьёзный сбой, возникший..."  +1 +/
Сообщение от arisu (ok), 16-Июн-14, 11:54 
p.s. да, компилятор имеет право проанализировать метод lock(), увидеть, что a там не меняется и выкинуть проверку нафиг.
Ответить | Правка | К родителю #296 | Наверх | Cообщить модератору

304. "В DNS-сервере BIND устранен серьёзный сбой, возникший..."  +/
Сообщение от 0xd34df00d (??), 16-Июн-14, 17:37 
>  if (a) {
>    mtx.lock();
>     if (a) {  // явно же лишняя
> проверка - только что проверили.

Ну так в C++ до 11 не было memory model, машина представлялась однопоточной. Это уже проблема языка и стандарта, а не компилятора.

Ответить | Правка | К родителю #296 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

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