The OpenNET Project / Index page

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

Влияние несущественных изменений кода на производительность при использовании GCC

09.10.2018 08:53

Nadav Amit, разработчик ядра Linux из компании VMware, поделился результатом исследования особенностей оптимизации в GCC небольших функций ядра. Исследование было проведено после того, как разработчик столкнулся с непонятным феноменом - внесение несущественных изменений в код ядра, приводило к небольшому, но заметному снижению производительности в тестах. Примечательно, что подобные вносимые изменения были оптимизациями и теоретически должны были увеличить производительность, но на деле производительность падала.

Дело оказалось в том, что GCC принимает решение об использовании inline-развёртывания функций в зависимости от результатов косвенной оценки размера результирующего кода (даже если функция определена с ключевым словом "inline"). Компилятор не учитывает фактический размер результирующего кода, а пытается прогнозировать его. Для ассемблерных вставок прогнозирование делается на основе числа переводов строк ("\n") и разделителей (";") в исходном тексте.

Логика подобного расчёта связана с допуском, что одна строка представляет собой одну ассемблерную инструкцию. Но при этом не учитываются ситуации, когда в ассемблерных вставках применяется большое число директив для вычислений, несколько строк которых в результате приводят к генерации лишь одной небольшой инструкции. Подобная особенность может приводить к таким казусам как снижение производительности при добавлении несущественных макросов. Некоторые разработчики отмечают влияние на inline-развёртывание в новых версиях GCC даже замены символов табуляции на пробелы.

Разница в производительности особенно бросается в глаза для функций с ассемблерными вставками, для которых добавляется излишняя обёртка вместо прямой подстановки нескольких указанных в функции инструкций. В ядре Linux проблему представляют компактные функции с макросами WARN(), для которых оказалось, что не выполняется ожидаемая inline-оптимизация.

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

  1. Главная ссылка к новости (https://news.ycombinator.com/i...)
  2. OpenNews: Оптимизация кода компилятором может привести к появлению проблем безопасности в приложениях
  3. OpenNews: Линус Торвальдс выступил с резкой критикой GCC 4.9.0
  4. OpenNews: В DNS-сервере BIND устранен серьёзный сбой, возникший из-за изменений в оптимизаторе GCC
  5. OpenNews: Разработчики Mozilla столкнулись с проблемой производительности в GCC 4.5
  6. OpenNews: Обзор проблем в коде на C/C++, вызванных неопределённым поведением компилятора
Лицензия: CC-BY
Тип: Тема для размышления
Ключевые слова: gcc, optimization
При перепечатке указание ссылки на opennet.ru обязательно
Обсуждение (81) Ajax | 1 уровень | Линейный | Раскрыть всё | RSS
  • 1.1, Аноним (1), 11:13, 09/10/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • –7 +/
    >Дело оказалось в том, что GCC принимает решение об использовании inline-развёртывания функций в зависимости от результатов косвенной оценки размера результирующего кода (даже если функция определена с ключевым словом "inline").

    GCC теперь Apple пишет? "Мы знаем лучше что вам надо"?

     
     
  • 2.5, пох (?), 11:30, 09/10/2018 [^] [^^] [^^^] [ответить]  
  • +9 +/
    inline _всегда_ был _хинтом_ компилятору, что вот это вот имеет смысл попробовать сделать inline, а не директивным указанием. Точно так же как пресловутый register в определении переменных.

    > GCC теперь Apple пишет? "Мы знаем лучше что вам надо"?

    apple занят, он пишет llvm, и у него все хорошо с инлайнами (кроме несовместимости очень старого gcc кода). Проблема гнутых обезьянок в том, что они как раз не знают лучше, и добавили нечеловеческой логики в это незнание.

     
     
  • 3.69, Аноним (-), 10:10, 12/10/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Register так вообще считается deprecated, в плюсах им вообще пользоваться не сле... текст свёрнут, показать
     
     
  • 4.74, пох (?), 10:24, 12/10/2018 [^] [^^] [^^^] [ответить]  
  • +/
    > Потому что пытаться хинтить компилятору аллокацию регистров - дело тухлое.

    смотря на какой архитектуре.

    > В остальных случаях компилятор и сам догадывается как регистры раскинуть,

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

     
  • 4.77, Аноним (77), 12:07, 12/10/2018 [^] [^^] [^^^] [ответить]  
  • +/
    >сам догадывается

    я проверял, у меня он догадывался на простом счётчике для перебора массива только после компиляции с инфой профилирования (pgo), разница производительности что-то там в районе 3-4 порядков была. Просто космос. Добиться такого же результата позволяло добавление register, поэтому говорить можно что угодно.

     
  • 4.78, Аноним (78), 14:04, 12/10/2018 [^] [^^] [^^^] [ответить]  
  • +/
    > Register так вообще считается deprecated, в плюсах им вообще пользоваться не следует.

    Да-да. Давеча вот такое видел от GCC 8:

    warning: ISO C++17 does not allow ‘register’ storage class specifier [-Wregister]

     
  • 3.85, irinat (ok), 00:11, 21/10/2018 [^] [^^] [^^^] [ответить]  
  • +/
    inline был хинтом компилятору только в расширениях gnu89. В c99 ввели понятие inline, и оно с тех пор не связано с инлайнингом напрямую.
     
  • 2.14, Аноним (14), 12:47, 09/10/2018 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Это зачатки ИИ :-) , в среднем хорошо но в отдельных местах...
     
     
  • 3.56, Аноним (56), 11:36, 10/10/2018 [^] [^^] [^^^] [ответить]  
  • +/
    ... и если приблизить, то мы увидим 12 новых if.
     

  • 1.3, eganru (?), 11:14, 09/10/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    можно делать __attribute__((always_inline)), если требуется всегда inline.

    [i]настоящее время единственным способом убедиться, что код сгенерирован именно так как рассчитывал разработчик остаётся ручное инспектирование итоговых машинных инструкций. [/i] - единственный способ понять, правильно ли сгенерировалось - посмотреть асм листинг. по моему опыту значительная часть разработчиков не будут читать листинг.

     
     
  • 2.10, Аноним (10), 11:51, 09/10/2018 [^] [^^] [^^^] [ответить]  
  • –3 +/
    автор статьи там написал, почему always_inline - не решение проблемы. Но вы, конечно, ее не читали
     
     
  • 3.29, eganru (?), 14:24, 09/10/2018 [^] [^^] [^^^] [ответить]  
  • +2 +/
    читал.
    Вы не читали или не разобрались в сути вопроса.
    случаи там рассмотренные вполне можно было бы решить с помощью always_inline.
    рассматривался допустим
    static inline void *kzalloc(size_t size, gfp_t flags)
    который вызывает kmalloc, который по заверениям always_inline, и результирующий код не дает компилятору дважды выполнить подстановку кода.
    можно было бы бахнуть always_inline и выполнило бы подстановку дважды.

    то что функции-обертки волшебным образом не наследуют атрибуты или какие-то свойства пожалуй известно всем.

     
  • 3.33, Аноним (78), 15:01, 09/10/2018 [^] [^^] [^^^] [ответить]  
  • +/
    А вы так усердно читали, что мысленно вписали в статью того, чего там нет. :)
     

  • 1.4, Аноним (4), 11:21, 09/10/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • +16 +/
    Нужно новое ключевое слово really_inline.
     
     
  • 2.7, eganru (?), 11:32, 09/10/2018 [^] [^^] [^^^] [ответить]  
  • –2 +/
    [i]Нужно новое ключевое слово really_inline.[/i] - кому нужно-то? Вы можете сделать inline силой с помощью атрибута. только в 9 случаях из 10 это не нужно.
     
  • 2.8, Аноним (8), 11:38, 09/10/2018 [^] [^^] [^^^] [ответить]  
  • +/
    __attribute__((always_inline))
     
     
  • 3.12, Аноним (4), 12:19, 09/10/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Нестандартненько.
     
  • 2.24, Аноним (24), 14:00, 09/10/2018 [^] [^^] [^^^] [ответить]  
  • +4 +/
    в_натуре(__inline__)

    :)

     
     
  • 3.54, Аноним (54), 09:50, 10/10/2018 [^] [^^] [^^^] [ответить]  
  • –1 +/
    без_базара(--inline__)
     

  • 1.6, пох (?), 11:32, 09/10/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • +32 +/
    "примечательно", что этот пакистанец, кажется, на самом деле тестировал свои оптимизации на предмет реально ли они оптимизируют.
    Вот это - действительно неожиданный ход.

     
     
  • 2.66, J.L. (?), 12:36, 11/10/2018 [^] [^^] [^^^] [ответить]  
  • +/
    > "примечательно", что этот пакистанец, кажется, на самом деле тестировал свои оптимизации
    > на предмет реально ли они оптимизируют.
    > Вот это - действительно неожиданный ход.

    теперь я знаю чем пакистан от индии отличаются, раньше я их не различал

     
     
  • 3.67, Аноним (78), 14:44, 11/10/2018 [^] [^^] [^^^] [ответить]  
  • +/
    > теперь я знаю чем пакистан от индии отличаются, раньше я их не
    > различал

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

     
  • 3.75, пох (?), 10:28, 12/10/2018 [^] [^^] [^^^] [ответить]  
  • +/
    > теперь я знаю чем пакистан от индии отличаются, раньше я их не
    > различал

    в Индии помимо Кумаров тоже встречаются всякие Джавахарлалы, первые делают тупенько, за вторыми замучаешься распутывать, что они там наоптимизировали и почему ты одну строчку добавил а оно стало медленнее в сто раз. Хз, на самом деле, что хуже.

    видимо, зависит от сорта плана, который растет именно в этой местности.

     
  • 2.68, voleg (?), 22:49, 11/10/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Израиль не Пакистан. А мужичек сам в штатах.
     

  • 1.9, ыы (?), 11:43, 09/10/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • +13 +/
    "
    Влияние числа переводов строк и разделителей в исходном тексте программ на быстродействие скомпилированного кода
    "

    Эпично.


     
     
  • 2.15, Аноним (14), 12:49, 09/10/2018 [^] [^^] [^^^] [ответить]  
  • +1 +/
    ИИ в компиляторах...
     
  • 2.22, Аноним84701 (ok), 13:41, 09/10/2018 [^] [^^] [^^^] [ответить]  
  • +7 +/
    > Эпично.

    Вы явно недооцениваете "взрывно-поджигательный" потенциал предложения:
    > "влияние на inline-развёртывание в новых версиях GCC даже замены символов табуляции на пробелы."
    > identical functions that used spaces instead of tabs could run significantly slower because they weren't inlined.

    в любом сра^W обсуждении на опеннете новости о  питоне (или чем-то питоноподобном), где примерно 2/3 комментариев рассматривают (не)допустимость ущемления прав разработчика на свободное оформление кода, глубинную (не)правильность влияния пробелов на семантику ЯП (и общее  влияние на интеллект, сексуальные пристрастия или некоторые анатомические детали, вроде кривизны или места крепления верхних конечностей).

     
     
  • 3.44, Аноним (44), 18:19, 09/10/2018 [^] [^^] [^^^] [ответить]  
  • +/
    > глубинную (не)правильность влияния пробелов на семантику ЯП

    На семантику оно и не влияет.

     
     
  • 4.49, Аноним84701 (ok), 21:04, 09/10/2018 [^] [^^] [^^^] [ответить]  
  • +1 +/
    >> глубинную (не)правильность влияния пробелов на семантику ЯП
    > На семантику оно и не влияет.

    Даже если бы и не влияло (что не так[0]) -- таки уп0pно обуждают.
    Из недавнего: https://www.opennet.ru/openforum/vsluhforumID3/115403.html#63

    [0]
    [code]
    while True:
        ...
        if something < X:
          result.add(Y)
        break
    [/code]
    +1 Tab
    [code]
    while True:
        ...
        if something < X:
            result.add(Y)
            break
    [/code]

     
     
  • 5.82, Аноним (44), 19:10, 15/10/2018 [^] [^^] [^^^] [ответить]  
  • +/
    При чем здесь питон? Речь про C/C++.
     
  • 3.52, Акакжев (?), 06:43, 10/10/2018 [^] [^^] [^^^] [ответить]  
  • +/
    > Вы явно недооцениваете "взрывно-поджигательный" потенциал предложения:
    >> "влияние на inline-развёртывание в новых версиях GCC даже замены символов табуляции на пробелы."

    private\windows\media\avi\verinfo.16\verinfo.h:
    [CODE]
    * !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
    * !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
    * !!!!!!!IF YOU CHANGE TABS TO SPACES, YOU WILL BE KILLED!!!!!!!
    * !!!!!!!!!!!!!!DOING SO [ВЦ.] THE BUILD PROCESS!!!!!!!!!!!!!!!!
    * !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
    * !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
    [/CODE]

     

  • 1.11, IRASoldier (?), 12:18, 09/10/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • –8 +/
    Мне вот интересно, какому "умному" человеку пришло в голову внести в gcc т.н. GNU Extensions, которые разрешают, например, указывать размер статического (Карл!) массива в рантайме... Кому это было нужно? Ниасиляторам С и плюсов?
     
     
  • 2.18, Акакжев (?), 13:05, 09/10/2018 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Тому, кто потом в Комитете принимает решения по следующему Стандарту, куда расширения языка постепенно включаются.
     
     
  • 3.20, IRASoldier (?), 13:24, 09/10/2018 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Приведенный пример с массивами - это не расширение языка, это радикальное изменение.
     
  • 2.23, анонимный анонимус2 (?), 13:45, 09/10/2018 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Это расширение только для С++, для С99 это стандарт.
     
     
  • 3.27, IRASoldier (?), 14:10, 09/10/2018 [^] [^^] [^^^] [ответить]  
  • –2 +/
    А в C11 опять VLA не одобряэ... Путаники-с.
     
  • 2.26, Alex (??), 14:05, 09/10/2018 [^] [^^] [^^^] [ответить]  
  • +4 +/
    не статического массива а массива на стеке, дятел. Разница в том что это довольно просто реализовать, удобно, и не ломает язык. И да, это входит в c99 сейчас, наверняка войдет и в c++2x
     
     
  • 3.28, IRASoldier (?), 14:15, 09/10/2018 [^] [^^] [^^^] [ответить]  
  • –6 +/
    > не статического массива а массива на стеке, дятел.

    От дятла слышу. Всю жизнь использовали в повседневной речи - "статический" и продолжают использовать.

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

    Это может привести к undefined behavior если попытка выделения памяти окончилась фейлом.


     
     
  • 4.30, Аноним (30), 14:26, 09/10/2018 [^] [^^] [^^^] [ответить]  
  • +2 +/
    ПОловина софта не проверяет даже malloс на NULL...
     
  • 4.34, Аноним (34), 15:12, 09/10/2018 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Любое использование стека может привести к UB. На деле, кому надо обрабатывают SIGSEGV, а остальным плевать
     
  • 4.35, Аноним (78), 15:12, 09/10/2018 [^] [^^] [^^^] [ответить]  
  • +5 +/
    > Это может привести к undefined behavior если попытка выделения памяти окончилась фейлом.

    Это справедливо также если размер массива определяется во время компиляции. Компилятор то не знает, сколько там во время выполнения реально свободного стека останется. Будет такое "статическое" undefined behavior. :)

     
  • 4.37, Акакжев (?), 15:20, 09/10/2018 [^] [^^] [^^^] [ответить]  
  • +6 +/
    > Всю жизнь использовали в повседневной речи - "статический" и продолжают использовать.

    "Объекты c [I]static storage duration[/I] инициализируются до [I]program startup[/I]."

     
  • 4.38, Омоним (?), 16:23, 09/10/2018 [^] [^^] [^^^] [ответить]  
  • +5 +/
    > Всю жизнь использовали в повседневной речи - "статический" и продолжают использовать.

    Игнорируя, что в общепринятом смысле "динамичность"/"статичность" относятся не к изменяемости/константности размера объекта, а к типу его жизненного цикла, которых не джва, а три: "динамические" (живут неоговоренное время на куче), "статические" (живут всё время исполнения программы в заранее отведённой памяти) и "автоматические" (живут в кадре стэка (* храниться могут и в регистрах процессора, а не непосредственно в ОЗУ) и к "статическим" таки не относятся).

     
     
  • 5.47, IRASoldier (?), 19:46, 09/10/2018 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Не "игнорируя", а просто используя в определенном, заранее подразумеваемом контексте.
     
     
  • 6.48, Аноним (44), 19:52, 09/10/2018 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Кем подразумеваемом? В каком контексте? "Статический массив" - вполне допустимое выражение, которое значит совсем не то, что "массив на стеке".
     
  • 3.81, 0xd34df00d (??), 03:28, 13/10/2018 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > наверняка войдет и в c++2x

    Оно не войдет в C++ никогда, ибо ломает систему типов рядом с темплейтами.

     
  • 2.70, Аноним (-), 10:13, 12/10/2018 [^] [^^] [^^^] [ответить]  
  • +/
    > Мне вот интересно, какому "умному" человеку пришло в голову внести в gcc
    > т.н. GNU Extensions, которые разрешают, например, указывать размер статического (Карл!)
    > массива в рантайме... Кому это было нужно? Ниасиляторам С и плюсов?

    Вообще-то это часть стандарта C ... с 99 года аж. Туда же и всякие variable args и проч. Полезные между прочим штуки. И раздуплятся ли стандартизаторы - черт его знает, но все этим пользуются. Тот же шланг этому тоже научился. И без них иногда как-то душно.

     
     
  • 3.76, Andrey Mitrofanov (?), 10:32, 12/10/2018 [^] [^^] [^^^] [ответить]  
  • +/
    >черт его знает, но все этим пользуются.

    Некоторые уже напользовались -- избавиться никак не  могут.

    Старик Крупский, вот например, неполиткорректно против.
       https://lwn.net/Articles/749064/
       https://lwn.net/Articles/763641/
       https://lwn.net/Articles/764325/
      
    > Тот же шланг этому тоже научился. И без них иногда как-то

    Вы с "прогрессивным" человечеством, я вижу, на защите чести и свобод?

    Надо успеть, пока супостат не вернулся с "ретрита".

    > душно.

     

  • 1.13, Аноним (13), 12:23, 09/10/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    >  В настоящее время единственным способом убедиться, что код сгенерирован именно так как рассчитывал разработчик остаётся ручное инспектирование итоговых машинных инструкций.

    Ну так одно другому не мешает и бенмарки неплохо бы иметь. А то выйдет новая-кленовая версия компилятора с другим эвристиками и снова все просядет... или нет.

     
  • 1.16, Акакжев (?), 12:53, 09/10/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    Теория:

    -O turns on the following optimization flags:
    ...
    -fomit-frame-pointer

    Практика:

    0xffffffff817929e0 <+0>: push   %rbp
    ...
    0xffffffff817929ee <+14>: pop    %rbp
    0xffffffff817929ef <+15>: retq  

     
     
  • 2.21, Аноним (21), 13:34, 09/10/2018 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Данной оптимизация отключена, поскольку обратная опция находится в зависимостях других опций вроде C++ исключений. Без которых GCC не может сгенерировать рабочий код. Доходит до абсурда когда stack-frame создаётся в абсолютно пустых функциях.
     
     
  • 3.31, Акакжев (?), 14:37, 09/10/2018 [^] [^^] [^^^] [ответить]  
  • +/
    По поводу других в документации сказано Omit the frame pointer in functions ... текст свёрнут, показать
     
  • 3.59, Himik (ok), 19:26, 10/10/2018 [^] [^^] [^^^] [ответить]  
  • –1 +/
    push %rbp и pop %rbp не имеют ни какого отношения к стеку, это просто сохранение регистра для использования в вычислениях функции. Раньше rbp использовался для буфера в стеке, теперь нет.
     
     
  • 4.64, Акакжев (?), 08:32, 11/10/2018 [^] [^^] [^^^] [ответить]  
  • +/
    > push %rbp и pop %rbp не имеют ни какого отношения к стеку,
    > это просто сохранение регистра для использования в вычислениях функции. Раньше rbp
    > использовался для буфера в стеке, теперь нет.

    Вот подпрограмма целиком:
    [CODE]
    0xffffffff817929e0 <+0>: push   %rbp
    0xffffffff817929e1 <+1>: mov    $0x14080c0,%esi
    0xffffffff817929e6 <+6>: mov    %rsp,%rbp
    0xffffffff817929e9 <+9>: callq  0xffffffff8125d590 <__kmalloc>
    0xffffffff817929ee <+14>: pop    %rbp
    0xffffffff817929ef <+15>: retq  
    [/CODE]
    mov    %rsp,%rbp — формирование фрейма, который не используется.

     

  • 1.19, z (??), 13:11, 09/10/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • –5 +/
    И эти люди ещё ругают MSVC за изначальный отказ от inline-инструкций в x86_64 как класса =)
     
     
  • 2.71, Аноним (-), 10:17, 12/10/2018 [^] [^^] [^^^] [ответить]  
  • +/
    > И эти люди ещё ругают MSVC за изначальный отказ от inline-инструкций в
    > x86_64 как класса =)

    Дык msvc и C99 не особо поддерживает. Там народ недавно нашел брутальные факапы с этим даже в распоследней студии, которая выдает совершенно левые варнинги на валидный код. В общем, студия у ms тоже сдулась. Наверное мы по мнению MS должны в ядра операционок и прочие микроконтроллеры 17-е плюсы пихать, или дотнет. Главное не забудьте потом ремни пристегнуть - иначе по асфальту такая фирмварь вас все же размажет...

     

  • 1.32, Анониметс (?), 14:39, 09/10/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • –4 +/
    Кто все эти люди, что это за язык? Ни одного слова не понял ни из комментов, ни из статьи. Чьто это? Где я?)
     
     
  • 2.36, Аноним (78), 15:15, 09/10/2018 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Это GCC, братан
     
  • 2.39, Аноним (39), 16:40, 09/10/2018 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Ну раз речь о ядре Линукса, то догадайся)
     
     
  • 3.41, Аноним84701 (ok), 17:03, 09/10/2018 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Ну раз речь о ядре Линукса, то догадайся)

    Кто ж его знает -- может у него сейчас 2088, ядро в третий раз переписали, в GCC древний Си заменили на архаичный Оксид (а плюсы вообще исключили из набора, т.к c++73 и выше может разоборать только ИИ, с помощью машины Типпетта-Цанга умеющий передавать информацию самому себе в прошлое)?

     
  • 2.42, Аноним (42), 17:06, 09/10/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Assembly Language
    GCC – GNU Compiler Collection
    Про инлайнинг сами попгуглите.
     
  • 2.60, Himik (ok), 19:32, 10/10/2018 [^] [^^] [^^^] [ответить]  
  • –1 +/
    GNU C Compiler = GCC.
    Не путать с GNU Compiler Collection, такого языка программирования нет.
     

  • 1.40, Cradle (?), 16:48, 09/10/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    немного не в тему, но может кто подскажет, такая проблемка: использую arm-none-eabi-gcc-7.2.1 с cmake , и результаты оптимизации как-то сильно зависят от cmake кэша, процентов на 10 размер бинарника разный выходит, при том что реально разные варианты кода в пределах тех же самых функций получаются, проверял ассемлерные дампы. Пока лечится стиранием директории CMakeFiles, но может есть более умное решение?
     
     
  • 2.61, Himik (ok), 19:36, 10/10/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Не знаю точно, но может быть поможет export LDFLAGS='-s'
    чтобы вырезалась (strip) служебная информация из конечного результата.
     
     
  • 3.63, Cradle (?), 20:53, 10/10/2018 [^] [^^] [^^^] [ответить]  
  • +/
    нет, дело не в этом, я сравниваю дампы и размер бинарника уже после strip. На функцинальность эта проблема особо не влияет, но пока работаю над кодом в течении дня к бинарнику несколько кб мусора приростает. Приходится каждый раз когда нужно узнать точный размер или коллегам прошивку передать стирать CMakeFiles и пересобирать начисто.
     
     
  • 4.65, Sfinx (ok), 11:07, 11/10/2018 [^] [^^] [^^^] [ответить]  
  • +/
    включаешь verbose и смотришь опции компиляции или включаешь -frecord-gcc-switches и смотришь в бинарнике до стрипа.
     

  • 1.43, Аноним (43), 18:08, 09/10/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    Линус недавно устроил голвомойку разработчикам GCC за глюки в версии 4.9, кажется. Похоже, пора устроить её снова!
     
     
  • 2.45, Аноним (45), 18:56, 09/10/2018 [^] [^^] [^^^] [ответить]  
  • –1 +/
    А то что? На шланг перейдёт? Ну наконец-то в ядро примут патчи совместимости со шлангом.
     
     
  • 3.46, KonstantinB (ok), 19:09, 09/10/2018 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Или clang достигнет критического уровня совместимости с расширениями gcc.
    Собственно, уже большая часть кода ядра прекрасно собирается.
     
     
  • 4.72, Аноним (-), 10:19, 12/10/2018 [^] [^^] [^^^] [ответить]  
  • +/
    > Собственно, уже большая часть кода ядра прекрасно собирается.

    "Немножечко беременна".

     

  • 1.50, Дуплик (ok), 02:16, 10/10/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    Скорее бы Linux портировали на Clang/LLVM.
     
     
  • 2.62, Himik (ok), 19:38, 10/10/2018 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Нет, уж лучше старые глюки, чем новые.
     
  • 2.73, Аноним (-), 10:21, 12/10/2018 [^] [^^] [^^^] [ответить]  
  • +/
    > Скорее бы Linux портировали на Clang/LLVM.

    Мечтаешь увидеть проприерасские SDK к железкам, где даже сорц компилера зажали? Так что потом под эту архитектуру будет только какой-то левый блоб, под какой-нибудь 32-битный рхел 6, потому что у разработчиков видите ли было вот это, а если вы не похожи на 32-битный 6-й рхел... то черт его знает, виртуалочку чтоли запустите для пересборки, все дела, мде?

     

  • 1.51, Аноним (51), 03:04, 10/10/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • –3 +/
    > Некоторые разработчики отмечают влияние на inline-развёртывание в новых версиях GCC даже замены символов табуляции на пробелы.

    При чем тут gcc вообще? Коммент по ссылке про v8 (движок JavaScript).

     
     
  • 2.53, Аноним (53), 06:51, 10/10/2018 [^] [^^] [^^^] [ответить]  
  • +/
    > При чем тут gcc вообще?

    Там речь про GCC v8.

    > Коммент по ссылке про v8 (движок JavaScript).

    А в этом же комментарии упоминание v5.9 тогда про какой движок и откуда в  JavaScript-движке "inline assembly"?

     
     
  • 3.57, Аноним (56), 11:45, 10/10/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Web Assembly? Он вроде позваляет на любом языке писать.
     
     
  • 4.58, Himik (ok), 19:21, 10/10/2018 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Web Assembly в Linux kernel?
     
     
  • 5.80, sage (??), 19:34, 12/10/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Да. https://github.com/rianhunter/wasmjit
     
  • 3.83, Аноним (44), 19:15, 15/10/2018 [^] [^^] [^^^] [ответить]  
  • +/
    JavaScript движок под названием V8, версия движка 5.9. Что не понятно?
     
  • 3.84, Аноним (44), 19:43, 15/10/2018 [^] [^^] [^^^] [ответить]  
  • +/
    > откуда в  JavaScript-движке "inline assembly"?

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

     

  • 1.79, Andrey Mitrofanov (?), 17:34, 12/10/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Удивиился, что не Фороникс,
       https://lwn.net/Articles/767884/rss
    обнаружив сабж на.

    Бывает же?!

     

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



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

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