Посоветуйте C/C++ компилятор под Linux

Интересует максимальная оптимизация по скорости. Какой выбрать? GCC/Intel/SUN/lcc?/etc? На liberatum.ru ничего не нашел.

Сообщение от NOT_FOuND GCC Лучший в своём роде...., среди компиляторов ему нет равним, и это не только под Линух..

Да ну.. Уверен..? Почему же он лучший..?

0

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

0

там ссылко на компилятор отсутствует (

Вот новая ссылка: ftp://gcc.gnu.org/pub/gcc/rele... .0.tar.bz2 ............,......там просто наверное тот сайт удалили.........

1

Сообщение от NOT_FOuND во первых он бесплатный..

И что..??

Сообщение от NOT_FOuND во вторых удобный (всё можно скомпилировать и собрать в консоли)

Сомнительный, а точнее, субъективный фактор удобства..

Сообщение от NOT_FOuND в третьих он активно развиваеться,.....и так далие....

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

1. Скорость компиляции.
2. Качество сгенерированного кода(этот пункт можно ещё разделить на подпункты).
3. Оптимизационные возможности(качество реализации этих возможностей).
4. Количество поддерживаемых платформ и расширений инструкций.
и т. д.

По четвёртому пункту, думаю, GCC - лидер. Однако по первому, второму и третьему - весьма спорный момент...

Я не говорю, что GCC - плохой компилятор, однако терпеть не могу, когда люди говорят такие громкие высказывания

Сообщение от NOT_FOuND GCC Лучший в своём роде...., среди компиляторов ему нет равним, и это не только под Линух..

..без видимой аргументации.

0

Опять таки я так же не любли когда высказывают против без весомых аргументов,,.........у всего есть плюсы и минусы и ты должен выбирать где какие лаги тебу не будут мешать,...я просто высказал своё мнение,......

0

Сообщение от igor_nf ...но поскольку система управления проектом децентрализована...

Я вот, лично, не понял эту тему. Квартира-то официальная - GCC. Они и делают официальные релизы. А в исправлении багов участвует ВЕСЬ МИР.. Вы бы еще про главное преимущество сообщества *nix так выразились. Чета я про забажинность GCC не слыхивал. Зато с багами Борланда кажный день сталкиваюсь

Для меня MINGW - самое то. и можно даже без MSYS его пользовать - с убогой Виндовозной консолью. А уж под линухами компилять не с GCC - изврат, по-моему.

0

Лучший на сегодняшний день копилятор по критерию оптимизации - Intel C++.
Работает на популярных платформах (Виндовс, Линукс, Мак ОС икс).
Конкурентов в плане возможностей оптимизации не имеет.
В вычислениях на кластерах используется без вариантов.
Коммерческий.

0

вот именно цто комерческий

лично я под линуксом юзаю G++

0

Da v lenuhe est GNU KDevelop - a nas4et GNOM'a ia ne uzal ne znau.... ishi na distributivnom diske compileri

0

Intel C++ Compiler очень даже не плох, оптимизация дала в нашем проекте приблизительно +30% к скорости выполнения программы.
Но иногда некорректно работает с библиотекой boost.

0

самая лучшая оптимизация у intel C++ но под никсами сам бог велел GCC к тому же он не на много отстает в оптимизации

0

Сообщение от igor_nf 1. Скорость компиляции. 2. Качество сгенерированного кода(этот пункт можно ещё разделить на подпункты). 3. Оптимизационные возможности(качество реализации этих возможностей). 4. Количество поддерживаемых платформ и расширений инструкций. и т. д.

По скорости работы gcc, возможно, и есть самый быстрый компилятор в мире. Но по очень банальной причине - генерит хреновый код (по сути дело мало оптимизаций)

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

Сообщение от dioxidin Чета я про забажинность GCC не слыхивал. Зато с багами Борланда кажный день сталкиваюсь

Почитай changelog'и к релизам gcc - увидишь, сколько там ошибок исправляется. А у борланда каждый день ты сталкиваешься скорее с ошибками билдера и всей этой графической среды, а не с ошибками компилятора

Сообщение от dioxidin А уж под линухами компилять не с GCC - изврат, по-моему.

Просто эта GNU'шная политика. Мы выдаём вам бесплатно исходники компилятора, binutils и отладчика, написанные на стандартном Си без каких-либо расширений. А всё остальное с расширениями. И это всё остальное гарантированно собирается нашими компиляторами. Можете собирать и своими - но это уже на ваш страх и риск. Проблема ведь не в том, что другие компиляторы как-то не так под линухом работают, а в том, что glibc'шные заголовочные файлы вдоль и поперёк истыканы всякими нестандартными расширениями, да и сам бинарник glibc не всегда самостоятельный - требует библиотек run-time поддерэки компилятора gcc

0

Написать код, который компилируется любыми компилерами все равно не получится. А если и получится, то код будет не такой, как хотелось изначально. Если он написан под gcc, то это нормально. Всегда и в любом случае меняя компилер, получается "на свой страх и риск". GNU тут вообще не при чем.

Но по очень банальной причине - генерит хреновый код

Выбери правильную версию, поиграйся с опциями.

0

Сообщение от Vourhey Написать код, который компилируется любыми компилерами все равно не получится. А если и получится, то код будет не такой, как хотелось изначально.

Всё получится - вопрос только в желании. Я практически весь свой софт дополнительно прогоняю на Sun'овском компиляторе на какой-то древней версии Соляриса. Это мне позволяет сказать, что с очень высокой вероятностью мой софт будет работать на любой архитектуре и любом компиляторе. Другой вопрос, что это требует больше ресурсов при тестировании

Сообщение от Vourhey Если он написан под gcc, то это нормально. Всегда и в любом случае меняя компилер, получается "на свой страх и риск". GNU тут вообще не при чем.

GNU тут при том, что у них свои нестандартные расширения. Будь то в языке, будь то elf, будь то допоплнительные функции в glibc. И вопрос непереносимости тут не в замене компилятора, а в том, что на других компиляторах такой функциональности попросту нет. Не говоря уж о линкерах и прочих вещах, где все эти расширения закопаны ещё глубже

Сообщение от Vourhey Выбери правильную версию, поиграйся с опциями.

У компилятора gcc слишком тривиальное промежуточное представление RTL. Оно учитывает общие возможности всех архитектур (везде есть память, регистры, операции сложения и вычитания и т.п.). Представление довольно хорошее - на нём можно выразить какие-то нестандартные архитектурно-зависимые фичи. Например, где-то недавно упоминавшаяся возможность автоинкрементации на pdp11. 'MOV (R1)+, (R2)+' с точки зрения этого смого представления выразится как одновременно исполненные три операции: 'MOV (R1), (R2); ADD R1, 1; ADD R2, 1'. Вот такую поддержку от gcc ещё можно родить. Но современные процессоры поддерживают куда более сложные операции, которые на универсальном представлении очень плохо выражаются. Типа аппаратной поддержки накрученных циклов с переименованием регистров. Прирост проиводительности на счётных задачах здесь будет огромным, но gcc этого в принципе не вытянет, т.к. для этого уже манипуляций с одним лишь промежуточным представлением будет недостаточно - надо структуру компилятора сильно менять. Это пойдёт в ущерб его многоархитектурности, а потому разработчики не пойдут на это.

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

0

Всё получится - вопрос только в желании.

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

Другой вопрос, что это требует больше ресурсов при тестировании

Правильно. Поэтому они и не тартят свое время на всякую фигню )

GNU тут при том, что у них свои нестандартные расширения.

У тебя какая-то мания на расширения. Не вижу ничего нестандартного или плохого хоть в исходниках glibc, хоть где. А не нравится что-то - не используй. Никто не заставляет.
Аппаратная поддержка разной херни к gcc отношения не имеет. Если нет поддержки особенностей нужной архитектуры, я напишу на ассемблере. Если ее вообще нет в принципе, то я заменю ее другим кодом. Поддержка добавится со временем. Во все компиляторы. Поэтому, если у тебя есть любимый компилер, то он тоже не поймет какой-либо. Пока. Поэтому то, что ты написал во машинным инструкциям - фигня, по сути, которая свойственна всем. Всегда найдется архитектура особенностей которой компилятор знать не будет. И не обязан, в принципе-то... Это нормально.
А если у меня будут совсем большие проблемы с этим, то я просто возьму другой компилятор. После чего снова вернусь на gcc. Нет проблем никаких.

P. S. если бы под линуха был компилер качества компилера VC++, то я бы на него перешел с gcc.

0

Сообщение от Vourhey Нифига не в желании, а вопрос в том, нужно ли вообще горбатиться, чтобы написать кривой код компилируемый кучей компилеров? Ответ - нет не нужно. Если руки прямые - проблем не будет.

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

Сообщение от Vourhey Правильно. Поэтому они и не тартят свое время на всякую фигню )

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

Сообщение от Vourhey У тебя какая-то мания на расширения. Не вижу ничего нестандартного или плохого хоть в исходниках glibc, хоть где. А не нравится что-то - не используй. Никто не заставляет.

Напомню, что изначальный вопрос стоял так, что "посоветуйте компилятор под linux". Собтсвенно я ответил, почему компилятором, отличным от gcc, наверняка поимеешь кучу проблем

Сообщение от Vourhey Аппаратная поддержка разной херни к gcc отношения не имеет. Если нет поддержки особенностей нужной архитектуры, я напишу на ассемблере. Если ее вообще нет в принципе, то я заменю ее другим кодом.

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

Сообщение от Vourhey Поддержка добавится со временем. Во все компиляторы.

В том то и дело, что не добавится. По причине технической невозможности. На тот момент, когда они в очередной раз изменят промежуточное представление (как они это обломались сделать при переходе от gcc-2 к gcc-3, но всё-таки сделали при переходе к gcc-4), эти семейства процессоров уже будут устаревшими и что-то делать ради них уже будет неактульано. На всякий случай говорю - я веду вечь конкретно о gcc

Сообщение от Vourhey Поэтому, если у тебя есть любимый компилер, то он тоже не поймет какой-либо.

Если компилятор не понимает что-либо, написанное на языке программирования, то этому компилятору место на свалке

Сообщение от Vourhey Поэтому то, что ты написал во машинным инструкциям - фигня, по сути, которая свойственна всем. Всегда найдется архитектура особенностей которой компилятор знать не будет. И не обязан, в принципе-то... Это нормально. А если у меня будут совсем большие проблемы с этим, то я просто возьму другой компилятор. После чего снова вернусь на gcc. Нет проблем никаких.

Опять-таки речь шла о качестве кода из-под gcc

Сообщение от Vourhey P. S. если бы под линуха был компилер качества компилера VC++, то я бы на него перешел с gcc.

Если такое будет, то gcc умрёт почти автоматически. Но такого не будет, а если вдруг когда-то и будет, то только под intel и только тогда, когда микрософт начнёт сильно сдавать позиции перед линухом и они поймут, что надо порабощать мир и в линуховом направлении. А это, сам понимаешь, скорее всего при нашей жизни не случится

0

особенно если цена вопроса - лишняя строка кода?

В больших проектах такой ценой никогда не объходится.

Собтсвенно я ответил, почему компилятором, отличным от gcc, наверняка поимеешь кучу проблем

да, но это не является его недостатком самого компилятора.

По причине технической невозможности

ты не прав. Технически это вполне возможно.

Если компилятор не понимает что-либо, написанное на языке программирования, то этому компилятору место на свалке

От программиста зависит.

Опять-таки речь шла о качестве кода из-под gcc

Качество генерируемого кода хорошее (по сравнению со многими другими). Но не лучшее, конечно.

Добавлено через 7 минут 2 секунды
gcc - хороший компилер. И почти бесспорный лидер среди компилеров под линукс. Но я не говорю, что он лучший из всех. Согласен с тобой, трудности быть могут при использовании других. Но вины самого компилятора тут никакой.

0

Сообщение от Vourhey да, но это не является его недостатком самого компилятора.

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

Сообщение от Vourhey ты не прав. Технически это вполне возможно.

Я говорю не о том, возможно ли это теортетически при рассмотрении модели идеального компилятора в ваккуууме. А о том, что на ТЕКУЩИЙ момент на ТЕКУЩЕЙ версии gcc выжать производительность конкретно в том месте нельзя в силу технических особенностей ТЕКУЩЕГО устройства компилятора

Сообщение от Vourhey От программиста зависит.

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

Сообщение от Vourhey Качество генерируемого кода хорошее (по сравнению со многими другими). Но не лучшее, конечно.

Многие другие, это например что?

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

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

Сообщение от tux21 Интересует максимальная оптимизация по скорости. Какой выбрать? GCC/Intel/SUN/lcc?/etc? На liberatum.ru ничего не нашел.

Насколько я знаю, sun'овский компилятор под линухом не работает. Они его делали только на intel-solaris и вроде бы как исходники не открывали (возможно, я что-то путаю). lcc вроде бы компилятор под Win32, чуть ли не самоделка. Intel'овский компилятор по качеству кода лучше gcc, но, по крайней мере на момент 2005 года у них он был ненадёжным на IA-64 (хотя последнее не обязательно, что он так же был ненадёжным для IA-32). Насколько знаю, он тоже платный

И какой класс задач собираешься использовать. Если какая-то узкоспециализированная консольная программа, где не требуется каких-то специальных библиотек, то попробуй Intel'овский. Если умеешь работать с профилем кода, то попробуй на gcc, а потом узкие мест вылизать либо переписыванием кода, либо, если хорошо разбираешься в архитектуре, какую-то часть написать на ассемблерных вставках

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

Сообщение от Vourhey Добавлено через 7 минут 2 секунды

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

Сообщение от Vourhey gcc - хороший компилер

Я бы не стал говорит, что gcc хороший компилятор. По той причине, что с правильностью генерации кода у него всё-таки есть проблемы. Хотя "последние" версии в линейках gcc-2.95.3 и gcc-3.4.6 в общем-то приемлимые. Мир уже перешёл на gcc-4, но какойто стабильной версии наподобие gcc-2.95.3 или gcc-3.4.6 пока нет. И тем не менее это не мешает людям жить на ней. Скорее всего причина в том, что косяки они заранее известны и разработчики их обходят

Сообщение от Vourhey И почти бесспорный лидер среди компилеров под линукс. Но я не говорю, что он лучший из всех.

Слово "почти" можешь смело вычёркивать, ибо под линух приемлимой альтернативы нет. Если второе предложение в контексте линукса - то gcc и есть лучший компилятор под линух. Но с оговоркой, что надо знать, как обходить проблемные места (что не мешает ему быть лучшим)

Сообщение от Vourhey Согласен с тобой, трудности быть могут при использовании других. Но вины самого компилятора тут никакой.

Конечно gcc тут не при чём. Как я уже говорил - это политика GNU сообщества разработчиков всего этого добра. Я не всегда выражаюсь ясно, а потому вполне возможно, что не довёл свою мысль до тебя. GNU'шники предложили миру бесплатную среду разработки (назовём её так), в которую включается компилятор, binutils (в состав которого в том числе входят ассемблер и линкер) и отладчик. Эти три компоненты железно компилируются стандартным компилятором Си (а фактически любым компилятором на почти любой платформе). А вот всё остальное пишется исходя из того, что компиляроваться оно будет именно gcc и binutils'ом. И начиная прямо с Glibc дальше всё идут коды с использованием нестандартных расширений и возможностей. Т.е. типа мы вам отдаём кучу софта нахаляву, берите и что хотите с ним делайте, но в оригинальном виде оно будет компилироваться только с использованием нашего компилятора. Базусловно, имея исходники можно всё дорработать до состояния, чтобы работало и на стандартном компиляторе. Но ведь это миллиарды строк кода, которые надо перелопатить, к тому же этот код постоянно обновляется и развивается. Вот как-то так

0