LINUX.ORG.RU

проект GlobalGCC


0

0

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

В рамках европейского проекта ITEA (Information Technology for European Advancement), который поддерживается Европейским союзом, было решено улучшить производительность кода созданного компилятором GCC.

Длительность проекта - 30 месяцев. Треть проекта финансируется французским, испанским и шведским правительствами, остаток покрывается средствами университетов и предприятий. В их число входят Airbus, CEA, INRIA, Telefonica и MySQL.

Проект управляется Мандривой.

Новость с http://linuxfr.org/2006/11/02/21565.html (фр)

>>> The GlobalGCC project launches



Проверено: Pi ()

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

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

AVL2 ★★★★★
()

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

bigfrogg
()

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

gigabito
()

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

nx12
()

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

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

anonymous
()
Ответ на: комментарий от anonymous

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

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

anonymous
()

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

R_Valery ★★★
()
Ответ на: комментарий от anonymous

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

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

Relan ★★★★★
()
Ответ на: комментарий от R_Valery

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

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

Relan ★★★★★
()

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

saper ★★★★★
()
Ответ на: комментарий от saper

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

anonymous
()
Ответ на: комментарий от anonymous

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

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

GladAlex ★★★★★
()
Ответ на: комментарий от GladAlex

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

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

anonymous
()
Ответ на: комментарий от anonymous

VisualGCC

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

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

Camel ★★★★★
()
Ответ на: VisualGCC от Camel

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

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

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

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

GladAlex ★★★★★
()

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

k_andy ★★★
()
Ответ на: комментарий от anonymous

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

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

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

ASM ★★
()

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

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

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

ASM ★★
()
Ответ на: комментарий от xerc

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

babai
() автор топика
Ответ на: комментарий от GladAlex

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

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

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

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

anonymous
()
Ответ на: комментарий от anonymous

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

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

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

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

anonymous_incognito ★★★★★
()
Ответ на: комментарий от R_Valery

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

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

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

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

anonymous
()
Ответ на: комментарий от anonymous

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

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

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

vadiml ★★★★★
()

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

Legioner ★★★★★
()
Ответ на: комментарий от Legioner

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

Legioner ★★★★★
()
Ответ на: комментарий от anonymous

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

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

GladAlex ★★★★★
()
Ответ на: комментарий от Legioner

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

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

anonymous
()
Ответ на: комментарий от anonymous_incognito

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

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

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

anonymous
()
Ответ на: комментарий от anonymous

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

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

michwill ★★★★★
()
Ответ на: комментарий от anonymous

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

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

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

AK

anonymous
()

!ПРОЕКТ! GlobalGCC

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

Camel ★★★★★
()
Ответ на: комментарий от anonymous

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

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

Lumi ★★★★★
()
Ответ на: комментарий от anonymous

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

gloomdemon
()
Ответ на: комментарий от anonymous

А потому что если надо я беру 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

gloomdemon
()

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

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

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

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

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

anonymous
()
Ответ на: комментарий от anonymous

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

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

anonymous
()
Ответ на: VisualGCC от Camel

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

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

anonymous
()
Ответ на: комментарий от ASM

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

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

anonymous
()
Ответ на: комментарий от anonymous

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

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

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

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

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

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

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

R_Valery ★★★
()
Ответ на: комментарий от anonymous

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

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

anonymous
()
Ответ на: комментарий от anonymous

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

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

anonymous
()
Ответ на: комментарий от anonymous

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

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

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

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

gloomdemon
()
Ответ на: комментарий от Legioner

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

eXOR ★★★★★
()
Ответ на: комментарий от Lumi

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

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

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

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

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

anonymous
()
Ответ на: комментарий от anonymous

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

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

vtVitus ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.