LINUX.ORG.RU

Ответ на: комментарий от Deleted

XZ/7Z используют LZMA2 и умеют в несколько потоков.

Сравни скорость упаковки/распаковки, удивись. Сравни эффективность, удивись еще раз.

Moderators ★★
() автор топика
Ответ на: комментарий от baka-kun

Ты о «Почему бы не упаковывать пакты». :)

Так вот в чем дело. Странно это, литератором себя я никогда не объявлял

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

Я вообще-то о пакетах

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

baka-kun ★★★★★
()
Ответ на: комментарий от Moderators

литератором себя я никогда не объявлял

Так ты и анимешником себе не объявлял, что никому не мешает. :)

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

baka-kun ★★★★★
()

ты о каких однопоточных архиваторах говоришь? Все популярные архиваторы многопоточные (насколько я знаю)

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

ты о каких однопоточных архиваторах говоришь? Все популярные архиваторы многопоточные (насколько я знаю)

Сравни скорость с ZPAQ

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

Попробуй ZPAQ

Как ты предлагаешь распараллелить арифметическое кодирование, которое анализирует вероятность каждого следующего бита на основании потока предыдущих и по определению линейно? ZPAQ распараллеливает деля входной файл на блоки, пакуя несколько одновременно. Также, как и xz.

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

baka-kun ★★★★★
()
Ответ на: комментарий от Moderators

Слушай, ты начал тему с популярных (все пользуются) однопоточных архиваторов, видимо тебе стоит перечислить их. Мне гадать не с руки.

futurama ★★★★★
()
Последнее исправление: futurama (всего исправлений: 1)
Ответ на: комментарий от Moderators

Ты литератор что-ли?

«Что Вы! Такое же быдло, как и Вы.» ©

baka-kun ★★★★★
()
Ответ на: комментарий от futurama

Слушай, ты начал тему с популярных (все пользуются) однопоточных архиваторов, видимо тебе стоит перечислить их.

На фоне ZPAQ - LZMA однопоточен, попробуй, ну! Какой-нибудь ISO убунты сжать

Moderators ★★
() автор топика
Ответ на: комментарий от baka-kun

Как ты предлагаешь распараллелить арифметическое кодирование

Я ничего не предлагаю, а лицезрею скорость и результат

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

С возвращением, 12309. Теперь на каждом чихе!

?

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

грузит одно ядро, не дождался и прервал

Я не знаю, какие ключи добавляет PeaZip, но это далеко не так

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

Потому что на C очень трудно написать многопоточную программу без гонок и взаимных блокировок.

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

Потому что на C очень трудно написать многопоточную программу без гонок и взаимных блокировок.

Какое мне дело до языка, я не погромист. Я как пользователь, вижу скорость и эффективность. И неэффективность широко применяемых средств, поэтому и вопрос

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

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

Napilnik ★★★★★
()

Почему повсеместно используют архивы с однопоточными арихваторами?

Потому что многим многопоток не нужен.
Ваш К.О.

crutch_master ★★★★★
()
Последнее исправление: crutch_master (всего исправлений: 1)
Ответ на: комментарий от Napilnik

дополнительные несколько процентов сжатия не стоят усилий.

Это приятный бонус. Главное - сравни скорость.

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

Далеко не все используют архиваторы для сжатия 1ТБ образов. Обычно сжимают какую-нибудь мелочь, а простаивающие ядра занимают еще одним таким же процессом.

crutch_master ★★★★★
()
Последнее исправление: crutch_master (всего исправлений: 1)
Ответ на: комментарий от crutch_master

Далеко не все используют архиваторы для сжатия 1ТБ образов.

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

а простаивающие ядра занимают еще одним таким же процессом

Подробнее, то есть, ты не отрицаешь преимущество ZPAQ в скорости?

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

Подробнее, то есть, ты не отрицаешь преимущество ZPAQ в скорости?

Хз что у него там по скорости.

Даже архивы до сотни мегабайт будут упаковываться и распаковываться

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

Хз что у него там по скорости.

О чем тогда вообще речь? Я предлагаю сжать и сравнить скорость и эффективность, с чем предлагали - LZMA2. Ксенофобии искренне не понимаю.

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

Usecase где будут постоянно распаковываться архивы 100мб+? Обычное использование - сжатие сетевого трафика (gzip), обновление системы, где кучка мелких пакетов и по сути не важно как их распаковывать, ибо не критично, какие-нибудь jar'ки, которые запаковываются один раз при сборке и каждый раз при запуске, которые не делают, как правило больше 10 метров и в любом случае это не критично в сфере их применения.
Что ты вообще прицепился к многопоточной распаковке/запаковке? Кому профит от неё какой?

crutch_master ★★★★★
()
Последнее исправление: crutch_master (всего исправлений: 3)

Ты куда-то спешишь?

По моему опыту в реальной жизни встречается 2 объёма данных: достаточно мало, чтобы дождаться однопоточной обработки, и слишком много, чтобы несколькопоточная существенно улучшала жизнь. Т.ч. не нужно, пока количество процессоров в компутере не резиновое - не увеличивается в тысячу раз при потребности. Думаю, последнее возможно, но редко нужно и недёшево.

DonkeyHot ★★★★★
()
Последнее исправление: DonkeyHot (всего исправлений: 1)
Ответ на: комментарий от crutch_master

Usecase процесса, где будут постоянно распаковываться архивы 100мб?

То есть это принципиальная позиция - не использовать инструмент лучше? Меряй хоть на 50 Mb

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

Чем он лучше? Тем, что умеет в многопоток? Но он не нужен и профита на большинстве существующих задач никакого не даст.

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

Ты куда-то спешишь?

Размер данных увеличился с 90х, и процессоры, как ни странно тоже прибавили в ядрах

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

Чем он лучше? Тем, что умеет в многопоток? Но он не нужен и профита на большинстве существующих задач никакого не даст.

Вылезай из Пенька-4 уже

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

Вот ты вроде адекватный человек, а зачем-то споришь с Moderators

Кыш, аниме отребье

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

Вылезай из Пенька-4 уже

Еще раз спрашиваю usecase сжимания разжимания 100мб+ файлов в куче потоков. Твой этот zpaq ничего не выиграет на реальных задачах настолько, чтобы был смысл везде его вкорячить. Также нет смысла сжимать на 5% лучше, но терять 2000% по времени запаковки/распаковки. Впрочем, тебе никто не запрещает сжимать чем хочешь, непонятно зачем ты закатываешь тут бабскую истерику.

crutch_master ★★★★★
()
Последнее исправление: crutch_master (всего исправлений: 1)
Ответ на: комментарий от crutch_master

Еще раз спрашиваю usecase сжимания разжимания 100мб+ файлов в куче потоков.

Ты по одному файлу сжимаешь? И с большими архивами никогда не сталкивался? Чем оно помешает на маленьких архивах я тоже в упор не понимаю

жимать на 5% лучше, но терять 2000% по времени запаковки/распаковки.

Вот, у тебя в голове все перемешалось. Я говорю о превосходстве по обоим фронтам

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