LINUX.ORG.RU

GCC 4.0 нуждается в существенной доработке


0

0

Как заметил ведущий разработчик Марк Митчелл в интервью: "Он (GCC 4.0) получил полностью новую инфраструктуру оптимизации. Но вся она еще не была достаточно хорошо настроена — так, как в предыдущем релизе".

Одной из первых проблем GCC 4.0 стала невозможность сборки популярнейшей графической среды для UNIX/Linux-систем KDE. В результате проект KDE временно занес GCC 4.0 в "черный список". На данный момент ошибка с компиляцией KDE решена, и патч появится в ближайшее время: "Возможно, мы выпустим релиз 4.0.1 раньше, чем планировалось". Причем ожидалось, что 4.0.1 появится через два месяца, а выйти он может на месяц раньше.

О другой проблеме GCC 4.0 на этой неделе сообщил Скотт Лэдд. Сравнив GCC 4.0 с его предшественником (3.4.3), программист обнаружил, что новая версия зачастую не просто работает медленнее, но и собранные с ней приложения по скорости также уступают сборкам с GCC 3.4.3.

Реакция Митчелла на это оказалась достаточно нейтральной: "Полностью переписать оптимизатор и не ухудшить положение вещей в значительной степени — это настоящее достижение".

>>> Подробности

★★★★★

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

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

Nagwal ★★★★
()

интересно, как в федоре собрали kde тестовыми версиями gcc4?

ждем патчей от rh

JB ★★★★★
() автор топика

Нда, чуть было не поставил себе. Черт с ним, с КДЕ, но ведь и ядро-то не компилируется. Да и сам собой же он не собирается. Однако странная ситуация...

random_code ★★
()

>Полностью переписать оптимизатор и не ухудшить положение вещей в >значительной степени - это настоящее достижение

Спрашивается, зачем тогда переписывали?

/me тихо и спокойно сидит на 3.3.5 и не дергается

svyatogor ★★★★★
()

Те кто хоть немного следил за разработкой gcc4 давным давно знали о таком положении дел с оптимизатором. Была поменяна вся инфраструктура оптимизатора. Конечно поначалу она в некоторых случаях будет даже хуже оптимизировать чем пред. версии gcc (оптимизатор которого тюнился годами!). Зато в перспективе (да и прямо сейчас) это позволит делать оптимизатору то, что раньше было просто невозможно для пред. версий gcc (автовекторизация...).

SKYRiDER ★★★
()

мде, жалко конечно. впечатление словно разрабатывали-разрабатывали улучшали-улучшали - надоело и релиз выпустили чтобы отвязаться. им бы терпения товарищей из grub team ;-)

sakura-obscura
()
Ответ на: комментарий от random_code

> Да и сам собой же он не собирается.

Ты хоть понял, что ты сказал? Компилятор всегда собирается сам собой в процессе сборки.

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

> Зато в перспективе (да и прямо сейчас) это позволит делать оптимизатору то, что раньше было просто невозможно для пред. версий gcc (автовекторизация...).

На дворе 21-ый век, а для GCC автовекторизация считается "делом перспективы", а не "не самой важной из давно имеющихся фич"? ФТОПКУ!

Может, в нём ещё и поддержки OpenMP нет?

Whoo ★★
()

А по моему вполне нормальная ситуация.
Помню сколько вони было на 3.0.0 по выходу.
Holy wars и транспаранты 2.93 нам отец родной 3.0.0 ф топку. Он тормоз, глюк, ядро им не собирается и сам собой он собирается.

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

> Спрашивается, зачем тогда переписывали?

Чтобы перейти на новую ступень на пути к совершенству.

> /me тихо и спокойно сидит на 3.3.5 и не дергается

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

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

> "сам собой" это как ? как могут исходники собрать себя сами ?

сначала исходники gcc4 собираются предыдущей версией, например 3.4 или 3.3

потом полученным компилером снова снова собираются эти же исходники

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

ну эт я знаю:)), просто фраза некорректная была, и еще это делается не в процессе простой сборки компилятора, а в ходе бутстрапа (некоторые переводят как шнуровка) системы

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

>>Интересно, а как самый первый компилятор делали? Как его собирали? Спроси у lumag: > Ты хоть понял, что ты сказал? Компилятор всегда собирается сам собой в процессе сборки.

random_code ★★
()

>На данный момент ошибка с компиляцией KDE решена, и патч появится в ближайшее время

Шиза. На каждую прогу - свой патч.

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

> и еще это делается не в процессе простой сборки компилятора, а в ходе бутстрапа ... системы

Это делается каждый раз кроме кросскомпиляции компиляторов.

И не шнуровка, а вытягивание себя за собственные шнурки :)

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

2 Whoo:

> На дворе 21-ый век, а для GCC автовекторизация считается "делом перспективы", а не "не самой важной из давно имеющихся фич"? ФТОПКУ!

В танке?

> Может, в нём ещё и поддержки OpenMP нет?

Типа умный, да, про OpenMP слышал? :)

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

> > На данный момент ошибка с компиляцией KDE решена, и патч появится в ближайшее время

> Шиза. На каждую прогу - свой патч.

Почему на прогу? Это патч обычного regression, коих в GCC a.b.0 всегда полно.

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

> Интересно, а как самый первый компилятор делали? Как его собирали?

А и правда - что первично? Таки курица или таки яйцо?

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

> А и правда - что первично? Таки курица или таки яйцо?

В смысле, написан ли первый компилятор на компьютере или первый компьютер собран компилятором? ;)

Курица, вестимо. Компилятор, на сколько я представляю, писался на ассемблере в hex-кодах... Ну или 8-ричных, 7-ричных, 31-ричных, смотря какая машина :)

Месье никогда не писал в 16-ричных кодах вручную рассчитывая смещения, подбирая нужный формат команды, адресации и т.п.? Месье много потерял! :)

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

> Месье никогда не писал в 16-ричных кодах вручную рассчитывая смещения, подбирая нужный формат команды, адресации и т.п.? Месье много потерял! :)

Фу, какая гадость. Вот MACRO-11, да, были времена :)

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

> Интересно, а как самый первый компилятор делали? Как его собирали?
Почитай историю создания языка FORTRAN - там ты найдещь ответ. :)

Irsi
()
Ответ на: комментарий от alt-x

А то что он действительно был первым, самым первым компилятором с языка высого уровня, а цэ - нет. :) Впрочем можно почитать и историю создания ALGOL 60 - он хоть и был вторым, но тоже раскручивался с нуля.

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

Круче было с lisp 1.5 в 62 году - тогда лисп скомпилировал сам себя выполняясь своим интерпретатором.. Впервые в истории. :)

Компилятор естесственно был написан на лиспе. :)

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

> > На дворе 21-ый век, а для GCC автовекторизация считается "делом перспективы", а не "не самой важной из давно имеющихся фич"? ФТОПКУ!

> В танке?

Применительно к GCC - не слишком слежу за его прогрессом, ибо пользуюсь оным только опосредованно (т.е. пользуюсь только программами, скомпилированными оным). Так что, я правильно понимаю, что на начало 2005-го года GCC ещё не умеет самостоятельно код на SSE/SSE2/3DNow! раскладывать? Уууу...

> > Может, в нём ещё и поддержки OpenMP нет?

> Типа умный, да, про OpenMP слышал? :)

А если я скажу, что некоторые люди OpenMP не только слышали, но и активно пользовали - у тебя возникнет когнитивный диссонанс?

(Правда, не под GCC, разумеется. Куда уж этому убогонькому...)

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

А нафиг когд расскладывать на SSE/SSE2/3DNow! он может компилировать с учётом этих расширений и оптимизировать с их учётом.
Что ещё нужно?
А OpenMP если я неошибаюсь... гдето точно есть! Я не спец но вовремя гугливания натыкался на gcc+OpenMP.

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

если бы это было так, то бустрап ничем бы не отличался от сборки гцц, глибсов и сопутствующих утил, и его бы не выделили в отдельную процедуру процесса установки системы from scratch. И я у себя никогда не наблюдал повторной сборики при emerge (-u) gcc

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

2random_code: Есть патчик, после наложения которого не собирается только. i2c в ядре. Может еще что-нибудь не слишком распространеное из модулей. Остальное работает, полёт нормальный.

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

> И я у себя никогда не наблюдал повторной сборики при emerge (-u) gcc

Если только Gentoo не слишком все поменяли, почти в конце сборки gcc загляни в каталоги сборки gcc. Там и найдешь объектники от stage1 (cc собирает gcc), stage2 (gcc, скомпилированный cc, собирает сам себя) и stage3 (gcc, скомпилированный gcc, собирает себя еще раз, чтобы сравнить с результатом второй стадии. На этом этапе при разработке отлавливаются многие ошибки). При этом понятно, почему в ходе кросскомпиляции gcc собирается только один раз.

P.S. cc = системный компилятор, gcc = вновьсобираемый gcc.

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

тов фубар

нет перфокарточку зубами грызли=)

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

Ну, то что C был не первым, ничего не меняет. Он не был написан ни на алголе ни на фортране.

alt-x ★★★★★
()
Ответ на: комментарий от Whoo

2Whoo (*) (08.05.2005 5:27:25)

>(Правда, не под GCC, разумеется. Куда уж этому убогонькому...)

То, что вы выучили слово "OpenMP" и собрали с помощью ICC (на PGC или PathScale у вас вряд ли хватит денег ... вряд ли вы работаете на их триалках) пару примеров с его использованием еще не означает что можно нести пургу насчёт gcc.

Для остальных докладываю что проект с использованием OpenMP и gcc называется GOMP.

Кроме этого ещё есть более старый опенсорсный проект - OdinMP

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

> А нафиг когд расскладывать на SSE/SSE2/3DNow! он может компилировать с учётом этих расширений и оптимизировать с их учётом.

Поясните, как вы понимаете эту фразу, и как вы понимаете её отличие от "раскладывать на SSE/SSE2/3DNow!".

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

Помню пытался както gcc 3.4 заставить генерить код с SIMD и никак. Долго пытался и вконце бросил. А у icc 8.1 сразу получилось. Как говорил Жванецкий : "тщАтелней надо , товарищи"

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

> То, что вы выучили слово "OpenMP" и собрали с помощью ICC (на PGC или PathScale у вас вряд ли хватит денег ... вряд ли вы работаете на их триалках) пару примеров с его использованием еще не означает что можно нести пургу насчёт gcc.

Интересная у вас дихотомия OpenMP-щных компиляторов - на ICC и PGC/PathScale...

> Для остальных докладываю что проект с использованием OpenMP и gcc называется GOMP.

Ух ты! Есть, оказывается! А подскажите, пожалуйста, остальным (а то и, простите за назойливость, даже мне), насколько полноценно оный GOMP работает? Или хотя бы насколько быстро развивается? А то зашёл я к ним на сайт, посмотрел в ихний CVS и увидел там мееелкую кучку файлов двухлетней давности с ревизиями 1.1, 1.2 да 1.3...

Так что, есть в GCC поддержка OpenMP, или (тяжело вздохнув) таки нет?...

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

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

> Помню пытался както gcc 3.4 заставить генерить код с SIMD и никак. Долго пытался и вконце бросил.

"Тяжело искать чёрную кошку в тёмной комнате. Особенно если её там нет." :)

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

>> Помню пытался както gcc 3.4 заставить генерить код с SIMD и никак. Долго пытался и вконце бросил.

>"Тяжело искать чёрную кошку в тёмной комнате. Особенно если её там нет." :)

И как вам такое удаётся ?

hint: К примеру gcc для х86_64 генерит SSE2 код по дефолту. Чтоб заюзать x87 нужно специально подкрутить опции компилера...

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

> И как вам такое удаётся ?

Мне? - никак. Я GCC не пользуюсь.

> К примеру gcc для х86_64 генерит SSE2 код по дефолту.

А остальным... ну, я не знаю. Вот вы говорите, что gcc может генерировать SSE2-код. А некто SKYRiDER говорит, что автовекторизация стала возможна только с GCC 4.0. Вы там разберитесь между собой, всё-таки...

Или может, под "генерированием SSE2-кода" вы имеете в виду то, что посредством препроцессора можно узнать, для какой платформы компилируемся, и заюзать написанный вручную для этой платформы код :) ? Ключик "компилируемся под SSE2", который ничего в коде реально не меняет, зато создаёт препроцессорную константу типа GCC_SSE2_ENABLED :))) ? Или даже, может, вы про перплатформенные intrinsic functions :) ?

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

> Вот вы говорите, что gcc может генерировать SSE2-код. А некто SKYRiDER говорит, что автовекторизация стала возможна только с GCC 4.0.

если я не ошибаюсь, то gcc умеет генерировать sse2 код еще с версии 3.3.*

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

> если я не ошибаюсь, то gcc умеет генерировать sse2 код еще с версии 3.3.*

А что ВЫ имеете в виду под "уметь генерировать sse2-код"?

(С чувством страшного озарения) Может быть, ПОДДЕРЖКУ АССЕМБЛЕРНЫХ КОМАНД SSE2 В ИНЛАЙН-АССЕМБЛЕРЕ 8-() ?...

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

GCC, начиная с версии 3.1, умеет генерить скалярные инструкции SSE/SSE2. Теперь же GCC 4.0 научился сам генерить и векторные инструкции SSE/SSE2 (но не MMX/3DNow!).

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