С++ — самый красивый язык програмирования

[Алексей Гринь]

Если нравится жить мифами и предубеждениями, пожалуйста.

Я предложил поставить эксперимент.

Что будем сравнивать? На какой задаче?

[GaLL]

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

Ассемблер, конечно! На всех остальных языках процессорам приходится выполнять много лишнего. Вспоминается mov eax, eax из проги, написанной в Delphi.

[GaLL]

Что будем сравнивать? На какой задаче?

Вариантов очень много, не знаю, на чем остановиться.

[Алексей Гринь]

Может, попробуем C# vs. C++? C# третьей версии наполовину функционален С собой сейчас только gcc и C#овский компилятор.

[GaLL]

Может, попробуем C# vs. C++? C# третьей версии наполовину функционален С собой сейчас только gcc и C#овский компилятор.

Тоже можно. Только С++ лучше будем тестить на компиляторе от Intel или Microsoft, они генерируют более быстродейственный код, нежели gcc/g++, по крайней мере те версии, с которыми я сталкивался.

[myst]

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

Качество кода у разных компиляторов под разные процессоры разное. Если для IA-32 и компилятор от Intel, то я тягаться с ним не буду. А вот для Atmel'ов можно потягаться.
К тому же не надо забывать, что даже в пределах IA-32 оптимальный машинный код для разных моделей процессоров будет разным. Ассемблер теряет смысл. А если мы хотим перенести программу на другую процессорную архитектуру, то в случае ассемблера идём за мылом и верёвкой.

[myst]

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

На каком проценте задач это жизненно необходимо?
Какой получаемый профит? Что делать при апгрейде процессора, снова грызть этот кактус?

[Алексей Гринь]

Только С++ лучше будем тестить на компиляторе от Intel или Microsoft

Не имею таких и не умею. Интел - согласен, Майкрософт - поспорил бы.

[GaLL]

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

На каком проценте задач это жизненно необходимо?
Какой получаемый профит? Что делать при апгрейде процессора, снова грызть этот кактус?

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

[GaLL]

Только С++ лучше будем тестить на компиляторе от Intel или Microsoft

Не имею таких и не умею. Интел - согласен, Майкрософт - поспорил бы.

В смысле - поспорил?
А какое умение Вы подразумеваете? Сам язык везде почти один и тот же. Наверно, речь идет о разнообразных опциях компиляции, но тут можно в порядке эксперимента проверить эффективность кода, сгенереированного с разными ключами.

[myst]

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

В такой ситуации руками оптимизировать переписыванием на ассемблер тоже нет никакого смысла. В общем, асм — для встроенных систем, там он действительно Д'Артаньян.

[Алексей Гринь]

Только С++ лучше будем тестить на компиляторе от Intel или Microsoft

Не имею таких и не умею. Интел - согласен, Майкрософт - поспорил бы.

В смысле - поспорил?
А какое умение Вы подразумеваете? Сам язык везде почти один и тот же. Наверно, речь идет о разнообразных опциях компиляции, но тут можно в порядке эксперимента проверить эффективность кода, сгенереированного с разными ключами.

Ну-ну, особенно микрософтский С++ такой же. Очень такой же. Да.

[myst]

Господа, всё уже сделано до нас!
http://shootout.alioth.debian.org

[GaLL]

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

В такой ситуации руками оптимизировать переписыванием на ассемблер тоже нет никакого смысла. В общем, асм — для встроенных систем, там он действительно Д'Артаньян.

Так я о том же. "Магринальная задача", т. е. иногда возникает такая необходимость, в подавляющем же большинстве случает - совсем нет.

[Алексей Гринь]

Господа, всё уже сделано до нас!
http://shootout.alioth.debian.org

Я то же самое нагуглил, но мне везде The requested URL /u32q/gpp.php was not found on this server. пишут.

[GaLL]

Ну-ну, особенно микрософтский С++ такой же. Очень такой же. Да.

Если ограничиться тестированием компиляторов, то зачем весь этот Microsoft specific?

[Алексей Гринь]

О, вдруг заработало.

[myst]

Так я о том же. "Магринальная задача", т. е. иногда возникает такая необходимость, в подавляющем же большинстве случает - совсем нет.

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

[GaLL]

Так я о том же. "Магринальная задача", т. е. иногда возникает такая необходимость, в подавляющем же большинстве случает - совсем нет.

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

Нет, есть. Вспомните Doom II и Quake. Можно еще вспомнить разработку ОС и драйверов.

[myst]

Нет, есть. Вспомните Doom II и Quake.

В те времена смысл ещё сохранялся. А сейчас интеловцы такой зверинец развели, что чёрт ногу сломит. Количество специалистов, способных его приручить, боюсь, очень невелико. А ведь ещё есть AMD. Да и Cyrix восстал из ада.

[GaLL]

Вы имеете в виду расширения архитектуры x86, начиная от MMX и пр.? Это не такая уж проблема, просто заниматься этим теперь нет особого смысла. И это одна из причин, почему время С++ с его упором на быстродействие уходит.

[myst]

Вы имеете в виду расширения архитектуры x86, начиная от MMX и пр.?

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

[myst]

Можно еще вспомнить разработку ОС и драйверов.

При разработке ОС (MenuetOS не в счёт ) обычно стремятся минимизировать необходимый ассемблерный код, и с драйверами та же история, насколько я знаю.

[GaLL]

Вы имеете в виду расширения архитектуры x86, начиная от MMX и пр.?

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

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

[Алексей Гринь]

Кроме того, есть такие грубые "хаки", как самомодифицирующийся код.

Его дебуггить потом ...