| 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 +/– |
Это зачатки ИИ :-) , в среднем хорошо но в отдельных местах...
| | |
|
| 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 [^] [^^] [^^^] [ответить]
| +/– |
А вы так усердно читали, что мысленно вписали в статью того, чего там нет. :)
| | |
|
|
| |
| 2.7, eganru (?), 11:32, 09/10/2018 [^] [^^] [^^^] [ответить]
| –2 +/– |
[i]Нужно новое ключевое слово really_inline.[/i] - кому нужно-то? Вы можете сделать inline силой с помощью атрибута. только в 9 случаях из 10 это не нужно.
| | |
|
| 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 [^] [^^] [^^^] [ответить]
| +/– |
> теперь я знаю чем пакистан от индии отличаются, раньше я их не
> различал
в Индии помимо Кумаров тоже встречаются всякие Джавахарлалы, первые делают тупенько, за вторыми замучаешься распутывать, что они там наоптимизировали и почему ты одну строчку добавил а оно стало медленнее в сто раз. Хз, на самом деле, что хуже.
видимо, зависит от сорта плана, который растет именно в этой местности.
| | |
|
|
| 1.9, ыы (?), 11:43, 09/10/2018 [ответить] [﹢﹢﹢] [ · · · ]
| +13 +/– |
"
Влияние числа переводов строк и разделителей в исходном тексте программ на быстродействие скомпилированного кода
"
Эпично.
| | |
| |
| 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 [^] [^^] [^^^] [ответить]
| +/– | |
> глубинную (не)правильность влияния пробелов на семантику ЯП
На семантику оно и не влияет.
| | |
| 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.26, Alex (??), 14:05, 09/10/2018 [^] [^^] [^^^] [ответить]
| +4 +/– |
не статического массива а массива на стеке, дятел. Разница в том что это довольно просто реализовать, удобно, и не ломает язык. И да, это входит в c99 сейчас, наверняка войдет и в c++2x
| | |
| |
| 3.28, IRASoldier (?), 14:15, 09/10/2018 [^] [^^] [^^^] [ответить]
| –6 +/– | |
> не статического массива а массива на стеке, дятел.
От дятла слышу. Всю жизнь использовали в повседневной речи - "статический" и продолжают использовать.
> это довольно просто реализовать, удобно, и не ломает язык
Это может привести к undefined behavior если попытка выделения памяти окончилась фейлом.
| | |
| |
| 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 и проч. Полезные между прочим штуки. И раздуплятся ли стандартизаторы - черт его знает, но все этим пользуются. Тот же шланг этому тоже научился. И без них иногда как-то душно.
| | |
|
| 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 +/– |
 Кто все эти люди, что это за язык? Ни одного слова не понял ни из комментов, ни из статьи. Чьто это? Где я?)
| | |
| |
| |
| 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 [^] [^^] [^^^] [ответить]
| +/– | |
> Собственно, уже большая часть кода ядра прекрасно собирается.
"Немножечко беременна".
| | |
|
|
|
| |
| 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.83, Аноним (44), 19:15, 15/10/2018 [^] [^^] [^^^] [ответить]
| +/– |
JavaScript движок под названием V8, версия движка 5.9. Что не понятно?
| | |
| 3.84, Аноним (44), 19:43, 15/10/2018 [^] [^^] [^^^] [ответить]
| +/– | |
> откуда в JavaScript-движке "inline assembly"?
V8 генерирует машинный код. При этом часть функций инлайнится, так же как и при компиляции из других языков. Решение о том, инлайнить код или нет, судя по комментарию, принимается с учетом пробелов.
| | |
|
|
|
