вот и на улице мандривы праздник...

не похоже, что из этого проекта что-то толковое выйдет.

А вдруг поможет

Фраза "Проект управляется Мандривой" мну убила.

вместо улучшения мандриве можно посоветовать скачать версию посвежей

Муть какая-то...

Телефоника - редкостные мудаки. Врядли что хорошее выйдет. :(

> было решено улучшить производительность кода созданного компилятором GCC.

Блин. Они бы лучше улучшили производительность самого компилятора. А то он работает, например, в 10 раз медленнее, чем Borland C++

> А то он работает, например, в 10 раз медленнее, чем Borland C++

А Borland C++ работает?

Пусть работают. Может всё-таки что-либо хорошее получится. Только вот патронаж именно Mandriva... Ну, несколько смущает. Не получилось бы GCC _только_ для Mandriva. :-)

> Блин. Они бы лучше улучшили производительность самого компилятора. А то он работает, например, в 10 раз медленнее, чем Borland C++

А теперь давайте сравним степень соответствия GCC и Borland C++ стандарту ISO 14882, а?

> Не получилось бы GCC _только_ для Mandriva. :-)

Да и хрен с ним. Нам и с редхатовским гцц неплохо. :)

А Airbus это та фирма, которая недавно обонкротилась, чтоли? ;)

Молодцы Mandriva, надеюсь месяца хватит чтобы действительно что то путное сделать для GCC :-) А Telefonica и MySQL меня тоже смущают :-\

Для невнимательных: 30 месяцев

>Блин. Они бы лучше улучшили производительность самого компилятора. А то он работает, например, в 10 раз медленнее, чем Borland C++

Зато это дерьмо производит код работающий в 4 р. медленнее, чем GCC.

> Зато это #### производит код работающий в 4 р. медленнее, чем GCC.

А Visual Studio и код лучше генерит, и работает быстрее.

VisualGCC

> А Visual Studio и код лучше генерит, и работает быстрее.

И кроссплатформенность у Visual Studio зашибись. Собирает бинарники для любой архитектуры x86 и любой операционки Windows.

>> А Visual Studio и код лучше генерит, и работает быстрее.

Не знаю, если свою прогу на C# портирую (маловероятно ;) - проверю, верится с трудом, что байт-код работает быстрее. Или ты имеешь в виду C++?

>И кроссплатформенность у Visual Studio зашибись. Собирает бинарники для любой архитектуры x86 и любой операционки Windows.

Это да, но интересно также как с этим у Mono? Правда когда они версию .Net 2.0 реализуют - неизвестно (уже год как вышла, если не ошибаюсь), а 3.0 уже на подходе. Правда, возможно в свете последних веяний у Novell оявится возможность ускориться?!

Вот молодцы! Они занялись действительно нужным делом. ИМХО, GCC только для Mandriva у них не получится, т.к. те же MySQL и Airbus заинтересованы и в других платформах. Остается только пожелать им успехов в их начинаниях.

> Блин. Они бы лучше улучшили производительность самого компилятора. А то он работает, например, в 10 раз медленнее, чем Borland C++

Да тока при сборке ГУЯ с 1 кнопкой "ВЫХОД" обробатывается под 500 000 строк.... Как-то скорость эта совершенно незаметна....

А вообше этим компилятором можно чтонибуть скомпилить, то что написано не в борладне? GTK приложение например.

Что касается использовать

ИМХО лучще INTEL-овский компилятор..... Думаю он самый быстрый, да и код делает самый лучщий..... для intel процессоров конечно....

А вообше GCC душу греет, уж фсе и подофсе он компилит.... Очень нравиться что его потдерживает очень большое кол-во народа.

нет, эта та фирма которую просят помоч россйскому гражданскому авипрому

Borland C++, конечно, глючный до невозможности компилятор, но работает он быстрее, создаёт более быстрый код и меньший размер исполняемого файла. Пример сравнения можно поглядеть здесь: http://www.easycoding.org/content/view/19/48/ Вы говорите, gcc больше соответствует стандарту. Да, вы правы, но есть такие места стандарта (как, нарпимер, дружественные шаблоны), которые все компиляторы поддерживают, а gcc - нет. Не верите - почитайте Герба Саттера и опробуйте его код на своём компиляторе.

Я, однако же, прошу камней в меня не бросать. Сам пользуюсь gcc, в том числе в Windoze (mingw) и сам могу своим опытом подтвердить его отставание по скорости по сравнению с другими компиляторами.

А в тему скажу, что лучше бы ЕС скооперироваться с Edison Design Group или другим разработчиком ++ компилятора, или объявил об открытом тендере на "латание" gcc, или шёл по пути Google SoC

Доверили б проект RedHat или даже OpenBSD - я бы понял, но Mandriva - вообще не в тему

> А в тему скажу, что лучше бы ЕС скооперироваться с Edison Design Group или другим разработчиком ++ компилятора

Чтобы они своими руками делали себе конкурента?

> но Mandriva - вообще не в тему

А много ты знаешь других крупнейших европейских (ну пусть евробразильских) разработчиков дистрибутивов? SuSe теперь Novell, США. Мне кажется, что именно из этих соображений и выбрали их.

>Только вот патронаж именно Mandriva... Ну, несколько смущает.

Чем, если не секрет? Или предрассудки заменяют нам мышление?

>Не получилось бы GCC _только_ для Mandriva.

Сам понял что сказал, как ты себе это представляешь?

> Блин. Они бы лучше улучшили производительность самого компилятора. А то он работает, например, в 10 раз медленнее, чем Borland C++

а Вы не пробовали его пересобрать с под i686 с -O2 ?

хорошо помогает

Отличная новость! gcc фактически один из лидеров среди компиляторов С++. А насчёт его скорости.. Ну ерунда всё это. Весь проект редко пересобирается, а локальные изменения.. Ну какая разница, будут они компилироваться 10 секунд или 15. Тем более что на современных многопроцессорных машинах время компиляции значит ещё меньше. (Про товарищей, использующих генту я не говорю. Им конечно быстрый компилятор не помешает :)) А вот оптимизация генерируемого кода это штука важная, хотя в сущности gcc и так практически наравне с конкурентами. Если этот проект значительно улучшит gcc в этом плане, думаю, это будет значительная победа опенсорса.

Кстати если gcc будет генерировать код, который работает в полтора раза быстрее, то сам gcc будет тоже работать в полтора раза быстрее :))

>Borland C++, конечно, глючный до невозможности компилятор, но работает он быстрее, создаёт более быстрый код и меньший размер исполняемого файла. Пример сравнения можно поглядеть здесь: http://www.easycoding.org/content/view/19/48/

Мне не нужно никуда смотреть: я на своем коде проверял - GCC делает его в 4 раза! - в топку.

>Кстати если gcc будет генерировать код, который работает в полтора раза быстрее, то сам gcc будет тоже работать в полтора раза быстрее :))

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

>Чтобы они своими руками делали себе конкурента? Да ну, 1) EDG и gcc - немного разные вещи (EDG != компилятор) и значит конкуренция между ними исключена, 2) конкурента таким образом EDG может сделать для других компиляторов (в том числе основанных на EDG) - ну и что? 3) от них не требуется написать весь компилятор с нуля, задача - оптимизировать применяемые в gcc алгоритмы, 4) они наверняка знакомы с внутренней кухней gcc, 5) за эту нелёгкую работу заплатят крупную сумму (ЕС).

>А много ты знаешь других крупнейших европейских (ну пусть евробразильских) разработчиков дистрибутивов?

Твоя правда. И к сожалению эта правда не даёт развить дальше идею про EDG (наврядли евросоюз оплатит работу американской конторы...)

tcc == http://fabrice.bellard.free.fr/tcc/ ???

вот и я не понимаю почему надо поддерживать монстра gcc а не tcc

Через 30 месяцев либо шах, либо ишак сдохнет.

> вот и я не понимаю почему надо поддерживать монстра gcc а не tcc

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

> tcc == http://fabrice.bellard.free.fr/tcc/ ???

Этот Фабрис вообще мощный мужик. То он быстрый компилятор размером 100КБ напишет, то динамический транслятор с возможностью виртуализации qemu.

Кстати, на его страничке написано, что предком tcc был otcc: http://fabrice.bellard.free.fr/otcc/ , который он написал чтобы выиграть конкурс на самый запутанный код на С. Всем программерам рекомендую посмотреть исходники этого компилятора размером в несколько килобайт :))

AK

!ПРОЕКТ! GlobalGCC

Длительность проекта ограничена разумным сроком, это очень хорошо. Это значит что через 30 месяцев участники проекта будут подводить итоги. Значит через 30 месяцев можно будет посмотреть что получилось. А не как обычно бывает в open source, развитие самотёком.

> Этот Фабрис вообще мощный мужик.

Соглашусь на все 100. Но tcc это C-компилятор. Когда Фабрис напишет компилятор С++, вот его и сравните.

Блин, комменты жгут. Сварщеги блин. Для начала GCC - это "GNU Compiler Collection". Тот же icc или cl могут похвастаться что к ним можно любой язык прикрутить? А то началось C/C++ =) И нечего кричать что типа отстой, icc круче по скорости, он всё таки java копилить не умеет =)

А потому что если надо я беру gcc и прикручиваю к нему native-backend Mercury, и радуюсь жизнь.

Кто нибудь вообще читал сообщение?

"The GGCC (ITEA) project aims to extend the free GNU Compiler Collection by globally processing several compilation units (e.g. work on a whole program or on a library) in order to customize and configure GCC to European software industry needs : for performance level or for better diagnosis."

Одна из главных целей это улучшение сообщений об ошибках, что бы не сидеть и не чесать репу по 10 минут где же у тебя тут ошибка, что ему не нравится. И "number of available back-ends", тоже прикольно, интересно что к нему ещё прикрутят, Ada есть, фортран есть, паскаль есть. Basic'a нету :D

Вообще, неплохо бы. Код, производимый GCC, зело нетороплив. Сравнивал, компилируя один и тот же Qt-проект сначала MinGW, а потом Visual C++ 2005 Express. Ну, если не упоминать про отсутствие в VisualC++ таких вещей, как round (вот она, забота о пользователях) и прочих небольших шероховатостях, то:

1) Visual C++ компилит в несколько раз быстрее;

2) Результат - 729 кб вместо 1037 кб (линковка - динамическая);

3) Такие вещи, как обновление большой таблицы, в 1,5...2 раза быстрее;

4) памяти ест 11 мб против 18.

> Блин. Они бы лучше улучшили производительность самого компилятора. А то он работает, например, в 10 раз медленнее, чем Borland C++

Кстати, MinGW под виндой собирает Qt-проект в разы дольше, чем GCC тот же проект под линуксом, я замерял время. И GCC/Linux этот проект собирает лишь немногим дольше, чем VisualC++ 2005 Express/Windows. Так что здесь уместнее говорить о неоптимальности порта GCC под винду. И что меня окончательно, напрочь, убило: я собрал MinGW под линуксом и запустил кросс-компиляцию того же проекта для винды, но под линуксом. По времени - лишь процентов на 15..20 дольше, чем GCC собирает под линукс. Вот так. GCC просто сильно заточен под работу в среде линукса.

> И кроссплатформенность у Visual Studio зашибись. Собирает бинарники для любой архитектуры x86 и любой операционки Windows.

В идеале, каждая платформа должна иметь собственный компилятор, который собирает C/C++-программы наилучшим образом. Под винду есть Microsoft Visual, и нормальных конкурентов для программ общего применения ему там нет. MinGW может быть полезен для C-программ, которые изначально писались под юниксы и использовали такие вещи, как dirent. Windows - платформа в этом смысле убогая, нужны костыли. Но таких программ мало.

ИМХО лучще INTEL-овский компилятор..... Думаю он самый быстрый, да и код делает самый лучщий..... для intel процессоров конечно....

Применение intel-компиляторов сильно ограничено. Ими можно собирать мультимедийные или вычислительные приложения, которым дейстаительно важны уникальные фичи интеловских процов. А вот для приложений общего назначения под винду лучше использовать Visual, под линукс - GCC. Intel'овский компайлер - это старательно выполненная провокация.

2 anonymous (*) (04.11.2006 20:31:01)

>> Только вот патронаж именно Mandriva... Ну, несколько смущает.

> Чем, если не секрет? Или предрассудки заменяют нам мышление?

Полным отсутствием опыта в разработке компиляторов у сих дистростроителей... RH, мне кажется, было бы более ... конкретно. Хотя Европа - да, конечно... Но это, ессвенно, - сугубое IMHO.

>> Не получилось бы GCC _только_ для Mandriva.

> Сам понял что сказал, как ты себе это представляешь?

А Вы, уважаемый аноним, смайлик в конце видели? Или видим лишь то, что удобно для очередного наезда? Хоть и заточка компилера под конкретный дистр мне, отнюдь, не кажется абсолютно невозможной... Правда, сиё деяние практически лишит возможности использовать ядра с cernel.org, и фактически будет признаком форка ядра. Что потребует взять на себя и поддержку кучи прог (а это вряд ли Mandriva надо). Вот так. Понимать надо, где пошутили... ;-)

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

Конкретный пример: билдер собирал виндовую wxWidgets за минуту, гнусь линуксовую - 15 минут. Думаю, разница не в размере исходного кода.

>А Visual Studio и код лучше генерит, и работает быстрее.

вывод результатов его запуска в линховом/бсд-шном шелле в студию

> когда, кстати, GCC их будет поддерживать, не выдавая ошибок про fdopen

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12707

Блин, убивают комменты про виндовый, gcc. Почему никто не возмущается что официальный apache собранный под винду тоже медленнее линуксового? Это у них официально на страничке написано.

А потому что им то и это собрано под cygwin, и естественно медленнее работать будет. Кстати в доках апача виндового подробно разжёванно почему медленнее, особенно на фаловых операциях.

Ага. 10 секунд на каждую пересборку. А за день таких секунд часа на три натекает.

>Соглашусь на все 100. Но tcc это C-компилятор. Когда Фабрис напишет компилятор С++, вот его и сравните.

А если прямо сейчас не использовать плюсы. Что мы выкинем? QT+KDE.

Вывод - на серверах мы много потеряем? ядро им собирается. обычные С программы я им тоже собирал без проблем.

А остальной софт можно и gcc скомпилить при желании. И вообще пора переходить к бинарной совместимости и без всяких rpm/deb и прочей муйни (сам использую gentoo).

А если надо ООП - есть пресрасный инструмент - Java.

Ты возьми то что по уровню соответствует борлондовскому компайлеру - g++ 2.95(6). Там и скорость будет :D.

по subj - надёюсь, усё у них получится. g++ и так достаточно хорош, но нет пределов совершенства :D.