tux21

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

@igor_nf

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

0

@NOT_FOuND

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

0

ЬыВщы

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

@NOT_FOuND

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

1

@igor_nf

И что..??

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

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

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

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

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

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

0

@NOT_FOuND

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

0

@dioxidin

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

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

0

@Ensase

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

0

@Spo1ler

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

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

0

@plan4ik

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

0

@ferreus

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

0

@Mecid

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

0

Evg

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

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

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

0

Vourhey

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

0

Evg

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

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

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

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

0

Vourhey

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

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

0

Evg

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

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

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

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

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

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

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

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

0

Vourhey

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

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

0

Evg

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

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

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

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

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

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

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

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

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

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

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

0