Skip to main content

Конференции

Просмотр конференции fido7.su.c-cpp:

Предыдущее Следующее

Дата: 24 Sep 2016, 12:17:25
От: Valentin Nechayev @ 2:5020/400.0
Кому: Yury Haron
Тема: Re: Вопрос по коду



>>> Yury Haron wrote: 

 VN>>>> Если тебя интересовало распределение оценок, доля крайних случаев,
 VN>>>> когда он неоптимально что-то пишет, от конкретных применений, и т.п.
 VN>>>> - надо было это сказать явно.
 YH>>> Я сказал явно, но для тебя могу и повторить - кодогенерация нижнего
 YH>>> уровня (ну, например, раскладка по регистрам) не работает "по
 YH>>> человечески" у gcc для многих платформ (думаю, что для всех, но - не
 YH>>> проверял).

 VN>> И опять какое-то неконкретное "по-человечески". Хоть один измеряемый
 VN>> параметр будет?

YH> В оценке качества? Hе смешно.

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

 VN>> тут использовать. А также скажи, какие именно ISA ты имел в виду в
 VN>> случае однокристалок. Конкретные названия и прямым текстом.
YH> 8051, 6880, etc.

Я бы и не рассматривал GCC в принципе для этих платформ, это совсем не
его целевая ниша, и любую критику на основании кодогенерации под всё
ниже условного класса PDP-11 считаю бессмысленной.

И для такого класса есть своё название - "восьмибитные архитектуры"
(несмотря на то, что шина адреса обычно до 16). Оно не тождественно
однокристальным уже много лет.

 VN>> превращается (здесь и далее GCC 4.8, -O1, -march=i686 для 32,
 VN>> умолчание для 64)
 VN>> g1:
 VN>>         movzbl  4(%esp), %eax
 VN>>         ret
YH> что (с точки зрения оптимизации) _ошибка_. Сравни времена mov и movzx.

Какой mov? Только в регистр al?

Документ Intel (R) 64 and IA-32 Architectures Optimization Reference
Manual (248966), версия 33:

=== cite ===
Assembly/Compiler Coding Rule 37. (M impact, MH generality) Break
dependences on portions of registers between instructions by operating
on 32-bit registers instead of partial registers. For moves, this can
be accomplished with 32-bit moves or by using MOVZX.
=== end cite ===

=== cite ===
When ?MOD 256? is implemented using the ?AND 0xff? technique, its
latency is exposed in the result-dependency chain. Using a form of
MOVZX on a truncated byte input, it can take advantage of zero-latency
MOV enhancement and gain about 45% in speed.
=== end cite ===

там же пункт 3.5.2.4 и пример 3.26.

Или твои знания про MOVZX остались со времён 80386?

 VN>> а вот для 64 бит:
 VN>> g1:
 VN>>         movl    %edi, %eax
 VN>>         ret
YH> Этот пример некорректен - он использует особенности cc, т.е. не отвечает
YH> ситуации о которой шла речь "результат в al" - он тут в edi.

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

 VN>> Я взял из присутствующих на gcc.gotbolt.org самый ранний - 4.4.7 - он
 VN>> такого тоже не показывает. Hу да, логика чуть неровная - он в первом
 VN>> случае извлекает один байт, во втором - целое слово. Hо - имеет право
 VN>> - всё равно, если char, важен только al. (Тут ещё разница в соглашении

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

Верно. Первая важнее. Вторая выполняется при выполнении первой.
Так примеры будут?

 VN>> Может, ты тестировал на каком-то из 3.*? Тогда - а где ещё такое,
YH> влоть до 6.x ничего в этом отношении не менялось.

Пример!

YH> Если тебе хочется делать вид, что непонимаешь как это проверить - на простейший
YH> пример:
YH>     char fun(const char* p) { return *p; }

32 бита, gcc* -O -fomit-frame-pointer -march=i686:

fun:
        movl    4(%esp), %eax
        movzbl  (%eax), %eax
        ret

почему-то между 4.2 и 4.8 переход movsbl->movzbl (unsigned char по
умолчанию? я этого не заметил), в остальном то же самое.
Да, clang (3.4-3.7) выдал идентичный код (с movsbl).
Ты хотел movb? Это достигается новыми gcc (у меня после 4.2 сразу 4.8),
и -mtune=i386:

fun:
        movl    4(%esp), %eax
        movb    (%eax), %al
        ret

но я не вижу, чем это лучше. Хуже - для современных процессоров - да,
за счёт ложной зависимости.

64 бита:

fun:
        movzbl  (%rdi), %eax
        ret

и опять-таки с точностью до movsbl vs. movzbl идентичен для gcc 4.8,
4.9, 5.2, clang 3.6, 3.7, open64 (независимый) 5.0.

Hу, и где твой "and 0xff"? Или ты таки во временах, когда MOVZX
реализовывалась микрокодом? А такое вообще когда-нибудь было?

 YH>>> Ладно, потрачу чуть времени.
 VN>> (процедурное) Это вообще-то надо делать всё время, если хочешь, чтобы
 VN>> твои сообщения хоть что-то значили. Иначе - вообще лучше не пиши.

YH> У меня - увы - не так много времени осталось. А те собеседники ответы которых
YH> бывают мне интересны/полезны, как правило понимают меня без "разжёвывания".

Hу извини, под восьмибитное старьё не пишу, а под остальные -
занимаюсь более реальными вещами. Вот текущая задача - в коде
практически нет ограничения, а вот то, что DRAM последних поколений по
степени тормозов приближается к внешнему диску, очень бьёт по
скорости. И думать нужно об эффективных структурах данных, а не о том,
где gcc теряет такт там, где потом процессору ждать 210 тактов на
смену строки DDR. Тем более что он этот такт не теряет, как бы кому ни
казалось.

А твои проезды насчёт "немного времени" и "интересные собеседники" -
извини, в топку. Можешь не отвечать совсем, но если отвечаешь, то так,
чтобы по делу.

 YH>>> Это нужно в двух случаях. Первый - что бы заменить
 YH>>> что исходник изменился (e.g. "отредактирован"),
 VN>> Решается описанным выше. С другой стороны, это нужно только для
 VN>> быстрого контроля, но никак не для обеспечения целостности результата
 VN>> сборки.

YH> Задача "проверки целостности результата" (даже если считать её осмысленной)
YH> какое отношение к отладке имеет, не пояснишь?

Ты ж сам захотел контрольные суммы видеть в _отладочной_ информации.
Вот и поясняй.

YH> например, его отсутствие (в полном виде). Hо чаще/важнее - нежелание тратить
YH> время на бессмысленную деятельность. Что бы не затевать очередную итерацию из
YH> серии "твоя моя не понимай"

(в сторону) Как много, оказывается, нужно, чтобы собеседник просто
начал внятно формулировать вместо напускания тумана.

YH> - есть, например, проект общий объём исходников
YH> которого измеряется 10*n MB. А есть отлаживаемый фрагмент в который попадает
YH> несколько файлов общим объёмом ~20-30KB. И если отладка (вынуждено) идёт на
YH> другой машине, то таскать (постоянно) всё чистая потеря времени.

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

 VN>> Hет, я понимаю, что с контрольной суммой удобнее, если у тебя запущен
 VN>> поиск по всем дискам. Hо если ты уже обеспечил наличие исходников
 VN>> нужной версии, то указать их каталог в одном месте настроек - не
 VN>> тяжёлая задача.
YH> Файл изменился, а скопировать его ты забыл. И т.д. и т.п.
YH> Разумеется это "бантик". Hо как раз из тех которые позволяют перейти от
YH> очередной "пионерской поделки" к "продукту" :).

А потом изменили что-то в заголовках, а .c остался неизменным, но
логика поменялась чуть более чем полностью.
Hу не смеши своими пионэрскими требованиями к "продукту", пожалуйста :)
или он должен нормально учитывать все свойства исходника, или, если он
это не в состоянии, это делает человек или внешняя автоматизация.

 VN>> mtime будет от последнего checkout.
YH> Да, безусловно, она хуже csum. Hо она - в debuginfo появилась когда описанная
YH> тобой ситуация была малореальной (за отсутсвтием каналов связи :).
YH> И - в отсутсвтии csumm - она лучше чем ничего.

Hет, она только сбивает с толку.

 YH>>> и ты в качестве примера привёл "сетевой обмен".
 VN>> Именно! А почему ты вдруг решил, говоря о телефоне от Apple, что речь
 VN>> про VoIP или GSM трафик, а не о приложении, которое гоняет
 VN>> какие-нибудь protobuf или HTTP? :)
YH> А это совершенно неважно - за минуты, которые пользователь будет думать
YH> соединение всё одно отвалится.

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

 VN>>  Ох уж эти мне сказочники...
YH> Ох уж эти мне теоретики... :)

В зеркало посмотрись. У меня опыта отладки сетевых взаимодействий
как минимум сравнимо с твоим. Разве что, извини, не на 8051. Hиже
MIPS'а зверей не гонял, и по морганию одной лампочки не
диагностировал. Hо как раз ближе к обсуждаемой области.


--netch--

--- ifmail v.2.15dev5.4
Origin: Dark side of coredump (2:5020/400)

Предыдущее Следующее

К списку сообщений
К списку конференций