>а то запросто и 486

это фряха

или 386

такого вроде нигде нет

ну-ну
читай пост Сильвии

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

+1

убунта собирает i586 для десктопа и i686 для сервера

под 586 только мандрива и сузя )

Альт ещё, весь школьный линукс как раз и собран с таким ключом. Только сервер у них бывает дополнительно в 64-битной редакции.

раньше (jaunty) было -march=i486 -mtune=generic, что сейчас... я давно не смотрела,
хотя у меня лежит iso Natty alpha 3

в дебиане -march=i486 , без -mtune

про 64 речи нет, там x86_64 генерик вариант, с sse2 и без ряда инструкций порезанных на ранних моделях

про альт забыла, что они под пентиум собирают, впрочем, я не претендую на полноту заполнения списка, типичное перечислила

мб. Давно не юзал 32-битные дистрибутивы

Просто два месяца назад ставили Линукс в один компьютерный класс и тогда разбирались.

> в дебиане -march=i486 , без -mtune

Ужас какой.

код для march i486 на современных процессорах работает медленней, чем код для i386 (проверял многократно на разных задачах/приложениях).

// b.

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

Сделай что-то сам, а? Или только п*здеть?

Исходники PTS открыты - валяй, правь, делай «правильно».

код для march i486 на современных процессорах работает медленней, чем код для i386 (проверял многократно на разных задачах/приложениях).

Если это правда, то дело, скорее всего, в 80-разрядном математическом сопроцессоре, команды которго сейчас только эмулируются.

я для себя делаю тесты как надо
а поднимать проект уровня похороникса...
это надо кучу осей и железок - в том числе новейшего
извиняй - мне это не интересно

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

Можно через лоркод добровольцев найти

>Исходники PTS открыты - валяй, правь, делай «правильно».

От того, что исходники это г-на на похапэ открыты, никому не легче

>я для себя делаю тесты как надо

То-то я смотрю, результаты у тебя всегда какие-то феерические. Исследователь хренов, бугога -D

И это нам рассказывает человек, который уверяет, что 200-строчник — это хорошо. Ну-ну.

А чем он плох?

bzip2 бенчмарки

с bzip2 1.0.6 вот такое получается:

256 Mb кусок мусора из /dev/urandom  размещен в tmpfs, компрессия с -9
CFLAGS -O2 -fomit-frame-pointer
@Core2 Duo E8400 (Penryn, SSE4.1)

gcc 2.95.4 (=pentium)  - 0m53.722s
egcs-1.1.2 (=pentium)  - 0m56.607s
clang 2.8 (=native)         - 0m50.684s
gcc 3.4.6 (=pentium4)   - 0m51.866s
gcc 4.1.2 rh (=core2)     - 0m51.303s
gcc 4.2.4 (=nocona)       - 0m53.656s
gcc 4.3.5 (=native)          - 0m51.831s
gcc 4.4.5 (=native)          - 1m13.317s (упс!)
gcc 4.5.3pre (=native)    - 1m24.156s (еще "лучше")
gcc 4.6.0rel (=native)     - 1m5.343s

icc -xT
9.1     - 0m49.996s
10.1   - 0m50.129s
11.1   - 0m49.910s
12.0   - 0m48.339s

Тем, что костыль.
Есть адекватные решения проблемы, такие как systemd, BFS и BFQ. Но 200-строчник — это просто адовый костыль, но никак не решение проблемы. Проблемы ТАК не решают.

Поэтому надо использовать lbzip2. Прирост куда ощутимее.

>Тем, что костыль

Ещё один фапальщик на идеологическую стройность? Линукс, как система - сам по себе адовое нагромождение костылей и грязных трюков. Главное, чтобы задачи свои выполнял. А патч этот их выполняет на пять с плюсом.

systemd

Угу. Как давай тут полсистемы перелопачивать.

BFS и BFQ

От них тормоза.

никак не решение проблемы

раньше тормоза были, сейчас их нет. Это факт. А с фактами не могут спорить даже крикуны вроде тебя и мегабакса.

я вообще bzip2 как компрессор не люблю ) для бенчмарка он годится

>Угу. Как давай тут полсистемы перелопачивать.

В арче пакет собран так, что не мешает дефолтным initscripts, для запуска systemd нужно просто прописать в граб init=/bin/systemd.

Ну ещё лучше. Предлагаешь мне арч ставить? -D

Просто УЖОС какой-то! Что такого сделали в 4.4.5? Это же самый используемый на сегодня вариант!

Это я к тому, что в генте ebuild наверняка подобным образом сделан.

как? там же одни версии пакетов и ставятся из одного репозитория

> Ещё один фапальщик на идеологическую стройность? Линукс, как система - сам по себе адовое нагромождение костылей и грязных трюков. Главное, чтобы задачи свои выполнял. А патч этот их выполняет на пять с плюсом.
А потом эти люди удивляются, откуда берутся 12309. Сначала напихают дерьма костыльного, да прямо в ядро, а потом рыдают, что всё тормозит на простейших действиях. Потом через год приходят рыцари на белых конях и засовывают ещё один здоровеннейший костыль. Люди прыгают от счастья, проблема-то, мол, решена. Посмотрим, что вы годика через два скажите.

Угу. Как давай тут полсистемы перелопачивать.

Собрать и прописать в грабе init=/bin/systemd — это полсистемы перелопатить? И что ты тогда в генте забыл?
И чего метаться-то, всё равно systemd в ближайшее время скоро станет общепринятым стандартом для линуксов, так почему бы не перейти на него уже сейчас, тем более, что это ни капли не сложно?

От них тормоза.

Да что ты говоришь? Их, наверное, прямо специально ради тормозов делали, ага. Только почему-то в 90% они повышают отзывчивость. Ядро-то сам собираешь?

раньше тормоза были, сейчас их нет

У меня тот же эффект от чистого systemd, даже без BFS и BFQ. А с ними так и вообще, никаких результатов 200-строчника даже видеть не хочется.

[code]
4.3.5:
native 0m51.831s
core2 0m51.645s

4.4.5
native 1m13.317s
core2 1m13.231s

4.5.3pre
native 1m24.156s
core2 1m23.958s
generic 1m7.826s (на чем там тестил megabaks? gzip qtperf?)

4.6.0
native 1m24.156s
core2 1m5.222s
generic 1m5.361s
[/code]
вообщем вот такое получилось по сравнению с -march=native -mtune=native
опять же не стоит воспринимать это категорично, возможно что это только с bzip2, только этой версии и т д

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

можно подумать, что ты умеешь

ps: x86 естественно, для amd64 я не против увидеть подобное же сравнение...

Интересно в это сравнение добавить gcc-4.4 из свежего rhel'а.

да, фигню сморозил. наверно i686 только йадро

bzip2 даёт наилучший результат на -march=i686

P.S. на 32
на 64 - хз

PPS: для официального сравнения существуют тесты SPEC,
вот собственно по ним и стоит сравнивать, а на bzip2 и прочем это быстрый «домашний» вариант

>Интересно в это сравнение добавить gcc-4.4 из свежего rhel'а.

Разве в свежем не такой же 4.4.0, как в несвежем?

мой gcc 4.4.5 взят из branches/redhat
как и 4.1.2, остальное - ванильное

>PPS: для официального сравнения существуют тесты SPEC

говорят, что Штеуды специально затачивают процы под SPEC, хотя производительность в реальных задачах не так уж хороша.

официальный тест, от которого зависит рейтинг как компилятора, так и процессора,
неудивительно что пытаются мухлевать ) поэтому стоит и реальное потестировать

>Собрать и прописать в грабе init=/bin/systemd

Да ладно? что, вот так прям и всё? тогда надо попробовать.

>Линукс, как система - сам по себе адовое нагромождение костылей и грязных трюков

вот до тех пор он и будет продолжать быть кучей г..на, пока вместо костыля в 200 строчек не начнут использовать более логичные и в 40 раз меньше.

От них тормоза.

Не от них, а они от тормозов.

раньше тормоза были, сейчас их нет. Это факт.

У меня при переходе на .38 тормоза пропали и с ВЫКЛЮЧЕННЫМ патчем. Никак б-жественная сила Патрега помогла.

>Не от них, а они от тормозов

До тридцать восьмого ядра я перепробовал разные комбинации - и bfs+bfq, и cfs+bfq и так далее и тому подобное, но нечто похожее на 12309 никуда и не думало пропадать.

Ну и, конечно же, включить необходимые при запуске демоны.
Список смотреть в /lib/systemd/system/
Включать посредством systemctl enable <имя_сервиса>.service
Ещё может понадобиться прописать, что грузиться надо в графический интерфейс по дефолту. ln -sf /lib/systemd/system/graphical.target /etc/systemd/system/default.target
В принципе, почти то же самое приходилось делать при первой настройке openrc.

Sylvia,

надо бы bugreport добавить в bugzilla.

gcc 4.1.2 rh (=core2) - 0m51.303s

vs

gcc 4.5.3pre (=native) - 1m24.156s (еще «лучше»), gcc 4.6.0rel (=native) - 1m5.343s

Это же на 27% медленней! Если тебе лень, я могу сделать.

// b.

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

а написать конечно можно, только оно там так и останется, мертвым грузом, без деталей

>возможно что это только с bzip2, только этой версии и т д

Core i5-430M, gcc 4.6. игры c mtune не дают вообще ничего, разница в пределах погрешности.
Вырубание выравнивания уменьшает время на .3-.5 секунды.
Включение кое-каких оптимизаций ускорило сжатие еще на 1-2 секунды.

Как-то уныло. Что скажешь, откатиться на 4.3?

пока ничего, потестить на чем-нибудь еще
в bzip2 мир не упирается.

У генты почти все пакеты в .bz2