Проект FreeBSD намерен сменить GCC на LLVM+Clang

> Начиная с 4.3 кода стало больше, скорость падает: -march=native -O2 -pipe -ftree-vectorize unrar-424 size: 180488 time: 1m17.608s unrar-440 size: 188348 time: 1m27.211s

Это один тестовый случай, у нас таких тестовых случаев было гораздо больше: 35-ть платформ, на каждой платформе нужно довести до максимума производительность 10-15 критичных по скорости алгоритмов. В совокупности на каждой платформе GCC 4.3 лидировал по сравнению с другими компиляторами, за исключением платформы IA32 на которой отставание от ICC было до 10%.

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

Этим примером просто ничего нельзя показать, ИМХО. Уж слишком много параметров влияет на конечный результат независимо от компилятора.

Попробуйте похожее сравнение провести для платформы AMD64. На ней для нашей задачи GCC 4.3 "уделывал" все компиляторы.

64bit пока не mainstream, поэтому не хочу на него переходить.

1) глюки

2) неработающий проприетарный софт

3) неработающий старый софт

Кроме этого, ломает держать в системе две копии lib - а без этого никуда (по крайней мере, для меня).

> вариантов "почти оптимального" кода существует очень много. Компилятору сложно найти оптимальный код именно для этой платформы.

Извините, никак не осилю логику. Либо оптимум есть(неважно, если он не один), либо его нет. Задача компилера - генерить оптимально именно под текущую архитектуру, даже при полностью опущеных флагах.

Регистры - да, а у кого их слишком много?? На то и есть кэш 1 уровня.

Возможно, x86 слишком бестолковая архитектура, чтобы поддерживать производительность операций "хотя бы не хуже". Так и фик с ней! Гигагерц полно, какой смысл в этих жалких 5%? Да и конечная производительность зависит больше от индусячьего кода, чем от тонких оптимизаций компилера.

> Извините, никак не осилю логику. Либо оптимум есть(неважно, если он не один), либо его нет. Задача компилера - генерить оптимально именно под текущую архитектуру, даже при полностью опущеных флагах. Сложно это для IA32... потому что много всего нужно учитывать, нереально много.

> Регистры - да, а у кого их слишком много?? На то и есть кэш 1 уровня. Да их и не нужно слишком много, хотя бы штук 16-ть, но не 7-иь же. Кэш 1-го уровня классная вещь, но обращение к памяти, даже если это кэш - это дополнительные инструкции как не крути, больше инструкций - хуже производительность в общем случае.

> Возможно, x86 слишком бестолковая архитектура, чтобы поддерживать производительность операций "хотя бы не хуже". Так и фик с ней! Гигагерц полно, какой смысл в этих жалких 5%? Да и конечная производительность зависит больше от индусячьего кода, чем от тонких оптимизаций компилера.

Вот здесь я полностью согласен. От головы гораздо больше зависит чем от компилятора. Но! Хороший компилятор Си мне нужен для того, чтобы избежать поддержки тонн ассемблерного кода для кучи архитекутр. Мне очень важно, чтобы мой Си-шный код оптимизированный на верхнем уровне под особенности микроархитекутры хорошо транслировался компилятором в ассемблерный код (с подбором правильных инструкции и расстоновкой их в правильном порядке). И эту задачу для большого количества современных архитектур в совокупности GCC выполняет лучше других! А часто даже лучше чем все другие компиляторы даже для конкретной архитекутры (AMD64, Sparc64, Power64).

Для целочисленных задач GCC имеет одно очень важное преимущество над другими компиляторами. Только GCC поддерживает целочисленный тип int128_t и умеет выполнять 64-битное умножение, ни один другой компилятор АФАИК не умеет этого. Это большой плюс GCC на 64-битных архитектурах.