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

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

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

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

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

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

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

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

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

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

DFA scheduller

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

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

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

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

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

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

Брать от сюда: ftp://gcc.gnu.org/pub/gcc/releases/index.html

Незнаю как этот релиз, а 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>

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

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

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

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

Удачи.

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

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

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

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

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

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

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

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 выглядит лучше.

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

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

CFLAGS и опции ./configure -- в студию!

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

В тесте по ссылке сравнивается 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 используется.

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

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

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

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

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

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

SadAlex.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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