Xpeccy

[Vitamin]

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

А еще раньше трава зеленее была и небо голубее.

Компилятор не может сгенерировать код лучше программиста. Он может сгенерировать код лучше среднестатистического программиста. В большинстве случаев. И то не всегда.

Компилятор- это всего лишь инструмент. Правильное применение снимает головную боль, неправильное- добавляет.

Поэтому если хотите получить хороший код - помогите компилятору.

Я про это и говорил.

Вон взять Шалаевский эмулятор. С той поры кроме нескольких недокументированных фичей и точных времянок не появилось в эмуляторах принципиально ничего нового. Толка тогда на 120-м пне оно летало со свистом, а сейчас на двухгигагерцовом каждый второй эмулятор лагает.

И где он теперь этот эмулятор Шалаева? Почему он не развивается? Может потому, что написан был для оптимизации по скорости под имеющееся на то время оборудование. Что привело к
а) абсолютной неподдерживаемости
б) абсолютной некроссплатформенности
в) далеко не оптимальной работе на современных платформах, ибо правила выполнения даже машинных кодов поменялись, а пересборка ассемблерного кода (в отличие от ЯВУ) бессмысленна

Потому-что "я синтаксически корректный код ему скормил, пускай оптимизирует".

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

Чтобы генерировать эффективный код нужно иметь представление как компилятор думает и во что примерно он скомпилирует ту или иную конструкцию. Тогда еще когда вы пишете код можно выбрать наиболее эффективную, даже если алгоритм чуть изменить придется для этого. Это называется "уметь эффективно пользоваться инструментом"

Потому-что где-то правильнее для какого-то конкретного компилятора сделать switch-case, а где-то if вложенный. Где-то надо цикл руками развернуть, а где-то компилятор сам справится. Где-то явное приведение типа в условии надо сделать, потому-что автоматическое приведение порождает функционально тот-же, но избыточный код, навроде test eax,1, and eax,eax, jz somewhat.

Существуют платформы, отличные от x86 (Всегда ваш, Капитан Очевидность).
Или ты можешь изглаголить универсальные рецепты по оптимизации под все возможные платформы?

Где-то в явном виде сделать табличный вызов функции, где-то отказаться от ООП чтобы не иметь оверхеда на цепочке inherited вызовов которые фактически nullsub-ами являются но программисту выяснять это лениво и он тупо inherited вызов делает, хуже то мол всяко не станет. Да прагму написать какую-нть иногда полезно бывает. Выравниванием поуправлять.

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

Я тут давеча код один ковырял. В некоторых местах оверхеда до 90% насчитал. Полмегабайта кода который реально не делае ничего, кроме передачи друг другу управления и возвращения единственного нулевого статуса. Просто потому-что две библиотеки писали разные люди которым было лень и некогда разбираться в другдружьем коде, а третий воспользовался библиотеками первых двух и тоже поленился разбираться, да еще отнаследовался не от того что надо а от того что на глаза попало. В итоге дикий оферхэд как по производительности так и по памяти (две сотни абстрактных методов еще, против десятка которые реально используются и переопределены). Это только один inherited вызов. Вложенность наследования - чуть более сотни. Единственный пустой метод. А там еще есть конструктор и деструктор как минимум. И все виртуальное. Нахрена ?

Ну дык, умеючи и член сломать можно. Наследование- это сильная связь, агрегирование- слабая. Надо использовать агрегирование чтобы легко переделывать программу при необходимости. В моем коде размер типичной иерархии наследования- 2 уровня (абстрактный интерфейс и один или множество наследников). 3 и более уровней (приходится иногда писать) становятся в очередь на рефакторинг.

Я вот тоже видел программу, "оптимизированную по скорости", и располагающуюся в одном(!) файле размером в 600кб(!). Внутри километровые функции по тысяче строк. Сопровождению не поддается.

Или еще пример (из моей программерской жизни). Необходимо описать атрибуты некой сущности. Как поступает обычный программист- пишет структуру и возвращает ее заполненную из некой функции. Я тоже так сделал. И начал ловить дикие тормоза. Переделал все в ООП-стиле (интерфейс с методами доступа) и получил более чем трехкратный прирост скорости. О причинах этого прироста предлагаю догадаться самостоятельно.