Skip to main content

Конференции

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

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

Дата: 23 Sep 2016, 12:07:02
От: Yury Haron @ 2:5020/848.23
Кому: Valentin Nechayev
Тема: Вопрос по коду


Приветствую Вас Valentin!

22 Сен 16 в 09:03, Valentin Nechayev сообщал Yury Haron:

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

 VN> Какое "такое" поведение?

"Работает в среднем достаточно хорошо"(с) твой.

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

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

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

 VN> В регистрах хранится меньше, чем могло бы влезть?

Достаточно бессмысленный показатель - использование регистров далеко не всегда оптимизация (бывает и наборот).

 VN> Используются не все возможные комбинации регистров для операций,
 VN> некоторые явно пропущены?

Про комбинации не знаю (это "интересно" анализировать только авторам компилятора). А вот ситуации когда идёт "перекладывание" между 1-2-3мя регистрами при наличии ещё 10ка незадействованных
встречаются регулярно.

 VN> Или "по-человечески" означало всегда использовать для одного и того же
 VN> парамтра один и тот же регистр? :)

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

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

8051, 6880, etc.

 YH>> Хочешь рассуждать на примере x86? Да Бога ради - попробуй
 YH>> "обосновать" то, что gcc для процедур возвращающих bool (или char)
 YH>> хронически генерит на выходе нечто вроде
 YH>> and eax, 0ffh
 YH>> ret

 VN> Да, ты знаешь, трудно такое воспроизвести. Очень трудно. Давай я
 VN> попробую погадать. Первый, самый логичный, вариант: речь о каком-то
 VN> сужении диапазона для загоняние из более широкого значения. Какое у
 VN> нас более широкое? int? Пробуем - да, заведомо на самом простом коде,
 VN> чтобы исключить все посторонние эффекты.

 VN> char g1(int a) {
 VN>   return a;
 VN> }

 VN> превращается (здесь и далее GCC 4.8, -O1, -march=i686 для 32,
 VN> умолчание для 64)

 VN> g1:
 VN>         movzbl  4(%esp), %eax
 VN>         ret

что (с точки зрения оптимизации) _ошибка_. Сравни времена mov и movzx.

 VN> а вот для 64 бит:
 VN> g1:
 VN>         movl    %edi, %eax
 VN>         ret

Этот пример некорректен - он использует особенности cc, т.е. не отвечает ситуации о которой шла речь "результат в al" - он тут в edi.

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

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

 VN> g1:
 VN>         movl    %ecx, %eax
 VN>         ret
 VN> Уй, регистр поменялся.

см. комментарий выше.

 VN> Может, ты тестировал на каком-то из 3.*? Тогда - а где ещё такое,

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


 YH>> Причём тут "недоверие"? Как раз генерация ошибочного (с точки зрения
 YH>> результатов вычислений) кода у него встречается, пожалуй, даже реже чем
 YH>> у соседей.
 VN> Ура! Что-то в плюс. Так, может, и "лишние", с твоей точки зрения,
 VN> операции это результат того, что он старается соблюсти корректность?

Вот уж что меня совершенно точно не интересует, так это его "мотивы". Он может руководстваться чем угодно, я смотрю только на результат.

 VN> Да, последовательность выполнения строк исходника. Она ровно по
 VN> порядку написания, я проверил через построчные шаги в отладчике.
 VN> Прыжков не было. Ещё примеры будут?

В ближайший раз когда придётся что-то смотреть в *nix'ах пришлю, если хочешь, а тратить время на их "специальное написание" смысла не вижу. Был бы ты (со)автором, ещё можно было бы разок потратить
время из соображений "а вдруг исправят" (хотя для OS это исключение, а не правило), а просто воздухосотрясения для...


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

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

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

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

 YH>> а второй когда отлаживается программа не там где она
 YH>> писалась/компилировалась и в окрестностях лежит несколько файлов с
 YH>> одним и тем же именем (при этом исходники берутся не из тех путей
 YH>> как прописано в бинарнике, а по указанным пользователям).
 VN> Мнэээ... они лежат деревом как исходное, или как? Что мешает

или как.

 VN> подключить это дерево в проект при отладке?

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

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

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

 VN>>> Hу а против передачи даты сборки есть даже явное требование -
 YH>> Hе сборки. Исходника.
 VN> Тем более! Эта дата вообще ничего не значит.
 VN> Я вот сделал checkout ветки A, потом ветки B, потом снова ветки A.
 VN> mtime будет от последнего checkout.

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

 VN>>> Это тебе опять двойка за логику, потому что предположил, что 1) все
 VN>>> задачи на современном смартфоне автоматически realtime с малыми
 VN>>> таймаутами, 2) отладка всегда предполагает существенные задержки
 VN>>> из-за ожидания реакции человека. Hи одно, ни другое в общем виде не
 VN>>> верно.
 YH>> Специально для любителей не следить за контекстом - разговор идёт об
 YH>> отладке человеком (а не о логах/скриптах)
 VN> Об отладке отладчиком - что не значит человеческие задержки.

Значит. Ещё раз повторю - "не о логах/скриптах". Да, существуют скриптовые отладчики, но разговор изначально шёл о "взаимодействии" человека и отладчика.

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

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

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

Ох уж эти мне теоретики... :)


 Hа чем и прощаюсь,
    Юра.

--- (none)
Origin: АР словарь: software - придурковатый продукт (2:5020/848.23)

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

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