тип long long. почему нестандартный?

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

_DEN_
http://www.iar.com там сверху список платформ. ищите х86.

 

Ustus, ну, не знаю. у кого-то VC глючит, у кого-то IAR. у меня всё норм. довольно хороший компилятор. отлично оптимизирует, проблем не вызывает. Вот Keil - другое дело. Довольно глюконутое создание. Хотя, и с ним можно работать.
Чтобы писать на gcc, а потом отлаживать под gdb - это нужно обладать особым мазохизмом.

 

Ещё одно мега обоснованное заявление.
Что-то последнее время обострение пошло: то у кого-то студия не так работает, то у gcc оптимизатор плохой...
Оптимизатор там сравнимый с MSVS и ICC.
Где лучше есть я не знаю...

 

имхо msvc-gcc-icc, такой порядок качества оптимизации.
Хотя в большинстве ситуаций сравнимо.

 

Это всё спорные вопросы.
В некоторых ситуациях ICC намного лучше, в некоторых нет.
Но то что у GCC хороший оптимизатор - это однозначно.

 

По поводу качества оптимизации gcc могу поспорить. Что касается сторонних процессорных архитектур, таких как ARM, AVR, то он, действительно, довольно слабо оптимизирует. У IAR качество кода значительно выше - как по размеру, так и по производительности. В гугле можно найти довольно много сравнительных тестов.

 

Ну давай свой проведём
Под AVR я не писал, под ARM сейчас пишу.
GCC 4.5.0 оптимизирует если не отлично, то очень хорошо.

 

+1
gcc благодаря промежуточному коду почти не зависит от платформы компиляции, и для arm/avr генерит очень неплохой код.
Правда ручками иногда можно чуть лучше написать из-за особенностей платформ, но не всегда.

 

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

 

cupuyc

Да если б глючил. Эта зараза у меня как-то заклинила на какой-то фигне типа char a; int b; if( a & b )... - точно уже не вспомню. Путем шизофренического изучения кода было выяснено, что оно делает арифметику на смешанных типах не так, как всякие зануды из ISO/IEC, а как хочет его левая пятка. Сей прискорбный факт сильно уронил его в моих глазах. А оптимизирует да, оптимизирует хорошо, зараза, особенно по размеру - руками хрен так сделаешь.

Насчет gcc - сам поток кода оптимизит хорошо, правда паттерны ловит похуже MS. Только вот некоторые фичи - просто плакать хочется. Ну какого делать memcpy через тормознутое rep movs? Как ни крутил настройки - от этой ереси никак не избавиться

 

Совсем недавно (пока не добавили поддержку SSE) студия делала то же самое, и никто не жаловался.
А вообще у тебя скорее всего размер копируемого блока маленький просто.

 

cppasm
TermoSINteZ
разве есть проблема скомпилить с -O1 (не знаю зачем компилить всю прогу с -O2) и тем и тем? последний раз когда полгода назад компилил и тем и тем бинарь из мингв-гцц на то время последнего был в ~2 раза толще, чем из мсвс2003. и не могу сказать, что это исключение. бинари из гцц с -О1 всегда в 1.5 и больше раза толще, чем из мсвс.

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

 

qqwe

Ну как зачем?! -O2 врубает ряд существенных оптимизаций. Правда -O2, в некотором смысле, тоже не фонтан, поскольку всё ещё не включаются -funroll-loops и -finline-functions. Я в make.conf, вечно к -O2 добавляю ещё -ftracer и -ftree-vectorize (это помимо -funroll-loops и -finline-functions). -ftree-vectorize я в действии не наблюдал -- как-то руки не дошли, а вот -ftracer реально помогает коду быть лучше: я изучал вопрос, как бы так написать inline функцию с аргументом n и циклом for (i = 0; i < n; i++), причём, чтобы цикл разворачивался. Без -ftracer я не смог добиться такого. Правда было это пару-тройку лет назад, может сейчас ситуация изменилась.
-O2 ведь, по-сравнению с -O1, делает выход лишь лучше: проводятся оптимизации по скорости, которые не увеличивают размер. Поэтому, по-моему, имеет смысл всегда врубать -O2, отключая его лишь для создания отладочного билда. Скорость компиляции не настолько критична, чтобы отказываться от пачки дополнительных оптимизаций.

И что это доказывает? Что опция gcc -O1 подразумевает меньшую оптимизацию, чем аналогичная у msvc?

 

Уже был вопрос про пруфлинк. Я очень хочу его повторить. Мне очень не нравится, читая поверхностные описания непонятно чего, подозревать тебя в том, что твои эксперименты были поставлены криво. И в то же время, мне было бы интересно посмотреть на описание серьёзных проблем оптимизации, которые ещё неизвестна разработчикам gcc, или с которыми они не в состоянии справиться. Мне всегда было интересно, что получается в результате работы gcc. Но, к сожалению, это абстрактное любопытство последнее время не подкрепляется практическим интересом, и поэтому не в состоянии в состоянии сподвигнуть меня на самостоятельные исследования. И я бы благодарен, за содержательные линки на эту тему.

 

Отличный подход.
Давай тогда вообще отключим оптимизацию (-O0) и будем писать что оптимизатор плохой.
Я вообще всё с -O3 собираю, чтоб не добавлять кучу ключей к -O2 как r90 написал.

И какой смысл сравнивать тёплое с мягким?
-O1 - оптимизация по скорости, а сравниваешь ты размер.
Это показатель что-ли?
Хочешь по размеру оптимизировать - для этого отдельные ключи есть.

 

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

 

У меня видимо звёзды так не становились, не сталкивался с таким ни разу.
Ну можно -O2 -finline-functions -funroll-loops если к -O3 резкая антипатия.
Но сравнивать при этом всё равно надо скорость, а не размер.

 

Это конечно.

Видимо именно так.

 

Я GCC 4.5.0 пользуюсь, вот из его мануала: http://gcc.gnu.org/onlinedocs/gcc-4.5.0/gcc/Optimize-Options.html

Никаких таких страшилок не пишут