Всем доброго времени суток! Я слышал что в ВС++ можно подключать различные компиляторы. Посоветуйте пожалуйста какой лучший =) . То есть качественней и делает самый быстрый код (размер не важен). Спасибо!

Это тема для религиозных войн, сейчас набегут поклонники разных компиляторов и начнется священная война на тему "какой компилятор лучше" (хотя что тут обсуждать, и так понятно что gcc лучший)

Это вопрос религии.

да, целых два...

Спасибо большое! =)



то есть? ну мне не важно какой размер исходного файла будет. Главное быстродействие =) и малое потребление РАМ =)



Ну два не два =) но выбор!   

Kirgston, ты говоришь про BC++ 3.1 или про VS 2008? Просто это разные вещи.
В случае VS 2008 я бы на твоем месте не рыпался без крайней необходимости. Компилятор от MS считается одним из лучших, как по качетсву результирующего кода, так и по скорости работы.

Я про вижуал студио 2008 =) а где можно почитать различия gcc и МСа?

ты себе отличие IDE от компилятора представляешь?
Просто зачем тебе менять компилятор? Вот скажи, зачем ставить в мерседес двигатель от БМВ? Если ты не знаешь зачем тебе нужен другой компилятор, то не заморачивайся.

Знаю =) если и в "горбатый" грамотно двигатель от ферарри то будет намного лучше))))) 
И какое стремление к учёбе и знаниям без заморочек? =) 
Если можно то подскажите где почитать можно. Да знаю - везде. Но более конкретно. Просто в ХолиВарах тьма флуда... а хочется одну статью но чтобы сразу понять что к чему =)

мне кажется что на данном этапе вашего развития вам это ни к чему...

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

Вот статья по сравнительному анализу различных компиляторов
http://www.cyberguru.ru/programming/cpp/cp...s-analysis.html
 
К сожалению, её можно считать несколько устаревшей поскольку компиляторы развиваются очень быстро.

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

Intel'овский все же получше будет. И в VS он встраивается без проблем. Вот только не уверен, что в Express версию встроится   

xvr, вот только есть проблема - далеко не все либы имеют вариант под ICC. Особенно, написанные на С++.

Угу, хотя Intel бьет себя пяткой в грудь и утверждает, что его icc более совместим с MS компилятором, чем сам MS компилятор   Так что и либы от MS должны работать (тем более, что либы из PSDK работают, ибо своих у icc нет)
Но конечно, не все так радужно и что то может не срастись   

xvr, серьезно?

xvr, у интеловского компилятора одна проблем, как я считаю главная, по какой не стоит его юзать, это работа ТОЛЬКО с x86 и x64. А если я написал программу и захотел через два года перенести её на другой процессор? Что тогда делать? Оптимизировать под другой компилятор? 

Неее... g++ - мой голос в этой теме!!!

Солидарен! Сам юзаю Intel C++ 11.0.72 for Linux. Остальные отдыхают...

Это сообщение отредактировал(а) andrew_121 - 20.6.2009, 04:24

Серьезно.
Хотя если топикстартеру не нужна до упора пиковая производительность, то лучше не заморачиваться  

Добавлено через 4 минуты и 20 секунд

Не только - еще Intanium. Да и на AMD тоже будет работать
Откомпилировать другим компилятором, вестимо   
Оптимизировать под компилятор не надо, он и так должен справится. И вообще - оптимизировать - это работа компилятора   

А это не относится к x86 и x64?

Слышал, что разные компиляторы незначительно различаются, хотя сам никогда не проверял... так - предположение.

Itanium не относится
Отличаются, но грамотно написанная программа будет компилится на всех (в идеале   ) компиляторах
Тем более, что на С и С++ есть стандарт, так что теоретически полностью мультиплатформенные программы возможны (правда практически это будет 'сферический конь в вакууме'   )

В любом случае оптимизации у Intel'овского компилятора ГОРАЗДО сильнее, чем у gcc

А у вас конкретные примеры есть? Я не спорю, просто мне интересно. 

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

Есть на www.spec.org
Для Xeon X5355 2 x 2.33GHz:

серьезное преимущество... может с ключами оптимизации что наворотили?

Это сообщение отредактировал(а) bsa - 7.5.2009, 20:51

Все оптимизации по максимуму. Конечно для чистоты эксперимента надо прогнать SPEC'и на одной машине и разных компиляторах. На spec.org данные для разных машин (но с одинаковым процессором, частотой и конфигурацией системы)
Можно покопаться и найти одинаковые машины (если повезет). Там правда больше тысячи записей, мне как то влом заниматься раскопками   

А по интеллектуальности? Не знаю как насчёт 2009, а вот MS VC 6.0 мне не выдал варнинга а online GCC выдал

какого он года вы не смотрели? вы бы ещё легенду "Borland C++ 3.0" взяли.
***
недостатки компилятора студии в том, что он пропускает невалидный код, который gcc ловит.
хотя может быть и у gcc таже ситуация, только наоборот 

Не замечал...

ну так вы ж студией не пользуетесь, как заметите? 

Почему же?! По роду службы, иногда приходится м под виндавз писать. Потому ее и ненавижу! Не просто так, как вам могло показаться...

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

Странное условие)
Как будто, отладка, это первостепенное что нужно программисту  
Я привык не дебагить контейнеры. Они работают. Проверенно  
Но даже если нужно отладить, то есть свой набор отработанных функций и макросов препроцессора для отладки.
Я бы сказал, что отлаживать в студии, или подобных IDE, как-то принципиально не правильно. Это мое мнение.
Хотя работаю в KDevelop. Наилучшая среда разработки. Так же мое мнение.
Ах да, SlickEdit забыл упомянуть. Многие кто им пользуются, говорят что он много развитее студии. И плагинов к нему много. Не знаю. Не проверял.
П.С.
А лечить последствия - не правильно. Нужно писать правильный код 

Добавлено через 14 минут и 52 секунды
Дополню:
SlickEdit - есть для Linux, Mac OS X, Windows.
Отладчик - IDA. Так же для Linux, Mac OS X, Windows.
Для экспериментов, лучше использовать andLinux

как-то не верится, что ты не пользуешься отладчиком   
отладчик visual studio - на порядок лучше чем gdb, и даже не потому, что он умеет визуализировать данные, он помимо этого много чего умеет  


часто бывает нужно посмотреть, что содержит тот или иной контейнер, в vs есть визуализатроы для стандартных типов, можно писать для своих  
в gdb проще выводить все что нужно в лог или в терминал, чем копаться во внутренностях объектов

я перепробовал множество сред разработки для linux, netbeans, eclipse, code::blocks, anuta... KDevelop - самая ужасная среди них  лично для меня оказалось проще всего использовать vim, все эти IDE - отстой  
eclipse + CDT - страшно жрет память, индексер часто падает, причем иногда, из-за него вообще не удается запустить IDE, запускаешь eclipse, сразу открывается проект, стартует indexer и все это с грохотом падает. Страшно представить что будет на большом проекте... единственный выход из этой ситуации, не использовать indexer, но в этом случае eclipse мало чем отличается от обычного редактора кода.
net beans - умный(семантическая подсветка кода, аналог inteli-sense), не падает, но жрет намного больше памяти чем эклипс (400-500 Мб в среднем, на небольшом проекте) и тормозииииииииииииииииииит
code::blocks - не тормозит, память не жрет, но при этом ничего толком не умеет, код эта штука не понимает(использовал не самую свежую версию, ту что в была в репозитории)

по фичам и самое главное по реализации, все это и рядом с visual studio не стояло  

Про это, я и упоминать не стал...




Пользуюсь. Но редко. В основном макросами препроцессора и функциями вывода в консоль.




Спорить не стану. Не проверял. На днях попробую.
Хотя, помнится мне, пару лет назад работал в одной конторе. Там на мою машину поставили 2005 студию. Я так и не увидел плюсов. Тот же notepad++ по редактированию кода, не хуже, даже лучше. Плагинов больше.


П.С.
Остальное комментировать не стану. Похоже на истерику.

я бы попросил
мне пришлось сделать 2 проекта, над которыми я работал то в windows то в linux, отсюда такой горький опыт, средства разработки для linux не так развиты как средства разработки для windows, это факт, а не истерика  

Он ему не нужен, видимо потому что он им пользоваться не умеет или в глаза не видел   
  
М. Жванецкий



Это сообщение отредактировал(а) xvr - 19.6.2009, 21:31

 Малыш, сколько тебе годиков? "Я не знаю, чему тебя учили в твоей стране добрых фей и ласковых щенят, в которой ты если и не вырос, то провел свои летние каникулы, но ты сейчас в реальном мире" © Perry Cox из сериала "Клиника". Людям свойственно ошибаться, даже самым талантливым. К тому же отладчик бывает нужен для того, чтобы разобраться в алгоритме, заложенном в основу написанного другим разработчиком кода (безошибочного), который требуется изменить с учётом новых требований.


А другим как будто бы не наплевать на то, что ты её ненавидишь 


А чего единственное? Мне вот, например, часто был нужен break на изменение памяти. Бывает, что непонятно какая сволочь ни с того ни с сего меняет некий объект, и очень хочется выяснить, где же именно это происходит. GDB умеет останавливаться при изменении данных, расположенных по заданным адресам памяти? 

Это сообщение отредактировал(а) UnrealMan - 20.6.2009, 02:45

xvr,  

Добавлено через 5 минут и 46 секунд

Кто на что учился.

Вписал для ясности. Взаимно.

Вспомнился старый анекдот - два солдата и лопата заменяют экскаватор  
В линукс есть много чего другого что помогает в процессе дебага. Я обходился лог файлом и cat, tail -f + grep. Ну и valgrind (мощная штука) еще не портировали под виндоуз. У студии дебаг конечно удобный, но не все так плохо  пишут ведь люди под линукс, я писал несколько лет. Не помню чтоб сильно страдал. Коробка автомат на автомобилях конечно вещь удобная и современная, но многие предпочитают ручную. Им так удобнее. Дело привычки, я одно время так к vim привык что в студии работать не мог.   

О чем спор?

Это сообщение отредактировал(а) azesmcar - 19.6.2009, 22:17

Не спор. Истерика почему-то...

Умеет, он много чего умеет. Но как и все в *nix'ах это у него происходит строго и сурово    нет, даже скорее так  
И если ты не помнишь наизусть основные команды для работы с ним (немного, десятка 2-3, не больше   ) то работа с ним будет несколько утомительная   
И всякие GUI к нему не помогут - не сделали еще достаточно большого телевизора, на который влезут все кнопочки, на которые развешают ВСЕ команды, которые он поддерживает.   

PS. Лично я предпочитаю студию и Винды.

Под *nix-ом-то, может, и умеет, а как насчёт отладки под виндой?

Да у майкрософта он считается лучшим, у интела лучшим считается интеловский и так до бесконечности. Каждый обязательно даст листинг, где его компилятор самый крутой и навороченный и его приложения аж в десять раз быстрее работают.  


Может и к чему, мало ли, здесь от выбора зависят будущие умения.


Например. Скорее всего то что он дополнительно умеет только для любителей мегаотладки под винду.


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

Палюбас! ...В среднем, производительность всего ядра, после сборки в icc, увеличивается на 8-9%... Целых 9% vs морально устаревшие версии gcc. Вот еще.... Неговоря о том, совершенно не учтено то что там наворотили в новых версиях!


Это нечто новое вообще в тестировании   ...


А с PowerPC? А с ARM7,9,11(КПК, мибилки и т.д.)? А с BlackFin(радары, телекомуникационное и измерительное оборудование, игрушки)? А с MIPS(почти все бытовые роутеры на них)? А с AVR или MSP430(встроенные микроприборы, например медицина)? 


 Ну и сравнение - все равно что сравнить МиГ-29 и шасси от F-22. Это подход "Дэлфистов" сравнивающих утилитки по их GUI   . GDB - это ядро отладчика выдающее отладочную информацию (Unix-way - одна задача, одна программа). Если надо визуализация, то есть хотя-бы DDD - но вообще GUI отладчиков куча.


Флаг в руки! А кто-то предпочитает работать на горнодобывающих предприятиях...


О, да, чем лучше развиваются IDE-средсва от MS тем больше нужно RAM ихним ОС при той же функциональности. Деградация программирования на лицо.  . Скажем так - в современном линуксе есть на 2-а порядка больше для разработки чем в свое время было у Дейкстры, Кнута, Томпсона, Ричи, Таненбаума, Торвальдса иже с ними... И дай то боги Валгаллы сегодняшним нытикам по отсутстию автодополнения кода и визуализации всего-на-свете когда-нибудь работать над проектами такого уровня. 


А студия умеет то, что умеет анюта(или кодеблокс) в связке с KScope+cscope(например визуальная трассировка вызова функции), DDD, AStyle, doxygen и всякими остальными утилитками + разумеется "вся мощь bash"? Боюсь это выливается сравнение теплого и мягкого, причем всяк навязывает свое "авторитетное мнение" хотя и понимает что сравнивает даже не противоположности...

 Кстати не забываем, что как свободный компилятор GCC не одинок.  Вот-вот появится его BSD-шный собрат - и кстати ветви GNU и BSD и так сильно расходящиеся по идеологии и ресурсам с того момента начнут вообще стремительный разлет   . Почему никто не вспомнил D/C++/C? Есть еще свободный и опенсорцный компилятор (x86, PowerPC, 68000 и кажется ARM) энтузиастов из Амстердама (родной для minix), ну и теперь мой любимый компилятор   tcc(кстати единственный позволяющий на C писать скрипты   ) <--- АФФтАру топика вот саймый лучший компилятор, нечего раздумывать.

Это сообщение отредактировал(а) DRUID3 - 20.6.2009, 04:20

  

...промолчу для чего она приспособлена...

DRUID3, Во задвинул  

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

Лог файл как и cat/grep/tail/... средства универсальные и от ОС не зависят. Только вот в MSVC плюс к этим средствам есть еще и нормальный отладчик, а не консольный gdb и куча кривых front-end к нему. И чего же такого другого есть в линукс?
.

Есть, например, Rational Purify for Windows с нормальным GUI и возможностью интеграции в студию (правда только в старые версии). А какой есть нормальный GUI для valgrind? Чтобы при ошибке обращения к памяти сработал breakpoint, подключился отладчик и можно было прям сразу посмотреть значения переменных?

cygwin + gdb (от него). У него даже GUI встроенный   

вообще, мы говорили здесь о компиляторах, затем речь зашла о отладчике, ну и теперь ты свел все к разговорам о AStyle  
все это можно использовать и в винде, но почему-то мало кто использует, насчет bash, в windows есть windows script host, пусть для него можно писать скрипты только на vbscript и на javascript, зато возможностей у него масса, можно юзать любой COM объект, поддерживающий автоматизацию, думаю bash так не умеет...
кстати я использую в винде cygwin bash, по привычке, но скрипты на нем писать, необходимости не возникало  
Про AStyle ты вообще к чему сказал? такой инструмент встроен в студию, да и к программированию он имеет не самое прямое отношение.
cscope - можно собрать под windows, правда толку от этого, если ту-же самую визуальную трассировку вызовов может делать студия  
В общем, все эти крутые фишки может и работают, но, нужно в каждой из них разбираться, нужно с ними возиться. Тот-же функционал как правило доступен другими способами.

просто у тебя нет серьезных аргументов  


если ты этми все пользуешься, то чувствуешь себя Дейкстрой? 

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

Дык, icc тоже на месте не стоит   По поводу 9% - на www.spec.org заходили? Или Linux kernel - это наше все?

В смысле? Вы не в курсе, что у компиляторов есть ручки, которыми можно настраивать оптимизации? 

А что, Intel начал все это выпускать? Или вы обвиняете его, что он не делает компиляторы для других процессоров?

А вы видимо предпочитаете трепаться в эхах?
Для того, что бы иметь право писать предпочитаю, надо иметь выбор. Вы видимо предпочитаете Linux+gdb из Linux+gdb?

Ой! А давно целью программирования стало уменьшить потребность RAM?

Есть, но и Винде это тоже есть.

Гы гы, а вам эти 'нытики' уже поведали, над проектами какого уровня они работают?

Не умеет, да от нее этого и не требуют. doxygen замечательно из под Win работает. У gdb со всеми его мордами есть один недостаток - это не готовый дебагер, а набор 'собери себе дебагер' (как и все в *nix   )

предпочитаю Perl, в том числе и на Виндах

Это выливается (в основном) в огульное охаивание того, о чем охаивающий не имеет никакого понятия

По поводу 'предпочитаю писать на Виндах', хочу уточнить - предпочитаю на Виндах, но пишу в основном на Linux'е (так надо). А сейчас у меня проект вообще на голой машине, без ОС (x86 64бита). В качестве cross платформы используется Linux, компилятор gcc, дебагер gdb (через remote stub). Тексты (С++) пишу в Виндах в far'е   

empty

Это сообщение отредактировал(а) Леопольд - 20.6.2009, 11:35

В виндоуз нет таких мощных утилит для работы с консолью. Или вы станете спорить что виндоуз консоль может сравнится с юниксовской? Они и рядом не стояли. Линукс в своей консоли дает всю мощь операционной системы.


Давайте не забывать что purify и под линукс есть (и даже если не ошибаюсь он сначала под линукс был создан).
Насчет valgrind. Выбирайте что по душе
http://valgrind.org/downloads/guis.html


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

Можно сколько угодно твердить о том что в линукс программировать неудобно. Но это значит что вы просто не привыкли.
Пишите кому как угодно.

Кстати, valgrind умеет работать с Windows приложениями (под Wine). Несколько через ж... , но все же  

Добавлено через 2 минуты и 22 секунды
Нравится мне эта тема   
Вопрос:

ответ:

  

Ну да..требуете от него черт знает чего а потом удивляетесь что через ж...  

А ведь я в самом первом посте предупреждал

  

помимо студии я попробовал несколько других IDE: CodeBlocks, CodeLight, Qt Creator.
и сразу бросилось в глаза, что STL контейнеры отображаются не так, как в Студии. вот и выдвинул требование 

Вот так расколбас от xvr



Не знаю как в студии сделано, наверное и дебагер работает без этих самых команд и гуй у него встроенный. РЖУНИМАГУ
(наверное он телепат.....)


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

Добавлено @ 14:30
Автор тот же

Невозможно не согласиться.

Добавлено @ 14:35
xvr

Вы видимо не работали под нормальным дистрибутивом линукса. Без обид.
Такая хрень, которую вы описали, осталась наверное в BSD системах, не думаю что под ними сидят программисты, и linux'ах типа "собери конструктор".

Это сообщение отредактировал(а) fry - 20.6.2009, 14:36

Логично!   

Я это сказал в контексте того, что IDE в nix это не программа которую нужно проинсталить с коробки, а просто GUI обычно с открытым инструментарием — утилиты, плагины и т.д.. Добавив 2-3 десятка утилиток получаем возможности близкие к студии - причем на 101% достаточные для эффективной работы.

Дейкстра, кстати, очень медленно набирал и вообще предпочитал бумажку и ручку  - так что он не пользовался и таким. Но я не о том, кто что чувствует - а об избыточности инструментария. Его уже больше чем нужно, и если есть стимул и желание писать программы - то вот оно - все есть о чем предшественники только мечтали. А божество Мара(ненасытность) из индуиского пантеона не умрет никогда - всегда где-то найдутся рюшечки да фишечки на обманчивый мираж которых побежит очередная свора балбесов. Стоит ли из-за этого расстраиваться? 

Вау! Во времена моей молодости она такого не могла - честно!  Никак сперли идею у GNU...


Дык один седовласый дедушка-приколист сказал что все в этом мире относительно. Потому icc точно на месте не стоит а движется в зад  ...

 Нет не заходил. Потому как пропуская произвольный сигнал через произвольную дискретную цепь мы получаем произвольный результат. Это я о том, что все эти тесты это попытка аппроксимировать прямой линией систему более высокого порядка - и это не метафора. А вот ядро Linux это О-О-ОЧЕНЬ показательный пример. Там находятся практически все встречаемые в реальном программировании структуры данных - и лучший практический тест тяжело придумать. Кстати, а Вы утрируете - 9% это относительно уже морально устаревших версий gcc. Почти у всех кто сейчас работает на Linux-машинах даже более новый компилятор.

Мы в курсе что это был тест по одновременной оптимизации - время исполнения и размер. Очень малое подмножество всех опций компилятора. А где результаты для остальных? Также мы вкурсе, что для того же GCC помимо обыкновенных "уровней оптимизации" есть еще уйма ключей для каждой отдельной архитектуры - от AMD64 до AVR8 манипулировать которыми нужно еще уметь, потому как некоторые опции взаимоисключающие. Как с ними поступить? Получился тест мотороллера с мотоциклом - но зато оба на второй передаче. 


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


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


Да, давненько. Как только пришли к выводу, что будущее за дискретными (а не аналоговыми) вычислительными машинами - так и сразу. Кстати, ану ка, какие там критерии качества для компиляторов выдвигаются, напомните ка общественности...


Да, и даже с избытком. Но звезды от этого не становятся ближе. 


По количеству флейма в форуме - я догадываюсь и без дознаний с пристрастием   ...


Да много что в ней из nix-инструментария замечательно работает. Но никак не благодаря MS - но это отдельный разговор, не надо еще одного холивара в холиваре...


Именно.  

А нету у него команд, совсем   Все по кнопочкам и менюшкам развешано.
А ей не надо столько кнопочек, не умеет она столько, сколько умеет gdb
Золотые слова   

RH и SUSE устроят? Правда я с ними работаю исключительно в командной строке (через ssh). C GUI'ями разбираться лень, да и не приспичило пока.

Сколько тут было перечисленно GUI к gdb? С десяток наверное будет. И всяких IDE тоже с десяток (начиная от VIM и до eclipse)
Так что все таки конструктор   

gdb ОЧЕНЬ мощный дебагер, студия с ним и рядом не стояла. С другой стороны, за эту мощность надо платить - либо досконально знать его команды (его командная строка доступна в любом его GUI), либо заниматься раскопками среди его GUI, т.к. единого мнения по поводу того, какой из них самый самый - нету.
С другой стороны студия гораздо более user-friendly, чем gdb

Кстати, в Виндах есть дебагер сравнимой с gdb мощности - windbg. От так же с командной строкой, и такой же неудобный в использовании как и gdb без GUI   И команды у них не совпадают   

И с чего бы это?          

Факты есть, или просто потрепаться вышел?

А стоило бы. Хотя бы посмотрел, что это такое. Не стал бы своё дремуче невежество выставлять
Мы в 21 веке живем, не забыл? Drystone'ы в прошлом веке остались   
Это вообще не пример. Прикладные программы не в ядре сидят, они работать должны.

Что такое SPEC (конкретно SPECCPU)
Это набор РЕАЛЬНЫХ программ (в частности, туда входят gcc, bzip, xerces, и много других, всего около 2х десятков). Их компилируют и исполняют на тестируемой системе. Все параметры присутствуют в отчете, включая конфигурацию компьютера и компилятор. Результатом является скорость исполнения (среднее геометрическое по всем тестам).
Есть 2 режима тестирования - base и peak. При base для ВСЕХ тестов выставляются одинаковые опции компилятора, при чем их количество ограниченно. При peak опции выставляются индивидуально на каждый тест, их количество не ограничено.
Все результаты публикуются на www.spec.org
Абсолютно не практичный тест, мне честно говоря начхать насколько быстрее будет исполняться ядро. Если программа сидит в ядре, то с этой программой что то не так (или с программистом)
А icc версии 9.1 (с которой там сравнивали) - это не 'морально устаревший'? Сейчас icc уже 11.1

Размер тут никого не интересует
  Зачем вам опции, с которыми результаты хуже? Или специально, что бы было с чем gcc сравнивать?

бла бла бла. Тестировали 2 компилятора на одной и той же машине. Или это не понятно?

Правда 2й ножик резать разучился, а так да, выбор есть   
Если вас интересует ПРОИЗВОДИТЕЛЬНОСТЬ на x86 машине (КОНКРЕТНОЙ), так и надо выбирать компилятор под нее. Если вас не интересует производительность, а интересует многоплатформенность - надо брать gcc. Если вас интересует и то, и другое вместе - надо сразу застрелится   

Их 3 - скорость, скорости и еще раз скорость (для x86 по крайней мере)

Да уж, и вы к нему тоже руку приложили (и не одну   )

Добавлено через 1 минуту и 3 секунды

Потому что он не gdb а dbg (от MS)

Шутка.