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

Красавец , грамотно всё разложил по полочкам.

Может я чего то не понимаю, а посмотреть ассемблерный код скомпилированного Сишного и понять где теряется скорость?

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

Я и не говорил что хочу писать на ассемблере, я хочу научится «читать». Фрагменты кода. Ну и так, для общего развития.

Пока я только лишь ответил на две фразы из первого поста на которые ответил.

Читать - это вы про что? Отладка и реверс инжиниринг - оно полезно, но к производительности это отношения не имеет.

Пока я только лишь ответил на две фразы из первого поста на которые ответил.

Я давно спрашивал про то нужен ли асм. Там была огромная дискуссия, и часто говорили что компилятор точно лучше человека (в планах оптимизации) я помнил что где то читал обратное но забыл где, а теперь нашел это и запостил тут.

Читать - это вы про что?

А под читать я имею в виду.. Ну например, хочу посмотреть как что то делается с указателем, в qt-creatore показывается асм код функции. Пример весьма тупой,но лучше привести трудно.

Иди учи язык

Битовые операции со знаковыми целыми сами по себе UB. Так что идите учиться дальше.

Со справочником можно и год просидеть. Ценящие своё время люди используют инструменты: VTune, например.

Так ли это?

Да.

я хочу научится «читать». Фрагменты кода.

Рекомендую расчехлить ollydbg/idapro и поковырять какие-нибудь софтинки. Можно даже crackme от Cruehead, хоть они и для другой цели предназначены, но главное их достоинство - они очень просты.
ЗЫ: Тулузы род оффтопик, да, но под онтопик по удобству использования с ними ничто не сравнится (буду рад ошибиться)

Так ли это?

Так. Но не потому что компиляторы оптимизируют код хуже. А потому что только человек способен оценить что и как именно нужно оптимизировать. Компилятору план человека неведом.

гдееее имееенноооо?

Вот зачем ты вбиваешь в молодые умы, что оптимизация не нужна, компилятор соберет все сам, железо вытянет, а вы просто теряете время. Уже и так все обленились, что хочется головой об угол стукнуться, когда малофункциональное ПО пожирает ресурсы. Нужна оптимизация, всегда нужна, вопрос в подходе, но стараться выжать все - НУЖНО. Если не получается, значит нужно учиться дальше, если влом - значит ты не ту профу выбрал.

Битовые операции со знаковыми целыми сами по себе UB.

Битовые операции со знаковыми целыми сами по себе - не UB. Представление знаковых чисел может отличаться в различных архитектурах, но применять к ним битовые операции стандарт разрешает. Алгоритм с тремя xor'ами будет работать независимо от представления знакового числа.

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

у автора ЧСВ Over9000, а опыта без году неделя.

но иногда хороший программист может сделать лучше, чем компилятор. И делает!

тогда, и ТОЛЬКО ТОГДА, когда CPU ТОЧНО задан.

правда ли, что при работе с оптимизирующими компиляторами, следуя неким приёмам программирования, можно помочь оптимизатору сгенерить более лучший код?

конечно. Смотри на то, что получается.

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

не очевидно.

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

не сможет. Компилятор «думает», что если программист использует пузырёк, значит так надо.

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

Суперкомпиляторы - вполне могут.

стараться выжать все - НУЖНО.

Зачем? Нужно, чтобы программа работала достаточно быстрее. Нет никакого смысла в том, чтобы она работала быстрее, чем «достаточно быстро». Если ты тратишь время на подобную оптимизацию - ты идиот, который зря тратит время.

Порой бывает даже хуже. Банальный пример: все помнят, что менять местами целочисленные значения XOR'ом — это супрекруто и супероптимально.

IRL всё НАМНОГО хуже, т.к. обычный обмен компилятор в контексте заоптимизирует, а вот xor — увы. Ну например в случае insert sort мы просматриваем массив с конца, и меняем соседние, если пробный эл-т меньше. Таким образом массив растёт, а дырка сдвигается к его началу до тех пор, пока мы туда не вставим пробный эл-т. Если мы возьмём твой первый swap, то его компилятор вообще выкинет, и будет просто переносить a[i]→a[i+1]. В случае с XOR так не получится.

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

а на кой ляд ты читаешь про всякое говно мамонта?

Как пример - меньше инструкций там, меньше инструкций сям, разве нет?

конечно нет, ибо выборка инструкций — отдельный блок CPU, который никак НЕ влияет на производительность.

Во-вторых, пишущие на асме скорее будут использовать xchg reg,reg, потому что это банально короче.

эта оптимизация из тех далёких времён, когда XCHG просто не существовало.

сходу не помню, меняет ли xor CF, потому что если он не перезаписывает флаги, то с xor-ами вообще содомия происходит.

AFAIK xor всегда сбрасывает CF, и устанавливает ZF тогда и только тогда, когда результат нулевой.

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

на ВСЕХ процессорах?

за это надо убивать! это же каким дебилом надо быть, чтобы такое написать!?

успокойся. Где ты был в 1992ом?

*a ^= *b; *b ^= *a; *a ^= *b;

Тут же UB.

нет

компилятор точно лучше человека

лучше тем, что «помнит» и «знает» про Over9000 существующих CPU. А человек — только про СВОИ локалхосты, на которых он тестировал.

Если ты не видишь разницы, между достаточно быстро и как получилось, то определение - идиот относится к тебе. Задолбали писатели - «собралось и ладно»

Если ты не видишь разницы, между достаточно быстро и как получилось

Если программа работает, то это достаточно быстро. Я, по крайней мере, не знаю ни одной из известных программ, которая работала бы не «достаточно быстро».

С тобой все ясно, пациент не излечим. Засим адьё, разговаривать тут не о чем.

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

стараться выжать все - НУЖНО

Напомнить, что внутри процессоры достаточно сильно различаются и поток команд, оптимальный для одного, валится на другом (привет, P4 и AMD FX)?

Нужна оптимизация, всегда нужна, вопрос в подходе

Тоже читаем только то, что хотим видеть?

Читай вторую половину моего комментария, да.

pipeline hazards

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

Один регистр сэкономился (edx).
Это способ оптимизации используемой памяти же.

Но если уж пошла такая пьянка, то кто мешает анализировать железо самому ПО и выбирать оптимальный способ исполнения на конкретном камне

Необходимость тестировать и переписывать всё каждый раз, когда выходит новый процессор?

и есть необходимость перейти к ручной оптимизации asm вставками

Интрисинки и так есть, а ниже спускаться уже неоптимально.
Достаточно указать компилятору «here goes SIMD», оптимальный поток он уже сам расставит.

В большинстве случаев в тормознутости современного софта виноваты алгоритмы.

практически во всех случаях тормознутость современного софта - миф.

то кто мешает

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

практически во всех случаях тормознутость современного софта - миф.

Если кратко - миф.
Если развёрнуто - смотря что и как мерять.

Как часто появляется новая архитектура? Кто сказал, что нет куска который будет работать на большинстве? Если софтина жива и имеет поддержку, почему не запилить под новую архитектуру? По поводу второй части твоего поста - вопрос выбора инструмента оптимизации, если недостаточно простых и не очень, то можно обратиться и к ASM. Чтож за фанатизм такой? Вроде нигде не призывал переписать все в машинный код.

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

допустим надо написать программу, которая складывает десять чисел. Допустим, я написал и моя программа работает секунду. для значительного числа юзкейсов (для которых, возможно, и писалась программа) это вполне ок и нету никакого смысла программу оптимизировать. ну будет она работать не 1 секунду, а 1 миллисикунду, ну и что? всем все равно похуй.

[trollmode]Мы на портале о линукс и гну, денежная сторона вопроса мало должна волновать.[/trollmode]

Вроде нигде не призывал переписать все в машинный код.

а как же твое «НУЖНО пытаться выжать все»?

ну ладно, тогда так:

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

https://www.coursera.org/course/malsoftware

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

нет куска который будет работать на большинстве?

Работать - будет. Оптимально - сомнительно.

то можно обратиться и к ASM.

Интрисинки - это не plain asm.

допустим надо написать программу, которая складывает десять чисел. Допустим, я написал и моя программа работает секунду.

Основная проблема немного не в этом.
Есть софтина.. Ну допустим года 95-97. Весит 100 килобайт. Выполняет задачу за минуту на Pentium-166
И вот в 201х появляется новая хайскалабилити хайавалабалити энтерпрайз вундервафля на до-диез++,
весит как полагается годному софту пару десятков мегабайт, работает над этой же задачей эту же минуту на топовом i7,
в следующей версии обещают добавить ТруЪ®™ WunderOptimizations ®™ и всё будет работать уже 50 секунд!

Странно, не находишь?

Где в этой фразе про машинный код? Читаем между строк? Других методов оптимизации нет?

http://en.wikipedia.org/wiki/Analysis_of_algorithms тоесть это говно мамонта ? Или тебя опять неправильно поняли?