forum.opennet.ru - "Влияние несущественных изменений кода на производительность ..." (81)

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

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

"Влияние несущественных изменений кода на производительность ..."	+/–
Сообщение от opennews (??), 09-Окт-18, 11:13
Nadav Amit, разработчик ядра Linux из компании VMware, поделился (https://nadav.amit.zone/blog/linux-inline) результатом исследования особенностей оптимизации в GCC небольших функций ядра. Исследование было проведено после того, как разработчик столкнулся с непонятным феноменом - внесение несущественных изменений в код ядра, приводило к небольшому, но заметному снижению производительности в тестах. Примечательно, что подобные вносимые изменения были оптимизациями и теоретически должны были увеличить производительность, но на деле производительность падала. Дело оказалось в том, что GCC принимает решение об использовании inline-развёртывания функций в зависимости от результатов косвенной оценки размера результирующего кода (даже если функция определена с ключевым словом "inline"). Компилятор не учитывает фактический размер результирующего кода, а пытается прогнозировать его. Для ассемблерных вставок прогнозирование делается на основе числа переводов строк ("\n") и разделителей (";") в исходном тексте. Логика подобного расчёта связана с допуском, что одна строка представляет собой одну ассемблерную инструкцию. Но при этом не учитываются ситуации, когда в ассемблерных вставках применяется большое число директив для вычислений, несколько строк которых в результате приводят к генерации лишь одной небольшой инструкции. Подобная особенность может приводить к таким казусам как снижение производительности при добавлении несущественных макросов. Некоторые разработчики отмечают (https://news.ycombinator.com/item?id=18170499) влияние на inline-развёртывание в новых версиях GCC даже замены символов табуляции на пробелы. Разница в производительности особенно бросается в глаза для функций с ассемблерными вставками, для которых добавляется излишняя обёртка вместо прямой подстановки нескольких указанных в функции инструкций. В ядре Linux проблему представляют компактные функции с макросами WARN(), для которых оказалось, что не выполняется ожидаемая inline-оптимизация. Автор исследования делает вывод, что требуется создание новых средств для контроля за поведением расширенных возможностей компилятора и анализа эффективности результирующих исполняемых файлов. В настоящее время единственным способом убедиться, что код сгенерирован именно так как рассчитывал разработчик остаётся ручное инспектирование итоговых машинных инструкций. URL: https://news.ycombinator.com/item?id=18169584 Новость: https://www.opennet.me/opennews/art.shtml?num=49412
Ответить \| Правка \| Cообщить модератору

Оглавление

Влияние несущественных изменений кода на производительность ..., Аноним (1), 11:13 , 09-Окт-18, (1) –7

Влияние несущественных изменений кода на производительность ..., пох (?), 11:30 , 09-Окт-18, (5) +9

Влияние несущественных изменений кода на производительность ..., Аноним (-), 10:10 , 12-Окт-18, (69)

Влияние несущественных изменений кода на производительность ..., пох (?), 10:24 , 12-Окт-18, (74)
Влияние несущественных изменений кода на производительность ..., Аноним (77), 12:07 , 12-Окт-18, (77)
Влияние несущественных изменений кода на производительность ..., Аноним (78), 14:04 , 12-Окт-18, (78)

Влияние несущественных изменений кода на производительность ..., irinat (ok), 00:11 , 21-Окт-18, (85)

Влияние несущественных изменений кода на производительность ..., Аноним (14), 12:47 , 09-Окт-18, (14) +2

Влияние несущественных изменений кода на производительность ..., Аноним (56), 11:36 , 10-Окт-18, (56)

Влияние несущественных изменений кода на производительность ..., eganru (?), 11:14 , 09-Окт-18, (3)

Влияние несущественных изменений кода на производительность ..., Аноним (10), 11:51 , 09-Окт-18, (10) –3

Влияние несущественных изменений кода на производительность ..., eganru (?), 14:24 , 09-Окт-18, (29) +2
Влияние несущественных изменений кода на производительность ..., Аноним (78), 15:01 , 09-Окт-18, (33)

Влияние несущественных изменений кода на производительность ..., Аноним (4), 11:21 , 09-Окт-18, (4) +16

Влияние несущественных изменений кода на производительность ..., eganru (?), 11:32 , 09-Окт-18, (7) –2
Влияние несущественных изменений кода на производительность ..., Аноним (8), 11:38 , 09-Окт-18, (8)

Влияние несущественных изменений кода на производительность ..., Аноним (4), 12:19 , 09-Окт-18, (12)

Влияние несущественных изменений кода на производительность ..., Аноним (24), 14:00 , 09-Окт-18, (24) +4

Влияние несущественных изменений кода на производительность ..., Аноним (54), 09:50 , 10-Окт-18, (54) –1

Влияние несущественных изменений кода на производительность ..., пох (?), 11:32 , 09-Окт-18, (6) +32

Влияние несущественных изменений кода на производительность ..., J.L. (?), 12:36 , 11-Окт-18, (66)

Влияние несущественных изменений кода на производительность ..., Аноним (78), 14:44 , 11-Окт-18, (67)
Влияние несущественных изменений кода на производительность ..., пох (?), 10:28 , 12-Окт-18, (75)

Влияние несущественных изменений кода на производительность ..., voleg (?), 22:49 , 11-Окт-18, (68)

Влияние несущественных изменений кода на производительность ..., ыы (?), 11:43 , 09-Окт-18, (9) +13

Влияние несущественных изменений кода на производительность ..., Аноним (14), 12:49 , 09-Окт-18, (15) +1
Влияние несущественных изменений кода на производительность ..., Аноним84701 (ok), 13:41 , 09-Окт-18, (22) +7

Влияние несущественных изменений кода на производительность ..., Аноним (44), 18:19 , 09-Окт-18, (44)

Влияние несущественных изменений кода на производительность ..., Аноним84701 (ok), 21:04 , 09-Окт-18, (49) +1

Влияние несущественных изменений кода на производительность ..., Аноним (44), 19:10 , 15-Окт-18, (82)

Влияние несущественных изменений кода на производительность ..., Акакжев (?), 06:43 , 10-Окт-18, (52)

Влияние несущественных изменений кода на производительность ..., IRASoldier (?), 12:18 , 09-Окт-18, (11) –8

Влияние несущественных изменений кода на производительность ..., Акакжев (?), 13:05 , 09-Окт-18, (18) +1

Влияние несущественных изменений кода на производительность ..., IRASoldier (?), 13:24 , 09-Окт-18, (20) –2

Влияние несущественных изменений кода на производительность ..., анонимный анонимус2 (?), 13:45 , 09-Окт-18, (23) +1

Влияние несущественных изменений кода на производительность ..., IRASoldier (?), 14:10 , 09-Окт-18, (27) –2

Влияние несущественных изменений кода на производительность ..., Alex (??), 14:05 , 09-Окт-18, (26) +4

Влияние несущественных изменений кода на производительность ..., IRASoldier (?), 14:15 , 09-Окт-18, (28) –6

Влияние несущественных изменений кода на производительность ..., Аноним (30), 14:26 , 09-Окт-18, (30) +2
Влияние несущественных изменений кода на производительность ..., Аноним (34), 15:12 , 09-Окт-18, (34) +3
Влияние несущественных изменений кода на производительность ..., Аноним (78), 15:12 , 09-Окт-18, (35) +5
Влияние несущественных изменений кода на производительность ..., Акакжев (?), 15:20 , 09-Окт-18, (37) +6
Влияние несущественных изменений кода на производительность ..., Омоним (?), 16:23 , 09-Окт-18, (38) +5

Влияние несущественных изменений кода на производительность ..., IRASoldier (?), 19:46 , 09-Окт-18, (47) –2

Влияние несущественных изменений кода на производительность ..., Аноним (44), 19:52 , 09-Окт-18, (48) +2

Влияние несущественных изменений кода на производительность ..., 0xd34df00d (??), 03:28 , 13-Окт-18, (81) –1

Влияние несущественных изменений кода на производительность ..., Аноним (-), 10:13 , 12-Окт-18, (70)

Влияние несущественных изменений кода на производительность ..., Andrey Mitrofanov (?), 10:32 , 12-Окт-18, (76)

Влияние несущественных изменений кода на производительность ..., Аноним (13), 12:23 , 09-Окт-18, (13) +1
Влияние несущественных изменений кода на производительность ..., Акакжев (?), 12:53 , 09-Окт-18, (16) –1

Влияние несущественных изменений кода на производительность ..., Аноним (21), 13:34 , 09-Окт-18, (21) –1

Влияние несущественных изменений кода на производительность ..., Акакжев (?), 14:37 , 09-Окт-18, (31)
Влияние несущественных изменений кода на производительность ..., Himik (ok), 19:26 , 10-Окт-18, (59) –1

Влияние несущественных изменений кода на производительность ..., Акакжев (?), 08:32 , 11-Окт-18, (64)

Влияние несущественных изменений кода на производительность ..., z (??), 13:11 , 09-Окт-18, (19) –5

Влияние несущественных изменений кода на производительность ..., Аноним (-), 10:17 , 12-Окт-18, (71)

Влияние несущественных изменений кода на производительность ..., Анониметс (?), 14:39 , 09-Окт-18, (32) –4

Влияние несущественных изменений кода на производительность ..., Аноним (78), 15:15 , 09-Окт-18, (36) –1
Влияние несущественных изменений кода на производительность ..., Аноним (39), 16:40 , 09-Окт-18, (39) –1

Влияние несущественных изменений кода на производительность ..., Аноним84701 (ok), 17:03 , 09-Окт-18, (41) +1

Влияние несущественных изменений кода на производительность ..., Аноним (42), 17:06 , 09-Окт-18, (42)
Влияние несущественных изменений кода на производительность ..., Himik (ok), 19:32 , 10-Окт-18, (60) –1

Влияние несущественных изменений кода на производительность ..., Cradle (?), 16:48 , 09-Окт-18, (40) –1

Влияние несущественных изменений кода на производительность ..., Himik (ok), 19:36 , 10-Окт-18, (61)

Влияние несущественных изменений кода на производительность ..., Cradle (?), 20:53 , 10-Окт-18, (63)

Влияние несущественных изменений кода на производительность ..., Sfinx (ok), 11:07 , 11-Окт-18, (65)

Влияние несущественных изменений кода на производительность ..., Аноним (43), 18:08 , 09-Окт-18, (43) +1

Влияние несущественных изменений кода на производительность ..., Аноним (45), 18:56 , 09-Окт-18, (45) –1

Влияние несущественных изменений кода на производительность ..., KonstantinB (ok), 19:09 , 09-Окт-18, (46) –1

Влияние несущественных изменений кода на производительность ..., Аноним (-), 10:19 , 12-Окт-18, (72)

Влияние несущественных изменений кода на производительность ..., Дуплик (ok), 02:16 , 10-Окт-18, (50) –1

Влияние несущественных изменений кода на производительность ..., Himik (ok), 19:38 , 10-Окт-18, (62) +1
Влияние несущественных изменений кода на производительность ..., Аноним (-), 10:21 , 12-Окт-18, (73)

Влияние несущественных изменений кода на производительность ..., Аноним (51), 03:04 , 10-Окт-18, (51) –3

Влияние несущественных изменений кода на производительность ..., Аноним (53), 06:51 , 10-Окт-18, (53)

Влияние несущественных изменений кода на производительность ..., Аноним (56), 11:45 , 10-Окт-18, (57)

Влияние несущественных изменений кода на производительность ..., Himik (ok), 19:21 , 10-Окт-18, (58) +1

Влияние несущественных изменений кода на производительность ..., sage (??), 19:34 , 12-Окт-18, (80)

Влияние несущественных изменений кода на производительность ..., Аноним (44), 19:15 , 15-Окт-18, (83)
Влияние несущественных изменений кода на производительность ..., Аноним (44), 19:43 , 15-Окт-18, (84)

Влияние несущественных изменений кода на производительность ..., Andrey Mitrofanov (?), 17:34 , 12-Окт-18, (79)

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

1. "Влияние несущественных изменений кода на производительность ..." –7 +/–

Сообщение от Аноним (1), 09-Окт-18, 11:13

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

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

5. "Влияние несущественных изменений кода на производительность ..." +9 +/–

Сообщение от пох (?), 09-Окт-18, 11:30

inline _всегда_ был _хинтом_ компилятору, что вот это вот имеет смысл попробовать сделать inline, а не директивным указанием. Точно так же как пресловутый register в определении переменных.
> GCC теперь Apple пишет? "Мы знаем лучше что вам надо"?
apple занят, он пишет llvm, и у него все хорошо с инлайнами (кроме несовместимости очень старого gcc кода). Проблема гнутых обезьянок в том, что они как раз не знают лучше, и добавили нечеловеческой логики в это незнание.

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

69. "Влияние несущественных изменений кода на производительность ..." +/–

Сообщение от Аноним (-), 12-Окт-18, 10:10

> сделать inline, а не директивным указанием. Точно так же как пресловутый
> register в определении переменных.
Register так вообще считается deprecated, в плюсах им вообще пользоваться не следует. Потому что пытаться хинтить компилятору аллокацию регистров - дело тухлое. А если ну очень хочется, есть asm() и intrinsics, наконец. В остальных случаях компилятор и сам догадывается как регистры раскинуть, так что втыкание "register" ничего не дает кроме лишней писанины.
>> GCC теперь Apple пишет? "Мы знаем лучше что вам надо"?
> apple занят, он пишет llvm, и у него все хорошо с инлайнами
Зато у него почему-то хваленая скорость компиляции ушла в плинтус как только им захотелось производительность кода сколь-нибудь сравнимую с gcc.
> и добавили нечеловеческой логики в это незнание.
...а разработчики шланга собезьянили, как обычно?

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

74. "Влияние несущественных изменений кода на производительность ..." +/–

Сообщение от пох (?), 12-Окт-18, 10:24

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

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

77. "Влияние несущественных изменений кода на производительность ..." +/–

Сообщение от Аноним (77), 12-Окт-18, 12:07

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

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

78. "Влияние несущественных изменений кода на производительность ..." +/–

Сообщение от Аноним (78), 12-Окт-18, 14:04

> Register так вообще считается deprecated, в плюсах им вообще пользоваться не следует.
Да-да. Давеча вот такое видел от GCC 8:
warning: ISO C++17 does not allow ‘register’ storage class specifier [-Wregister]

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

85. "Влияние несущественных изменений кода на производительность ..." +/–

Сообщение от irinat (ok), 21-Окт-18, 00:11

inline был хинтом компилятору только в расширениях gnu89. В c99 ввели понятие inline, и оно с тех пор не связано с инлайнингом напрямую.

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

14. "Влияние несущественных изменений кода на производительность ..." +2 +/–

Сообщение от Аноним (14), 09-Окт-18, 12:47

Это зачатки ИИ :-) , в среднем хорошо но в отдельных местах...

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

56. "Влияние несущественных изменений кода на производительность ..." +/–

Сообщение от Аноним (56), 10-Окт-18, 11:36

... и если приблизить, то мы увидим 12 новых if.

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

3. "Влияние несущественных изменений кода на производительность ..." +/–

Сообщение от eganru (?), 09-Окт-18, 11:14

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

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

10. "Влияние несущественных изменений кода на производительность ..." –3 +/–

Сообщение от Аноним (10), 09-Окт-18, 11:51

автор статьи там написал, почему always_inline - не решение проблемы. Но вы, конечно, ее не читали

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

29. "Влияние несущественных изменений кода на производительность ..." +2 +/–

Сообщение от eganru (?), 09-Окт-18, 14:24

читал.
Вы не читали или не разобрались в сути вопроса.
случаи там рассмотренные вполне можно было бы решить с помощью always_inline.
рассматривался допустим
static inline void *kzalloc(size_t size, gfp_t flags)
который вызывает kmalloc, который по заверениям always_inline, и результирующий код не дает компилятору дважды выполнить подстановку кода.
можно было бы бахнуть always_inline и выполнило бы подстановку дважды.
то что функции-обертки волшебным образом не наследуют атрибуты или какие-то свойства пожалуй известно всем.

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

33. "Влияние несущественных изменений кода на производительность ..." +/–

Сообщение от Аноним (78), 09-Окт-18, 15:01

А вы так усердно читали, что мысленно вписали в статью того, чего там нет. :)

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

4. "Влияние несущественных изменений кода на производительность ..." +16 +/–

Сообщение от Аноним (4), 09-Окт-18, 11:21

Нужно новое ключевое слово really_inline.

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

7. "Влияние несущественных изменений кода на производительность ..." –2 +/–

Сообщение от eganru (?), 09-Окт-18, 11:32

[i]Нужно новое ключевое слово really_inline.[/i] - кому нужно-то? Вы можете сделать inline силой с помощью атрибута. только в 9 случаях из 10 это не нужно.

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

8. "Влияние несущественных изменений кода на производительность ..." +/–

Сообщение от Аноним (8), 09-Окт-18, 11:38

__attribute__((always_inline))

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

12. "Влияние несущественных изменений кода на производительность ..." +/–

Сообщение от Аноним (4), 09-Окт-18, 12:19

Нестандартненько.

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

24. "Влияние несущественных изменений кода на производительность ..." +4 +/–

Сообщение от Аноним (24), 09-Окт-18, 14:00

в_натуре(__inline__)
:)

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

54. "Влияние несущественных изменений кода на производительность ..." –1 +/–

Сообщение от Аноним (54), 10-Окт-18, 09:50

без_базара(--inline__)

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

6. "Влияние несущественных изменений кода на производительность ..." +32 +/–

Сообщение от пох (?), 09-Окт-18, 11:32

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

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

66. "Влияние несущественных изменений кода на производительность ..." +/–

Сообщение от J.L. (?), 11-Окт-18, 12:36

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

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

67. "Влияние несущественных изменений кода на производительность ..." +/–

Сообщение от Аноним (78), 11-Окт-18, 14:44

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

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

75. "Влияние несущественных изменений кода на производительность ..." +/–

Сообщение от пох (?), 12-Окт-18, 10:28

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

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

68. "Влияние несущественных изменений кода на производительность ..." +/–

Сообщение от voleg (?), 11-Окт-18, 22:49

Израиль не Пакистан. А мужичек сам в штатах.

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

9. "Влияние несущественных изменений кода на производительность ..." +13 +/–

Сообщение от ыы (?), 09-Окт-18, 11:43

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

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

15. "Влияние несущественных изменений кода на производительность ..." +1 +/–

Сообщение от Аноним (14), 09-Окт-18, 12:49

ИИ в компиляторах...

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

22. "Влияние несущественных изменений кода на производительность ..." +7 +/–

Сообщение от Аноним84701 (ok), 09-Окт-18, 13:41

> Эпично.
Вы явно недооцениваете "взрывно-поджигательный" потенциал предложения:
> "влияние на inline-развёртывание в новых версиях GCC даже замены символов табуляции на пробелы."
> identical functions that used spaces instead of tabs could run significantly slower because they weren't inlined.
в любом сра^W обсуждении на опеннете новости о  питоне (или чем-то питоноподобном), где примерно 2/3 комментариев рассматривают (не)допустимость ущемления прав разработчика на свободное оформление кода, глубинную (не)правильность влияния пробелов на семантику ЯП (и общее  влияние на интеллект, сексуальные пристрастия или некоторые анатомические детали, вроде кривизны или места крепления верхних конечностей).

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

44. "Влияние несущественных изменений кода на производительность ..." +/–

Сообщение от Аноним (44), 09-Окт-18, 18:19

> глубинную (не)правильность влияния пробелов на семантику ЯП
На семантику оно и не влияет.

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

49. "Влияние несущественных изменений кода на производительность ..." +1 +/–

Сообщение от Аноним84701 (ok), 09-Окт-18, 21:04

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

while True:
    ...
    if something < X:
      result.add(Y)
    break

+1 Tab

while True:
    ...
    if something < X:
        result.add(Y)
        break

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

82. "Влияние несущественных изменений кода на производительность ..." +/–

Сообщение от Аноним (44), 15-Окт-18, 19:10

При чем здесь питон? Речь про C/C++.

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

52. "Влияние несущественных изменений кода на производительность ..." +/–

Сообщение от Акакжев (?), 10-Окт-18, 06:43

> Вы явно недооцениваете "взрывно-поджигательный" потенциал предложения:
>> "влияние на inline-развёртывание в новых версиях GCC даже замены символов табуляции на пробелы."
private\windows\media\avi\verinfo.16\verinfo.h:

* !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
* !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
* !!!!!!!IF YOU CHANGE TABS TO SPACES, YOU WILL BE KILLED!!!!!!!
* !!!!!!!!!!!!!!DOING SO [ВЦ.] THE BUILD PROCESS!!!!!!!!!!!!!!!!
* !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
* !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

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

11. "Влияние несущественных изменений кода на производительность ..." –8 +/–

Сообщение от IRASoldier (?), 09-Окт-18, 12:18

Мне вот интересно, какому "умному" человеку пришло в голову внести в gcc т.н. GNU Extensions, которые разрешают, например, указывать размер статического (Карл!) массива в рантайме... Кому это было нужно? Ниасиляторам С и плюсов?

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

18. "Влияние несущественных изменений кода на производительность ..." +1 +/–

Сообщение от Акакжев (?), 09-Окт-18, 13:05

Тому, кто потом в Комитете принимает решения по следующему Стандарту, куда расширения языка постепенно включаются.

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

20. "Влияние несущественных изменений кода на производительность ..." –2 +/–

Сообщение от IRASoldier (?), 09-Окт-18, 13:24

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

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

23. "Влияние несущественных изменений кода на производительность ..." +1 +/–

Сообщение от анонимный анонимус2 (?), 09-Окт-18, 13:45

Это расширение только для С++, для С99 это стандарт.

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

27. "Влияние несущественных изменений кода на производительность ..." –2 +/–

Сообщение от IRASoldier (?), 09-Окт-18, 14:10

А в C11 опять VLA не одобряэ... Путаники-с.

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

26. "Влияние несущественных изменений кода на производительность ..." +4 +/–

Сообщение от Alex (??), 09-Окт-18, 14:05

не статического массива а массива на стеке, дятел. Разница в том что это довольно просто реализовать, удобно, и не ломает язык. И да, это входит в c99 сейчас, наверняка войдет и в c++2x

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

28. "Влияние несущественных изменений кода на производительность ..." –6 +/–

Сообщение от IRASoldier (?), 09-Окт-18, 14:15

> не статического массива а массива на стеке, дятел.
От дятла слышу. Всю жизнь использовали в повседневной речи - "статический" и продолжают использовать.
> это довольно просто реализовать, удобно, и не ломает язык
Это может привести к undefined behavior если попытка выделения памяти окончилась фейлом.

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

30. "Влияние несущественных изменений кода на производительность ..." +2 +/–

Сообщение от Аноним (30), 09-Окт-18, 14:26

ПОловина софта не проверяет даже malloс на NULL...

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

34. "Влияние несущественных изменений кода на производительность ..." +3 +/–

Сообщение от Аноним (34), 09-Окт-18, 15:12

Любое использование стека может привести к UB. На деле, кому надо обрабатывают SIGSEGV, а остальным плевать

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

35. "Влияние несущественных изменений кода на производительность ..." +5 +/–

Сообщение от Аноним (78), 09-Окт-18, 15:12

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

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

37. "Влияние несущественных изменений кода на производительность ..." +6 +/–

Сообщение от Акакжев (?), 09-Окт-18, 15:20

> Всю жизнь использовали в повседневной речи - "статический" и продолжают использовать.
"Объекты c static storage duration инициализируются до program startup."

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

38. "Влияние несущественных изменений кода на производительность ..." +5 +/–

Сообщение от Омоним (?), 09-Окт-18, 16:23

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

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

47. "Влияние несущественных изменений кода на производительность ..." –2 +/–

Сообщение от IRASoldier (?), 09-Окт-18, 19:46

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

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

48. "Влияние несущественных изменений кода на производительность ..." +2 +/–

Сообщение от Аноним (44), 09-Окт-18, 19:52

Кем подразумеваемом? В каком контексте? "Статический массив" - вполне допустимое выражение, которое значит совсем не то, что "массив на стеке".

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

81. "Влияние несущественных изменений кода на производительность ..." –1 +/–

Сообщение от 0xd34df00d (??), 13-Окт-18, 03:28

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

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

70. "Влияние несущественных изменений кода на производительность ..." +/–

Сообщение от Аноним (-), 12-Окт-18, 10:13

> Мне вот интересно, какому "умному" человеку пришло в голову внести в gcc
> т.н. GNU Extensions, которые разрешают, например, указывать размер статического (Карл!)
> массива в рантайме... Кому это было нужно? Ниасиляторам С и плюсов?
Вообще-то это часть стандарта C ... с 99 года аж. Туда же и всякие variable args и проч. Полезные между прочим штуки. И раздуплятся ли стандартизаторы - черт его знает, но все этим пользуются. Тот же шланг этому тоже научился. И без них иногда как-то душно.

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

76. "Влияние несущественных изменений кода на производительность ..." +/–

Сообщение от Andrey Mitrofanov (?), 12-Окт-18, 10:32

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

> Тот же шланг этому тоже научился. И без них иногда как-то
Вы с "прогрессивным" человечеством, я вижу, на защите чести и свобод?
Надо успеть, пока супостат не вернулся с "ретрита".
> душно.

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

13. "Влияние несущественных изменений кода на производительность ..." +1 +/–

Сообщение от Аноним (13), 09-Окт-18, 12:23

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

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

16. "Влияние несущественных изменений кода на производительность ..." –1 +/–

Сообщение от Акакжев (?), 09-Окт-18, 12:53

Теория:
-O turns on the following optimization flags:
...
-fomit-frame-pointer
Практика:
0xffffffff817929e0 <+0>: push   %rbp
...
0xffffffff817929ee <+14>: pop    %rbp
0xffffffff817929ef <+15>: retq

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

21. "Влияние несущественных изменений кода на производительность ..." –1 +/–

Сообщение от Аноним (21), 09-Окт-18, 13:34

Данной оптимизация отключена, поскольку обратная опция находится в зависимостях других опций вроде C++ исключений. Без которых GCC не может сгенерировать рабочий код. Доходит до абсурда когда stack-frame создаётся в абсолютно пустых функциях.

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

31. "Влияние несущественных изменений кода на производительность ..." +/–

Сообщение от Акакжев (?), 09-Окт-18, 14:37

> Данной оптимизация отключена, поскольку обратная опция находится в зависимостях других
> опций вроде C++ исключений. Без которых GCC не может сгенерировать рабочий
> код.
По поводу "других" в документации сказано: Omit the frame pointer in functions that don't need one.
make V=1 показывает, что fomit-frame-pointer передаётся компилятору.
Пример навскидку.

void cyc2ns_read_begin(struct cyc2ns_data *data)
{
        int seq, idx;
        preempt_disable_notrace();
        do {
                seq = this_cpu_read(cyc2ns.seq.sequence);
                idx = seq & 1;
                data->cyc2ns_offset = this_cpu_read(cyc2ns.data[idx].cyc2ns_offset);
                data->cyc2ns_mul    = this_cpu_read(cyc2ns.data[idx].cyc2ns_mul);
                data->cyc2ns_shift  = this_cpu_read(cyc2ns.data[idx].cyc2ns_shift);
        } while (unlikely(seq != this_cpu_read(cyc2ns.seq.sequence)));
}
void cyc2ns_read_end(void)
{
        preempt_enable_notrace();
}

Прошу прощения, если кому непривычен формат,
отсутствие фреймов видно:

.text:0000000000000228 cyc2ns_read_begin proc near
.text:0000000000000228                 inc     gs:__preempt_count
.text:000000000000022F                 mov     rsi, offset cyc2ns
.text:0000000000000236 loc_236:
.text:0000000000000236                 mov     edx, dword ptr gs:cyc2ns+20h
.text:000000000000023D                 mov     eax, edx
.text:000000000000023F                 and     eax, 1
.text:0000000000000242                 shl     rax, 4
.text:0000000000000246                 add     rax, rsi
.text:0000000000000249                 mov     rcx, gs:[rax+8]
.text:000000000000024E                 mov     [rdi+8], rcx
.text:0000000000000252                 mov     ecx, gs:[rax]
.text:0000000000000255                 mov     [rdi], ecx
.text:0000000000000257                 mov     eax, gs:[rax+4]
.text:000000000000025B                 mov     [rdi+4], eax
.text:000000000000025E                 mov     eax, dword ptr gs:cyc2ns+20h
.text:0000000000000265                 cmp     edx, eax
.text:0000000000000267                 jnz     short loc_236
.text:0000000000000269                 retn
.text:0000000000000269 cyc2ns_read_begin endp

.text:000000000000026A cyc2ns_read_end proc near
.text:000000000000026A                 dec     gs:__preempt_count
.text:0000000000000271                 jnz     short locret_278
.text:0000000000000273                 call    ___preempt_schedule_notrace
.text:0000000000000278 locret_278:
.text:0000000000000278                 retn
.text:0000000000000278 cyc2ns_read_end endp
.text:0000000000000278

Можно предположить, что собирали там с опцией CONFIG_FRAME_POINTER.

grep -C2 frame-pointer Makefile
HOSTCFLAGS   := -Wall -Wmissing-prototypes -Wstrict-prototypes -O2 \
                -fomit-frame-pointer -std=gnu89 $(HOST_LFS_CFLAGS)
--
ifdef CONFIG_FRAME_POINTER
KBUILD_CFLAGS   += -fno-omit-frame-pointer -fno-optimize-sibling-calls
else
# Some targets (ARM with Thumb2, for example), can't be built with frame
# pointers.  For those, we don't have FUNCTION_TRACER automatically
# select FRAME_POINTER.  However, FUNCTION_TRACER adds -pg, and this is
# incompatible with -fomit-frame-pointer with current GCC, so we don't use
# -fomit-frame-pointer with FUNCTION_TRACER.
ifndef CONFIG_FUNCTION_TRACER
KBUILD_CFLAGS   += -fomit-frame-pointer
endif
endif
В таком случае, возникает вопрос: влияет ли она на эффект от inline?

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

59. "Влияние несущественных изменений кода на производительность ..." –1 +/–

Сообщение от Himik (ok), 10-Окт-18, 19:26

push %rbp и pop %rbp не имеют ни какого отношения к стеку, это просто сохранение регистра для использования в вычислениях функции. Раньше rbp использовался для буфера в стеке, теперь нет.

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

64. "Влияние несущественных изменений кода на производительность ..." +/–

Сообщение от Акакжев (?), 11-Окт-18, 08:32

> push %rbp и pop %rbp не имеют ни какого отношения к стеку,
> это просто сохранение регистра для использования в вычислениях функции. Раньше rbp
> использовался для буфера в стеке, теперь нет.
Вот подпрограмма целиком:

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

mov    %rsp,%rbp — формирование фрейма, который не используется.

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

19. "Влияние несущественных изменений кода на производительность ..." –5 +/–

Сообщение от z (??), 09-Окт-18, 13:11

И эти люди ещё ругают MSVC за изначальный отказ от inline-инструкций в x86_64 как класса =)

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

71. "Влияние несущественных изменений кода на производительность ..." +/–

Сообщение от Аноним (-), 12-Окт-18, 10:17

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

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

32. "Влияние несущественных изменений кода на производительность ..." –4 +/–

Сообщение от Анониметс (?), 09-Окт-18, 14:39

Кто все эти люди, что это за язык? Ни одного слова не понял ни из комментов, ни из статьи. Чьто это? Где я?)

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

36. "Влияние несущественных изменений кода на производительность ..." –1 +/–

Сообщение от Аноним (78), 09-Окт-18, 15:15

Это GCC, братан

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

39. "Влияние несущественных изменений кода на производительность ..." –1 +/–

Сообщение от Аноним (39), 09-Окт-18, 16:40

Ну раз речь о ядре Линукса, то догадайся)

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

41. "Влияние несущественных изменений кода на производительность ..." +1 +/–

Сообщение от Аноним84701 (ok), 09-Окт-18, 17:03

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

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

42. "Влияние несущественных изменений кода на производительность ..." +/–

Сообщение от Аноним (42), 09-Окт-18, 17:06

Assembly Language
GCC – GNU Compiler Collection
Про инлайнинг сами попгуглите.

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

60. "Влияние несущественных изменений кода на производительность ..." –1 +/–

Сообщение от Himik (ok), 10-Окт-18, 19:32

GNU C Compiler = GCC.
Не путать с GNU Compiler Collection, такого языка программирования нет.

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

40. "Влияние несущественных изменений кода на производительность ..." –1 +/–

Сообщение от Cradle (?), 09-Окт-18, 16:48

немного не в тему, но может кто подскажет, такая проблемка: использую arm-none-eabi-gcc-7.2.1 с cmake , и результаты оптимизации как-то сильно зависят от cmake кэша, процентов на 10 размер бинарника разный выходит, при том что реально разные варианты кода в пределах тех же самых функций получаются, проверял ассемлерные дампы. Пока лечится стиранием директории CMakeFiles, но может есть более умное решение?

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

61. "Влияние несущественных изменений кода на производительность ..." +/–

Сообщение от Himik (ok), 10-Окт-18, 19:36

Не знаю точно, но может быть поможет export LDFLAGS='-s'
чтобы вырезалась (strip) служебная информация из конечного результата.

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

63. "Влияние несущественных изменений кода на производительность ..." +/–

Сообщение от Cradle (?), 10-Окт-18, 20:53

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

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

65. "Влияние несущественных изменений кода на производительность ..." +/–

Сообщение от Sfinx (ok), 11-Окт-18, 11:07

включаешь verbose и смотришь опции компиляции или включаешь -frecord-gcc-switches и смотришь в бинарнике до стрипа.

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

43. "Влияние несущественных изменений кода на производительность ..." +1 +/–

Сообщение от Аноним (43), 09-Окт-18, 18:08

Линус недавно устроил голвомойку разработчикам GCC за глюки в версии 4.9, кажется. Похоже, пора устроить её снова!

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

45. "Влияние несущественных изменений кода на производительность ..." –1 +/–

Сообщение от Аноним (45), 09-Окт-18, 18:56

А то что? На шланг перейдёт? Ну наконец-то в ядро примут патчи совместимости со шлангом.

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

46. "Влияние несущественных изменений кода на производительность ..." –1 +/–

Сообщение от KonstantinB (ok), 09-Окт-18, 19:09

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

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

72. "Влияние несущественных изменений кода на производительность ..." +/–

Сообщение от Аноним (-), 12-Окт-18, 10:19

> Собственно, уже большая часть кода ядра прекрасно собирается.
"Немножечко беременна".

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

50. "Влияние несущественных изменений кода на производительность ..." –1 +/–

Сообщение от Дуплик (ok), 10-Окт-18, 02:16

Скорее бы Linux портировали на Clang/LLVM.

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

62. "Влияние несущественных изменений кода на производительность ..." +1 +/–

Сообщение от Himik (ok), 10-Окт-18, 19:38

Нет, уж лучше старые глюки, чем новые.

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

73. "Влияние несущественных изменений кода на производительность ..." +/–

Сообщение от Аноним (-), 12-Окт-18, 10:21

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

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

51. "Влияние несущественных изменений кода на производительность ..." –3 +/–

Сообщение от Аноним (51), 10-Окт-18, 03:04

> Некоторые разработчики отмечают влияние на inline-развёртывание в новых версиях GCC даже замены символов табуляции на пробелы.
При чем тут gcc вообще? Коммент по ссылке про v8 (движок JavaScript).

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

53. "Влияние несущественных изменений кода на производительность ..." +/–

Сообщение от Аноним (53), 10-Окт-18, 06:51

> При чем тут gcc вообще?
Там речь про GCC v8.
> Коммент по ссылке про v8 (движок JavaScript).
А в этом же комментарии упоминание v5.9 тогда про какой движок и откуда в  JavaScript-движке "inline assembly"?

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

57. "Влияние несущественных изменений кода на производительность ..." +/–

Сообщение от Аноним (56), 10-Окт-18, 11:45

Web Assembly? Он вроде позваляет на любом языке писать.

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

58. "Влияние несущественных изменений кода на производительность ..." +1 +/–

Сообщение от Himik (ok), 10-Окт-18, 19:21

Web Assembly в Linux kernel?

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

80. "Влияние несущественных изменений кода на производительность ..." +/–

Сообщение от sage (??), 12-Окт-18, 19:34

Да. https://github.com/rianhunter/wasmjit

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

83. "Влияние несущественных изменений кода на производительность ..." +/–

Сообщение от Аноним (44), 15-Окт-18, 19:15

JavaScript движок под названием V8, версия движка 5.9. Что не понятно?

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

84. "Влияние несущественных изменений кода на производительность ..." +/–

Сообщение от Аноним (44), 15-Окт-18, 19:43

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

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

79. "Влияние несущественных изменений кода на производительность ..." +/–

Сообщение от Andrey Mitrofanov (?), 12-Окт-18, 17:34

Удивиился, что не Фороникс,
   https://lwn.net/Articles/767884/rss
обнаружив сабж на.
Бывает же?!

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

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

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

Партнёры:

Хостинг:

Закладки на сайте
Проследить за страницей

Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру

1. "Влияние несущественных изменений кода на производительность ..."	–7 +/–
Сообщение от Аноним (1), 09-Окт-18, 11:13
>Дело оказалось в том, что GCC принимает решение об использовании inline-развёртывания функций в зависимости от результатов косвенной оценки размера результирующего кода (даже если функция определена с ключевым словом "inline"). GCC теперь Apple пишет? "Мы знаем лучше что вам надо"?
Ответить \| Правка \| ^ к родителю #0 \| Наверх \| Cообщить модератору


	5. "Влияние несущественных изменений кода на производительность ..."	+9 +/–
	Сообщение от пох (?), 09-Окт-18, 11:30
	inline _всегда_ был _хинтом_ компилятору, что вот это вот имеет смысл попробовать сделать inline, а не директивным указанием. Точно так же как пресловутый register в определении переменных. > GCC теперь Apple пишет? "Мы знаем лучше что вам надо"? apple занят, он пишет llvm, и у него все хорошо с инлайнами (кроме несовместимости очень старого gcc кода). Проблема гнутых обезьянок в том, что они как раз не знают лучше, и добавили нечеловеческой логики в это незнание.
	Ответить \| Правка \| ^ к родителю #1 \| Наверх \| Cообщить модератору


	69. "Влияние несущественных изменений кода на производительность ..."	+/–
	Сообщение от Аноним (-), 12-Окт-18, 10:10
	> сделать inline, а не директивным указанием. Точно так же как пресловутый > register в определении переменных. Register так вообще считается deprecated, в плюсах им вообще пользоваться не следует. Потому что пытаться хинтить компилятору аллокацию регистров - дело тухлое. А если ну очень хочется, есть asm() и intrinsics, наконец. В остальных случаях компилятор и сам догадывается как регистры раскинуть, так что втыкание "register" ничего не дает кроме лишней писанины. >> GCC теперь Apple пишет? "Мы знаем лучше что вам надо"? > apple занят, он пишет llvm, и у него все хорошо с инлайнами Зато у него почему-то хваленая скорость компиляции ушла в плинтус как только им захотелось производительность кода сколь-нибудь сравнимую с gcc. > и добавили нечеловеческой логики в это незнание. ...а разработчики шланга собезьянили, как обычно?
	Ответить \| Правка \| ^ к родителю #5 \| Наверх \| Cообщить модератору


	74. "Влияние несущественных изменений кода на производительность ..."	+/–
	Сообщение от пох (?), 12-Окт-18, 10:24
	> Потому что пытаться хинтить компилятору аллокацию регистров - дело тухлое. смотря на какой архитектуре. > В остальных случаях компилятор и сам догадывается как регистры раскинуть, "в остальных случаях компилятор и сам догадается, что заинлайнить". Вот он и "догадался".
	Ответить \| Правка \| ^ к родителю #69 \| Наверх \| Cообщить модератору


	77. "Влияние несущественных изменений кода на производительность ..."	+/–
	Сообщение от Аноним (77), 12-Окт-18, 12:07
	>сам догадывается я проверял, у меня он догадывался на простом счётчике для перебора массива только после компиляции с инфой профилирования (pgo), разница производительности что-то там в районе 3-4 порядков была. Просто космос. Добиться такого же результата позволяло добавление register, поэтому говорить можно что угодно.
	Ответить \| Правка \| ^ к родителю #69 \| Наверх \| Cообщить модератору


	78. "Влияние несущественных изменений кода на производительность ..."	+/–
	Сообщение от Аноним (78), 12-Окт-18, 14:04
	> Register так вообще считается deprecated, в плюсах им вообще пользоваться не следует. Да-да. Давеча вот такое видел от GCC 8: warning: ISO C++17 does not allow ‘register’ storage class specifier [-Wregister]
	Ответить \| Правка \| ^ к родителю #69 \| Наверх \| Cообщить модератору


	85. "Влияние несущественных изменений кода на производительность ..."	+/–
	Сообщение от irinat (ok), 21-Окт-18, 00:11
	inline был хинтом компилятору только в расширениях gnu89. В c99 ввели понятие inline, и оно с тех пор не связано с инлайнингом напрямую.
	Ответить \| Правка \| ^ к родителю #5 \| Наверх \| Cообщить модератору


	14. "Влияние несущественных изменений кода на производительность ..."	+2 +/–
	Сообщение от Аноним (14), 09-Окт-18, 12:47
	Это зачатки ИИ :-) , в среднем хорошо но в отдельных местах...
	Ответить \| Правка \| ^ к родителю #1 \| Наверх \| Cообщить модератору


	56. "Влияние несущественных изменений кода на производительность ..."	+/–
	Сообщение от Аноним (56), 10-Окт-18, 11:36
	... и если приблизить, то мы увидим 12 новых if.
	Ответить \| Правка \| ^ к родителю #14 \| Наверх \| Cообщить модератору

3. "Влияние несущественных изменений кода на производительность ..."	+/–
Сообщение от eganru (?), 09-Окт-18, 11:14
можно делать __attribute__((always_inline)), если требуется всегда inline. [i]настоящее время единственным способом убедиться, что код сгенерирован именно так как рассчитывал разработчик остаётся ручное инспектирование итоговых машинных инструкций. [/i] - единственный способ понять, правильно ли сгенерировалось - посмотреть асм листинг. по моему опыту значительная часть разработчиков не будут читать листинг.
Ответить \| Правка \| ^ к родителю #0 \| Наверх \| Cообщить модератору


	10. "Влияние несущественных изменений кода на производительность ..."	–3 +/–
	Сообщение от Аноним (10), 09-Окт-18, 11:51
	автор статьи там написал, почему always_inline - не решение проблемы. Но вы, конечно, ее не читали
	Ответить \| Правка \| ^ к родителю #3 \| Наверх \| Cообщить модератору


	29. "Влияние несущественных изменений кода на производительность ..."	+2 +/–
	Сообщение от eganru (?), 09-Окт-18, 14:24
	читал. Вы не читали или не разобрались в сути вопроса. случаи там рассмотренные вполне можно было бы решить с помощью always_inline. рассматривался допустим static inline void *kzalloc(size_t size, gfp_t flags) который вызывает kmalloc, который по заверениям always_inline, и результирующий код не дает компилятору дважды выполнить подстановку кода. можно было бы бахнуть always_inline и выполнило бы подстановку дважды. то что функции-обертки волшебным образом не наследуют атрибуты или какие-то свойства пожалуй известно всем.
	Ответить \| Правка \| ^ к родителю #10 \| Наверх \| Cообщить модератору


	33. "Влияние несущественных изменений кода на производительность ..."	+/–
	Сообщение от Аноним (78), 09-Окт-18, 15:01
	А вы так усердно читали, что мысленно вписали в статью того, чего там нет. :)
	Ответить \| Правка \| ^ к родителю #10 \| Наверх \| Cообщить модератору

4. "Влияние несущественных изменений кода на производительность ..."	+16 +/–
Сообщение от Аноним (4), 09-Окт-18, 11:21
Нужно новое ключевое слово really_inline.
Ответить \| Правка \| ^ к родителю #0 \| Наверх \| Cообщить модератору


	7. "Влияние несущественных изменений кода на производительность ..."	–2 +/–
	Сообщение от eganru (?), 09-Окт-18, 11:32
	[i]Нужно новое ключевое слово really_inline.[/i] - кому нужно-то? Вы можете сделать inline силой с помощью атрибута. только в 9 случаях из 10 это не нужно.
	Ответить \| Правка \| ^ к родителю #4 \| Наверх \| Cообщить модератору


	8. "Влияние несущественных изменений кода на производительность ..."	+/–
	Сообщение от Аноним (8), 09-Окт-18, 11:38
	__attribute__((always_inline))
	Ответить \| Правка \| ^ к родителю #4 \| Наверх \| Cообщить модератору


	12. "Влияние несущественных изменений кода на производительность ..."	+/–
	Сообщение от Аноним (4), 09-Окт-18, 12:19
	Нестандартненько.
	Ответить \| Правка \| ^ к родителю #8 \| Наверх \| Cообщить модератору


	24. "Влияние несущественных изменений кода на производительность ..."	+4 +/–
	Сообщение от Аноним (24), 09-Окт-18, 14:00
	в_натуре(__inline__) :)
	Ответить \| Правка \| ^ к родителю #4 \| Наверх \| Cообщить модератору


	54. "Влияние несущественных изменений кода на производительность ..."	–1 +/–
	Сообщение от Аноним (54), 10-Окт-18, 09:50
	без_базара(--inline__)
	Ответить \| Правка \| ^ к родителю #24 \| Наверх \| Cообщить модератору

6. "Влияние несущественных изменений кода на производительность ..."	+32 +/–
Сообщение от пох (?), 09-Окт-18, 11:32
"примечательно", что этот пакистанец, кажется, на самом деле тестировал свои оптимизации на предмет реально ли они оптимизируют. Вот это - действительно неожиданный ход.
Ответить \| Правка \| ^ к родителю #0 \| Наверх \| Cообщить модератору


	66. "Влияние несущественных изменений кода на производительность ..."	+/–
	Сообщение от J.L. (?), 11-Окт-18, 12:36
	> "примечательно", что этот пакистанец, кажется, на самом деле тестировал свои оптимизации > на предмет реально ли они оптимизируют. > Вот это - действительно неожиданный ход. теперь я знаю чем пакистан от индии отличаются, раньше я их не различал
	Ответить \| Правка \| ^ к родителю #6 \| Наверх \| Cообщить модератору


	67. "Влияние несущественных изменений кода на производительность ..."	+/–
	Сообщение от Аноним (78), 11-Окт-18, 14:44
	> теперь я знаю чем пакистан от индии отличаются, раньше я их не > различал Индусы рисуют красную точку на лбу, а паки проверяют оптимизацию компилятора.
	Ответить \| Правка \| ^ к родителю #66 \| Наверх \| Cообщить модератору


	75. "Влияние несущественных изменений кода на производительность ..."	+/–
	Сообщение от пох (?), 12-Окт-18, 10:28
	> теперь я знаю чем пакистан от индии отличаются, раньше я их не > различал в Индии помимо Кумаров тоже встречаются всякие Джавахарлалы, первые делают тупенько, за вторыми замучаешься распутывать, что они там наоптимизировали и почему ты одну строчку добавил а оно стало медленнее в сто раз. Хз, на самом деле, что хуже. видимо, зависит от сорта плана, который растет именно в этой местности.
	Ответить \| Правка \| ^ к родителю #66 \| Наверх \| Cообщить модератору


	68. "Влияние несущественных изменений кода на производительность ..."	+/–
	Сообщение от voleg (?), 11-Окт-18, 22:49
	Израиль не Пакистан. А мужичек сам в штатах.
	Ответить \| Правка \| ^ к родителю #6 \| Наверх \| Cообщить модератору

9. "Влияние несущественных изменений кода на производительность ..."	+13 +/–
Сообщение от ыы (?), 09-Окт-18, 11:43
" Влияние числа переводов строк и разделителей в исходном тексте программ на быстродействие скомпилированного кода " Эпично.
Ответить \| Правка \| ^ к родителю #0 \| Наверх \| Cообщить модератору


	15. "Влияние несущественных изменений кода на производительность ..."	+1 +/–
	Сообщение от Аноним (14), 09-Окт-18, 12:49
	ИИ в компиляторах...
	Ответить \| Правка \| ^ к родителю #9 \| Наверх \| Cообщить модератору


	22. "Влияние несущественных изменений кода на производительность ..."	+7 +/–
	Сообщение от Аноним84701 (ok), 09-Окт-18, 13:41
	> Эпично. Вы явно недооцениваете "взрывно-поджигательный" потенциал предложения: > "влияние на inline-развёртывание в новых версиях GCC даже замены символов табуляции на пробелы." > identical functions that used spaces instead of tabs could run significantly slower because they weren't inlined. в любом сра^W обсуждении на опеннете новости о питоне (или чем-то питоноподобном), где примерно 2/3 комментариев рассматривают (не)допустимость ущемления прав разработчика на свободное оформление кода, глубинную (не)правильность влияния пробелов на семантику ЯП (и общее влияние на интеллект, сексуальные пристрастия или некоторые анатомические детали, вроде кривизны или места крепления верхних конечностей).
	Ответить \| Правка \| ^ к родителю #9 \| Наверх \| Cообщить модератору


	44. "Влияние несущественных изменений кода на производительность ..."	+/–
	Сообщение от Аноним (44), 09-Окт-18, 18:19
	> глубинную (не)правильность влияния пробелов на семантику ЯП На семантику оно и не влияет.
	Ответить \| Правка \| ^ к родителю #22 \| Наверх \| Cообщить модератору


	49. "Влияние несущественных изменений кода на производительность ..."	+1 +/–
	Сообщение от Аноним84701 (ok), 09-Окт-18, 21:04
	>> глубинную (не)правильность влияния пробелов на семантику ЯП > На семантику оно и не влияет. Даже если бы и не влияло (что не так[0]) -- таки уп0pно обуждают. Из недавнего: https://www.opennet.me/openforum/vsluhforumID3/115403.html#63 [0] while True: ... if something < X: result.add(Y) break +1 Tab while True: ... if something < X: result.add(Y) break
	Ответить \| Правка \| ^ к родителю #44 \| Наверх \| Cообщить модератору


	82. "Влияние несущественных изменений кода на производительность ..."	+/–
	Сообщение от Аноним (44), 15-Окт-18, 19:10
	При чем здесь питон? Речь про C/C++.
	Ответить \| Правка \| ^ к родителю #49 \| Наверх \| Cообщить модератору