home.social

#lz4 — Public Fediverse posts

Live and recent posts from across the Fediverse tagged #lz4, aggregated by home.social.

  1. Как не получилось сделать PostgreSQL лучше (и почему это нормально)

    Недавно я получил статус Major Contributor в проекте PostgreSQL. Это довольно радостное для меня событие и интересное, поэтому коллеги попросили написать статью об этом. А чтобы я не сомневался — заботливо составили список достижений за меня. Получилось замечательно, но публиковать от своего имени статью вида «как я крут» я не хочу. Я совсем не против про это говорить, и из каждого утюга вещаю про разные технологии, сделанные моей командой или вот прям вообще мной. Но только в контексте «как использовать эти технологии», либо в узком кругу или личной беседе. Я решил написать другую статью: что у меня не получилось. Писал довольно спешно, поэтому, возможно, местами будет понятно только специалистам. Не расстраивайтесь, если что‑то неясно и пришлось гуглить. А вот если всё понятно — возможно, стоит меньше смотреть в монитор и чаще трогать траву. Инкрементальное улучшение любой популярной технологии зачастую имеет негативные последствия. И в большинстве случаев предлагаемых в PostgreSQL доработок — вред превышает пользу. Построить что‑то новое, ничего не сломав, бывает трудно и в чистом поле, а ядро PostgreSQL в этом смысле — лабиринт с граблями.

    habr.com/ru/companies/yandex/a

    #postgresql #wal #btree #btree_индекс #синхронная_репликация #lz4 #pglz

  2. Введение в zram и сжатие памяти

    zram — это механизм ядра Linux, создающий сжатый блок памяти в RAM, используемый как пространство подкачки (swap). Это позволяет эффективнее использовать оперативную память, особенно на системах с ограниченным объемом ОЗУ. Вместо записи данных на медленный диск, zram сжимает их и хранит в RAM, обеспечивая значительно более высокую скорость доступа.

    Выбор алгоритма сжатия — ключевой момент при настройке zram. Наиболее популярные варианты — LZ4, Zstd и LZO. Каждый из них предлагает разный баланс между скоростью сжатия/распаковки и степенью сжатия.

    Сравнение LZ4 и Zstd

    Хотя ваш вопрос предполагает, что LZ4 предпочтительнее Zstd, на практике это не всегда так. Предпочтение зависит от конкретных целей:

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

    Zstd (Zstandard), разработанный Facebook, предлагает лучшее сжатие при сохранении высокой скорости. Он может достигать степени сжатия, близкой к gzip, но со скоростью, сравнимой с LZ4.

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

    Производительность: скорость vs степень сжатия

    По скорости: LZ4 быстрее Zstd. В сценариях, где CPU является узким местом, или при очень высокой частоте обращений к swap, LZ4 может предотвратить лаги и задержки. Один из пользователей на Reddit отметил, что при тяжелых нагрузках (например, эмуляция игр) Zstd вызывал заметные лаги, которых не было с LZ4 при стандартных настройках.

    По степени сжатия: Zstd превосходит LZ4. Это означает, что с Zstd можно сэкономить больше RAM, что особенно важно на системах с малым объемом памяти (например, 4–8 ГБ).

    Сценарии использования и рекомендации

    Используйте LZ4, если:

    1. У вас ограниченная мощность CPU.

    2. Вы хотите минимизировать задержки при активной подкачке.

    3. Система работает в реальном времени или чувствительна к лагам (например, игры, аудио-обработка).

    Используйте Zstd, если:

    1. У вас мало RAM, и вы хотите максимально эффективно её использовать.

    2. Процессор достаточно мощный (современные CPU хорошо справляются с Zstd).

    3. Вы готовы настроить систему (например, использовать оптимизированные параметры ядра).

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

    Заключение

    Неверно утверждать, что LZ4 предпочтительнее Zstd в zram. Наоборот, Zstd часто рекомендуется как более сбалансированный и современный алгоритм. Хотя LZ4 быстрее, Zstd обеспечивает значительно лучшее сжатие при сохранении высокой скорости. При правильной настройке системы (например, с ядром 6.7+ и оптимизированными параметрами) Zstd может превзойти LZ4 по общей производительности.

    Вывод: Zstd — отличный выбор для большинства пользователей, особенно на системах с малым объемом RAM. Однако LZ4 остаётся предпочтительным при высокой нагрузке и слабом CPU.

    #zram #zramen #Linux #LZ4 #zstd

  3. Сжатие графики при помощи алгоритма LZ4

    Привет, Хабр! Меня зовут Александр Крестинин, я разработчик встроенного ПО в компании Whoosh. Мы в embedded-команде не только переливаем биты из одного регистра в другой, но и решаем разные бизнес-задачи. Иногда попадаются головоломки. Однажды мы подумали, что было бы здорово выводить на экраны самокатов анимации и изображения — показывать инструкции, как пользоваться сервисом, как начать и закончить поездку, и чтобы запускать DOOM. Зачем? 1) Сделать комфортнее. Удобно видеть инструкции на большом и ярком экране перед глазами, а не нырять за ними в приложение на смартфоне. 2) Сделать безопаснее. Пользователь меньше отвлекается на телефон, крепче держится за самокат и внимательнее смотрит на всё, что вокруг. 3) Почти у всех привычных устройств уже есть экраны, которые выводят пользователям видео и картинки, а почему бы не сделать то же самое на самокате? Но тут возникает проблема. Микроконтроллер крайне ограничен в памяти и вычислительных ресурсах. Самая простая анимация занимает чрезмерно много места. А если внедрить в отрисовку алгоритмы сжатия, то вычислительная нагрузка увеличится и анимация будет сильно лагать. Расскажу, как мы нашли решение этой задачи. Прошу под кат.

    habr.com/ru/companies/whoosh/a

    #микроконтроллеры #микроконтроллер #whoosh #lz4 #графика #изображения #анимации #сжатие_изображений #сжатие_данных #дисплей

  4. Today I had a quick look at compression speed of the various compression algorithms in #UnrealEngine.

    In my use case, speed is more important than compression ratio, so I had COMPRESS_BiasSpeed set.

    To little surprise, #gzip and #zlib took about the same time, and #lz4 was a lot slower.

    The big surprise was #Oodle, which was faster than all others. By a lot.

    So, if you are compressing data in your Unreal game at runtime, you might want to check if Oodle is an option for you.

  5. #LZ4 v1.10 Introduces #MultiThreading Support For Major #Compression Speedups

    LZ4 1.10 has been dubbed the "multi-cores edition" with this version adding multi-threading support to help speed-up compression now that modern I/O storage with NVMe is so much faster there's a real need to make compressing data even faster.
    phoronix.com/news/LZ4-1.10-Mul

  6. What is your advise to decompress the #initramfs on a #raspberry #pi 4 running on #manjaro ?
    I hesitate between #zstd and #lz4: which one is the best in term of decompression time ?

    #arch

  7. Man I love Rust libraries.

    🦀 **lz4_flex**: Fastest pure Rust implementation of LZ4.

    😳 Features: Very good logo.

    ⭐ GitHub: github.com/pseitz/lz4_flex

  8. Sent a PR to for a new API which I would like to use in my new GConverter implementation for

  9. A researcher from old ole U
    Had been searching to find out who's who
    By crunching the data
    A man was found later
    And it was his pic on LZ4's view

    #ledzepplin #lz4 #albumcover #unsolvedmystery #limerick #poetry

    bbc.co.uk/news/uk-england-wilt

  10. #dar 3/ Dar's homepage is dar.linux.free.fr/ . As a simple file archiver tool, dar is great. Random access is preserved, you can compress with #gzip #bzip2 #lzo #xz #zstd or #lz4. You can encrypt with #GnuPG or symmetric #AES. You can stream if you want. You can split ("slice") across multiple media, and dar will prompt you for the slice(s) you need and seek you right to them.

    That's cool, but we're just getting started.

  11. #dar 3/ Dar's homepage is dar.linux.free.fr/ . As a simple file archiver tool, dar is great. Random access is preserved, you can compress with #gzip #bzip2 #lzo #xz #zstd or #lz4. You can encrypt with #GnuPG or symmetric #AES. You can stream if you want. You can split ("slice") across multiple media, and dar will prompt you for the slice(s) you need and seek you right to them.

    That's cool, but we're just getting started.

  12. #dar 3/ Dar's homepage is dar.linux.free.fr/ . As a simple file archiver tool, dar is great. Random access is preserved, you can compress with #gzip #bzip2 #lzo #xz #zstd or #lz4. You can encrypt with #GnuPG or symmetric #AES. You can stream if you want. You can split ("slice") across multiple media, and dar will prompt you for the slice(s) you need and seek you right to them.

    That's cool, but we're just getting started.

  13. #dar 3/ Dar's homepage is dar.linux.free.fr/ . As a simple file archiver tool, dar is great. Random access is preserved, you can compress with #gzip #bzip2 #lzo #xz #zstd or #lz4. You can encrypt with #GnuPG or symmetric #AES. You can stream if you want. You can split ("slice") across multiple media, and dar will prompt you for the slice(s) you need and seek you right to them.

    That's cool, but we're just getting started.

  14. #dar 3/ Dar's homepage is dar.linux.free.fr/ . As a simple file archiver tool, dar is great. Random access is preserved, you can compress with #gzip #bzip2 #lzo #xz #zstd or #lz4. You can encrypt with #GnuPG or symmetric #AES. You can stream if you want. You can split ("slice") across multiple media, and dar will prompt you for the slice(s) you need and seek you right to them.

    That's cool, but we're just getting started.

  15. I decided to be weirdly patient: to buy gradually, over the years, all the latest #Hitman titles first, and then play the whole trilogy under Hitman 3's mechanics. Finally got them all! This will be an epic playthrough. Probably would keep me busy until I finally have to upgrade to the newest gen of #Xbox. I gotta say, the ability to play all three games under one engine is amasing! Pretty cool what they did with the #LZ4 compression, too: the entire download was only about 75 GB 🏆

  16. My conclusion after all this is that I'll probably use level 1 (not the default level 3!) for of my measurement data from now on:

    - ultra fast compression and decompression, on par with
    - nearly as good a compression ratio as level 9
    - negligible RAM usage

    When I need ultra small files though, e.g. for transfer over a slow connection, I'll keep using level 9.

  17. Repeated the with the same file on a beefier machine (AMD Ryzen 9 5950X), results are quite identical, except faster overall.

    This plot is also interesting:

    - and have fixed (!) and very low RAM usage across levels and compression/decompression
    - RAM usage scales with the level from a couple of MBs (0) to nearly a GB (9)
    - RAM usage scales weirdly with level but not as extreme as

  18. First let's look only at the non-fancy options (no --fast or multithreading) and make log-log plots to better see what's happening in the 'clumps' of points. Points of interest for me:

    - has a *really* low memory footprint across all compression levels
    - clearly wins the decompression speed/compression ratio compromise!
    - at higher levels is unrivalled in compression ratio
    - higher levels aren't worth it. is also just fast.

  19. ⏱️ Compression vs Decompression speed. Interesting that has some settings that actually decompress slower than they compress. Might just be my machine, though... is still a turtle 🐢, is not much better, decompresses much faster than is compressed, again has something for everybody.

  20. Cool behaviour, ! Refusing to compress a file when redirecting STDOUT but *still* deleting the input file when having --rm specified. What could go wrong? Surely the user has a backup of the input file! 😌