LINUX.ORG.RU

GCC 3.3 Вышел!


0

0

Следующий функциональный релиз колекции компиляторов GNU - 3.3
Убрано большое количество устаревших фич, добавлен DFA планировщик (http://gcc.gnu.org/news/dfa.html), улучшена поддержка ISO C99 (http://gcc.gnu.org/gcc-3.3/c99status....), других языков (С++, Objective-C, Java, Fortran, Ada), а также добавлено/улучшено много чего другого (http://gcc.gnu.org/gcc-3.3/changes.html).
Качаем исходники: http://gcc.gnu.org/mirrors.html , или ждем багфикс релизов =).

>>> Домашняя страница GNU Compiler Collection



Проверено: green

Ура, наконец-то убрали поддержку i?86-*-win32.

anonymous
()

Не подскажет ли уважаеый ALL какую из современных сетевых карт можно поставить в дабиан (с минимальными телодвижениями )

Заранее спасибо

anonymous
()

>Не подскажет ли уважаеый ALL...
А что такое дабиан? И при чем здесь gcc?

По поводу gcc 3.3 - подожду пока stack protector для него выйдет.

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

пока ещё не видел чтоб сетевая карта не завелась под Debian'ом, поэтому видимо любую

anonymous
()

anonymous (*) (2003-05-15 10:15:50.023)

Есть такая фича cdrtools-dvdr называется.

anonymous
()

Ага Спасибо (извините что так не в тему )

anonymous
()

А всё равно, пока что, если мерять производительность через Mplayer/Mencoder, gcc-2.95.x на несколько процентов более быстрые бинарники делает чем gcc3.

alt-x ★★★★★
()

DFA scheduller

А кто-либо мерял производительность кода который получается при использовании этого нового DFA планировщика инструкций?

hvv
()

>А всё равно, пока что, если мерять производительность через
>Mplayer/Mencoder, gcc-2.95.x на несколько процентов более быстрые
>бинарники делает чем gcc3.

Так и должно быть. Собирается медленнее, работает быстрее.

jackill ★★★★★
()

Дык это UNSTABLE ветка ?!!

anonymous
()

igor@igor:~> gcc --version
gcc (GCC) 3.3 20030226 (prerelease) (SuSE Linux)

сусе следует за редхетом в политике версии gcc в дистре ;-)

Z
()

Незнаю как этот релиз, а gcc 3.3 prerelease от SuSE 8.2 генерит просто сказочный код ;)
Приведу пример:
137277: e8 54 ee ff ff call 1360d0 <set_low_priority>
13727c: e9 58 ff ff ff jmp 1371d9 <longterm_lock_znode+0x89>
137281: eb 0d jmp 137290 <longterm_lock_znode+0x140>
137283: 90 nop
137284: 90 nop
137285: 90 nop
137286: 90 nop
137287: 90 nop
137288: 90 nop
137289: 90 nop
13728a: 90 nop
13728b: 90 nop
13728c: 90 nop
13728d: 90 nop
13728e: 90 nop
13728f: 90 nop
137290: e8 fc ff ff ff call 137291 <longterm_lock_znode+0x141>

Пойду попробую новый релиз, вдруг его попустило...

green ★★★★★
()

писать на лиспе надо ;)

emacs
()

2 anonymous (*) (2003-05-15 10:15:50.023)

Рекомендую 3Com 3c905C-TX-NM
Пару лет интенсивного использования - НИКАКИХ нареканий.
До этого еще несколько лет с 3c905B - тоже все ОК.

Удачи.

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

Да, новый релиз значительно лучше. И такого ужасного кода незаметно и вообще просто неправильного кода вроде как меньше стало генериться. По крайней мере фунцкии с двусмя локальными переменными больше не расходуют по 5 килобайт стека.

green ★★★★★
()

To jackill - прочитай еще раз, что написано. РАБОТАЕТ медленнее. Про то с какой скоростью он собирает вообще можно промолчать. Единственный + (во всяком случае для поздних 3.2 и ранних 3.3) - размер получаемых бинарников меньше чем с 2.95, но кому это в наше время важно?!?

alt-x ★★★★★
()

> размер получаемых бинарников меньше чем с 2.95, но кому это в наше время важно?!?

Всем. Память пока дороже гигагерцев.

anonymous
()

swap еще никто не отменял

anonymous
()

> swap еще никто не отменял

Да, это охерительно повысит столь драгоценную скорость.

anonymous
()

To:anonymous (*) (2003-05-15 18:12:34.484)

Что-то ты гонишь. Смотрим: -10% памяти от типовых 512M это -~$7 и зависимость цены от объёма ~линейна, -10% от P4-2666 это разница между P4-2666 и P4-2400, а это $30-40. А если взять еще более быстрый проц (а ведь ты берешь его, чтобы иметь производительность), то разница выйдет еще больше. Поэтому размер бинарников интересен гоооораздо меньше, чем производительность.

P.S. значение 10% использовано для удобства - я не утверждаю, что gcc 2.95.X на 10% быстрее чем gcc3. P.P.S Речь идет о C. С другими языками не исключено, что gcc3 выглядит лучше.

alt-x ★★★★★
()

> размер получаемых бинарников меньше чем с 2.95, но кому это в наше время важно?!?

Мне важно. Делаю поддержку reiser4 в GRUB. Попробуй запихнуть reiser4 c парой десятков плугинов и т.д. в 31744 байт :-)

Banshee
()

Дык это UNSTABLE ветка ?!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!1

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

А пропускную способность шины, скорость винта, сетевухи, etc. Для прокачки распухших бинарников ты как будешь увеличивать? На сайте Оберхаймера (так пишется? - это который lzo) приведен пример, когда чтение сжатого файла с распаковкой на лету было быстрее, чем чтение того же файла в несжатом виде.

anonymous
()

Кроме того добаить память не так просто. Иначе бы не раздавались постоянные вопли в форумах "А как мне заставить сервер работать с 3|3.5|4|8|16 Gb?"

anonymous
()

To Dselect - этот тест произвел ни кто иной как Arpi.

http://mplayerhq.hu/pipermail/mplayer-users/2002-September/020335.html

Последний раз я перепроверял в феврале - всё было так же. Если к релизу 3.3 что-то улучшилось (пусть даже ценой ЕЩЕ более медленной компиляции) - я искренне рад.

alt-x ★★★★★
()

To anonymous (*) (2003-05-15 18:46:24.157)

Это здравая мысль, но перечитай/подумай еще раз: они УЖЕ медленнее, даже не смторя на меньший размер.

To anonymous (*) (2003-05-15 18:50:26.712)

Ну и что? А процов с 16G тактовой вообще в промышленном производстве не существует.

alt-x ★★★★★
()

И вообще надо завязывать с сями и переписывать Линух и гнутый софт на форте. Размер бинарников сократится на порядки.

anonymous
()

> И вообще надо завязывать с сями и переписывать Линух и гнутый софт на > форте. Размер бинарников сократится на порядки

Только вот писать на нем сложнее чем на том же С...

syomin
()

а о каком стэк протекторе о котором говорит svs(*) ?? Это который смотрит за нарушением границ структуры данных или я ошибаюсь ??

D_D
()

> Только вот писать на нем сложнее чем на том же С...

Зато намного интереснее...

anonymous
()

Скорость при компиляции разными gcc лучше бы на glibc, X и kde сравнивали - там явно видно, что собранные gcc 3.2 работают быстрее.
А то, что mplayer очень хитро написан, давно известно.

jackill ★★★★★
()

размер сократиться? реально? с каких щей? за счёт "косвенного шитого кода"? ладно, я соглашусь, что по статистике форовые бинарники меньки меньше чем на си комплёные. но это проблема не языка, а _конкретного_ компилятора. и ваще, как один ассемблер может быть лучше другого?

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

А ты проверь еще раз.

В тесте по ссылке сравнивается GCC 3.2 с 2.95.3,
в changelog GCC 3.3 есть такая замечательная строка:

* A new scheme for accurately describing processor pipelines,
the DFA scheduler, has been added.
http://gcc.gnu.org/news/dfa.html

Насколько я понимаю в 3.3 для i386 DFA scheduler используется.

anonymous
()

Народ а как насчет Intel'овских компайлеров? Меня конкретно интересуют компайлеры для Pentium (первый :)) и Pentium Pro. Если не ошибаюсь их можно прикрутить как дефолтные и код генерится и работает гораздо быстрее. Если есть где дока или топик на эту тему кинте ссылку.

anonymous
()

>Ура, наконец-то убрали поддержку i?86-*-win32.

Да тут вообще идиоты тусуются чтоль?

КОМУ БЛЯДЬ НУЖНА ПОДДЕРЖКА GCC на x86-win32???

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

>Народ а как насчет Intel'овских компайлеров? Меня конкретно интересуют >компайлеры для Pentium (первый :)) и Pentium Pro. Если не ошибаюсь их >можно прикрутить как дефолтные и код генерится и работает гораздо >быстрее. Если есть где дока или топик на эту тему кинте ссылку.

Украинский журнал argc&argv #2 2003 (март-апрель) дает исчерпывающее сравнение.

SadAlex.

anonymous
()

anonymous (*) (2003-05-16 00:03:47.066) Не все же борланд воруют с визуалом.

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

> и ваще, как один ассемблер может быть лучше другого?

И как это он может быть лучше? И с чего фортовые бинарники меньше? Мистика какая то... ;)

> о статистике форовые бинарники меньки меньше чем на си комплёные.

Они обычно меньше и сваянных на чистом асме (для x86 к примеру).

> но это проблема не языка, а _конкретного_ компилятора

Т.е. предлагаешь компилятор си->форт?

P.S. Прямой шитый код - лучше.

anonymous
()

SadAlex> Украинский журнал argc&argv #2 2003 (март-апрель) дает исчерпывающее сравнение.

А для тех, кто не имеет "счастья" жить на украине пересказал бы.

sem
()

"Дык это UNSTABLE ветка ?"

Здесь версии именуются не как в ядре. UNSTABLE в CVS'се (или пре-релизах)

"Последний раз я перепроверял в феврале - всё было так же. Если к релизу 3.3 что-то улучшилось (пусть даже ценой ЕЩЕ более медленной компиляции) - я искренне рад."

Не надо забывать, что GCC 3 включает больше оптимизаций для конкретных процесоров (например тот же -march=pentium4, в 2.95 максимум (для i86 конечно) - i686). Дает хорошую "бесплатную" оптимизацию. (я использую -march=athlon-tbird для своего Duron 1.3)
И вообще это в корне неправильно, сравнивать производительность GCC только на одном MPlayer'e.

qusk
() автор топика

> И вообще это в корне неправильно, сравнивать производительность GCC только на одном MPlayer'e.

А где она еще нужна?

anonymous
()

>> И вообще это в корне неправильно, сравнивать производительность GCC только на одном MPlayer'e.

>А где она еще нужна?

Да.. Жестоко.
=). Ядро, apache, различные библиотеки..... Практически везде.

qusk
() автор топика

Да и вообще может кому-то и не нужна (за имением очень быстрых камней), но это не про меня.

qusk
() автор топика

> =). Ядро, apache, различные библиотеки..... Практически везде.

Не смеши пожалуйста ладно?

mplayer - это, пожалуй, единственный продукт где компилятор может оказать _существенное_ влияние на прозводительность.

anonymous
()

"mplayer - это, пожалуй, единственный продукт где компилятор может оказать _существенное_ влияние на прозводительность."

Нет это ты меня смешишь =). _ОЧЕНЬ_ спорное выражение. Как обоснуешь? Я вот например не заметил никакой разницы на глаз между производительностью MPlayer'a, скомпилированного на GCC 2.95 и 3.2.2

qusk
() автор топика

> Нет это ты меня смешишь =).

На сколько там продляют жизнь пять минут здорового смеха?

> _ОЧЕНЬ_ спорное выражение.

а ты приходишь на ЛОР в поисках абсолютной истины?

> Как обоснуешь?

Это оскорбление.

> Я вот например не заметил никакой разницы на глаз

Ну и кто из нас лучше шутит?

> между производительностью MPlayer'a, скомпилированного на GCC 2.95 и 3.2.2

Если уж тут нет разницы, то на других задачах и подавно не будет.

anonymous
()

А вот например перекомпилированное ядро ее (производительность) на глаз увеличивает.

qusk
() автор топика

> А вот например перекомпилированное ядро

Меняешь только компилятор или конфиг тоже?

> ее (производительность) на глаз увеличивает.

Ну хватит, ладно? Я не собираюсь жить сто лет.

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