К сожалению интеловский компилит далеко не все. Мне плевать кто и что не так написал, просто постоянно держать в руках напильник не хочется.

–02 and –03 Intel faster than GNU by 19 – 18%

Ну и где 10% ???

Aggressive Intel faster than GNU by 10% - это? Сам компилируй с такими ключами.

Вообщем, авторам GCC есть к чему стремиться.

7.0? Проснулись!:( Актуален 7.1! :)

Оба компайлера gcc и icc хороши для своих задач.

Сейчас для моих задач мне нужен gcc 3.3. "Религиозные споры" уже приелись и не прикалывают как раньше. После "русских физиков" любой стеб не катит.

Хмм хитрые интеля почему то (почему - вопрос риторический) не включили Stepanov Test ;)
Да и ++ из целой пачки тестов только один ...

Так что это они пусть домохозяйкам впаривают про 30% скорость
;)

Могет и мне чего нибудь затестить числодробильное :)
Правда у меня интелей нету (под линухом по крайней мере)

Я бы сказал, что актуальны ICC 7.1 и GCC 3.3.1. :)

Разве есть какая-то особая разница между 7.0 и 7.1, кроме того, что в 7.1 автодетект типа процессора жестче поступает с процессорами AMD - он их к самым младшим Pentium'мам приравнивает, без каких-либо MMX расширений.

смерть icc!

Заточенный под одну субархитектуру убогий компилятор,
не умеющий толком ничего собрать, -- в сад!

2Dselect: дадада! слакваря РУЛЕЗ!

дык оно такое же далекое от стандарта как и VC одно это уже дает однозначный вывод - в морг. Я не говорю о том что оно только под intel да еще и пытается встариватся в VC :) Отстой короче :)

странно шо на поделии, к-рое местные недоумки списывают в морг (VC я имею ввиду для танкистов) собираетца где-то в районе 30% всего софта в мире
мозги поправь, да, патологоанатом-самоучка

>Aggressive Intel faster than GNU by 10% - это? Сам компилируй с такими ключами.
А чего вам не нравится? Это -- ключи для оптимизации!

вам че, делать нефига? из-за 10 процентов? у меня ваще компилятор в 10 раз медленнее, но зато готовых модулей полтора гигабайта...

блин 10 процентов, да хрен с ними, GCC вообще компилирует весь софт, а icc в стандартной поставке 2.4.20-8asp не нашел... чего есть icc, чего нет... разница?

Или есть такие типы программ, в которых код генерируется какой-то другой программой, а потом компилится компилится компилится... ??

2 mr (*) (2003-08-11 13:53:27.272768)
> Это -- ключи для оптимизации!

Угу. И что с ними собирать? Проги типа "Hello, чуваки"?

>>мозги поправь, да в попу пошел, да ? Любитель кривых поделий блин. Это г (VC) да же на свои хедеры ругается. Но ты можешь им пользоваться, разрешаею ! Раб билла блин...

2 PitStop > Угу. И что с ними собирать? Проги типа "Hello, чуваки"? А вы, верно, других прог то и не собирали?

2 mr (*) (2003-08-11 15:04:25.025108)
> А вы, верно, других прог то и не собирали?

С чего Вы взяли. Компилить ядро (к примеру) здесь (на LOR'е) последний красноглазик умеет, а уж я и подавно справлюсь. Вот только стрёмно такое ядро ставить на сервер... В любой мало-мальски путной доке не рекомендуется "насиловать" GCC на оптимизацию при сборке НАДЁЖНОГО ядра (да и не только ядра). Это последнему студенту известно... :-)

2PitStop:
>>не рекомендуется "насиловать" GCC на оптимизацию
угу и вообще все оптимизации это для лохов ! пускай на машинах катаются,
а мы пешком. даже лучше ползком - так надежнее !

Ядро на icc?
А разве это вобще кому-нибудь удалось?

>оно такое же далекое от стандарта как и VC На счет соответствия стандарту ICC, GCC, VC смотри http://boost.sourceforge.net/regression-logs/ последний VC ближе к стандарту чем GCC и ICC.

2 anonymous (*) (2003-08-11 16:32:31.508036)
Ты у Irsi научился фразы из контекста выдёргивать?

А что касается автомобилей. На твоём авто не иначе как "оптимизированный" моторчик от F-1 стоит?

AMD mustdie. Слака тоже говно. У меня все, спасибо за внимание.

>http://boost.sourceforge.net/regression-logs/ последний VC ближе к стандарту чем GCC и ICC.

Как ты из этих чифирей сделал вывод о близости к стандарту???

>В любой мало-мальски путной доке не рекомендуется "насиловать" GCC на оптимизацию при сборке НАДЁЖНОГО ядра (да и не только ядра). Это последнему студенту известно... :-)

А может эта... Но в общем доки (в принципе) могли и устареть?

По крайней мере в теоритических книгах про построеине компиляторов (Д.Грис, М:Мир 1975) таких советов про опасность оптимизаций нет.

Правда тогда ни линукса ни gcc не было :) А компиляторы с оптимизацией были (не принято было ресурсами разбрасываться).

>Как ты из этих чифирей сделал вывод о близости к стандарту???
Проект boost ведется комитетом по стандартизации C++.
Эти логи есть показатель насколько успешно компилятор скомилировал бустовые библиотеки в которых используются многие (в том числе и не очень распространенные) фичи стандартного C++. Это, конечно, не полный тест по всем фичам, но библиотеки достаточно объемные и слолжные чтобы ими можно было тестировать компилятор.
Смотри
http://www.boost.org/index.htm
http://www.boost.org/status/compiler_status.html

2Dead удалось и не раз, но в основном работникам интеля

"последний VC ближе к стандарту чем GCC и ICC."

Где такую мощную траву берут?

как сделать { [1] = 2, [3] = 6 } как в мелкожопом С++?

Весельчак ХЫ!

> Проект boost ведется комитетом по стандартизации C++.

Из FAQ:

Is there a formal relationship between Boost.org and the C++ Standards Committee?  No, although there is a strong informal relationship in that many members of the committee participate in Boost, and the people who started Boost were all committee members.

Will the Boost.org libraries become part of the next C++ Standard?  Some might, someday, but that is up to the standards committee.  Committee members who also participate in Boost will definitely be proposing at least some Boost libraries for standardization.

> Эти логи есть показатель насколько успешно компилятор
> скомилировал бустовые библиотеки в которых используются
> многие (в том числе и не очень распространенные) фичи
> стандартного C++. Это, конечно, не полный тест по всем фичам,

Нет, это вообще не тест по фичам, а только "показатель насколько успешно компилятор скомилировал бустовые библиотеки". Не больше и не меньше.

> Смотри
Вот и посмотри сам хорошенько, о том я тебе и говорю!

> http://www.boost.org/index.htm
> http://www.boost.org/status/compiler_status.html

Kakay nahuy rasneza kokoy Compiler ICC ili GCC beresch wserawno oba rabotajut!!!

из тех цифр близость VC к стандарту никак не следует
в буст используются такие пассажи:

#if !defined(BOOST_MSVC) || BOOST_MSVC > 1300
template <int NDims>
#else
template <int NumDims, int NDims> // else ICE
#endif // BOOST_MSVC

Не гоните на AMD. Они уже пол года круче и дешевле (до этого были только дешевле).

2anonymous (*) (2003-08-11 18:26:15.805804) одна ебет другая дразница

А VC то все равно лучше в плане кодогенерации. Сосите, красноглазые.

2 anonymous (*) (2003-08-11 20:45:19.888047) Иди ты нахуй, уебак зассаный!!! Компили своим VC свои поделки для геи-клуба. Нехуй здесь пиздеть, свою крутость показывай своим приятелям-пидорам из вышеозначенного клуба.

>> А VC то все равно лучше в плане кодогенерации.
:))) Короче ты понял. Чувак я тебе завидую, воистину меньше знаешь - лучше спишь. Пользуй и дальше это говно :)))

GCC 3.2 по сравнению с VC 7.0 сосет однозначно практически по всем параметрам.

Ребята! Плохо же вы читали. Intel таки делает gcc на 10-20% и на 30% при "agressive optimization" (согласно статье). Хочется, конечно, чтобы gcc развивался в этом направлении. Сам я именно его использую. Знаю, например, что на моих задачах по сравнению с Борландом он делает код работающий в 4 раза быстрее. Кто-нибудь сравнивал gcc с Microsoft C/C++ Compiler? Интересно было бы послушать.

SadAlex.

Хех - ну если бы ICC да VC были еще и хуже в плане кода - то кто б их пользовал 8) A в gcc код хромает в силу хреновой тучи платформ которые он саппортит - не так оно все просто - довести всё это до ума. Жалко, что pgcc кинули тянуть - сделали б для х86 компилер приличный :(

>>>GCC на оптимизацию при сборке НАДЁЖНОГО ядра....

Если осторожно - то можно. Стандартная сборка кернела -O2 -fomit-frame-pointer. -O3 предролагает включение inline для функций - в основновном это корень всех неприятностей (в кернеле). Если это запретить (inline) - ядра пашут не хуже (надежность) чем в стандартном случае - а производительность в некоторых местах лучше.( Имеются ввиду участки кода где кернел не взаимодействует активно с железом) Это касается не только ядра. Хотя многие пакеты нормально собираються и без этого "предохранительного" акта :)

gcc ближе к стандарту чем VC++/IntelC++ говорю это как человек имевший несчастье долгое время с ними общаться. А 10% скорости да еще и только на Win+Intel нафиг не надо, тем более что эти мифические 10% если и существуют скоро испарит новый оптимизатор gcc !

Все сосут Visual Basic рулит Линух хуйня

>>>скоро испарит новый оптимизатор gcc ....

Который тут же спиздят M$ и Intel

Мдэ - есть такое дело - и доказать что они украли будет весьма непросто ...

Мэтры!
Подскажите!
Как собрать какую-нить софтинку с другим glibc
Мучаюсь, никак не могу решить :(
Со свежей версией собирается, но не работает :(
Надо не руша системы полностью переехать в старую glibc (2.1.3)
Куда рыть?
Что читать?
Сбился с ног :(

gcc .......... -L/old/glibc/path и соотвествественно указать ld.so этот пач первым при запуске

Ну если совсем правильно то надо еще добавить -I/old/glibc/path/include при копмпиляции и то что выше при линковке , а дальше как сказано

Ребята! Плохо же вы читали. Intel таки делает gcc на 10-20% и на 30% при "agressive optimization" (согласно статье). Хочется, конечно, чтобы gcc развивался в этом направлении. Сам я именно его использую. Знаю, например, что на моих задачах по сравнению с Борландом он делает код работающий в 4 раза быстрее. Кто-нибудь сравнивал gcc с Microsoft C/C++ Compiler? Интересно было бы послушать.

SadAlex.

>А 10% скорости да еще и только на Win+Intel нафиг не надо, тем более что эти мифические 10% если и существуют скоро испарит новый оптимизатор gcc !
То, что это преимущество испарится, сомнений нет. Но случится ли это так уж скоро --большой вопрос.

анонимусам с IQ<=75

2 anonymous (*) (2003-08-11 13:35:41.855178) :

> дадада! слакваря РУЛЕЗ!

Помои под вывеской Slackware идут на корм свиньям.

Solaris -- rulez forever!

Debian GNU/Linux -- тоже весьма неплох

ебанутые вы все вам не нравиться: тут нахалеву можно получить 10-30 процентов производительности, но мы: не это Интел это сакс, а вот GCC рулез, а пользоваться Интел процессорами это как - нормально???? (я думаю тут процентов 50 минимум на интелях)

Вообще было бы странно, чтобы фирма выпускающая процессоры, выпустила бы компилятор в целях продвижения своих продуктов, который был бы медленне конкурентов... Что тут еще спорить? GCC крут, открыт, поддерживает хуеву тучу платформ, но... в интеле лучше знают как их процессоры работают... поэтому и ICC быстрее...