Peter пишет:

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

там для каждого процессора своя память. например: http://www.f1cd.ru/news/motherboard/111/

Вот этого то ли не знал, то ли не обращал внимания. С учётом этого,
т.е. с точки зрения функциональности, ядро действительно не совсем
процессор.

Пётр.

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

там для каждого процессора своя память. например: http://www.f1cd.ru/news/motherboard/111/

Пётр.

ЗЫЖ всё-же, не все модули в многоядерном процессоре персональные для каждого ядра. Только я не знаю, какие из них общие...

Пётр.

Я имел в виду, что руками его не запускал, а log-файлы сжимаются gzip'ом.
Вот о существовании xz действительно не знал, хотя он у меня есть.

используйте. только учтите - он может пожрать сотни метров памяти. И если памяти мало - начать свопиться, и тормозить.

зря. по моим тестам - это совсем не процессор.

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

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

Да не, когда можно вписаться в 1000-10000 байт, всё нормально, многоядерность рулит. Вот только в царстве сжатия правят величины >1048576. Забудьте о кешировании.

Ну грубо говоря: один процесс забирает себе 100Мб, причём на каждой следующей итерации алгоритм обращается к ЛЮБОЙ из этих 100 000 000 ячеек памяти. Кеширование невозможно В ПРИНЦИПЕ. Ну и тут уже совсем не важно, один процессор, или 1024 - всё упирается в память, которая тормозит всё остальное.

Самое обидное - чем более "кешируем" алгоритм, тем он хуже по степени сжатия. Т.е. для максимального сжатия нужен максимально случайный разброс по памяти. Ну и память как можно больше. Потому сегодня лучшие алгоритмы работают на скорости работы DDR.  Для HDD это просто смешно, для кеша - грустно (лучше юзать LZ77/78).

Выводы: на сегодня, имея несколько гигов памяти, на них и надо рассчитывать. четверть гига, пол гига, гиг, два гига, четыре гига, восемь гигов, 16 гигов, 32 гига... Ну вот и вся линейка на сегодня. Я из этого исхожу. Я не прав?

Peter пишет:

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

Ой-ли? Пользовались. Только вы об этом не знаете. В Linux одна большая задача решается десятками, а иногда тысячами мелких утилиток.

Что до многозадачности... Понимаете, bzip2 безнадёжно устарел, и его держат исключительно ради совместимости. xz даёт намного более лучшие результаты (алгоритм LZMA2). Эффективно распараллелить сжатие почему-то не получается, ИМХО это связанно с особенностями архитектуры x86 (любопытный, кстати, случай - идеально распараллеливамый алгоритм с т.з. математики не распаралеливается на практике. Видимо это связано с тем, что архиваторы работают с огромными массивами памяти, но у нас нет "двух-памятных" компьютеров (двойная скорость - не то). Мало того, у нас даже двухпроцессорных нету - потому как ядро CPU это вовсе не процессор). Потому, в архивировании и распаковке данных многопоточность - не нужна.

Я имел в виду, что руками его не запускал, а log-файлы сжимаются gzip'ом.
Вот о существовании xz действительно не знал, хотя он у меня есть.
Я не силён в терминологии, но аппаратное ядро считаю процессором, т.к. в нём есть всё,
чтобы так называться, и при работе кэш 3-го уровня у каждого ядра свой. Они могут
изменять свой размер, но всё же область памяти у каждого ядра своя.

Пётр.

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

Ой-ли? Пользовались. Только вы об этом не знаете. В Linux одна большая задача решается десятками, а иногда тысячами мелких утилиток.

Что до многозадачности... Понимаете, bzip2 безнадёжно устарел, и его держат исключительно ради совместимости. xz даёт намного более лучшие результаты (алгоритм LZMA2). Эффективно распараллелить сжатие почему-то не получается, ИМХО это связанно с особенностями архитектуры x86 (любопытный, кстати, случай - идеально распараллеливамый алгоритм с т.з. математики не распаралеливается на практике. Видимо это связано с тем, что архиваторы работают с огромными массивами памяти, но у нас нет "двух-памятных" компьютеров (двойная скорость - не то). Мало того, у нас даже двухпроцессорных нету - потому как ядро CPU это вовсе не процессор). Потому, в архивировании и распаковке данных многопоточность - не нужна.
(я не говорил о специальных случаях! например про MPEG).

zet_lab, кстати, распаковка "не нужна", в том смысле, что она часто выполняется сама по себе. Например можно сохранить web страничку с картинками и прочим, потом сжать, а потом просматривать этот архив обычным браузером как обычный каталог. Воспринимайте архив как обычный каталог

(хотя почему у нас глючит ark - без понятия - по идее, можно прямо мышкой перетаскивать файлы из ark'а на ваш сайт, но у меня так не получается - Application: Ark (ark), signal: Segmentation fault )

Для выяснения проблем запускайте ark в консоли.

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

Peter пишет:

bzip2 и вообще все исполнимые файлы из пакета bzip2 у меня находятся  в/bin.
А в /usr/bin нагодится pbzip2 - многопотоковая речлизация bzip2.

зачем?

многопоточность - не нужно. (С) Патрег

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

Пётр.

bzip2 и вообще все исполнимые файлы из пакета bzip2 у меня находятся  в/bin.
А в /usr/bin нагодится pbzip2 - многопотоковая речлизация bzip2.

зачем?
ЗЫЖ

PACKAGE NAME:     bzip2-1.0.6-i486-1_slack13.1
...
lib/
lib/libbz2.so.1.0.6
bin/
bin/bzip2
bin/bzip2recover
usr/
usr/lib/
usr/lib/libbz2.a
...
usr/bin/
usr/bin/bzdiff
usr/bin/bzgrep
usr/bin/bzmore
...

многопоточность - не нужно. (С) Патрег

Peter пишет:

А у меня есть такая программа

ну и что? возможно (надо сырцы глянуть), эта версия применяется например в инсталляторах для лёгкости - ведь инсталлятор ничего не пакует, а только запаковывает. Или ещё где-нибудь. (Кстати, замете, она у вас в /bin - там лежит необходимый МИНИМУМ для старта системы. А зачем при старте что-то паковать? А весь остальной софт лежит в /usr, который может быть и удалённо. Кроме того, не забывайте про встроенные системы)

bzip2 и вообще все исполнимые файлы из пакета bzip2 у меня находятся  в/bin.
А в /usr/bin нагодится pbzip2 - многопотоковая реализация bzip2.

Пётр.

А у меня есть такая программа

ну и что? возможно (надо сырцы глянуть), эта версия применяется например в инсталляторах для лёгкости - ведь инсталлятор ничего не пакует, а только запаковывает. Или ещё где-нибудь. (Кстати, замете, она у вас в /bin - там лежит необходимый МИНИМУМ для старта системы. А зачем при старте что-то паковать? А весь остальной софт лежит в /usr, который может быть и удалённо. Кроме того, не забывайте про встроенные системы)

Peter пишет:

Распаковываю их программой bunzip2, никогда ничего не усекалось.

нет такой программы. Это то-же bzip2, но с ключом -d.
(точнее, это симлинк на bzip2, и если через него запускать, добавляется ключ -d)

А у меня есть такая программа

Пётр.