Доступен релиз библиотеки zlib-ng 2.0 который отмечен как первый стабильный выпуск проекта (следом уже доступен корректирующий выпуск 2.0.1). Zlib-ng совместим с zlib на уровне API, но предоставляет дополнительные оптимизации, не принятые в официальный репозиторий zlib из-за консервативного подхода к приёму изменений. Дополнительно предложен модернизированный API, основанный на zlib, но изменённый для упрощения портирования. Код проекта написан на языке Си и распространяется под лицензией Zlib...Подробнее: https://www.opennet.ru/opennews/art.shtml?num=54775
Почему не на Rust? Сам пошутил - сам посмеялся.
> не принятые в официальный репозиторий zlib из-за консервативного подхода к приёму измененийУважаю zlib, никаких zlib-ng в моей системе не будет.
О да, 16-разрядные системы и несовместимых с ANSI C компиляторы это ваше все!
Ты такие слова знаешь, ну прям вааащее
вообчето используются они.
Старые версии zlib для таких систем никуда не денутся.
Да ? А где они ? Может там есть старая рабочая жаба ? Или нетскейп ? Где все это ?
В архивах, которые несложно нагуглить.
Ногугли ка мне архив с нетскейпом который я смогу собрать под ппц
А нетшкаф хоть когда-то был под ппц? Чтобы что-то гуглить - это наверное должно хотя бы существовать? А так потомок шкафа, файрфокс - пожалуйста. Скачай какой-нибудь третьей версии и собирай. Он даже собирается раз в 10 проще современных. Правда фиг его знает как там с ppc.
ок, давай любой чтоб под арм ? или все, позиция ногуглю любой архив провалилась ?
> ок, давай любой чтоб под арм ? или все, позиция ногуглю любой архив провалилась ?Так это, в демьяне под ARM браузеры собраны не хуже чем под все остальное. Можешь потомка нетшкафа в виде файрфокса укачать. И даже его винтажные версии на archive.debian.org каком, если это зачем-то надо. Не совсем нетшкаф, но это самое нетшкафообразное что я знаю из существовавшего в виде сорцов.
Я не говорю о софте который у меня был до твого рождения, но ты даже популярные вещи ногуглить не смог, чтож такое, гуглилка таки не работает выходит
> Я не говорю о софте который у меня был до твого рождения,Проблемы мамонтов с PDP11 меня не интересуют.
> но ты даже популярные вещи ногуглить не смог, чтож такое, гуглилка
> таки не работает выходитДа вот как-то лис старинных версий и под ARM таки есть. А остального в сорцах и не было, насколько я помню, а в бинарях откуда оно возьмется, если ARM современных версий вылупился позже? И тем не менее, в их archive есть вот как раз примерно то самое лохматых версий, современных тем версиям демьяна. Даже, вон, сорцы есть. Кушайте не обляпайтесь, даже, вон, сорцы этого антика есть. А развернув тот ископаемый вариант дистра можно даже всю эту некромансию пересобрать, если это за каким-то кукуем надо.
А так - под ARM в том же демьяне есть практически весь тот же софт что и под x86, так что на глаз дистро и не отличишь если cpuinfo не зырить. А вы там гуглите и нойте если оно надо. Я так как раз винтажную версию файрфокса подбирал для x86-32 системы без SSE2 энное время назад. Правда негодяй пох нашел еще более зачетный ресурс, конечно после того как он был мне нужен...
Смотри фокус! Машина времени! На этом табло вводится дата назначения: https://snapshot.debian.org/archive/debian/ :)
p.s. опеннет конечно же испортил урлу, вводить надо с последним слэшом.
Нам всем очень интересно, что на твоей системе есть, а чего нет и не будет. Продолжай держать нас в курсе.
Это конечно всё очень полезно, только zlib в основном из-за сжатия веб страниц жив. И, я слышал, brotli его заменил. А трафик так и вовсе бесплатный теперь -- не то, что раньше. Но интересно как так получается, что gz быстрее zlib, когда это одно и то же (по-сути). Или я чего то не знаю, или подобрали специальные кейсы.
Угу, гуглу это расскажи. А то чего-то для них трафик основная статья расходов. Думаешь чего они с сжатием возятся, для прикола?! И мобильные операторы тоже почему-то пипеткой этот "бесплатный" отмеряют. А то эфир видите ли делится на всю толпу и поэтому ограниченый ресурс.
И все труды gzip множатся на ноль из за маленький изображений... с весом более 10 Мб, а так же из за видеорекламы.
Для начала
1) gzip в картинках вообще не встречается.
2) гугл webp любит, там совсем zip'а/deflate'а нет.
3) Грузить 10метровые картинки на нагруженных страницах гугол не любит.
> gzip в картинках вообще не встречаетсяРасскажи это PNG.
> Расскажи это PNG.deflate != gzip ;). Гзип как бы deflate + некие свои хидеры. А png это deflate + некие свои хидеры. При чем тут gzip? В png нет заголовков оного, кукуйте.
> Или я чего то не знаю,Наверное не знаешь вообще ничего. Все что ты видишь перед собой, в той или иной мере использует zlib, вся твоя графика без нее работать не будет, даже твой глубоко консольный пакетный менеджер без нее не может. Игры и инторнеты и подавно.
Или же знаю по крайней мере больше тебя? Во всяком случае, deflate очень медленный и неэффективный, как ни крути.
Ты даже не знаешь как работает пнг
Может быть. Это не делает deflate менее опциональным.
Спасибо за ыкспердное мнение.
> Ты даже не знаешь как работает пнгТаки можно приколоться и сделать нежатый png. Или RLE-only. Однако для декодирования произвольного inflate все же понадобится.
p.s. а таки png устарел... ну вот не лучшая либа по сжатию это, словарик мелкий, скорость распаковки так себе. Тот же zstd и жмет лучше и декомпрессится быстрее одновременно.
Я ещё могу понять, что неэффективный (тут по коэффициенту сжатия всё равно всех делает PAQ8) или неоптимальный (где, судя по всему, хорош Zstandard), но с каких это пор он медленный?
На сжатие он медленный, особенно на 9чку. Не для сжатия текстур скажем так. На распаковку достаточно ок конечно.
И да, помимо веб-страниц он использовался примерно только в png (zlib и был сделан для png).
Вот ты ламер. Он используется много где. А просто потому что долгое время это было 1 приличной опенсорс либой сжатия.Ну например, формат данных HMM III (и IV) пожат тем самым deflate'ом. О чем прозрачно намекает копирайт Адлера и проч в коде их бинаря (статически влинковано, при том уязвимая версия, трололо, удачной игры по сети!).
Прости, но… С каких пор коммерческие поигручечки (из 90х!) считается за "используется"? Им ведь ровно всё равно, чем жать, многие и не жмут даже нули -- в итоге все эти гигабайты сейвов сжимающиеся в 100000 раз валяются на диске как есть, ровно то же самое и с текстурами. Допустим, может использоваться для _медленного_ сжатия текстур где-то, допустим. Ну и? А вот в левелдб используется снаппи, дальше что? Этот же снаппи может использоваться опционально и не очень ещё в десятке проектов. Странно, почему не дефлейт, он же такой хороший и универсальный?
> Прости, но… С каких пор коммерческие поигручечки (из 90х!) считается за "используется"?С таких каких я в них играю, например.
> 100000 раз валяются на диске как есть, ровно то же самое
> и с текстурами.Да ну, эксперт в треде, все в машину! Им настолько все-равно что есть такая фирма как RadGameTools с весьма специфичными форматами, про которые ты поди и не слышал. Потому что самяя проприетарщина из проприетарщины. Они даже обуели и наехали на опенсорсника который альтернативные реализации без платной либы накодил. Правда потом из-за урона репутации с такого демарша задний ход все же дали.
Но факт в том что они вот настолько считают это ценностью. И игроделы это юзают. В смысле коммерческие проприетарные, конечно.
> Допустим, может использоваться для _медленного_ сжатия текстур где-то,
> допустим. Ну и? А вот в левелдб используется снаппи, дальше что?А ничего. Snappy вообще один из самых бестолковых алгоритмов. Единственное его "достоинство" - NIH. В остальном он не делает ни LZ4, ни LZO, ни другие сравнимые. Ни по скорости ни по сжатию.
> Этот же снаппи может использоваться опционально и не очень ещё в
> десятке проектов. Странно, почему не дефлейт, он же такой хороший и универсальный?Потому что это алгоритмы из сильно рахных категорий. Snappy в принципе степень сжатия deflate не получит на большинстве типов данных. Куды гольному LZ с туповатым битстримом супротив LZ+Huffman по сжатию? Но по скорости декодирования - отпедалить два алгоритма (LZ + Huffman), очевидно, дольше чем один. Особенно актуально для распаковки LZ, которая сама по себе довольно быстрая операция в силу принципов работы.
>RadGameToolsОпять некрофильствуешь? Я практически уверен что они кокнулись ещё в 90 (да, я в курсе, что в начале нулевых было ещё пара игрушек с bik).
Насчет снаппи я ответил в соседнем посте. Они не взяли deflate видимо по причине недостаточной производительности на сжатии, что в некоторых случаях роялит. Но дейстивительно, выигрыш от его использования очень неочевиден.
>из сильно рахных категорий
По-моему, это несколько упрощённая и понерфленная версия zlib, возможно, именно благодаря нему появился brotli. А то и zstd (наш спаситель).
Никакого отношения это всё ни к чему не имеет, deflate пусть универсальный, но с любой стороны дорогой и медленный даже сегодня, что говорить о ситуации 30 лет назад.
> Опять некрофильствуешь? Я практически уверен что они кокнулись ещё в 90 (да,
> я в курсе, что в начале нулевых было ещё пара игрушек с bik).Черта с два! Живее всех живых. И просто для понимания, в PS5, кажется, один из их форматов В ЖЕЛЕЗО ВХАРДКОЖЕН. В смысле, там после SSD хардварный декодер. Выжимает гигов 5, чтоли, в секунду. Что дает совсем иные понятия о времени loading крутых тяжелых гамез.
И даже, цуки проприетарные, выпилили, вот, репу с альтернативной реализацией своих экзотов. Правда потом из-за жесткого бэкслэша и попадания в новости с негативным контекстом - вернули.
> по причине недостаточной производительности на сжатии, что в некоторых случаях роялит.
Это разные классы алгоритмов. Snappy - в той же категории что LZ4, LZO, LZ5, Lizard, lsza ... (имя им легион). Одностадийный LZ, без хаффмана (арифметика, ANS, rangecoder, в общем entropy coding). Вторая фаза - кодирование за LZ энтропийным кодером повышает сжатие, но это два алгоритма друг за другом, поэтому медленнее. Особенно на распаковку.
Фэйл в том что по параметрам snappy вообще совсем ничем не интересен. Он ну вот не делает сравнимые алгоритмы. Вроде бы совсем ни в чем, кроме NIH синдрома у гугла. Поэтому и не встречается почти, кроме пары гуглопроектов.
> По-моему, это несколько упрощённая и понерфленная версия zlib, возможно, именно благодаря
> нему появился brotli. А то и zstd (наш спаситель).Это другой класс алгоритмов - LZ без entropy coding. Точнее, zlib, zstd, lzma и ко - попросту двухступенчатые алгоритмы. Сперва примерно такой же по смыслу LZ, но его выход потом отдается фазе entropy coding. Поэтому декомпрессия медленнее, надо 2 разных алгоритма сжевать вместо 1.
Нагляднее всего это в формате Lizard (потомок LZ5) видно, там даже LZ в чистом виде очень странно складывает результат, в 5 разных субпотоков (которые опционально можно huffman'у отдать, каждый отдельно конечно).
> Никакого отношения это всё ни к чему не имеет, deflate пусть универсальный,
> но с любой стороны дорогой и медленный даже сегодня, что говорить о ситуации 30 лет назад.Ну да, он медленноват и не очень хорошо жмет, словарик мелкий. В эпоху DOS оперативки видите ли было сильно меньше...
Хотя, что касается снаппи… Будем считать, что это было тёмное время. Нет, конечно, на сжатие он в 2 и более раз быстрее, но он ведь на распаковку медленнее zlib и жмёт при этом в 2 раза хуже. Но суть в том, что медленное ресурсоёмкое сжатие походит не везде и не для всего, а так конечно может быть использовано любое сжатие где угодно. Но вот на уровне стандарта или формата файла zlib только в png.
> Хотя, что касается снаппи… Будем считать, что это было тёмное время.Будем считать, что у кого-то в гугле NIH очень зудел.
> Нет, конечно, на сжатие он в 2 и более раз быстрее, но
> он ведь на распаковку медленнее zlibВащет быстрее. Но проблема в том что сравнимые алгоритмы либо
- Жмут лучше а распаковываются примерно как оно.
- Жмут примерно так же, но распаковываются быстрее.Есть такая штука - pareto frontier. Грубо говоря, некая кривая, "степень сжатия vs скорость распаковки". Чем лучшем сжатие, тем, естественно, сложнее это потом быстро распаковывать из-за более продвинутого алгоритма и трюков формата. Проблема snappy в том что он находится не на этой кривой state of art'а, а где-то здорово под ней, не демонстрируя стоящих результатов вообще ни с каким выбором этих соотношений. И пойнт этого дизайна вызывает вопросы, если это нечто новое. Ну, предполагается что если кто-то новое дизайнит то оно чем-то лучше старого, чтоли. А так алгоритмов такого класса и без гугля было навалом, fastlz, quicklz, lzo, примерно в то же время lz4 вылупился, более длинный список - в lzbench можно посмотреть, "fast" кодеки.
> и жмёт при этом в 2 раза хуже.
Если это на примере тех XMLок с ratio в 4%, там очень специфичный результат. Когда инфо настолько избыточное, входной поток в декомпрессоре почти отсутствует и не рушит кэш, и алгоритм сильно втапливает. И чем лучше сжатие тем больше выигрыш на этом. Однако если коэффициент сжатия более вменяемый, скажем, 30-50%, такая халяве не наступает, входные данные достаточно интенсивно вымывают кэш, алгоритмы более-менее в равных условиях без дискриминаци по сжатию, и соотношения вообще совсем другие - snappy уделает zlib'а по скорости в пару раз на распаковке, просто потому что там декомпрессор тривиальный, в отличие от. Это неудачные/специфичные тестовые данные, сильно избыточнее типового случая.
> Но суть в том, что медленное ресурсоёмкое сжатие походит не везде и не для всего,
Поэтому для этого и были всякие LZO а потом и LZ4 - но у них есть фатальный недостаток: их накодил не гугл. Впрочем, этот недостаток оказался фатальным только для гугля - ну вот заурядный и юзает в основном пара карманных проектов гугля.
> а так конечно может быть использовано любое сжатие где угодно. Но вот на уровне стандарта
> или формата файла zlib только в png.Очень распостраненный формат сжатия на самом деле. Всякие gzip и ко - deflate. Или вон ресурсы и сэйвы HMMIII/IV. А на самом деле в силу халявной лицензии и существования дочерта лет - таки встречается в каждой дырке. И стандартной и не очень. В маздае installshield злибом сетапы паковал. "Installshield CAB". Это не то же самое что MS CAB, другой формат. Впрочем, последний тоже как один из вариантов алгоритма deflate допускает (называется MSZIP, но суть та же что и обычно). Эксплорер кстати .zip сразу жрет, куды ж он без поддержки inflate такой красивый? Или этого тоже мало?
Оно настолько распостранено - что классификаторы неизвестных файлов и проч даже ловят хидеры zlib и проч и выдают нечто типа "zlib-compressed data", как generic классификацию даже если они не знают формат лично. Либу нашару вывалили много лет назад - ей и попользовался все кому не лень, их легион. Достаточно попробовать zlib у себя в системе удалить целиком, посмотрев сколько от него depends...
>Ващет быстрее. Но проблема в том что сравнимые алгоритмыЭто на примере тестовых файлов предоставленных авторами snappy и результат бенчмарка предоставленного авторами snappy. Глубоко я не копал.
>Есть такая штука - pareto frontier. Грубо говоря, некая кривая, "степень сжатия vs скорость распаковки".
Только zstd сжимает как lzma9 (или даже лучше, часто ощутимо), даже быстрее lzma9, и распаковывает всё равно в десятки раз быстрее (без преувеличения), в связи с чем меня всегда очень интересовало где это штука была и как это про неё забыли. А, может быть, она не имеет никакого отношения ко сжатию, и теоретические ограничения вызваны лишь текущими представлениями, нет?
> распостраненный формат сжатия
Я смотрел, что там от zlib зависит. Это не самый эффективный формат с любой стороны. Получается, "лишь бы было" и "достаточно хорошо" куда чаще, чем действительно какая-то польза и нужда.
-Qt/kde
-glib/gtk
-cairo/mesa (те самые сжатые текстуры и тут пролезли? deflate для текстур использовать… изверги)
-библиотеки шрифтов
-cmake
-разные эмуляторы (они опционально поддерживают сжатые gzip файлы, по крайней мере, часть из них)
-libxml2 (не в курсе, с какими целями)
-python/ruby/perl/nodejs
-git/openssh/rsync и браузеры
-gnupg
-libavif и gpac (не знаю, насколько опционально)
-mkvtoolnix (допустим)
-gcc/gdb/llvm (без deflate тут никуда понятно *сарказм*)И что-то всё, кончились пользователи deflate. Из 1300 приложений это не так и много.
> авторами snappy. Глубоко я не копал.Верить авторам алгоритмов стоит с оговорками. Особенно если они из гугола.
> Только zstd сжимает как lzma9 (или даже лучше, часто ощутимо),
Вообще-то чаще всего таки хуже. Особенно с всеми фичами. Но не сильно. А распаковка *сильно* быстрее. Что и делает zstd интересным. И он соответственно ближе к этой кривой. Но все же он как движок сжатия в целом чуть менее плотный. Я их плотно срвнивал на очень разных данных с сравнимыми параметрами.
> даже быстрее lzma9, и распаковывает всё равно в десятки раз быстрее (без преувеличения)
LZMA таки тормозной в распаковке. Но использует лучшие трюки получения ratio - половина остальных собезьянило технологии и идеи оттуда.
> она не имеет никакого отношения ко сжатию, и теоретические ограничения вызваны
> лишь текущими представлениями, нет?Та граница не стоит неподвижно. Каждый уважающий себя эксперт спит и видит чтобы подвинуть эту кривую своим алгоритмом. Крутое сжатие с быстрой распаковкой - "святой грааль" алгоритмов сжатия. На практике, конечно, применение многочисленных и крутых трюков улучшающих сжатие нагибает скорость. Как сжатия так и распаковки - их на фазе распаковки undo надо все-таки.
>> распостраненный формат сжатия
> Я смотрел, что там от zlib зависит.Дофига всего. Он в куче стандартов, форматов и программ на самом деле.
> Это не самый эффективный формат с любой стороны.
Словаря 32 кило на современных данных видите ли маловато бывает.
> Получается, "лишь бы было" и "достаточно хорошо" куда
> чаще, чем действительно какая-то польза и нужда.Просто он часто оказывается "good enough". Сжатие уже не позорное, скорость не как у LZMA все же, лицензия на шару, и есть под все что шевелится. А раньше особо и альтернатив не было. А так то zstd появился потому, что его автор нащупал почву для улучшений.
Если кто не знает, автор ZSTD теоретически должен был стать маркетологом. Практически его занесло на компрессионные ресурсы, ему вштырило, он возьми и сделай LZ4. Народ сказал - офигеть, дайте две! И чувак решил сменить карьеру, круто и всерьез. Сейчас он в Facebook эксперт по сжатию. А ты чего думаешь они к btrfs привинтили? (ага, девы оной тоже там есть).
> -gcc/gdb/llvm (без deflate тут никуда понятно *сарказм*)
Сжатие дебажных символов, etc. Оно опциональное вроде.
> И что-то всё, кончились пользователи deflate. Из 1300 приложений это не так и много.
Там еще inter-dependencies по цепочке, половина либ ими пользуется. Хотите TIFF читать? Оок, а zip - один из валидных субформатов. А сколько из 1300 программ в PNG умеет? Небось каждая вторая? Ну а без libpng это не получится и та depends на zlib ессно. Сюрприз!
>сколько из 1300 программ в PNG умеетШтук 5, но в целом согласен. Более того, я подозреваю, что зависимость от zlib там много где может быть именно из-за png. У tiff поддержка zlib/lzma/zstd как раз опциональная, я тут рассматриваю только обязательные зависимости. По остальному мне нечего сообщить.
>>сколько из 1300 программ в PNG умеет
> Штук 5,Это, имхо, врядли. PNG ща много где юзается. Ну и без zlib он как бы ни о чем. Есть минимальные генераторы нежатых версий без этого, но вот прочитать произвольный png без zlib таки будет обломно.
> tiff поддержка zlib/lzma/zstd как раз опциональная,
Настолько же как в PNG. Вы можете записать PNG без сжатия (некая кантата с чексуммами все же будет все-равно, но при желании минимальная генерация PNG решается без zlib в зависимостях).
А если произвольный файл захотеть открыть - и там и там *может* (но не обязан, я нежатые PNG и в диком виде встречал) быть пожат zlib. И если это было так - ну вы и обломаетесь. Чем облом в одном и другом случае так уж отличается?
> я тут рассматриваю только обязательные зависимости. По остальному мне нечего сообщить.
Возможно скроить нежатый png без zlib в обязаловку. Ну, примерно как нежатый тифф. И прочитать его тоже без zlib соответственно.
brotli почему-то до сих пор по умолчанию нету в nginx, и многие забывают его поставить.
Про бесплатность трафика не соглашусь, это бесплатно только для пользователя и для сайтов с трафиком ≤1ТБ (обычно до 1 ТБ бесплатно у многих хостингов).
На amazon aws 1 ГБ стоит $0.09 (первый 1 ГБ бесплатен). То есть 6500₽ за 1 ТБ.
На google cloud 1 ГБ стоит $0.06.
Несмотря на цены, почему-то aws много кто (вне СНГ) использует.
На digital ocean 1 ГБ стоит $0.01 (после 1000ГБ).
На hetzenr у vps после бесплатных 20 ТБ 1 терабайт стоит всего лишь €1.19. У выделенных с 10 Гбит/с после 20 ТБ так же.
На hetzner у выделенных серверов с 1 Гбит/с бесплатный неограниченный трафик.
У Селектел 1 ГБ = 1.0₽.
Кстати, безлимитный 1 Гбит/с в России находил только за 20000—25000₽ в месяц (всех обыскал).
Бротли дебильноват с архитектурной точки зрения, т.к. юзает огромный статистический текстовый словарь. Хренов на мобильных платформах и для больших бинарных файлов. Короче, это для веб-доставки HTML+JS, но не алгоритм общего применения.
Значит, ждем реализации rfc8478 в серверах и большем количестве клиентов.. Пока разве что curl поддерживает zstd http compression.
> Значит, ждем реализации rfc8478 в серверах и большем количестве клиентов.. Пока разве
> что curl поддерживает zstd http compression.Оно мультитридинг научилось или будем шило на мыло опять менять, как с заменов JPEG на корявый WEBP, не умеющий без прореживания цвета?
> Оно мультитридинг научилось или будем шило на мыло опять менять,КМК мультитрединг скорее к апликухе больше.
> как с заменов JPEG на корявый WEBP, не умеющий без прореживания цвета?
Ничего страшного, AVIF их всех зохавает. Там это, кажется, учли. А так прикольный формат - даже, вот, анимации есть с неких пор. Но софтом поддерживается охренеть как: ffmpeg может выдать анимированный webp (да, так можно). Но вот проигрывать его или юзать как input не умеет. Write-only формат!!!1111 который понимается только хромом и, вроде, совсем новыми лисами с недавних пор. Остальной софт не одупляет, так что отредактировать это - ну, ой.
> Ничего страшного, AVIF их всех зохавает.Да вообще не факт. Критически важно только для CDN, где уменьшение трафика картинок на 30% может быть актуальным. С другой стороны, на пережимание там в несколько раз больше выч. ресурсов тратиться будет. Эл-во вроде сильно дешевле не становится.
> Да вообще не факт. Критически важно только для CDN, где уменьшение трафика
> картинок на 30% может быть актуальным. С другой стороны, на пережимание
> там в несколько раз больше выч. ресурсов тратиться будет. Эл-во вроде
> сильно дешевле не становится.Кроме этого страницы еще быстрее грузиться видите ли будут. Особенно актуально вон тем мобильным юзерам на каком там еще GPRS который едва достреливает.
А что меньше батарею жрёт? Аппаратный декодер JPEG или AVIF, который есть у... скольких процентов?
> А что меньше батарею жрёт? Аппаратный декодер JPEG или AVIF, который есть у...
> скольких процентов?Декодирование картинок обчыно не является сушественным процентом времяпровождения системы, по поводу чего я готов поспорить с тем что этот вопрос вообще достоин внимания. Ну разве что какую-нибудь огроменную мегаанимацию на дофига мегов декодировать (я не смотрел сделали ли в спеках AVIF анимации). Но это уже экзотика. В всех остальных случаях это не особая проблема.
А вот пока юзер будет туповэйтить загрузки картинки, как минимум он будет в экран пялиться, и светящийся экран энергию совершенно точно жрет. И радио жрет пропорционально объему прокачаного.
В общем имхо это актуальнее для видео AV1, вот там без хардварного кодека на высоком разрешении проц уже поднапряжется пожалуй. Особенно мобилочный.
> Декодирование картинок обчыно не является сушественным процентом времяпровождения системыДекодирование сжатого потока тоже не является, но его одноко же зачем-то оптимизируют (про это же новость?)... и, не стоит забывать про серверы, эти картинки кто-то же ещё сжимает и аппаратных кодировщиков на серверах вроде ещё не придумали. Во сколько раз тормознее AV1 в сравнении с libjpeg-turbo?
> Декодирование сжатого потока тоже не является, но его одноко же зачем-то оптимизируют
> (про это же новость?)...Когда у тебя 10 000 юзерей и им надо пожать ответ сервера - вот тут скорость уже начнет интересовать. Как и при распаковке 100500 гигов, ну там бэкапа какого-нибудь допустим.
> Во сколько раз тормознее AV1 в сравнении с libjpeg-turbo?
Да пофиг имхо - юзер файл будет дольше искать чем он кодироваться будет, так что не особо крутая проблема. Вот с _видео_ это уже да, AV1 таки неспешный. Впрочем, гитовую версию на эту тему пиляют жестко и разогнали основательно. Жмет то плотно! Бандвиз экономить ессно охота.
> Когда у тебя 10 000 юзерей и им надо пожать ответ сервера
> - вот тут скорость уже начнет интересовать. Как и при распаковке
> 100500 гигов, ну там бэкапа какого-нибудь допустим.Так об чём и речь я вёл.
>> Во сколько раз тормознее AV1 в сравнении с libjpeg-turbo?
> Да пофиг имхо - юзер файл будет дольше искать чем он кодироваться
> будет, так что не особо крутая проблема.Страдания на тему "я видосики посмотрела 15 минут и мой телефон стал горячим, это нормально?", а потом "через n-месяцев у него корпус треснул от вздувшейся батареи" ты ещё не слышал? Современные телефоны вообще стали высокотехнологичным неремонтопригодным ненадёжным мусором. Даже тот же размер лопат — "берите больше, чаще будете из рук ронять, мы же этому только рады". Да не надо мне про гориллы лечить, корпус разлетается чаще, я тут эту драму лично наблюдал у сестры - третья лопата за год, все относительно верхнего диапазона от одного южнокорейского производителя. Уже не выдержал, когда попросили через две недели после предыдущего опять данные перенести и сказал, что "сколько ты ещё их бить будешь? Под твою руку максимум 5 дюймов". Вот и программисты аналогичным дрочерством занимаются. Куда вы гоните этот зоопарк новых форматов, даже лучшая половина которых никогда не будет аппаратно реализована?
> Так об чём и речь я вёл.Ну так потому корпы и пилят сабж.
> Страдания на тему "я видосики посмотрела 15 минут и мой телефон стал горячим, это нормально?",
Он греется и еще по over 9000 поводов. Плюс-минус 1 пофиг. Но вы как раз можете выкинуть ваш одноразовый крап и купить новый, такой же одноразовый, с аппаратным декодером. Производители железа одобряют.
> а потом "через n-месяцев у него корпус треснул от вздувшейся батареи" ты ещё не слышал?
Бедные хомяки, накупили одноразовую гадость с спайварью и еще чем-то недовольны. Айда за новым, зря чтоли батарею несменную делали?! Но вы ж хотели чтобы это бумажное фуфло гнулось о ж...у в заднем кармане - ну и получайте. Заодно как раз декодер в новом аппаратный будет, спрашивайте в аптеках...
> Современные телефоны вообще стали высокотехнологичным неремонтопригодным ненадёжным мусором.
А это не те ли пользователи, покупающие всякий шит и ставящие кривые поделки от вебмакак этому способствовали?
> Даже тот же размер лопат — "берите больше, чаще будете из рук ронять, мы же этому только
> рады". Да не надо мне про гориллы лечить, корпус разлетается чаще,Горилы тоже ухитряются раскокать. Физику не на...шь. Если нечто стекло, оно таки относительно хрупкое. А, вы хотели дисплей хитрой формы, с заподвыподвертом? Может еще и оригинальный? Вот и заплатите за него 50% нового девайса. А кули - такую дисплейную сборку только производитель аппарата и умеет.
> Куда вы гоните этот зоопарк новых форматов, даже лучшая половина которых
Ну как бы сейчас у нас вообще нет формата видео который все могут без проблем жрать. Мы не можем просто выложить мувик в интернет и чтобы его люди посмотрели. Патентованые алго не катят, браузероклепалы патенты оплачивать не хотят.
> никогда не будет аппаратно реализована?
В случае AV1 - вон та куча производителей железа вписались в проект не для красоты. Спецом для них есть забавная опция сборки - RTC (real-time вариант кодека). Там забавные ограничения. Типа плавучку не использовать, RAM не жрать, и вообще. Догадываешься почему? Этот вариант подразумевает транстялцию в аппаратный блок. И уже есть чипы с поддержкой AV1. Да что там, даже новые десктопные видяхи. И нвидия и амд. Интель тоже вроде в новых процах сделал. Зря они чтоли туда вписались?
> Бедные хомяки, накупили одноразовую гадость с спайварью и еще чем-то недовольны.Давай, в студию модели без спайвари, милый.
> В случае AV1 - вон та куча производителей железа вписались в проект не для красоты.
Про него я даже не сомневаюсь. Линуксоидам же опять страдать 10 лет без аппаратной поддержки. Я уже не говорю о том, что даже сейчас кодирование готового видосика зачастую дольше монтажа идёт.
> А это не те ли пользователи, покупающие всякий шит и ставящие кривые поделки от вебмакак этому способствовали?
А писатели кода кто? Тут половина анонимусов вебмакакингом занимается.
> Давай, в студию модели без спайвари, милый.Nokia N900 (из винтажных), motorola droid если maemo leste вкорячить (помощнее, клава лучше), pinephone (из более новых)... ах, не хомячненько? В фантик не завернуто? И вообще может повозиться потребоваться? Ну пардон, все и сразу - не бывает! А хорошего - понемногу. Ну а вы в вашем праве бегать с своим цифровым ошейником и радоваться автоматическому штрафу по геолокации, или что вы там предпочитаете. Папуасы с блестящими бусами и тифозным одеялом от "доброго" белого человека.
> Про него я даже не сомневаюсь. Линуксоидам же опять страдать 10 лет
> без аппаратной поддержки.Да мне класть, на десктопе системный проц 1080p жует на раз, на ноуте 720p с ютубовским битрейтом тоже катит. А если аппаратную поддержку приспичит так что вот прям спать не смогу, амд уже это вроде пилит как раз. Ну, вот, GPUшку новую амдшную куплю тогда. Пока лениво - и так играется, а для остального и того что есть хватает выше крыши.
> Я уже не говорю о том, что даже сейчас кодирование готового видосика зачастую
> дольше монтажа идёт.Так это ж не я его кодирую а компьютер. Раньше сроду на ночь оставляли перекодирование на ночь, я и сейчас не обломлюсь batch в фон отправить, а закончится - ну, когда-то закончится, какая мне разница, я его караулить не собираюсь все-равно. Это именно плотное "финальное" сжатие, когда хочется потом это выложить и смотреть с маргинальным битрейтом и проч.
> А писатели кода кто? Тут половина анонимусов вебмакакингом занимается.
Ну так за что и кому платите деньги - то и получаете. Вас никто с ножом к горлу не может заставить юзать вон тот шит на электроне. Если его снести к хренам - авторы хрен оспорят. Но вы х хаваете... а раз пипл хавает зачем напрягаться с качеством программ больше? А, вы не эксперты, блаблабла? Ну вон автомобиль себе так покупайте, у мутного типа, с прогнившими порогами, но ща краской подмалюем и будет как новый.
Да-да, ты ещё не забудь вспомнить первый линуксофон. Где-то у меня валяется, так ни раз и не звонил через него толком. На разработку прошивки забили, разрабов фактически кинули. Там ни спайвари, ни рабочего софта не было.
> Да-да, ты ещё не забудь вспомнить первый линуксофон. Где-то у меня валяется,
> так ни раз и не звонил через него толком. На разработку прошивки забили,
> разрабов фактически кинули. Там ни спайвари, ни рабочего софта не было.А какое-нибудь Maemo не только живое и софт до сих пор обновляется, но и вон там в сторонке Maemo Leste прикольный народ пиляет. А кто там кого кинул можно еще поспорить, глядя на то как мусорное ведро лихо "бэкапит" пароль от точки доступа на свой сервак, а эпл вообще неюзабелен без активации. О том что у них тотал контроль и говорить неудобно. Захотят да и выключат всем неугодным ифоны к хренам. Они там единственная и непререкаемая ауторити, а остальные как максиуму папуасы с иллюзией контроля над происходящим. Если кому нравится вот так - это его право, но тогда чего ныть что начинают откровенно держать за дурака? Денег много не бывает, так что лоха логично доить комплексно. Так что незаменяемая батарейка - мастхэв! А крякнутый при ее опухании экран - фича :)
Avif шляпа с любой стороны -- дефективный формат исключительно для экономии трафика на мобильниках. Для сжатия изображений vp9/av1 и h265 подходят ещё меньше vp8(чёртовы лестницы на градиентах!). Я видел текущие результаты jpeg-xl, и похоже он всех захавает. Потому что по качеству картинки он намного выше jpeg и не имеет артефактов вносимых видеокодеками. А размер файла меньше. Не "отличить от оригинала" будет на 25% меньше чем у жпег (у жпег это около 50% от лосслесс), так ещё и мусор весь скроет.
> Avif шляпа с любой стороны -- дефективный формат исключительно для экономии трафика
> на мобильниках. Для сжатия изображений vp9/av1 и h265 подходят ещё меньше
> vp8(чёртовы лестницы на градиентах!).Не догоняю какие к тому фундаментальные предпосылки. У av1 самого по себе очень крутое и сильное кодирование, и он умеет и без subsampling и high-bd, так что лестницы быть не обязаны.
И у него есть 1 жирный плюс: либа для декодирования по сути уже в браузере.
> Я видел текущие результаты jpeg-xl, и похоже он всех захавает.
Когда и если - тогда и поговорим. Для него еще либу отдельно надо переть. Тогда как AV1 фокс и хром уже жрут и декоднуть по сути I-frame оного - им в общем то почти ничего не стоит, уже все по сути на месте. И патентами не обложено. А вот в webp был тупняк, только 4:2:2 и 8-bit, это ограничение VP8. Он другое не умел тупо.
> (у жпег это около 50% от лосслесс), так ещё и мусор весь скроет.
При том этим мусором как обычно окажутся какие-нибудь мелкие детали. Потом еще окажется что дятлы из jpeg патенты продолбали, так что в браузеры не попадет чуть менее чем никогда (ждать 25 лет всем впадлу, извините). Или до них после смачного пинка с AV1 стало доходить где все их патентных троллей видали?
Нет, "мусор" это грязные артефакты lossy-lossy кодирования, например. Vp8 вместе с ними теряет детали, да. А av1, помимо скрытия деталей, разбавляет всё жутчайшим мылом и неспособностью определить контур (что проявляется и на vp8, только куда в меньшей мере), из-за чего изображение превращается черте во что, ещё и половину цвета теряет (при этом, webp, несмотря на прореживание цвета, умудряется не потерять цвета).
> Нет, "мусор" это грязные артефакты lossy-lossy кодирования, например.У AV1 во первых артефакты очень не паливные, а во вторых есть lossless режим, насколько я помню. И если в VP8 радости с него сильно меньше из-за 8bit с 4:2:2 YUV т.к. это единственное что VP8 умел как формат, то AV1 в этом аспекте сильно продвинутее (это упущение еще в VP9 исправили).
> Vp8 вместе с ними теряет детали, да. А av1, помимо скрытия деталей, разбавляет всё жутчайшим
> мылом и неспособностью определить контурСамо по себе это ниоткуда не следует опять же. Там на самом деле очень сильные алгоритмы, а какой-нибудь CDEF как раз артефакты гасит что надо. Не видев ориганил вообще хрен поймешь в чем прикол. Даже блин в стопкадре сильно сжатого видео.
> ещё и половину цвета теряет (при этом, webp, несмотря на прореживание
> цвета, умудряется не потерять цвета).Это у вас видимо что-то с конверсией в YUV и может даже 4:2:2 low bit depth если прога протупила. FFmpeg в частности этим страдает. Очень стебно получается когда _некоторые_ видео в VP9 лучше AV1 выглядят, из за вот этого вот. Но это косяк ffmpeg'а, его пока просто не обучили кодировать в HBD/sRGB colorpace/etc/etc.
Я не отрицаю, что для такого битрейта результат очень впечатляющий. Но av1 реально вымывает детали (чёрное на тёмном особенно страдает) и перерисовывает части изображения, что вкупе с неспособностью детектить края (и я так смотрю это так во всех реализациях кодеров, libaom просто наиболее эффективный и меньше артефактов выдаёт) приводит к значительным искажениям, которые сразу режут глаз. Допустим, контур чёрный, и тут полоса в 5 белых пикселей выходит за него.Ну это что такое? И это state of the art? Jctvc 10 летней давности справляется намного, намного лучше! Хотя размытая полоса светлых пикселей толщиной примерно в 0.3 пикселя есть и у него, но она хотя бы прозрачная и не такая толстая. И части изображения не перерисовываются, Тёмные участки изображения не исчезают даже на в разы меньшем битрейте…
А что касается цветов, это, возможно, из-за проблем с rgb, да. Но дело не только в ffmpeg -- libwebp от него не зависит, но у него ровно та же беда. При этом, у кодера webp есть параметр use-sharp-yuv, и вот он исправляет цвета, и, по-моему, даже избавляет их от прореживания (jpeg-xl ощутимо их прореживает с понижением битрейта). В bpg, я заметил, это искажение цветов убирает параметр colorspace=rgb (кодирует при этом аж на треть дольше), а в libaom я такого что-то не вижу. Это всё грустно, в jpeg при этом всё нормально с цветами и никаких искажений. Это не похоже на баг, поскольку проявляется во всех приложениях. На самых разных файлах, и это искажение цвета очень ощутимое.
> Я не отрицаю, что для такого битрейта результат очень впечатляющий.У него в принципе очень крутое соотношение битрейт-качество. Для этого и делался.
> Но av1 реально вымывает детали (чёрное на тёмном особенно страдает)
Весь пойнт lossy сжатия - выкинуть то что не видно без палива. Если хотелось не это - ну, av1 и в лосслесс умеет. AVIF по наследству вроде тоже. А то что размер файла не такой гламурный, ну так за перфекционизм придется платить.
> и перерисовывает части изображения,
Любой lossy кодек выдает изображение отличающееся от оригинала. Более того - весь пойнт метрик типа SSIM нечто типа количественной оценки этсамого. И вопрос соответственно сводится к соотношению битрейт/качество, которое у AV1 и AVIF весьма непозорные и покрывают всю палитру от нечто для GPRS линков до lossless. И да, вон там на скрине - муть по-моему не у AV1, а? Спасибо тому кто до ресурса по компрессии дошел и раскопал там это.
> что вкупе с неспособностью детектить края (и я так смотрю
> это так во всех реализациях кодеров,Вообще-то если кто не заметил, вон там на скрине края у AVIF проработаны сильно лучше конкурентов... у него как раз формат позволяет это все обыграть.
> libaom просто наиболее эффективный и меньше артефактов выдаёт)
Да, а еще он довольно быстро эволюционирует и если вы оценивали его эффективность по либе годичной давности то ваши бенчи давно протухли как категория.
> приводит к значительным искажениям, которые сразу режут глаз.
На вон той фотке глаз режет что угодно кроме AVIF-а, имхо...
> Допустим, контур чёрный, и тут полоса в 5 белых пикселей выходит за него.Бред сивой кобылы. В нормальном виде он на этом сделает мелкие блоки + CDEF'ом еще более правдоподобно закодит нежели остальные. Они так то все block based, а cdef очень неглупый хак от гуру в процессинге картинок типа Монти ващет, это на основе фичи из Daala, кажется, но потом еще совместно толпой доработано.
> Ну это что такое? И это state of the art?
Ну, э, как насчет воспроизводимого теста где вашу сказку увидеть вообще можно? Ну там скрин проблемы, исходную картинку, копипаст команды энкодинга? Хочу вообще посмотреть на границу 5 пикселов слепленую AV1 и посмотреть что там вообще было.
> Jctvc 10 летней давности справляется намного, намного лучше!
1) Пруф? С скринами side by side и воспроизводимым тестом?
2) Это на основе H.265? Тогда в браузерах этого не будет. Хотя вы можете оплатить всей планете патенты, но на рокфеллера вы не похожи.
3) без поддержки браузерами ради чего весь этот танец с бубном вообще?> хотя бы прозрачная и не такая толстая. И части изображения не
> перерисовываются, Тёмные участки изображения не исчезают даже на в разы
> меньшем битрейте…Я больше смотрел на артефакты H.265 - и ничего радующего глаз не заметил. На жестких битрейтах AV1 менее погано выглядел на мой вкус. И, главное, браузерами игрался. Формат не играемый в вебе вообще волнует только варезников.
> А что касается цветов, это, возможно, из-за проблем с rgb, да. Но
> дело не только в ffmpeg -- libwebp от него не зависит,Libwebp by design умеет кодировать только в intra-VP8. Со всеми лимитами того формата.
> но у него ровно та же беда.
А VP8 внезапно ничего кроме YUV 4:2:2 и не умел никогда. На уровне своих форматов, о великий гуру! Собссно в AVIF это вроде бы учли. Как и в VP9/AV1, где в формате есть HBD и варианты без субсэмплинга и даже с sRGB. Для VP9 в ffmpeg это работает, для av1 вроде не прикрутили еще, но родной кодер av1 все это ессно умеет.
Грубо говоря фичи формата одно, их прикрученность к ffmpeg и прочему софту - другое.
> При этом, у кодера webp есть параметр use-sharp-yuv, и вот он исправляет цвета, и, по-моему,
> даже избавляет их от прореживанияКак он их может избавлять если VP8 отродясь ничего кроме YUV в 422 не умел? И sRGB ему не светит, что, таки, обречено несколько похабить комповые скриншоты с мелким цветным контрастным текстом и проч. Хотя на фотах особенно не видно, собственно, 422 делался телевизионщиками под real world контент.
> (jpeg-xl ощутимо их прореживает с понижением битрейта).
Чудес не бывает, квантизация грубеет.
> В bpg, я заметил, это искажение цветов убирает параметр colorspace=rgb
Сразу видно computer-generated картинку. Которые, для начала, не основной юзкейс для photo-realistic кодеров. Извините, всех напрягают огроменный фоты которые юзери льют, а не скрины полутора хикки-извращенцев с какой там еще мангой.
> такого что-то не вижу. Это всё грустно, в jpeg при этом всё нормально с цветами
> и никаких искажений.На самом деле зависит от. Варианты кодирования без subsampling появились сильно опосля и опциональны, а на размере как вон там AV1 был он вообще выглядит как непонятная куча квадратиков.
> Это не похоже на баг, поскольку проявляется во всех приложениях. На самых разных файлах, и
> это искажение цвета очень ощутимое.На вон той леночке это почему-то вообще сосем не заметно. Хикки что-то явно не договаривает.
Субсамплинг вообще ни при чём, и, уж тем более, если исходное изображение и так 420. Слишком много цитат, и ты неправ практически в каждой из них, вообще непонятно к чему ты это всё написал. Ты нормальный? Сними розовые очки. Как vp8 качественно не кодирует, так и vp9 кодирует ещё хуже, а av1 это развитие vp9. У libaom версия 2020-11-25 v2.0.1 и в прошлый раз было ровно то же самое, вряд ли что-то изменилось.Короче
https://i.postimg.cc/3RvRD3Hw/out1.png
https://i.postimg.cc/Cx9pnkMj/out2.pngРазмеры не может показать для bpg и jxl, но по размерам
bpg27~avif60
bpg35~avif30
> Субсамплинг вообще ни при чём, и, уж тем более, если исходное изображение и так 420.Тогда и терять нечего, по большому счету.
> Слишком много цитат, и ты неправ практически в каждой из них, вообще непонятно
> к чему ты это всё написал.Забойный аргумент правоты, что сказать.
> Ты нормальный? Сними розовые очки. Как vp8 качественно не кодирует, так
> и vp9 кодирует ещё хужеВопрос про нормальность возвращается автору. Если у вас VP9 кодирует хуже VP8 вы делаете что-то не так. Про tune-content=screen для вашей хикки-гадости вы тоже видимо не доперли, очень типично для "гуру кодирования" с характерным матерьяльцем.
> а av1 это развитие vp9.
С добавлениям из thor и daala а также достаточно уникальными технологиями типа CDEF, ранее вообще нигде не существовашими.
> https://i.postimg.cc/3RvRD3Hw/out1.png
> https://i.postimg.cc/Cx9pnkMj/out2.pngГде командлайны? Ну и я угадал - хикки с их "видео" матерьяльцем детектятся влет. И хикки не пробовали VP9 и AV1 врубать режим для screen контента? Ваша хрень - вообще не видео по большому счету. Рисованая или computer-generated анимация - да. Видео - черта с два! Нормальные люди под видео подразумевают нечто вообще совсем другое.
И эффективность сжатия этой лабуды по большому счету интересует полутора хикки с варезом. Это точно не основной контент для кодеков. Мне например плевать как он жмется.
> Размеры не может показать для bpg и jxl, но по размерам
Давайте в следующий раз обсуждать _видео_ кодеки на примере _видео_? А photo-realistic кодеки - на фотографическом материале? А то как пример леночки показал там как раз таки полный порядок. А ваши дерганые анимашки - не фото и не видео, для начала. Так, графика какая-то.
Ну т.е. оскорбления -- это всё, на что ты способен? Ясно, понятно. Я показал тебе, что видеокодеки полное и абсолютное уг для графики (и это только маленький пример, есть куча других) и ты начал маняврировать. Видео это не только фильмы которые можно замылить (а это всё, чем сегодня занимаются это кодеки даже на высоком битрейте), но и CGI. Да и для фильмов они уг. Да, VP8 тоже меньше мылит видео на достаточном битрейте, лестницы градиентов на vp9 никуда не делись, а av1 выглядит всё так же убого в сравнении с h265 (который тоже мыло ещё то из-за того же sao) и h265 при этом выдаёт максимально чётенькую картинку при появлении мелких деталей в кадре. Требования к битрейту при этом взлетают до небес, но ни в одном из кодеков я ещё не видел такой чёткой картинки в фильмах -- фильм был пятилетней давности, снятый на 4к (ALEXA XT по-моему, старая камера уже тоже). Этот кодек позволяет в полной мере использовать высокий битрейт. Гугло же думает только об экономии и его не заботит комфорт зрителя, как и нетфликс и остальных шилей. Все пользователи уже отстегнули роялти мпегу и по несколько раз в каждой железке, ничто не мешает им использовать ИП. Но жадные нетфликсы жлобятся перечислять гроши за качественно разработанный кодек (при этом у нетфликса качество от h265 заметно выросло из того что я видел).
есть еще совсем новый jpeg xl
> есть еще совсем новый jpeg xlИ что там с патентами? После истории с gif и патентами на LZW, когда пришлось проблему срочно затыкать всякими libungif (помните такой? Я вот да, пишем формально gif, но не сжимаем) и изобретением png, дураков связываться с насмерть запатентованными алгоритмами с требованием платить куче консорциумов бабло за каждую релизацию кодера или декодера как бы нет. Т.е. там где необходимо свяжуться, но в свободном вебе - обойдутся.
Jpeg 2000 кстати так и не взлетел, почему Jpeg XL должен? Проще взять AVIF, там ксть и нормальные свободные реализации декодера (libaom), гарантии отсутствия проблем с патентами и прочее.
Глупости не говорите. Jpeg2k это тоже вейвлет кодирование, оно очень неплохо работает для сжатия без потерь, но и только. Jpeg xl позволяет делать очень сильное и качественное сжатие без искажений, avif это только искажения и потеря деталей. На низких битрейтах это выгодно, да. Но у нас до сих пор нет кодека для качественного кодирования, выбор до сих пор между jpeg (при всех его недостатках) и png (при всех его недостатках), и, кроме того, jpeg при кодировании lossy-lossy не очень хорошо справляется.
> Глупости не говорите. Jpeg2k это тоже вейвлет кодирование, оно очень неплохо работает
> для сжатия без потерь, но и только. Jpeg xl позволяет делатьЭто совсем не то, что заявляли авторы 2k и какие картинки в примеры они выводили. Но индустрия не взяла.
Ну в 2k хотя бы DCT, а не вейвлеты. Я помню кучу экспериментальных кодеков на вейвлетах, в 200х годах это была очень популярная тема - в т.ч. видео кодеки экспериментальные были. Не взлетел ни один. Да, блоки явно не лезут, а что делать с потерей четкости - так и не нашлось решения. Артефакты вейвлет-сжатия на практике оказались менее приятными.
> очень сильное и качественное сжатие без искажений, avif это только искажения
> и потеря деталей. На низких битрейтах это выгодно, да. Но уА почему вы так считаете? Повысьте битрейт. Как раз AVIF отлично масштабируется вверх. Это в Jpeg XL чуть битрейт понизишь, и артефакты глаза колят.
https://encode.su/attachment.php?attachmentid=7765&d=1594548444
Вот пример сравнения с нормальным битрейтом и пониженным. AVIF хорош всегда, на низком битрейте чуть мажет. JPEG XL... это просто ад какой-то, если битрейта чуток зажать.
> нас до сих пор нет кодека для качественного кодирования, выбор до
> сих пор между jpeg (при всех его недостатках) и png (при
> всех его недостатках), и, кроме того, jpeg при кодировании lossy-lossy не
> очень хорошо справляется.Вот то что lossy-lossy кодирвание в JPEG XL хорошее, это я знаю: но это не то чтобы так уж востребовано, просто авторы специально заточили его под такой юзкейз, чтобы показать, что если им пережать 1000 раз подряд, качество почти не изменится. Но это.. не очень жизненный пример, на самом деле.
>не очень жизненный примерНе только в себя, любое лосси перекодирование выглядит очень хорошо. Если не жабить битрейт. Если жабить, то оно выглядит кошмарно (я надеюсь, над этим ещё поработают) в сравнении с avif(libaom) и в частности в сравнении с bpg(jctvc). А это значит, можно уже убитый жпег перекодировать в жпег-хл без артефактов, можно при этом сделать и ресайз (более качественный). Чисто практически bpg очень значительно превосходит всех конкурентов как в плане сжатия файлов, так и в плане качества результата. Он нормально определяет края (удивительно), сохраняет цвета при работе в rgb (у его кодировщика есть такой параметр), позволяет различные варианты субсамплинга. На очень сильном сжатии (avif_q70-bpg_q25) теряет намного меньше деталей и ближе к оригиналу, меньше искажений. После этого на avif смотреть тошно, но увы, webp ещё хуже (на любом битрейте).
И это>AVIF хорош всегда,
Нет, он артефачит и не может нормально детектить края, перерисовывает части изображения, портит цвета. На любом битрейте. Разве что с градиентами получше вебп. Жпег-хл лишён всех этих недостатков, хоть и не позволяет жабить битрейт.
> Нет, он артефачит и не может нормально детектить края,Как раз технологически там для этого очень даже приличные вещи типа CDEF есть. И никаких проблем проработать границы нет, блоки переменного размера.
А чтобы lossless - там вообще +1 слой residuals (ошибок) кодируют относительно prediction. Файл ессно крупнее становится.
> перерисовывает части изображения, портит цвета.
Совершенно не обязано происходить. Скорее неоптимальности реализации кодека или того как либу подцепили.
> На любом битрейте. Разве что с градиентами получше вебп.
> Жпег-хл лишён всех этих недостатков, хоть и не позволяет жабить битрейт.Если он не позволяет жабить битрейт, зачем он тогда? Пойнт сжатия с потерями чтобы было мелким но почти как оригинал. Иначе смысл?
Файл и получается более мелким. Вот на давешнем примере:avif100=900kb
avif90=225kb (меньше нет смысла, но все дефекты за исключением адового замыливания проявляются и на q99)
jpeg95=430kb
jpegxl100=700kb
jpegxl96=295kb
jpegxl95=259kb (есть едва заметное прореживание цвета)
webp95=305kb (и скажем честно он выглядит не сильно лучше jpeg90(332kb))Пока, к сожалению, совершенно не вариант, и для lossless кодирования avif тоже не подходит. Это libaom, остальные в раза 2 хуже.
Avif99=402kb кстати, но реально он выглядит хуже максимально (без видимых искажений, на исходном файле) пережатого jpeg с 380kb. Т.е. лучше он уже просто не может сам по себе.
> Файл и получается более мелким.Але, гараж, если хочется качество сравнивать, в lossy варианте размер файлов должен быть сравнимый. Иначе это сравнения шила с мылом.
Как бы размер файла при lossy - "любой". От почти ноль до довольно жирного. Чем больше выкинуто тем меньше файл и хуже качество. И очевидно сравнивать разные кодеки имеет смысл только подогнав размер картинки до сравнимого и сравнив качество. Или как вариант пытаться догнать метрики до одинаковых (скажем одинаковая ошибка SSIM) и сравнить при этом размер файлов.
Если что - абстрактное качество=95 в нотациях одного и другого кодека вообще не обязано совпадать. Разработчики под этим могут иметь в виду что угодно и как оно там на внутренности действует вообще зависит от причуд конкретных разработчиков. Но вон те соотношения иллюстрируют соотношения сил, их в том виде не обманешь.
Очень красноречивая картинка, спасибо. Avif рулит.
> Очень красноречивая картинка, спасибо. Avif рулит.Очень красиво обмакнули в ушат того умника с его раржыпегом. Было бы странно если не рулил с таким набором технологий. А *peg в последнее время только ублажением патентных троллей занимается.
При том секрет обмакивания раскрыт. Умник тестил фото и видео на рисованых анимашках. Ничерта умнее этот чудак не придумал.
>> Значит, ждем реализации rfc8478 в серверах и большем количестве клиентов.. Пока разве
>> что curl поддерживает zstd http compression.
> Оно мультитридинг научилось или будем шило на мыло опять менять, как с
> заменов JPEG на корявый WEBP, не умеющий без прореживания цвета?Это вопрос клиенту, использующему библиотеку (вы ведь понимаете, что в библиотеке автоматически активировать треды как бы нельзя)?
Штатная реализация zstandard умеет параллелится из коробки, посмотрите zstd -T. Отлично работает, напр. в 8 тредов реально почти в 8 раз быстрее.
Для декомпрессии параллельность не требуется, там и так 1 ГБ/с скорость разжатия. Быстрее только LZ4/LZO...
> Для декомпрессии параллельность не требуетсяСмеялся...
> Штатная реализация zstandard умеет параллелится из коробки
А вот моя ядерная реализация из ядра линукс не параллелится. Шта делать прикажете?
В ядре очень уж протухшие версии, у меня вот тоже вопрос -- почему?
> В ядре очень уж протухшие версии, у меня вот тоже вопрос --
> почему?Там не протухшие, а собственные реализации. Как и всего остального, например тех же алгоритмов шифрования. Т.е. openssl может конечно и свой алгоритм использовать, но куда интереснее пробросить ядерную реализацию через драйвер с аппаратной поддержкой. Собственно, если память не изменяет, даже таких существует два метода проброса.
Очень плохо. Пока апстрим уходит на десятилетия вперёд (а также исправляет ошибки, что немаловажно), в ядре будет оставаться багованная копия доисторического кода.
> Очень плохо. Пока апстрим уходит на десятилетия вперёд (а также исправляет ошибки,
> что немаловажно), в ядре будет оставаться багованная копия доисторического кода.Скорее наоборот. Там будет самая вылизанная. Твой уход на десятилетия вперёд никому в деле архивирования вообще ни разу не упёрся. Там нужны стабильность формата, надёжность реализации и оптимизированность уж в последнюю очередь. А фрагментированность того же LZMA/LZMA2 стала ярким примером цирка с конями про "уход на десятилетия без оглядки назад".
Long таки даёт ощутимую экономию раза в 3 - например, из файла 2.6гб получается файл 210мб, у стандартного zstd3 файл 428мб, у lzma9/7zultra файл 370мб (сжимает долго, дедуплицирует только то что рядом, копии файлов будут сжаты несколько раз). Умолчательной троечки (которая быстрая) достаточно чтобы сравниться с lrz и получить файл ещё меньше чем у lrz-lzma9 на типичном использовании (220мб). В частности, этой экономией можно воспользоваться в каких-нибудь initramfs (файлы по гигабайту и больше) или squashfs (медленно работает с lzma9 и сжатие очень плохое получается). У фекбука огромные ДЦ, он, также как и гугл, использует кастомное ПО и кастомные ядра с кастомными параметрами конфигурации. Вопросы формата при внутреннем использовании никого не интересуют, важна только эффективность. Если образ будет в 5 раз меньше, он будет быстрее передаваться и быстрее загружаться, этого достаточно, особенно, при таких объёмах. Эффективность повышается. Бонусом он ещё и меньше места займёт на стораджах. И это касается всех данных.
Как я понял, long режим с расширенным окном позволяет практически моментально дедуплицировать и пережать 2гб данных. Вот я сжимаю файлов на 4.7гб, zstd достаточно быстро выплёвывет 2.160гб файл, lrzip достаточно долго пакует, но выдаёт файл 1.175гб, при этом zpaq (не твиканый особо -- я не разбирался в параметрах) даёт 1.330гб и lrz-lzo 1.522гб. Неплохо бы zstd запихнуть в lrz, интереса для. В оригинале это был rar на 2.5гб.
> В ядре очень уж протухшие версии, у меня вот тоже вопрос -- почему?В ядре сильно другие constraints. Вас же не устроит если ядро при каком-нибудь ауте памяти вылетит как апликуха, с вообще всем, правда? И так далее. Это и много чего еще заставляет ядерщиков юзать довольно кастомные реализации, не сильно похожие на general purpose либы предполагающие что вокруг есть операционка с типовыми facilities. А если это операционка как раз, унутрях кернела стандартного libc например ни разу не обязано быть, etc.
Из-за подобной нерасторопности страдают пользователи. Причём, вполне вероятно, сам фейспук использует собственные патчи с более свежей версией.
> Из-за подобной нерасторопности страдают пользователи.Ничего они не страдают - кернел threaded как черти что.
> Причём, вполне вероятно, сам фейспук использует собственные патчи с более свежей версией.
Это врядли. Такие вещи вне апстрима таскать чревато кучей грабель. Кернель - не гребаная юзермодовая апликуха, и наворачивать там такие facilities в обход апстрима весьма грабельно.
>> Для декомпрессии параллельность не требуется
> Смеялся...Ну хорошо, вы много знаете случаев, когда 1 ГБ/с скорости недостаточно?
>> Штатная реализация zstandard умеет параллелится из коробки
> А вот моя ядерная реализация из ядра линукс не параллелится. Шта делать
> прикажете?Ну так вы же не можете затащить полноценную библиотеку в ядро. Все будут сильно против, и будут правы. там место урезанной реализации. А треды.. наверное, можно добавить, если это кто-то сделает. Главное что сам формат и алгоритм позволяют.
>>> Для декомпрессии параллельность не требуется
>> Смеялся...
> Ну хорошо, вы много знаете случаев, когда 1 ГБ/с скорости недостаточно?У меня домашний массив больше 400 выдаёт (обычный домашний NAS на базе старого пролиант микросервер). Упирается именно в скорость сжатия (ядерная реализация zstd), которое я использую в целях экономии места (те же фотки-равки на процентов 15 поджимаются, а это уже десятки гигов) и просто из-за того, что гигабитка банально у меня не тянет даже такой поток. Перейду на новое железо и там уже, думаю, это будет реальной скоростью по кабелю. Про промышленное применение я вообще молчу.
> Ну хорошо, вы много знаете случаев, когда 1 ГБ/с скорости недостаточно?Возмём средний ссд, сколько там, 3ГБ/с? А нет, уже 5 ГБ/с (чтение и запись), 15ГБ/с в 2019 только продемонстрировали. Производительность имеет значение.
>> Ну хорошо, вы много знаете случаев, когда 1 ГБ/с скорости недостаточно?
> Возмём средний ссд, сколько там, 3ГБ/с? А нет, уже 5 ГБ/с (чтение
> и запись), 15ГБ/с в 2019 только продемонстрировали. Производительность имеет значение.Справедливости ради, скорость интерфейса и скорость работы даже в режиме линейного чтения-записи далеки от озвученных цифр.
Скорость ограничена только скоростью памяти, в 4 канальном режиме это порядка больше 100, и нынешние процессоры уже позволяют использовать память в 8-канальном режиме. Скорость интерфейса 10 летней давности именно 15GB/s, нынешняя ревизия интерфейса позволяет что-то там порядка 256GB/s. Цифры не всегда соответствуют по другим причинам. Optane там ещё жив?
> Смеялся...А теперь наша очередь. Обнаружен эксперт в алгоритмах от вебмакакинга!
Как мистер эксперт думает, во что ща упирается распаковка хорошего быстрого алго? А вот и неправильно! В RAM и cache miss. Проц достаточно быстро ворочается, хорошее алго на распаковку достаточно легкое. И все упирается в то что проц RAM ждет дофига если cache hit не случился. Откуда и дикий boost по скорости вон у того чудака с 3% ratio. Там входной поток почти не выносит кэш, все доступы к нему без cache miss - вот вам неиллюзорная накрутка перфоманса. На более вменяемых данных тот эксперт бенчмаркинга ессно получит совсем другие цифры и соотношения.
Что ожидается с многопоточности? А, загадить кэш кучей инстансов этого хлама, с отдельными данными и обвесом, и еще переключениями контекста почистить его основательно? А это точно именно профит скорости даст, учитывая что именно проц оно и так не туповэйтило? Собственно одна из причин по которой хрустикам на декомпрессии не светит чуть менее чем нихрена...
По той же причине ассемблерщикам слабо побить LZ4. А, собственно, в каком месте они профит могут извлечь? :)
> А вот моя ядерная реализация из ядра линукс не параллелится. Шта делать прикажете?
На распаковку это пофиг относительно. А так кернел умеет же в воркеры. И какой-нибудь btrfs по дефолту их по числу ядер вешает, например. Там и на сжатие и не только хватит. Это же касается и прочих ядерных facilities, ядро давно уже threaded как черти что.
> Что ожидается с многопоточности? А, загадить кэш кучей инстансов этого хлама...Давай начнём с малого. Как кэш делится между ядрами?
> Давай начнём с малого. Как кэш делится между ядрами?А вот это уже зависит от... довольно много чего. Бывают разные реализации, уровней кэша бывает несколько и проч. Вы захотели прибиться на гвозди к какой-то одной конкретике?
В любом случае, конкуренция нескольких потоков за дефицитный ресурс (RAM bandwidth) очень врядли может улучшить состояние дел. Вот испортить лишним оверхедом, дополнительными переключениями контекстов и вымыванием кэша - почему бы и нет?
По твоей теории, если всё упирается в ОЗУ, никакого проку от распараллеливания быть не должно, а он есть...
> По твоей теории, если всё упирается в ОЗУ, никакого проку от распараллеливания
> быть не должно, а он есть...На распаковку, именно современного быстрого алгоритма - не особо. Если это нечто неоптимальное и тормозное унутрях - еще может быть. Но всякие LZ4 и прочие ZSTD сделаны так чтобы минимизировать это, будучи как можно быстрее на распаковку.
Ну и вообще - окружения разные бывают. Бредить многоядерностью круто. Но если я допустим кернель сжал ZSTD, оно запускается на вполне конкретном проце. Одном. И распаковывается там же. И хренли толку с той кучи ядер ЕСЛИ ОНИ ЕЩЕ НЕ ЗАБУТЯВЛЕНЫ?! Поэтому если алго тормоз - я буду туповэйить декомпресс кернеля. На каком-нибудь LZMA это вполне заметно даже на x86, а на ARM уже просто назойливо и неприятно. Но возможно вам больше нравится пыриться на графики, туповэйтя загрузку своих телевизоров и что там еще?
Ближе к телу, меньше абстрактных измышлений, разговор был конкретно про ядерную реализацию zstd.
> Ближе к телу, меньше абстрактных измышлений, разговор был конкретно про ядерную реализацию zstd.Ядерная реализация используется в том числе и для распаковки кернела вроде.
> ядро давно уже threaded как черти что.Мне кажется, вы путаете воркеры каких-нибудь файловых систем, вроде той же btrfs, которая данные делит на блоки и каждый блок отдельно сжимает и, если нужно, шифрует. Я же вёл речь про реализацию самого алгоритма.
> Мне кажется, вы путаете воркеры каких-нибудь файловых систем, вроде той же btrfs,
> которая данные делит на блоки и каждый блок отдельно сжимает и,
> если нужно, шифрует. Я же вёл речь про реализацию самого алгоритма.Сам алгоритм может, конечно, сделать то же самое по смыслу, но вообще такая функциональность не только ему нужна и подход как у ядерщиков как раз логичнее смотрится. Хотя, конечно, можно самому таскать половину функциональности операционки и либ, nih штука злобная.
Автор малость смухлевал так для повышения сжатия. В принципе это даже малость работает - ценой переноса данных заранее на клиент, в либу бротли с ее словарем. С zstd так тоже можно, как впрочем и с почти любым алго. Т.е. если zlib'у словарь заранее подпихать на стороне клиента он тоже лучше жать начнет. Но у него словарь 32 кило максимум - с современными вебмакаками это уже маловато, они либы на мегабайты хотят - у словаря склероз, сжатие страдает.
> Автор малость смухлевал так для повышения сжатия...Спасибо, кэп )))
Что значит "забывают"? Так его не поставить по-человечески. Нет в репах - ни RHEL (включая rpmfusion), ни Debian, ни прочих не-серверных дистрибутивах. Компилять из сорцов, чтобы оно потом в usr/local болталось, нормально не управлялось, забывалось, ломалось при обновлении nginx и brotli (да-да, даже в рамках стабильного RHEL нынче доступны несколько веток nginx и появляются новые мажорные релизы)? Да нах это счастье надо. Будет распространяться нормально - будут ставить.А пока текущая политика nginx "купите nginx plus, там это есть, а в обычном халявном nginx.. упс, катитесь подальше, нищебрoды" или какие-то еще причины мешают его нормально распространять штатно в дистрибутивах - так и будет.
В смысле - не поставить?! А libbrotli1 в дебиане - это чего?
> В смысле - не поставить?! А libbrotli1 в дебиане - это чего?Я не про libbrotli1, а про nginx-module-brotli. Что вам толку от либы, когда nginx с ней не собран?
Вы ничего такого не поставите из коробки, чтобы в nginx можно было поддержку brotli сжатия в дополнение к zlib включить.
Ну я для себя и клиентов поддерживаю ppa в котором вместе с nginx'ом собираю и nginx-module-brotli, и некоторые еще необходимые мне модули которые не собирают ни в родных репах nginx'а, ни в репах Debian/Ubuntu.И все ставится и обновляется совершенно штатно. При выходе свежей версии mainline у nginx обновляю пакет, дурное дело не хитрое
> Ну я для себя и клиентов поддерживаю ppa в котором вместе с
> nginx'ом собираю и nginx-module-brotli, и некоторые еще необходимые мне модули которые
> не собирают ни в родных репах nginx'а, ни в репах Debian/Ubuntu.
> И все ставится и обновляется совершенно штатно. При выходе свежей версии mainline
> у nginx обновляю пакет, дурное дело не хитроеЧто мешает выложить в апстрим дистрибутива, сделав доступным для всех пользователей дебиан, RHEL и тп? Почему же каждый для себя должен делать? Вот из таких мелочей все и складывается..
Все и выложено и доступно, я же не из воздуха собираю.
И ppa общедоступный, ничто не мешает взять и добавить его или форкнуть его и собирать самому по готовому
> Вы ничего такого не поставите из коробки, чтобы в nginx можно было
> поддержку brotli сжатия в дополнение к zlib включить.Да собссно нжинкс не настолько сложно компилится, если это ну вот реально надо. Тоже мне проблему развели.
> Про бесплатность трафика не соглашусь, это бесплатно только для пользователя и для
> сайтов с трафиком ≤1ТБА попробуй стать гуглем - и узнаешь в чем прикол.
>> Про бесплатность трафика не соглашусь, это бесплатно только для пользователя и для
>> сайтов с трафиком ≤1ТБ
> А попробуй стать гуглем - и узнаешь в чем прикол.А нам-то что с того? Попробуешь, все равно не получится.
Да и гуглю оно больше для мороченья голов менеджерам менеджерами чем для чего-то еще. Да, в абсолютных числах это милионы, зал аплодирует (премию не дадут, в гугле не принято. дадут грамоту с подписью старшего менеджера). А по факту - 4% экономии. После того как миллионы вбуханы в прогибание под себя интернета и запихивание ненужнобротли всем в задницы (это даже если предположить что труд макаки ничего не стоит, что, безусловно, неверно - с учетом того, в скольки местах ненужное пришлось внедрять, и сколько высокооплачиваемых манагеров в этом задействовали).
А планомерно убирать ненужные гигабайты js и миллиарды картиночек - нее, это вот слишком сложно, и вообще на инновацию не тянет, грамоту не дадут.
> А нам-то что с того? Попробуешь, все равно не получится.По другим причинам - ты не соберешь такую же распределенную штуку. Ну вот нет у тебя архитектов и инженеров для этого, и денег на них у тебя нет, на 10% от номинала они не пойдут к тебе. Но это другой аспект. Тем не менее, как-то вот получается что траф терабайтами оптом народ напрягает и это денег стоит. Васяны с своими несколькими тб в месяц, конечно, никого не напрягают - там какой % использования канала? Эвон сколько васянов можно оверсельнуть. Потому и "дешево". А попробуй duty ratio ближе к 100%, всегда - и тут окажется что условия уже совсем другие и стоит это эвон сколько. И тут уже вопрос сколько клиентов оно сервировать может такое.
> Да и гуглю оно больше для мороченья голов менеджерам менеджерами чем для чего-то еще.
Конечно-конечно, им больше деньги некуда девать кроме как крутым ученым и инженерам их платить. Только почему-то снизу потом ТП Митчел оказывается, полагавшая что оно вот так, а сверху - вот эти.
> менеджера). А по факту - 4% экономии.
А по факту 4% в масштабах гугла это овердохрена и вообще, если профакивать 4% тут, 4% там, то вскоре это сольется до уровня мцст какого-нибудь. Акуле, пинать #%$ на рабочем месте все горазды.
> А планомерно убирать ненужные гигабайты js
JS являет собой крайне незначительный % трафика по сравнению с ютубовским видео. А вот когда вопрос в том что мы сегодня оптимизируем, вон те 4% или вон те 0.04% - гуглменеджеры таки не совсем дятлы и могут в управление ресурсами.
> и миллиарды картиночек - нее, это вот слишком сложно,
Они работают над этим! Чему пруфом - avif. А почему им это должно быть сложно, если они весь видеокодек сделали?! Поюзать его i-frames для картинок - когда он уже написан - ни в раз не проблема.
> и вообще на инновацию не тянет, грамоту не дадут.
Тю, avif и av1 в гугле в почете.
> Или я чего то не знаюПравила русского языка, в соответствии с которым "чего-то" пишется через дефис.
>> Или я чего то не знаю
> Правила русского языка, в соответствии с которым "чего-то" пишется через дефис.Докапываться до орфографии как минимум неприлично. Это занятие для людей, у которых в жизни больше ничего нет.
>>> Или я чего то не знаю
>> Правила русского языка, в соответствии с которым "чего-то" пишется через дефис.
> Докапываться до орфографии как минимум неприлично. Это занятие для людей, у которых
> в жизни больше ничего нет.Безграмотно писать — выказывать неуважение к собеседнику. Это удел людей, которым недоставало в жизни образования, как академического, так и культурного.
Езли тобе бизграматнасть мира выглядетт выкказываньем ниуваженья ктебе, та кем ты ся мниш, интиресно?
> Безграмотно писать — выказывать неуважение к собеседнику.Ты саписетник штоли ? Нисмиши аднаклетачнае
Ну и зачем эти полумеры типа zlib-ng когда есть Zstandard? Переходите на него, а zlib оставьте в покое, как классическое решение с консервативным подходом.
Так zlib они и не трогали, в чём претензия?
Говорят что LZO очень недооцененная штука. Вот если будет что-то такое - обязательно надо попробовать. Обещают суперскоростя если коротко.
lzo все-таки не для длинной сетевой передачи, а для задачи "сжимать хоть чуть-чуть со скоростями не сильно меньше, чем memcpy". И по факту он потерял актуальность (разве что для совместимости интересен) после появления Snappy и LZ4, любой из которых работает лучше (первый в плане скорости, второй в плане сжатия).А в нишах длинных линков по сети на пятки lz4 наступает zstd с соответствующими параметрами.
LZO для несколько других задач, он скорее с LZ4 сравним. Жмет чуть получше, но и распаковывается чуть помедленнее. Как-то так. У LZ4 формат потока совсем тупой и неэффективный, зато - все для скорости распаковки. И распаковать пару гигов в секунду (!!!) - поди плохо?
Ну дык жеж
Самое главное из статьи непонятно: сжатые модным нг файлы "консервативным" zlib можно распаковать или нет? А то, может он жмёт быстро как в анекдоте про ту секретаршу, которая со скоростью 600 знаков в минуту печатает.
Прочитал то ее хоть? Сказано же - весь прирост из-за SSE* AVX2 и чего только не. А в оригинал не принимают потому что платформоспецифические инструкции и опасаются что где-то что-то под экзотику неправильно ifdef'ы распарсит и сломается.
огигиналы, наверное, про #if defined () не слышали или боятся код определения фич платформы втыкать.
> огигиналы, наверное, про #if defined () не слышали или боятся код определения
> фич платформы втыкать.Ну, понимаешь, любую фичу можно поюзать в объеме когда от своей крутизны станет плоховато. И поддержка вон тех чудесатых платформ с левыми компилерами... ух, попробуй без поллитры одуплить вообще сорец какого-нибудь LZO. Это сцуко черная магия. Но ты можешь смухлевать, попросив препроцессор прожевать тебе это. Однако без препроцессора... ммм... как тебе код состоящий из #ifdef-ов чуть более чем полностью? :)
Ну почему? Если писать красиво и грамотно - любой код читаем и понимаем. Приверы - линукс и ванговс.
> как тебе код состоящий из #ifdef-ов чуть более чем полностью? :)А внезапно! Видел скриптовый язык, написанный на препроцессорных командах! )
> Ну почему? Если писать красиво и грамотно - любой код читаем и
> понимаем. Приверы - линукс и ванговс.Просто старинные компилеры дофига не умели или страдали дурными багами и требовали дофейхоа левых костылей, оформленых ессно ifdef'ами для той особо кривой платформы. Если этим чрезмерно увлечься, как M. Oberhumer (автор LZO/ucl/upx/...) - проблема в том что ухватить общую логику кода, когда там 20 вариантов для разных костыльных обрубков ifdef'нуто прям in place - становится довольно тяжко.
Наверное одна из причин недооценнености LZO. Сам формат достаточно недурной но optimal parse под него никто не написал, видимо потому что формальных спеков нет, а одуплять по его декодеру все особенности формата несколько канительно, когда там - вон то самое.
> А внезапно! Видел скриптовый язык, написанный на препроцессорных командах! )
Это как? Он же не тюринг полный, всего лишь заменялка токенов. Хотя я на этом смог нехило развернуться, типа range-check аргументов (с оговорками), жоских вариадиков выбирающих реализацию, эффективные битовые поля, целиком pre-computed compiletime и проч (на микроконтроллерах актуально) и прочие странности, напоминающие, наверное, плюсатые классы, только все напрочь precomputed. Но скриптовый язык?! Как они это сделали? Урл?!
> прям in place - становится довольно тяжко.Зачем in place? В один хедер их все засунуть и оставить.
> Это как?
Huang A. - The Hardware Hacker. Adventures in Making and Breaking Hardware - 2017
We invented our own language to avoid
subconscious plagiarism—it’s too easy to read one piece of code and, from memory, code something
almost exactly the same. By transforming the code into a new language, we were forced to consider
the facts presented and express them in an original arrangement.
Scriptic is basically a set of assembler macros, and the syntax is very simple.
> Зачем in place?Ну, может, в случае если функция в целом одинакова для всех, но вон тем и вон этим вот этот кусок надо немного локально оверрайднуть? Как его такое "в один хедер" в этом случае?
> В один хедер их все засунуть и оставить.
В идеале - да. А реально в LZO - вон то вон счастье :). Поэтому декодер Crush умещается на экран, т.к. таким не парится. А LZO - экранов 10 странного месива, которое без препроцессинга вообще хрен одуплишь.
>> Это как?
> Scriptic is basically a set of assembler macros, and the syntax is very simple.Урла у этой штуки есть? Уже довольно интересно звучит, если они умудрились сделать что-то тюрингполное из тюринг-неполного.
> Как его такое "в один хедер" в этом случае?Случаи разные и их много, согласен. Не буду же я все варианты придумывать-перечислять )
> А LZO - экранов 10 странного месива, которое без препроцессинга вообще хрен одуплишь.
Значит, лениво писали или свитерно-бородатый однофайловый проект )
> Урла у этой штуки есть? Уже довольно интересно звучит, если они умудрились
> сделать что-то тюрингполное из тюринг-неполного.Это книга. https://nostarch.com/hardwarehackerpaperback
Нет, нет. Это лишь описательный скрипт. Просто пример того как на практике может пригодиться то, что обычно зовут не иначе чем макробесие. )
> Случаи разные и их много, согласен. Не буду же я все варианты придумывать-перечислять )А вот Оберхамер прямо примерно это в коде и сделал ifdef'ами, злыдень. Поэтому так-то либы довольно клевые, от профи к тому же. Но вот руками это трогать почему-то все сыковали. Перестарался гуру малость с винтажными экзотами :). Впрочем, эта штука в NASAвском марсоходе вроде как - и кто его знает какие там платформы актуальны, наверное и достаточно кривые и винтажные, RAD-hard чипы в принципе весьма консервативные.
>> А LZO - экранов 10 странного месива, которое без препроцессинга вообще хрен одуплишь.
> Значит, лениво писали или свитерно-бородатый однофайловый проект )И то и другое и можно без хлеба. FXJ Oberhumer так-то весьма крутой прогер. Но, вот, переклин на поддержке вообще всего что шевелится, и чтоб быстро, в том числе и с очень маргинальными и кривыми компилерами - свое черное дело все же сделали и код состоит из ifdef'ов чуть более чем полностью. Это на самом деле достаточно ... нетипичный подход. Показывающий что любую даже самую безобидную идею можно довести до уровня когда насчет "безобидной" можно будет поспорить. Там настолько обложено ifdef'ами что вот тупо трекинг логики алгоритма в бошке срывается при попытке его осознать. И пока я пытался понять какой из десяти вариантов мне было надо я уже слегка потерял осталной контекст...
> Нет, нет. Это лишь описательный скрипт. Просто пример того как на практике
> может пригодиться то, что обычно зовут не иначе чем макробесие. )Так то я с препроцессором тоже нехило развлекся. Хоть и считается что это фу-фу, но местами все же клево получается, ну вон макро считает аргументы вариадик макро, и потом генерит имя вызываемого. А вон там - еще и чекает аргументы. Идея последнего подсмотрена в линуховом ядре, кстати. Они тоже макросы любят и имеют на то основания.
Оригиналы не только слышали, как вот ты, например, но еще и в курсе, что никаким "if defined" не получится проверить наличие в компиляторе и отдельно в ассемблере нужных фич - нужных банально для протестировать возможности процессора и гордо заявить "ой, не тот". Потому что, в отличие от тебя - умеют кодить. А в отличие от этих вот модных-молодежных - умеют еще и в переносимый код, а не "многоплатформенная - это винда, винда, винда и еще вот, linux-amd64-самойпоследнейверсии".Именно такой шлак приходится каждый раз выкидывать при пересборке на нетиповых платформах.
I understand your frustration.gifНу, экстраполируй за #ifdef-ы, что-ли. Мне приходилось писать код и под разные платормы и разные API, зачастую даже без #ifdef-ов. Если в коде не используешь совсем уж заковыристые инструкции, то всё везде скомпилится. printf и fopen есть на любом тостере.
> I understand your frustration.gifпохоже, нет.
> Ну, экстраполируй за #ifdef-ы, что-ли. Мне приходилось писать код и под разные
> платормы и разные API, зачастую даже без #ifdef-ов. Если в кодеприходилось ли тебе хоть раз в жизни писать код, который вызывает "illegal opcode" или просто фэйл ассемблера? Похоже, что нет. Приходилось ли тебе менять такой код в чужом большом проекте с неясной тебе системой сборки? Точно нет.
Вот тебе кот:
// GCC >= 4.7.0 required for AVX2.
#if defined(__GNUC__) && (defined(__x86_64__) || defined(__i386__))
#if (__GNUC__ > 4) || (__GNUC__ == 4 && (__GNUC_MINOR__ >= 7))
#define GCC_HAS_AVX2 1это прямо охереть как удобочитаемо, это намертво прибито к GCC, и, РАЗУМЕЕТСЯ - неправильно.
Просто автырь никогда и не проверял - "унегофсеработаит"Особенно здорово - что в автоконфигуре этой же штуки ЕСТЬ такой тест. И он правильно работает, поскольку не надеется на угадав __неведомаяхерня__, а проверяет факт сборки. Но афтор не разбирается в автоконфигураторе, его не он писал.
Я тоже не разбираюсь, и вечной жизни у меня нет - поэтому патчей не будет.
> приходилось ли тебе хоть раз в жизни писать код, который вызывает "illegal opcode"Ну не, такого говнокода я не писал. Разве что - если где-то указатель выходил в открытый космос.
> Вот тебе кот:
нормальный код, только я написал бы более универсально.
#define COMPILER_HAS_AVX2
Ну, и у меня полно проектов которые комплятся от VS6 и GCC 2.x.
> Ну не, такого говнокода я не писал.Это нормальный код. Просто на неправильном процессоре он не должен выполниться.
А то что я процитировал - нет.
> нормальный кодтолько не компилируется.
> #define COMPILER_HAS_AVX2
и откуда такой возьмется? Кстати, семантика тоже неверная.
> Ну, и у меня полно проектов которые комплятся от VS6 и GCC 2.x.
ну это прекрасно, только наверняка окажется что это хеловроты.
Код который я процитировал - ни разу не хеловротный и вряд ли ты сможешь его поправить. Нет, если захочется - велкам. Правда, там еще пяток подобных мест, и не все они одинаковые, потому что это копипасты из чужих исходников.
Нахрен мне чужой быдлокод? Своего мегатонны.
Я что-то !пойму - ты админ || программист?
> Я что-то !пойму - ты админ || программист?Он и админ и программист. Уровня бох^W пох. Извини, пох, ты не против побыть мемасиком? :P
> Нахрен мне чужой быдлокод? Своего мегатонны.
> Я что-то !пойму - ты админ || программист?Я админ opensource систем. Кажется, это то, чему когда-то был посвящен данный сайт.
Весь смысл их применения вместо нормальных коммерческих решений именно в том, что иногда можно что-то самому починить.
> Я админ opensource систем.С Exchange то? Хвалящий винду? Странный какой-то "админ опенсорсных систем".
> Кажется, это то, чему когда-то был посвящен данный сайт.
Кто же его заспамил рассказами про эксченжи и винду? ;)
> Весь смысл их применения вместо нормальных коммерческих решений именно в том, что
> иногда можно что-то самому починить.Раз в год и пох дело говорит... бывает же.
> Это нормальный код. Просто на неправильном процессоре он не должен выполниться.Просто эстетикой его кодер на заморачивался и явно написал первое что ему в бошку взбрело.
> только не компилируется.
В каком месте? Ну и интринсики например - таки можно прочекать что они задефайнены. А билдсистема может и переумничать: то что бинарь с AVX2 не отработал на вот конкретно том проце, вовсе не означает что результат компила не валиден или что фичи в компилере принципиально нет. Может это билдхост был, компилящий для кого-то еще? И получится тогда горе от ума - все users обрублены до фичесета buildhost.
> и откуда такой возьмется? Кстати, семантика тоже неверная.
А вон в какой-нибудь хелпер-хидер затолкать чек компилерфич - и он задефайнит что-то такое. Так что мерзко выглядящие трехэтажные штуки будут в своем локальном загончике, в одном месте. А в актуальном коде только #if HAVE_AVX2 какое-нибудь. Понятное даже болвану и не загромождающее код.
Есть такая интересная идея - single source of truth. Если интересно, у Cyan в бложике более подробно расписано - и я нахожу что он имеет некий пойнт. В этом контексте, грубо говоря, удобно когда чек компилерфич случится в ОДНОМ месте а не ПО ВСЕЙ ПЛОЩАДИ СОРЦА. При необходимости чекнуть что-то еще - будет отрихтован 1 хидер в 1 месте, что сделает рефактор или добавление фичи намного более тривиальным занятием, не говоря про отсутствие тех 20 багов когда вы что-то не заметили в той пачке трехэтажных ifdef'ов и дали маху.
>> Ну, и у меня полно проектов которые комплятся от VS6 и GCC 2.x.
> ну это прекрасно, только наверняка окажется что это хеловроты.Ггг а я целюсь на C99 - и кто его не умеет, ну, тот пролетает. Если за 20 лет компилер C99 платформе не накодили я таки посчитаю ее (полу)трупом. Есть, конечно, всякое, типа PIC12, но оно изначально очень на любителя.
> это копипасты из чужих исходников.
Ну вот там это может быть не когерентно чуть менее чем нихрена.
> Есть такая интересная идея - single source of truth.Судя по тому, как ты это описал, это то, чем я и нормальные программисты пользуются со времён появления более чем двухфайловых проектов. Такие монстры как Source и UE имеют в себе по уровню системных абстракций (железо, компилятор, ОС, АПИ) в паре файлов, а всё остальное их инклюдит и никто даже не заморачивается. Никто ж в здравом уме не будет городить а каждой отрисовке #ifdef OPENGL #else ifdef DIRECT3D #else ifdef WTFGTFO...
> Судя по тому, как ты это описал, это то, чем я и
> нормальные программисты пользуются со времён появления более чем двухфайловых проектов.Возможно. Однако советую глянуть у Cyan'а в блоге (автор LZ4). Там еще очень злобный набор ключей по части warnings компилера есть. Я узнал кой-что новое даже о коде который спокойно проезжал cppcheck и -Wall/-Wextra.
> здравом уме не будет городить а каждой отрисовке #ifdef OPENGL #else
> ifdef DIRECT3D #else ifdef WTFGTFO...Ну да. Однако, вот, попадаются весьма чудесатые экземпляры, типа LZO или UCL от Оберхамера. Дико портабельны, но цена за это огого. Я вот так с наскока даже factor out минимальный декомпрессор не смог, проще оказалось, цуко, другой алгоритм пакера взять... вон, crush, там из "типа-плюсового" кода депакер делается чисто-севый сильно проще, у него из ++ там только "namespace", который можно выпилить напрочь, а остальное по сути чистый си (видимо в винде совсем паршиво с сями, вот и лепят ++ чуть не ради // в коментах).
Эх, заставил меня вспомнить как я проект доброй сотней сырцов с -w3 перевёл на -Wall :)>Однако советую глянуть у Cyan'а в блоге (автор LZ4).
Ну так дал бы сразу ссылку, сохранил бы собеседнику драгоценные минуты купания в гуглиях.
> это прямо охереть как удобочитаемо,Вынести в какой-нибудь хидер типа compiler-features.h, чтобы взгляд не оскорбляло? А потом везде писать что-то типа #if HAVE_AVX2 ... ? :)
> это намертво прибито к GCC,
Шланг тоже это дефайнит.
> и, РАЗУМЕЕТСЯ - неправильно.
Если тебя AVX2 интересовал, как интринсики, тебя портабельность кода точно не колыхала.
> Просто автырь никогда и не проверял - "унегофсеработаит"
Код с AVX2 априори не особо портабелен. Удачи его на ARM завести, etc.
> проверяет факт сборки. Но афтор не разбирается в автоконфигураторе, его не он писал.
Так подсказал бы. Знать все и вся на этой планете невозможно, автор врядли от патча будет отбиваться?
> Я тоже не разбираюсь, и вечной жизни у меня нет - поэтому патчей не будет.
Ну тогда долбайся как есть :)
>> и, РАЗУМЕЕТСЯ - неправильно.
> Если тебя AVX2 интересовал, как интринсики, тебя портабельность кода точно не колыхала.Автор конкретного процитированного куска думал что это - портабельно.
Но недодумал, и проверил не то, не так и не тех версий.
> Код с AVX2 априори не особо портабелен. Удачи его на ARM завести, etc.
На arm если бы ты потрудился прочитать написанное, все работает -
&& (defined(__x86_64__) || defined(__i386__))
и в армовской сборке компилятору не требуется парсить этот кусок вообще, поэтому неважно, умеет ли он эти инструкции.А вот сочетание не той версии с i386 - фатально для _сборки_. Оно бы даже работало, если бы собралось - там есть runtime проверка. Но мой as (а не компилятор, в чем и ошибка, помимо еще и ошибки в версии) не знает этих инструкций. Процессор их тоже не знает, поэтому апгрейдить его незачем, нужно было просто и не пытаться собирать этот код.
> Автор конкретного процитированного куска думал что это - портабельно.Интринсики и портабельно - ну, э, лол.
> Но недодумал, и проверил не то, не так и не тех версий.
С такими вещами это бывает. Специфичное знание.
> и в армовской сборке компилятору не требуется парсить этот кусок вообще, поэтому
> неважно, умеет ли он эти инструкции.Спасибо кэп.
> А вот сочетание не той версии с i386 - фатально для _сборки_.
> Оно бы даже работало, если бы собралось - там есть runtime
> проверка. Но мой as (а не компилятор, в чем и ошибка,
> помимо еще и ошибки в версии) не знает этих инструкций. Процессор
> их тоже не знает, поэтому апгрейдить его незачем, нужно было просто
> и не пытаться собирать этот код.Ты опять какой-то индустриальной некромансией занимался, юзая инструменты на 5 версий древнее чем у кодера? Открою страшную тайну: чем твой конфиг похожее на девелоперскую систему, тем меньше факапов тебя ждет. И наоборот. А так вон то довольно специфичное знание, в конфиге дева все работало, а проверить все сочетания таки напряжно. А чего сие за вундервафля?
> Открою страшную тайну: чем твой конфиг похожее на девелоперскую систему, тем меньше факапов
> тебя ждет.открою страшную тайну: чем раньше в помойку летит поделка недоумка, неспособного сделать ее не то что работающей, а собирающейся не только на его собственном локалхосте с только что из под хвоста упавшими версиями всего - тем меньше шансов на факапы.
Особенно если тебе хоть сколько-то дороги твои данные.
И вот поэтому - авторы zlib абсолютно правильно подобную поделку не пустили и на порог - пусть где-нибудь в песочнице свои замки строят. Пока не повзрослеют, или пока мы все не помрем - тогда уже будет пофиг, что их раздавит песочным замком, сдуру отстроенным в натуральную величину.
> Особенно если тебе хоть сколько-то дороги твои данные.Знаешь, пох, с таким подходом - софтом вообще лучше не пользоваться, в нем баги бывают. И это, у лифтов так то трос тоже обрывается иногда, и поезда сходят с рельсов.
Если верить тебе, у дикарей жизня была сильно безопаснее. Но, правда, 35 лет уже за долгожителя считались. Может не все так просто в этом мире?
> уже будет пофиг, что их раздавит песочным замком, сдуру отстроенным в
> натуральную величину.Справедливости ради, в zlib так то своих скелетов в шкафу. Сложное апи на все оказии, с чертовой тучей фич. А если хотелось что-то мелкое и просто немного сжатия... ну... это не про zlib вообще :)
> Знаешь, пох, с таким подходом - софтом вообще лучше не пользоваться, в нем баги бывают.я _только_что_ напоролся. Переоптимизированный для amd64 код умудряется порождать такое, что клиент на неправильной платформе - падает. Потому что там нет этой оптимизации, и, похоже, никто не то что не тестировал, а даже не отлаживал.
> И это, у лифтов так то трос тоже обрывается иногда
изобретением Отиса, если ты не в курсе, был вовсе не тросовый подъемник, их в шахтах сто лет до того использовали, а вот в домах таких дураков не было, звиздовали по лестницам (шахтеров-то не жалко).
А современные смузихлебы "изобретут" именно лифт без уловителя. Они так мыслят, и так все строят. Но внизу будет автоматически выпадать специальная губка, впитывающая кровь и кишки, если что.
> Может не все так просто в этом мире?
в _современном_ все именно так. Метания ВОЗ и властей в "борьбе" с ковидлой вполне достаточное тому свидетельство. Человечество за последние 20 лет в значительной степени утратило и инженерное мышление, и банальный здравый смысл.
Можно.
> Самое главное из статьи непонятно: сжатые модным нг файлы "консервативным" zlib можно
> распаковать или нет?Конечно. Иначе нафиг он уперся, можно сразу zstd какой-нибудь было взять. С его размерами словарей лучшее сжатие будет обеспечено хотя-бы на одном этом если есть где развернуться.
а твой консервативный zlib однопоточный?пойду натру свой pbzip2 и 12 ядерный кирпич
>Код проекта написан на языке СиКак это приятно видеть на фоне нынешней растомании.
Ага, а потом куча вирусор поплывет по интернету через какие нибудь уязвимости
Ну когда же они поплывут ? Уже сколько лет обещают и все никак не плывут.
Heartbleed? Не, не слышал, ведь ты тогда ещё в школу ходил и не знал даже про opennet.
А когда он стал вирусом ?
> +2
> -3
> +1
> -2
> +3Не понимаю, школьники или сифанатики минусуют и плюсуют? По факту же - heartbleed - ярчайший пример крупнейшей уязвимости - ни много ни мало, уязвимость года, которую можно было избежать, используй разрабы язык, защищающий именно от этого типа ошибок. Самый что ни на есть конкретный пример.
Вполне конкретный пример маркетингового булшита и набивания цены всякому хламу. В общем то что Торвальдс называет secutity circus. Но да, когда вы что-нибудь напрограммите и лажанетесь - так и быть, я с удовольствием потанцую и на вашей могилке, потому что долг платежом красен, а то что вы ни разу не лоханетесь - ну вот не факт.
Ну вот нет же, Вы даже не ответили, как так вышло, что данные из-за Heartbleed поутекали и многим компаниям пришлось просить (или принудительно) менять пользовательские пароли - какой же тут маркетинг? Лишь факт - уязвимость, из-за которой немалая часть Интернета утекла. И, кстати, если бы Вы почитали про что именно говорил "security circus", то не упомянули бы его здесь - контекст был в том, что баги безопасности превозносятся над остальными. Heartbleed же наоборот - изначально недооценённый многими случай, потом веб завыл.
Давай всё-таки факт, а не отговорку "маркетинг".
Факт: вы занимаетесь софистикой и маркетинговым булшитом. Ну как, полегчало? :)
> Факт: вы занимаетесь софистикой и маркетинговым булшитом. Ну как, полегчало? :)+10
И где вирусы на его основе? Вот именно вирус на основе heartbleed сделать - на удивление нетривиальная задача. Как вы это себе представляете вообще?
<sarcasm>А где вирус для браузера на основе Spectre?</sarcasm>
Между вирусом, червём, ботнетом, дроппером, криптоджеком, шифровальщиком и прочими зловредами - разница не мальнькая. А сравнивать уязвимость и вирус - тёплое и мягкое. Да и далеко не каждый вирус получает неканцеляритное название.
Не просто так наверное утекли данные как минимум одной коммерческой больницы. Не просто так многие сайты во внеочередном порядке либо принудительно, либо просто попросили пользователей сменить пароли.Хотя о чём это я? Собирай свой портфель - завтра в школу!
Первая попавшаяся с хабра статья:
https://habr.com/ru/post/218661/
> Первая попавшаяся с хабра статья:И где там вирусы которые обещал тот тупизень?
Вирусы никто не обещал, ты сам себе напридумывал невесть чего. А там всего лишь пол Интернета утекло - даже социнжиниринг не потребовался. Это сейчас люди на местах сами продают данные, а Heartbleed позволил не нанимать соц инженеров, что скорее всего сэкономило немало ресурсов атаковавшим.
> Вирусы никто не обещал,И даже тут вранье у маркетоида - https://www.opennet.ru/openforum/vsluhforumID3/123598.html#19
Они только про оптимизацию или есть всё же шанс дождаться там поддержки Zip64/Deflate64?
>> Код проекта написан на языке СиNenuzhno^3
> Nenuzhno^3Элементарно, Ватсон! Не нравится - не используй.
Интересно было бы увидеть сравнение с zopfli.
Парсер у них вероятно старый от zlib
Вроде на странице гихаба зопфли написано что он медленный но сжимает лучше злиба, так что в их сравнии меня бы скорее интересовало качество сжатия. Или парсер влияет и на это?
там казнитьнильзяпамилавать написано, стремновато если честно
Zophli ровно обратную задачу решает: хрен с ней с скоростью, зато максимально плотное сжатие в пределах этого формата.Фокус в том что один и тот же формат сжатия можно кодировать разными способами. При этом получается разная степень сжатия. Для относительно простых форматов - есть даже некая теория "optimal parsing". Для сильно некоторых форматов, совсем простых, как LZ4 - реализуем полностью оптимальный парсинг (лучше которого чисто теоретически сжать те данные невозможно, в пределах выбранного формата). Более сложные варианты форматов - используют эмпирические приближенные к оптимальному подходы, с мощным match finder и множеством попыток кодирования потока чтобы отобрать наиболее удачные варианты. А для двухстадийных схем по типу LZ+Huffman (как в zlib) - оптимальность парсинга LZ ничего не говорит о том как оно будет по оптимальности кодирования хаффману и это еще более приблизительно. Однако zophli пытается нечто довольно близкое к оптимуму для формата и обычно может сжать плотнее остальных. Ценой ломового жрача ресурсов, конечно. Зато это занимает чуть меньше места и формат остается стандартный, не требует изменений существующих декодеров. И можно скостить еще немного места "на халяву" (без переделки софта).
Спасибо за разъяснения)
> но предоставляет дополнительные оптимизации, не принятые в официальный репозиторий zlib из-за консервативного подхода к приёму измененийВредителям из zlib желаю тяжелого коронавируса, а всем дистрибутивам перейти на zlib-ng.
Ага, сидят и видят как бы не принять улучшение в проект
вы это пожелали человеку, который сделал свободную реализацию deflate, вылизал её для запуска на куче (в том числе и экзотических) архитектур — сделал то, благодаря чему deflate/zlib/gzip стали стандартом de facto.и только потому, что он не бежит принимать патчи, качество которых вызывает сомнения?
пока zlib-ng не работает под кучей архитектур. и через день после релиза уже вышли исправления, он оказался сломанным:
https://github.com/zlib-ng/zlib-ng/releases/tag/2.0.1а плохой, почему-то, Марк Адлер (автор/мейнтейнер оригинального zlib).
> добавлена реализация алгоритма вычисления контрольных сумм Adler32,
> оптимизированная при помощи инструкций SSSE3, AVX2, Neon и VSX
>
> Adler32лол
> лолВ чём?
смишная нируская фамилия наверное
>> лол
> В чём?Там от силы 20 строчек кода...
Гагаг, фу лол, надо было 21 . так чтоли получается ?
А вот 5 строк, принёсшие Криске Касперски мировую известность.
int main()
{
unsigned long c, c2, p2, pol = 0xEDB88320;
long n, k;
{
printf("CRC32 Adjuster (c) 2001 by RElf @ HHT/2\n");
printf("Length of data: "); scanf_s("%ld", &n);
printf("Offset to patch: "); scanf_s("%ld", &k);
n = (n - k) << 3;
printf("Current CRC32: 0x"); scanf_s("%x", &c);
printf("Desired CRC32: 0x"); scanf_s("%x", &c2);
c ^= c2;
p2 = (pol << 1) | 1;
while (n--) if (c & 0x80000000) c = (c << 1) ^ p2; else c <<= 1;
printf("XOR masks:%02X%02X%02X%02X\n", c & 0xff, (c >> 8) & 0xff, (c >> 16) & 0xff, c >> 24);
}
return 0;
}
Потестил с lzbench.
Результаты:
lzbench 1.8 (64-bit Linux) Assembled by P.Skibinski
Compressor name Compress. Decompress. Compr. size Ratio Filename
memcpy 6947 MB/s 6970 MB/s 202372260 100.00 ucd.all.flat.xml
zlib 1.2.11 -1 249 MB/s 792 MB/s 11590367 5.73 ucd.all.flat.xml
zlib 1.2.11 -2 241 MB/s 808 MB/s 10859008 5.37 ucd.all.flat.xml
zlib 1.2.11 -3 229 MB/s 812 MB/s 10535907 5.21 ucd.all.flat.xml
zlib 1.2.11 -4 145 MB/s 841 MB/s 9105206 4.50 ucd.all.flat.xml
zlib 1.2.11 -5 131 MB/s 860 MB/s 8669704 4.28 ucd.all.flat.xml
zlib 1.2.11 -6 117 MB/s 873 MB/s 8214385 4.06 ucd.all.flat.xml
zlib 1.2.11 -7 97 MB/s 886 MB/s 8007300 3.96 ucd.all.flat.xml
zlib 1.2.11 -8 57 MB/s 898 MB/s 7713591 3.81 ucd.all.flat.xml
zlib 1.2.11 -9 55 MB/s 893 MB/s 7688188 3.80 ucd.all.flat.xml
done... (cIters=1 dIters=1 cTime=1.0 dTime=2.0 chunkSize=1706MB cSpeed=0MB)
lzbench 1.8 (64-bit Linux) Assembled by P.Skibinski
Compressor name Compress. Decompress. Compr. size Ratio Filename
memcpy 6199 MB/s 6444 MB/s 202372260 100.00 ucd.all.flat.xml
zlib-ng 2.0.1 -1 412 MB/s 1223 MB/s 16526984 8.17 ucd.all.flat.xml
zlib-ng 2.0.1 -2 463 MB/s 1314 MB/s 10942166 5.41 ucd.all.flat.xml
zlib-ng 2.0.1 -3 389 MB/s 1358 MB/s 10363364 5.12 ucd.all.flat.xml
zlib-ng 2.0.1 -4 304 MB/s 1403 MB/s 9132355 4.51 ucd.all.flat.xml
zlib-ng 2.0.1 -5 259 MB/s 1447 MB/s 8646438 4.27 ucd.all.flat.xml
zlib-ng 2.0.1 -6 243 MB/s 1449 MB/s 8573669 4.24 ucd.all.flat.xml
zlib-ng 2.0.1 -7 179 MB/s 1519 MB/s 7866203 3.89 ucd.all.flat.xml
zlib-ng 2.0.1 -8 142 MB/s 1541 MB/s 7708245 3.81 ucd.all.flat.xml
zlib-ng 2.0.1 -9 131 MB/s 1536 MB/s 7690062 3.80 ucd.all.flat.xml
done... (cIters=1 dIters=1 cTime=1.0 dTime=2.0 chunkSize=1706MB cSpeed=0MB)
zlib-ng с SSE2.
Такие дела...
То есть оно ещё и жмёт лучше. Сууупер.
Наоборот же - хуже! :-)
Оригинальный файл: 202372260 байтов.
Сжатый zlib -1: 11590367
Сжатый zlib-ng -1: 16526984И для других режимов то же самое.
Но скорость выше, это да.
Имхо - баг (зарепортите им).-1 и -2 в zlib не интересны вот практически никогда вообще. -3 - тот актуален, но на нем и выше проблем не наблюдается.
Как лего видно из этих цифр, относительно -3, -1 дает +50% файл при 6-8% приросте скорости компресии и таком же падении скорости декомпресии: в жизни это не интересно вот совершенно.
Если вы попробуете с другим набором, получите ту же картину. -3 это по факту минимальный режим, используемый кем-либо в zlib.
> Имхо - багПочему это?
Они гарантируют более высокую скорость и совместимость с deflate.
Лучшее сжатие никто не обещал.
Их официальные бенчмарки тоже показывают худшее сжатие.
> Их официальные бенчмарки тоже показывают худшее сжатие.Там разница в пределах погрешности. А zophli все-равно обоих натянет - если ждать результат не заколебетесь.
> Там разница в пределах погрешности.Ну так они и не мой файл использовали. :-)
Когда-нибудь поднатужусь, и встрою в lzbench datagen из zstd.
Но не сегодня. :)
> Ну так они и не мой файл использовали. :-)А твой файл вообще очень синтетический походу. Процент сжатия злобный, скорость распаковки искусственно раздута, судя по ratio довольно сильно. Не большинстве других данных будет менее оптимистично.
>> Имхо - баг
> Почему это?
> Они гарантируют более высокую скорость и совместимость с deflate.
> Лучшее сжатие никто не обещал.
> Их официальные бенчмарки тоже показывают худшее сжатие.Худшее там - в пределах погрешности.
Так-то даже в 7zip если форсировать однотредовый режим, сжатие будет чуть выше, чем в многотредовом. Но +300 или 500% к скорости при 1% потере сжатия волнуют мало кого, к счастью, нужно уметь сопоставлять выгоду и проигрыш...
> То есть оно ещё и жмёт лучше. Сууупер.Примерно однохренственно оно жмет. Если надо суперсжатие в этот формат любой ценой тебе zophli какой, или реализация из 7zip'а. Но они тормозные аки трактор, пытаются подбирать более оптимальное представление формата ценой хреновой кучи использования проца и оперативы.
Зачем, если есть lbzip2?
Тогда уже лучше lzip (алгоритм xz) - жмёт лучше, быстрее, тоже умеет восстановление файлов (в отличие от оригинального xz).
> Зачем, если есть lbzip2?Bzip2 в 2020 году вообще совсем ни о чем. Жмет заурядно. Упаковка не быстрая. Распаковка откровенно тормозная, примерно как упаковка (lz-based на распаковку сильно упаковки быстрее обычно). И зачем бы он такой? Вот на него все и забили...
>> Зачем, если есть lbzip2?
> Bzip2 в 2020 году вообще совсем ни о чем. Жмет заурядно. Упаковка
> не быстрая. Распаковка откровенно тормозная, примерно как упаковка (lz-based на распаковку
> сильно упаковки быстрее обычно). И зачем бы он такой? Вот на
> него все и забили...Для начала bzip2 умеет какую-то хоть возможность восстанавливать архивы. Из новых только lzip умеет её. У остальных же несколько битых байтов обозначают смерть всего архива практически гарантированно. Ну и банально он везде практически есть. Да и война с форматами архивов у юниксов вообще в традициях. Сколько пердолей было с переездом с оригинального compress с его .Z архивами на gzip...
> Для начала bzip2 умеет какую-то хоть возможность восстанавливать архивы.Довольно маргинальную. И если это реально было надо - есть утилиты реализующие кодирование с избыточностью и проч.
> Из новых только lzip умеет её.
Как бы мухи отдельно, котлеты отдельно. Это специфичная фича, нужная в основном для всякого архивного хранения, она как минимум сжатие нагибает, а полноценное рекавери на 100% -- добавляет весьма конкретный оверхед. И кому это надо есть и другие варианты.
> У остальных же несколько битых байтов обозначают смерть
> всего архива практически гарантированно.Ну и нахрен мне архив с половиной исходников? Один черт перекачивать придется. А сжатие довольно паршивое и скорость распаковки не фонтан, мягко говоря. Вот и выпал из использования.
> Ну и банально он везде практически есть.
Не отменяет того факта что по соотношениям с другими он таки легаси то еще.
> Да и война с форматами архивов у юниксов вообще в традициях.
> Сколько пердолей было с переездом с оригинального compress с его .Z
> архивами на gzip...У gzip видите ли было 2 достоинства на тот момент. Лучше жмет и не патентованный. А когда unisys патентами на LZW видите ли пытается накрячить то системный пакер, то GIF'ки, это уже немного другой коленкор.
> Это специфичная фича, нужная в основном для всякого архивного хранения.Алло, гараж, речь про архиватор была. Повторю, А-Р-Х-И-В-А-Т-О-Р используют для упомянутого тобой архивного хранения. Люди не только исходники с гихаба качают, а и хранят уникальный контент. Старые архивы таки иногда портятся и, если нет механизма восстановления, то прощайте данные.
> легаси...
GZIP не легаси, а BZIP2 легаси? Это на основании чего такой вывод? Или brotli уже стал архиватором общего назначения?
> Алло, гараж, речь про архиватор была. Повторю, А-Р-Х-И-В-А-Т-О-Р используют для упомянутого
> тобой архивного хранения.Если надо именно это - логично с recovery info каким делать, по типу par какого и проч. Вот это уже может довольно большой урон пережить. Но partity таки тоже займет места под хранение.
Ну или какой-нибудь 7zip-овский формат юзать, p7zip каким, там можно хоть non-solid сжатие делать. Сжатие испортится, зато каждый файл в архиве независимый и декодабелен отдельно от других. Так что урон ограничивается затронутым разрушением сжатым файлом.
> Старые архивы таки иногда портятся и, если нет механизма восстановления, то прощайте данные.
Для вот именно этого - ну, еще может быть, и то - есть другие варианты, более разумные, смотря что хотелось.
> GZIP не легаси, а BZIP2 легаси?
Типа того. Жмет он конечно неважно - но распаковывается в разы (и даже десятки, пожалуй) быстрее, да и пакует довольно быстро если не звереть с уровнем. Поэтому для перекидыания данных без заморочек, с хоть каким сжатием - иногда до сих пор makes sense.
> Это на основании чего такой вывод?
На основании их usage в целом народом.
> Или brotli уже стал архиватором общего назначения?
В unix way вообще исторически принято разделять архиватор и пакер. Это таит в себе определенные tradeoffs. В частности - урон рушит верхний уровень, слой сжатия. Как он из этого (не) восстановится контролю других уровней особо не поддается. В этом плане форматы все-в-одном по типу 7z имеют определенные преимущества. Но таки не юниксвэйно - и пожать форматом который не предусмотрен, путем пайпа нежатого тар в прогу сжатия - уже опа. Будет только то что в формате предусмотрено.
> Ну или какой-нибудь 7zip-овский формат юзать, p7zip каким, там можно хоть non-solid
> сжатие делать. Сжатие испортится, зато каждый файл в архиве независимый и
> декодабелен отдельно от других. Так что урон ограничивается затронутым разрушением сжатым
> файлом.https://www.nongnu.org/lzip/xz_inadequate.html — просто так, навеяло.
> Для вот именно этого - ну, еще может быть, и то -
> есть другие варианты, более разумные, смотря что хотелось.Некоммерческих было всегда по пальцам одной руки. Поэтому большинство старых архивов просто остаются в том, в чём они были в оригинале созданы. И там нет ни xz, ни zstd, ни brotli...
> Жмет он конечно неважно...
Ты же понимаешь, что прогресс в сжатии не бесконечен и gzip жмёт вполне себе прилично, если сравнивать с затрачиваемыми ресурсами?
> На основании их usage в целом народом.
Ну ты же понимаешь, что следующей фразой просто обязана быть "Оценку популярности в студию!"?
> В частности - урон рушит верхний уровень,
> слой сжатия.Простите, что?
>https://www.nongnu.org/lzip/xz_inadequate.html — просто так, навеяло.Я бы на вашем месте эту писульку не упоминал почём зря -- автор там, как минимум, предвзят, а вполне возможно и неадекват.
>>https://www.nongnu.org/lzip/xz_inadequate.html — просто так, навеяло.
> Я бы на вашем месте эту писульку не упоминал почём зря --
> автор там, как минимум, предвзят, а вполне возможно и неадекват.Давай я тебе рандомно побью архив и мы посмотрим, как ты его восстановишь, договорились?
> Давай я тебе рандомно побью архив и мы посмотрим, как ты его
> восстановишь, договорились?Если это меня беспокоит, я, для начала, RAID1 на btrfs юзаю. И наткнувшись на дурной сектор он скажет "CSUM error, corrected". При этом восстановление стопроцентное, а он к тому же знает какая из копий правильная. Но да, это требует потратить место на хранение дважды.
Для начала, raid1 с btrfs - тупое говно-решение. Если тебе нужно восстановление, то юзай raid6 с parity. А восстанавливать btrfs — это ад, даже если тебе это и не нужно делать из-за наличия дубликата.
> Для начала, raid1 с btrfs - тупое говно-решение.Я думаю что моя квалификация позволяет принимать мне решения как мне хранить мои данные без чужих заявлений обоснованных аж апломбом и измышлизмами. И в случае чего я предпочту иметь дело вот с ним. Если что, я таки иногда развлекаюсь data recovery умеренной степени хардкорности. А заодно знаю где btrfs'ники обитают на случай совсем уж крутых непоняток.
> Если тебе нужно восстановление, то юзай raid6 с parity.
1) Это подразумевает минимум 4 девайса.
2) Без btrfs это подразумевает 4 более-менее одинаковых девайса.
3) Это, цуко, неудобное требование.
4) Расширять ЭТО - еще более неудобно. В btrfs я просто воткну +1 винч и скажу btrfs device add, и пофиг какой там размер и проч.
5) Без чексуммы данных это все-равно "не предел мечтаний".
6) Btrfs может использовать DUP, даже с одним носителем. При этом даже таблица разделов опциональна. От полной кончины диска/флехи конечно не помогает, но теорвер резко разворачивается в мою сторону и шансов что при редких сбоях бэды накроют именно обе копии одного и того же блока все же крайне маргинальные. Выходка катит даже для винча на ноуте. Где оно как раз и парировало случайный бэд разок. А вот с RAID6 там как-то напряжненько уже.> А восстанавливать btrfs — это ад, даже если тебе это и не нужно делать
> из-за наличия дубликата.Ничего страшного, я справлюсь. Я более-менее представляю структуру этой штуки и вон там офлайн читалка есть на совсем пиковый случай. Для остальных такое вообще только в коммерческом платном софте за отдельные бабки есть. А в новых версиях как раз подогнали опций монтирования на случай когда ну вот вообще совсем трэш а что-то поиметь оттуда все же хочется.
> Я думаю что моя квалификация позволяет принимать мне решения как мне хранить мои данные без чужих заявлений обоснованных аж апломбом и измышлизмами.Это и называется апломб. Но ты продолжай юзать raid в btrfs, он же ни у кого не сыпался ни разу. Да, я вроде писал же, что я о btrfs знаю не понаслышке?
> же ни у кого не сыпался ни разу. Да, я вроде
> писал же, что я о btrfs знаю не понаслышке?ты бы лучше расписал детали, что и где у тебя пошло не так - хоть какая-то польза была бы от впопеннета.
А истово верующих не оскорбляй - уголовно наказуемо, да и зачем - потом заработаем на восстановлении.
> ты бы лучше расписал детали, что и где у тебя пошло не
> так - хоть какая-то польза была бы от впопеннета.Я тебе даже расписывал как я его на машине с битой RAM гонял, в DUP конфигурации, посмотреть что вообще будет, как ты и просил. А он возьми да и не помри за обозримое время. Хоть к тому и были все предпосылки. На сыпучем и текучем я его тоже гонял, питание крешил и проч.
> А истово верующих не оскорбляй - уголовно наказуемо, да и зачем -
> потом заработаем на восстановлении.Ну я не знаю что у человека было. Может он и правда RAID1 убил в btrfs - мало ли, вдруг у изена достойный продолжатель появился. Но что надо сделать с btrfs'ным RAID1 чтобы он сдох для меня все же некая загадка. Ну нет, я могу придумать несколко способов. Скажем пыхнувший китайский питальник может аннулировать сразу все винчи к хренам. Или, там, окажутся винчи в ovh - и фигли толку с RAID на углях? Это ж не шашлык.
>> ты бы лучше расписал детали, что и где у тебя пошло не
> Я тебе даже расписывал как я его на машине с битой RAMя Тимура спрашивал, вообще-то. То что в твоем специфическом случае оно работало - ничуть не гарантирует от катастроф. А вот знание у кого и когда оно НЕ сработало - позволит подстелить соломки или вовремя спрыгнуть с технологии.
> ты бы лучше расписал детали, что и где у тебя пошло не
> так - хоть какая-то польза была бы от впопеннета.Самое крутое - на выдернутой без отмонтирования флехе видимо слетел erase block, а может и erase group. В результате в страну вечной охоты отлетело 2 суперблока из 3. Но поскольку их 3, таки успешно починилось из 3-й копии.
Еще у меня питание во время конверсии уровней RAID падало. Ну, отскреблось и дальше продолжило с места облома. Я даже и не знаю - а кто-то еще так умеет уже вообще?
А в чемпионате неочевидных грабель - я включил сжатие zstd. Новое, модное, клевое... и при следуюшем ребуте (кернел обновил как раз) grub и сказал мне "unknown compression" при попытке этот самый кернел прочитать (он видите ли zstd и сжался как раз). Ага, блин! Новое, грите? А grub, вот, не очень новый. Ффффак. Так то логично что если кто хочет читать кернель с /boot в системном разделе то и его сжатие он должен понимать :)
> https://www.nongnu.org/lzip/xz_inadequate.html — просто так, навеяло.Это все круто, только имеет смысл в очень некоторых применениях. Видите ли смотря в книгу главное не увидеть там фигу. А то бывает и такое.
> Некоммерческих было всегда по пальцам одной руки. Поэтому большинство старых архивов просто
> остаются в том, в чём они были в оригинале созданы.Сейчас их на самом деле уже сильно больше поразвелось на самые разные оказии. Просто некоторые достаточно специфичны или сильно простые, и не пытаются быть суперлибой на все оказии как zlib/zstd.
> И там нет ни xz, ни zstd, ни brotli...
И чего? Это не значит что надо пакуя новые данные ограничиться словарем в 32 кило эпохи доса. Блок bz2 в 900 кило тоже не предел мечтаний в современном мире. И дальше этой дистанции оно в принципе избыточность не убирает, как я понимаю.
> Ты же понимаешь, что прогресс в сжатии не бесконечен и gzip жмёт
> вполне себе прилично, если сравнивать с затрачиваемыми ресурсами?Я понимаю что когда словарь в несколько метров - он на этой дистанции совпадения и видит. А у zstd есть longrange моде на манер lrzip, когда он умеет искать совпадения на оооооочень почтенной дистанции. А для gzip abcdefgh вот тут и abcdefgh через мег - вообще не совпадение. Оба раза кодируются независимо, как будто первого никогда в потоке и не было. Ограничение абстракции.
> Ну ты же понимаешь, что следующей фразой просто обязана быть "Оценку популярности в студию!"?
Как минимум исходники в bzip2 уже мало кто выкладывает - предпочитая xz какой-нибудь. Который заметно меньше при прочих равных.
>> В частности - урон рушит верхний уровень, слой сжатия.
> Простите, что?Ну вот ток. В *никс вэй оно как бы по слоям обрабатывается. Сперва нежатый архив tar, потом он компрессору отдается. И вон тот результат - это его творчество, он вершина пищевой цепочки. Проблема в том что в результате по сути алгоритм сжатия без дополнительных твиков сталкивается с разрушением данных - а на это он малость не заточен. Примерно об этом вон в той ссылке и рассказывается. Но это проблема в сильно некоторых случаях.
p.s. блин, это было сильно актуальнее при чтении с флопиков цать лет назад :) вот там хороший FEC был бы на вес золота, но с этим тоже было не богато.
> Проблема в том что в результате по сути алгоритм сжатия без дополнительных твиков сталкивается с разрушением данныхА что такое там происходит с данными в tar, что ваш убер архиватор не может потом сопадения найти? Как думаешь, если подсунуть твоему убер-архиватору 100 файлов, он сможет найти совпадения из разных файлов или всё же искать в tar архиве проще без каких-либо "твиков"? Такое впечатление, что у вас остроумность логики проявляется исключительно в попытке доказать свою позицию, а не в попытке здраво оценить ситуацию.
> А что такое там происходит с данными в tar, что ваш убер
> архиватор не может потом сопадения найти?Если декомпрессор вернул отлуп что ошибка в данных, до попытки парсинга tar дело может вообще не дойти. А если он вернул труху вместо этого - там скорее всего шум океанов марса.
В этом плане преимущество имеет интегрированный не-юниксвэйный формат, где оглавление в том же слое что и остальное, доступное напрямую, а файлы пожаты независимо друг от друга, так что вон тот битый файл не затрагивает остальные. Тогда как tar -> gz при ошибке чтения в середине не сможет прожевать весь хвост, просто потому что состояние алгоритма не сбрасывает. Bz2 таки иногда сбрасывает - но не по границам файлов, поэтому это весьма субоптимальная полумера по сравнению с recovery records или хотя-бы non-solid сжатием. Контроля над этим процессом нет.
> Как думаешь, если подсунуть твоему убер-архиватору 100 файлов, он сможет найти
> совпадения из разных файлов или всё же искать в tar архиве проще без каких-либо "твиков"?ЧСХ все нормальные архиверы типа рар и 7зип именно это как раз сто лет и делают, сливая их в один поток, еще и доперев отсортировать по расширению (типу) - это улучшает сжатие отностельно тупого сваливания в тар. Собссно вон то действо и приводит к тому что при ошибке в середине потока не декодируется вообще ничего. А сбрасывать состояние алгоритма - да, с этого места можно начать разбор заново. Но сжатие от этого таки страдает - вновь запущенный алгоритм никак не реюзает предыдущие данные и неизбежно теряет ratio.
> Такое впечатление, что у вас остроумность логики проявляется исключительно в попытке доказать
> свою позицию, а не в попытке здраво оценить ситуацию.На самом деле позиция проста - халявы на халяву не бывает. Есть некий tradeoff, при том у bzip2 он не особо удачный и не особо отключаемый, а если надо было именно вон то - есть реализации с куда более вменяемым этим самым, гранулярно контролируемым, а то и нафиг не нужным из-за использования FEC который ценой оверхеда починит сбой на 100%.
А так - какая мне радость с половины рабочего проекта? Я еще эвон сколько недостающее буду выписывать если бэкапа не было. А раз так - я лучше удостоверюсь что все читается как надо и сделаю несколько копий.
> ЧСХ все нормальные архиверы типа рар и 7зип именно это как раз сто лет и делают, сливая их в один потокИзвините, вы читать не умеете.
> А раз так - я лучше удостоверюсь что все читается как надо и сделаю несколько копий.Удачи. Один RAID1 предлагает, другой вообще несколько копий всего держит. Линуксоиды, х...ле )))
> Удачи. Один RAID1 предлагает, другой вообще несколько копий всего держит. Линуксоиды, х...ле )))Ну а нафиг мне полувосстановленный рабочий проект например? Что с ним делать? Дописать недостающий кус? А это довольно много долботни.
> В этом плане преимущество имеет интегрированный не-юниксвэйный форматА если заголовок побит, то всё?
> А если заголовок побит, то всё?Зависит от. У zip, например, заголовков как таковых два. Один "конденсировано" в хвосте, для быстрого лукапа того что ищем (привет, тар, который надо целиком жевать для этого - доставляет на больших архивах) и второй - там где данные реально есть.
Ну и в случае tar -> gz (xz, ...) при левых данных в середине потока весь хвост tar станет нечитаемым. bz2 сбрасывает состояние между блоками, по поводу чего и могет вон то, но за это своя цена. В виде поганого сжатия например - несмотря на тормознутость.
> Зависит от.Поменьше болтовни, про tar c gz/bz2 я и без тебя знаю, побольше про свой любимый формат.
> Поменьше болтовни, про tar c gz/bz2 я и без тебя знаю, побольше
> про свой любимый формат.Увы, я не верю в серебряные пули - и поэтому предпочитаю формат под задачу выбирать. И если сформулировано что должно еще и ошибки чтения переживать - это не про tar.gz/xz/bz2/...
> И чего? Это не значит что надо пакуя новые данные ограничиться словарем
> в 32 кило эпохи доса. Блок bz2 в 900 кило тоже
> не предел мечтаний в современном мире. И дальше этой дистанции оно
> в принципе избыточность не убирает, как я понимаю.Речь идёт об алгоритме, который работает в том числе на слабых IoТ устройствах или ты мне на микроконтроллер, который ещё более-менее тянет HTML и при желании всё же может жать zlib'ом, предлагаешь засунуть словарь brotli? Вы со своими Феномами вообще потеряли берега. Куча устройств НИКОГДА не получит производительности, достаточной для brotli. Сами же создаёте условия для неуниверсальности решений, а потом жалуетесь на фрагментацию платформ и невозможность изучить и начать зарабатывать деньги на этом. Я уже не говорю о том, что история потом элементрарно повторяется, когда переизобретается велосипед с новым уровнем абстракции.
> Речь идёт об алгоритме, который работает в том числе на слабых IoТ устройствахИм bz2 совсем не друг, там проблемы со всем и сразу - и плотное сжатие все хотят, и проц дохлый. А bz2 там нечего ловить, тормозной и жмет неважно, ни два ни полтора получается.
> или ты мне на микроконтроллер, который ещё более-менее тянет HTML
> и при желании всё же может жать zlib'ом, предлагаешь засунуть словарь brotli?Там не столько в словаре будет основная проблема. А в том что максимальный объем RAM, даже на декомпрессию, может быть довольно непотребный (минимум словарь размером + еще оверхед). Впрочем 200 кило словаря в чем-то таком тоже "не очень". И поэтому там не логично заявлять accepts для бротли. Иначе можно тупо OOM получить если ремота прикольнется.
Хочешь рассказать мне про микроконтроллеры? :) Так то там что-то типа crush интересно, декодер лезет на экран, жмет сносно, "uses no RAM for decompression" (в том плане что там нет больших state, словарей, ... ). Можно LZO и UCL, но там декодеры воистину наркоманские.
> Вы со своими Феномами вообще потеряли берега.
Мы с нашими STM32F0 еще и не на таком декомпрессию запускали... вон там чуваки с Z80 ажно. Чего вопишь? Хошь алго покажу? Спроси LZSA на гитхабе. Весьма непогано жмет для "simple LZ" в втором варианте. И даже на Z80 декомпрессуемо.
> Куча устройств НИКОГДА не получит производительности, достаточной для brotli.
Мне этот момент тоже не нравится до некоторой степени.
> Сами же создаёте условия для неуниверсальности решений, а потом жалуетесь на
> фрагментацию платформ и невозможность изучить и начать зарабатывать деньги на этом.Зарабатывать деньги на ... чем именно? Небольшом объеме данных? Я видите ли в этом случае использую компактные бинарные протоколы, резонно полагая что чем меньше на входе, тем больше предпосылок чтобы и на выходе было меньше, да и времени на сжатие и распаковку так меньше.
> Я уже не говорю о том, что история потом элементрарно повторяется, когда
> переизобретается велосипед с новым уровнем абстракции.Тем не менее сама возможность вгружать словари достаточно забавная. Ты никогда не думал что это дельтакомпрессор на халяву?
Это делается так: словарем грузится old version. Запускается алгоритм сжатия. Его выхлоп с тем словарем - дельта новой версии от старой по сути. Если ремота при декомпрессе тоже умеет словарь юзать, может вгрузить вон ту дельту и сделать из старой версии новую ... просто распаковав это. А хренли, LZ как таковой совпадения кодирует и если история предзагружена из словаря - ну значит и относительно этого закодирует. По этой причине большой словарь и является мухлежом.
Если довести идею до абсолюта, скачав всю википедию любая статья жмется до URL на нее. Но словарь получается оооооочень большой :)
Смотри. Взять lzma вместо bz2 -- первый жмёт быстрее и лучше второго, добавить парити на сэкономленное место, и в итоге получить по-настоящему устойчивый к повреждениям файл так ещё и ещё остаться в плюсе по экономии места. https://www.opennet.ru/openforum/vsluhforumID3/123533.html#178
> Смотри...Вперёд! Миру нужен ещё один формат архивов.
Так там тот же тар. Просто сжат получше.
> Вперёд! Миру нужен ещё один формат архивов.Не, блин, будем до упора пользоваться ископаемой архаикой, тормозной как трактор и при этом не дающей никаких измеримых _гарантий_ дата рекавери в сколь-нибудь потребном виде. Если уж кого восстановление с битых архивов интересовало - логично это делать нормально.
Ты par видимо не застал, его одно время форсили. Там один криво реализованный алгоритм два раза исправляли. В результате каша форматов вышла и из-за этого не взлетело.> Не, блин, будем до упора пользоваться ископаемой архаикой
Между оптимизированной "архаикой" вроде того же zlib-ng и кривоспроектированной "современностью" brotli я выбираю "архаику".
> Ты par видимо не застал, его одно время форсили.Когда ничего лучше не было - форсили. А так то алгоритмы сжатия, вот, развиваются постепенно.
> Там один криво реализованный алгоритм два раза исправляли. В результате каша форматов вышла и
> из-за этого не взлетело.Да почему? В свое время достаточно популярный был. Но это время все же прошло.
> Между оптимизированной "архаикой" вроде того же zlib-ng и кривоспроектированной
> "современностью" brotli я выбираю "архаику".ИМХО смотря где. Вон тот одноплатник с гигом RAM его прожует влет и сэкономит траф. А вон тот роуетер с 32 RAM могет по OOM улететь уже. И на нем в accepts заявлять brotli уже чревато ремотным выносом.
Было бы здорово, если бы было можно прицепить парити к файлу. Ну там по типу ntfs-streams, а то в xattr слишком много ограничений для такого. Сколько там 1 поле ограничего 64кб и всего 255 полей или всего 64кб на всё? Я не помню. А так бы взял приложил к любому файлу 5% парити и ты в шоколаде. А это всё "восстановление" полнейшая лажа -- файлы всё равно битые и часть данных потеряется.
> файлы всё равно
> битые и часть данных потеряется.Весь уровень знаний в одной фразе.
Ну сорян, я правда не слышал чтобы какое-либо парити хотя бы по типу кода рида-соломона было в том же bz2, не говоря уже об остальных. Когда я исследовал вопрос, единственное заключение, к которому я пришёл: этот формат _возможно_ потеряет меньше данных из битого потока, но и только. И равндомно повредятся всё равно несколько файлов, поскольку bz2 их не различает. Или я тебя не понял?
Так еще и по bz2 ыксперд ? Десять салом онов из десяти :D
Меня почему-то раздражает твоя тупость. Хотя я не часто встречаю таких самонадеянных глупцов, может быть в этом дело.
Удивительно, но моя мудрость спровоцирована твоей глупостью.
> Ну сорян, я правда не слышал чтобы какое-либо парити хотя бы по
> типу кода рида-соломона было в том же bz2, не говоря уже
> об остальных. Когда я исследовал вопрос, единственное заключение, к которому я
> пришёл: этот формат _возможно_ потеряет меньше данных из битого потока, но
> и только. И равндомно повредятся всё равно несколько файлов, поскольку bz2
> их не различает. Или я тебя не понял?Да, его нет. Парити обеспечивали ленточные накопители, под которые tar и проектировался когда-то. Кто там сейчас из дисковых или твердотельных накопителей парити умеет? Или уже портиться они перестали? Парити в par/dar фиксили, первое не взлетело, второе вроде даже ещё шевелится.
Что это пар не взлетело? А что же я каждый день на файлообменных форумах вижу его? Парити в 1мб позволяет исправить сотни килобайт повреждений сразу в нескольких местах на 1гб архиве. Как часто архивы бьются? Ну, если отбросить посыпавшиеся сектора, наверно наиболее вероятен битфлип и сбоящая память. Так вот, парити в 1мб скорее всего будет достаточно для того, чтобы восстановить все данные и пару мб на гб можно и выделить. Взять какой-нибудь lzma вместо gzip и парити может быть уже 5-10% при том же объёме, а это уже вообще наверно любой файл можно восстановить. 5мб парити на гигабайт и так за глаза для восстановления кучи повреждений, и это всего пол процента.
Правда нужно учитывать что на ссд скорее всего вылетать будут блоки не 512 байт или 4кб или даже 8кб, а сразу по 20мб, а это значит на одно такое повреждение понадобится никак не меньше 20мб парити (а на деле больше). 5% от гигабайта это 50мб если я ничего не путаю, в таком случае может хватить и 3. Но вообще, вопрос был про парити в дисках, и, насколько я знаю, в ссд есть скрытое парити, иначе данные постоянно бы сгнивали, чего не происходит аж до года да? Или, во всяком случае, было, где-то я слышал такую информацию.
> Правда нужно учитывать что на ссд скорее всего вылетать будут блоки не
> 512 байт или 4кб или даже 8кб, а сразу по 20мб,1) FEC делается _постранично_. И вылетает страница, если FEC не выдюжил вон то количество сбойных битов. У HDD соответственно вылетает сектор.
2) Erase block (который крупный) маркируется как BAD по итогам _стирания_ а не записи. Данные при этом в него еще не успевают затолкать.
3) Erase block чаще всего кратен 2^N и 20 мегабайтов он обычно не бывает. Хотя с чудесатыми TLC возможны и варианты.При чтении нет никаких предпосылок не прочитать весь eraseblock. Читается страницами, а "ошибка стирания" - всего лишь "не все биты вернулись в исходное состояние". Он при этом успешно запишется, кроме скольких-то битов, и постраничное чтение вытащит большинство страниц.
> а это значит на одно такое повреждение понадобится никак не меньше
> 20мб парити (а на деле больше).Бывают странные приколы, конечно, когда питание екнули а ssd eraseblock или erase group кантовал и он уже стер, но еще не записал, а тут питание пропало, но приличные SSD при этом все же сие не теряют, только изменение которое хотели сделать. А вот неприличные флехи с примитивным контроллером - могут. Но при этом может ФС урыться, тогда у вас будут более веселые проблемы. Или таблица трансляции, тогда ваш файл будет выглядеть очень интересно и вы врядли это сами соберете. Паззл из кусочков собирать на глазок не сильно просто.
Я не знаю, по каким местам вы шастаете (кстати, а где?), но в дикой природе я его уже лет 5 не видел. Допускаю, что просто сменил пристрастия за последние 10 лет. Там просто в первой версии был какой-то убер-тупейший баг дизайна из-за которого почти сразу второй формат запилили. Про преимущества парити мне рассказывать не надо, я ещё 5 лет назад хоть и относительно простецкие, но стримеры использовал, там это всё есть на железном уровне.
> Я не знаю, по каким местам вы шастаете (кстати, а где?)варезник, небось
там критично свойство архиватора нарезать мелкими ломтиками, ну и восстановление тоже.
У криминала свои специфические нужды и странности.
> Ну сорян, я правда не слышал чтобы какое-либо парити хотя бы по
> типу кода рида-соломона было в том же bz2,Да нет там ничего такого, он просто состояние компрессора каждый блок сбрасывает. От чего и имеет проблемы с неважным сжатием, но декомпресс при факапе можно начать с нового блока. В случае solid сжатия - с момента сбоя в декомпреснутом потоке ессно труха и хвост не декодируем совсем.
А таки да, рид-соломон и т.п. при правильном применении будет сильно эффективнее, загасив сбой в ноль, ценой некоего оверхеда. В том бомж-репайре видите ли вообще совсем никаких гарантий относительно того что накроется и что починится. Поэтому те кому надо было всерьез юзают FEC конечно же, или просто делают несколько копий.
bzip вообще не нужен, xz на низких степенях сжатия (-3 и около того) жмёт быстрее и сильнее.
Справедливости ради, на некоторых входных данных bzip2 сжимает эффективнее, чем xz. Но в целом согласен, при наличии xz и zstd bzip2 не особо актуален.
Я не пойму, почему столько негатива? Если будет гарантировать совместимость на уровне ABI, то во времена, когда никто не уделяет время оптимизации кода, а только увеличивает кол-во слоёв-абстракций, это вообще бесценно.
> Я не пойму, почему столько негатива? Если будет гарантировать совместимость на уровне
> ABI, то во времена, когда никто не уделяет время оптимизации кода,
> а только увеличивает кол-во слоёв-абстракций, это вообще бесценно.Да даже хрен с ним с ABI, нехай API + формат данных останется тем же. А софт можно и рекомпильнуть накрайняк.
>> Я не пойму, почему столько негатива? Если будет гарантировать совместимость на уровне
>> ABI, то во времена, когда никто не уделяет время оптимизации кода,
>> а только увеличивает кол-во слоёв-абстракций, это вообще бесценно.
> Да даже хрен с ним с ABI, нехай API + формат данных
> останется тем же. А софт можно и рекомпильнуть накрайняк.Если формат данных разный, то это очередные пердоли, как с gzip и zlib, когда алгоритм одинаковый, а формат чуток отличается. Как ты себе представляешь PNG со своим особенным ZLIB'ом внутри?
> Если формат данных разный, то это очередные пердоли, как с gzip и
> zlib, когда алгоритм одинаковый, а формат чуток отличается. Как ты себе
> представляешь PNG со своим особенным ZLIB'ом внутри?Так при чем тут ABI? ABI это _бинарный_ интерфейс программа <-> либа. На уровне какие регистры что содержат при вызове, что из функции возвращается и куда и проч. Вот это совпадать не обязано. А на уровне _апи_ (вызвать функцию с теми же параметрами и сравнимым результатом) - может и одинаково быть. Или не быть, если авторы донкихотствуют всерьез.
К формату данных это никак не относится - он конечно же останется zlib'овский, иначе нахрен кому эта либа вперлась вообще. Если менять формат, тогда сразу уж zstd какой чтоли брать. А тут весь фокус в совместимом формате данных на выходе, так что менять все декодеры на планете не надо.
А у png таки ... довольно специфичный подход к формату данных. Я как-то пробовал "несжатый" делать "руками" и там свои приколы, чексумм местами надо, как раз из-за вот таких вещей. Zlib и gzip основаны на 1 алгоритме, но обернут он чуть по разному. В том смысле что gzip некие хидеры добавляет к пожатому zlib'ом и проч. А хренли, zlib сам по себе жмет source в destination, вообще как mem to mem операция. В этом контексте нет такого понятия как имя файла и прочие глупости. А коли gzip это надо - он сам сие как-нибудь придумывает.
> Так при чем тут ABI?Ну что ты городишь? Ну вот тебе, например, libjpeg-turbo бинарно совместим с libjpeg и я могу просто использовать первую со старыми пропритарными программами, слинкованными с обычным libjpeg.
> Ну что ты городишь? Ну вот тебе, например, libjpeg-turbo бинарно совместим с
> libjpeg и я могу просто использовать первую со старыми пропритарными программами,
> слинкованными с обычным libjpeg.И чего? Со своей стороны я считаю что опенсорсникам хватит и совместимости API. А насколько там древность корректно будет работать с вон той версией вон той либы - очень отдельный вопрос.
> Так при чем тут ABI? ABI это _бинарный_ интерфейс программа <-> либа.
> На уровне какие регистры что содержат при вызове, что из функции
> возвращается и куда и проч. Вот это совпадать не обязано. А
> на уровне _апи_ (вызвать функцию с теми же параметрами и сравнимым
> результатом)Изменение, например, порядка аргументов меняет их размещение в регистрах. Добавление и удаление - тоже.
>> Так при чем тут ABI? ABI это _бинарный_ интерфейс программа <-> либа.
>> На уровне какие регистры что содержат при вызове, что из функции
>> возвращается и куда и проч. Вот это совпадать не обязано. А
>> на уровне _апи_ (вызвать функцию с теми же параметрами и сравнимым
>> результатом)
> Изменение, например, порядка аргументов меняет их размещение в регистрах. Добавление и
> удаление - тоже.Что сказать-то хотел, кэп?
> Что сказать-то хотел, кэп?Что бинарной совместимости не жди
> Изменение, например, порядка аргументов меняет их размещение в регистрах. Добавление и
> удаление - тоже.Я об этом догадывался :)
>Добиться существенного повышения производительности сжатия/распаковки в основном удалось благодаря задействованию векторных инструкций SSE*, AVX2, VSX и Neon.Неужели в GCC автовекторизатор на -O3 работает настолько плохо?
> Неужели в GCC автовекторизатор на -O3 работает настолько плохо?Обычно хуже, чем ручками
он вообще никак не работает. Что бы там секта свидетелей -O9 не бормотала. Собственно, он даже в прекрасном icc не работает.Чтобы автовекторизатор подхватил твой код, надо написать такое бюэээ, которое во-первых абсолютно нечитаемо, во-вторых, внезапно - совершенно неоптимально для исполнения на основном процессоре.
Поэтому проще сразу написать на ассемблере - его знание тебе все равно понадобится.
Единственный бонус от писания под "автовекторизаторы" - такой код худо-бедно компилируется везде, не требуя пресловутых ifdef и стремных тестов по автоугадаву наличных фич компилятора. Но работает плохо.
Но одновременно avx2/sse и neon - это все равно фантастика, ненаучная.
> Поэтому проще сразу написать на ассемблереЕсть ещё промежуточный вариант - интринсики. Чуть удобнее ассемблера.
> его знание тебе все равно понадобится.
Это да.
> Есть ещё промежуточный вариант - интринсики. Чуть удобнее ассемблера.теперь тебе надо не только знать ассемблер и архитектуру (три разных, как в этом проекте), но еще и замысловатый синтаксис конкретного компилятора ;-)
Фиг знает, удобнее или нет - я так и не осилил, каждый раз матерюсь, натыкаясь в чужом коде.
Как по мне - asm {} были удобочитаемей. Правда, регистры надо сохранять самому.Причем от необходимости проверять, умеет ли данная связка конкретной версии gcc и конкретной версии gas конкретно твой avx2 ни разу не избавляет.
? Наоборот же. Интринсики описываются в .h файле и имеют тот же самый С-интерфейс для каждого компилятора, который их поддерживает. А синтаксис блока asm {} и его взаимодействия с остальным С-кодом как раз любит чуть-чуть отличаться от компилятора к компилятору.
> теперь тебе надо не только знать ассемблер и архитектуру (три разных, как
> в этом проекте), но еще и замысловатый синтаксис конкретного компилятора ;-)Немного не так. Теперь надо знать "возможности архитектуры" и "желаемую операцию". При этом есть шанс что на разных платформах смогут относительно эффективно скроить вон то (интринсик с этим синтаксисом) из того что у платформы есть.
Если что я таки запиливал интринсики себе, "как у ARM и STM32 в cmsis, но моим кодом с моей лицензией" (а почему бы и нет?!). Т.е. некий "compat".
Caller однако понятия не имеет что там унутрях __disable_irq() какого. И, более того, это сработает и на ARM и на RISCV, если я (или кто-то еще) запилит это __disable_irq() в тамошних абастракциях. Внутрях ARM и RISCV конечно разные, но caller эту разницу не увидит.
С математикой ессно сложнее - часто фичи того или иного набора команд достаточно уникальны и не имеют прямых аналогов. Сэмулировать можно что угодно, но если это не ускоряет операцию, смысл теряется и зачем такой интринсик надо? Он на раз окажется хуже сишного кода :)
> Фиг знает, удобнее или нет - я так и не осилил, каждый
> раз матерюсь, натыкаясь в чужом коде.Ну вот у именно x86 с их адовым количеством команд - так себе развлекуха. Я интринсики чуть по другому поводу научился.
> Как по мне - asm {} были удобочитаемей. Правда, регистры надо сохранять самому.
Технически интринсики и есть в общем то это самое, просто делается не тобой а ты уже готовое дергаешь, и по задумке сие может быть сделано под разные платформы/компилеры. В чем пойнт? В том что код при миграции менять не надо в идеале. Это головняк system implementer'а, тулчейна, либы, или кого-то еще, но не вон того прогера, который просто дергает фичу.
> Причем от необходимости проверять, умеет ли данная связка конкретной версии gcc и
> конкретной версии gas конкретно твой avx2 ни разу не избавляет.Ну, вообще, если хочешь вы...ся можешь попробовать incbin :D :D прекомпильнутого блоба :))) делать из асма, при этом его понимание набора команд до лампочки. Но за такую реализацию интринсика желающие тебя линчевать выстроятся в очередь...
>проведена чистка кода от обходных решений, используемых в zlib для поддержки старых компиляторов и платформсмузихлёбов хлебом не корми, дай что-нибудь обозвать старым и устаревшим и выбросить
>но мешающих реализации более эффективных методов
Ну да, конечно, ну прям совсем-совсем мешающих, сохранить совместимость было совсем-совсем невозможно.
> смузихлёбов хлебом не корми, дай что-нибудь обозвать старым и устаревшим и выброситьа оно у них все равно не собирается на тех платформах. Или ты думал, в сказку попал?
> сохранить совместимость было совсем-совсем невозможно.
да, но нет. В смысле - их основной проект уже послал, поэтому уже незачем.
А сжатие как? Если не ухудшилось, то хорошо, годно.
собрал и установил, собранные с обычным zlib проги норм работают без пересборки
Я думал zlib уже давно оптимизирован по самые уши, а тут оно вон что. Жду в дистрибутивах.
Да уж. Тоже мне бинарная совместимость... Попытался через LD_LIBRARY_PATH заменить стандартную /lib/libz.so.6 на libz-ng.so.2.0.6:$ mc
ld-elf.so.1: /usr/local/lib/libz.so.6: version ZLIB_1.2.4.0 required by /usr/local/lib/libssh2.so.1 not found
