LINUX.ORG.RU
Новости — Open Source  

Библиотека для сжатия данных от Google

 , , , , ,


0

1

Компания Google опубликовала код библиотеки Snappy, служащей для сжатия и распаковки данных. Snappy не совместима с другими библиотеками, коэффициент сжатия также далёк от рекордных показателй. Вместо этого целью разработки является максимальная скорость работы при сохранении приемлемой степени компрессии. Так, например, для большинства входных данных Snappy оказывается на порядок быстрее, чем Zlib в режиме максимальной скорости, а результирующие файлы на 20-100% больше. На одном ядре процессора Core i7 в 64-битном режиме скорость сжатия составляет более 250 Мб/сек, а распаковки — 500 Мб/сек и больше.

Snappy широко используется во многих сервисах Google — от BigTable и MapReduce до внутренних систем RPC.

Вместе с иходным кодом библиотеки распространяется код теста Snappy для сравнения с некоторыми другими библиотеками, такими как Zlib, LZO, LZF, FastLZ и QuickLZ. Библитека распространяется под лицензией Apache License 2.0.

>>> Подробности

★★★★

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

 ← 1 2 3 4 →
Ответ на: комментарий от anonymous

> на счет второго - толсто. Имеется ввиду 20-100% от размера сжатого файла zlib. Исходный файл: 100 Кб, сжатый zlib'ом: 20 Кб, сжатый snappy: 24-40 Кб, а не 200 Кб. Горе математики, епта... Твой КО

Да ну.. Конечно, для текста так и будет. А что насчет видео или почти случайного набора байт.

КО дорогого КО

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

>> И всякие трюки вроде записи в память в обход кеша CPU там тоже можно делать столь же дешево и ненапряжно?

Обезьяна.

Приятно познакомиться. А я - homo sapience.

Ты на Python ядро ОС писать собрался, или какие то системные проги - тогда ты полный даун.

Я писать на Python вообще не собрался. А ты, конечно, невменяем. Читай пост, на которых я написал ответ. Там ясно написано «и скоростью исполнения присущей Си», что суть вранье.

Иди убейся.

Хороша команда. Вот зачем вы вслух собой управляете?

И настоящую многопоточность там можно замутить? В C - можно. Тот же POSIX Threads есть. А у вас как с этим обстоят, Свидетели GILа?

А ты какую реализацию и версию Python имеешь ввиду? CPython, PyPy, Stakless Python, Jython, IronPython? Может другую какую? Так что бля, со своими уебищными придирками насчет GIL - иди убейся. Ты бля не можешь отличить интерпретатор один от другого, и только слышал, что на GIL матерятся, а толком в чем проблема, к чему относится, и где решена - не знаешь.

Я имею в виду CPython, о котором идет речь в посте выше, алкашик ты наш. Свой бред про придирки и GIL лучше оставь себе, если нечего сказать по существу.

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

>>И настоящую многопоточность там можно замутить? В C - можно.

Что-то тесты на сайте блала.дебиан.орг показывают обратное - в многопоточных задачах си жестко сосет по сравнению с тем же с++

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

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

хотя ситуация оказывается еще страшнее чем думал - http://shootout.alioth.debian.org/u32/performance.php?test=knucleotide

Здесь си в четыре раза тормознее с++ при то что в обоих случаях используется только один процессор

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

8129 - забавный magic number. Специально для торможения на втором и последующих вызовах fread сделан? 8192 - правильный размерчик.

anonymous
()
Ответ на: комментарий от eveel

> Интересный результат. Не в ключах ли компиляции дело?

Результат примерно такой, какой обещал гугль:

lzop: 130.3MB/s avg
snappy: 170.1MB/s avg

Кроме того, меня напряг постоянный вызов output.resize в теле цикла.

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

Попробуй заменить

output.resize(snappy::MaxCompressedLength(bytes));


на

output.resize(snappy::MaxCompressedLength(sizeof(buf)+1));


и вообще поставить эту строчку перед оператором while.

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

> 8129 - забавный magic number. Специально для торможения на втором и последующих вызовах fread сделан? 8192 - правильный размерчик.

Точно. Я это проморгал.

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

Кроме того, меня напряг постоянный вызов output.resize в теле цикла

он ничего не делает, в данном случае на скорости это не скажется

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

> то что lzo в два раза меньше тоже результат ключей? ;)

В смысле, файл меньше? Пусть у LZO файл меньше, суть не в этом, я говорю про быстродействие.

Для стерильной чистоты эксперимента можно попробовать собрать Snappy с теми же ключами, что и lzop в дистрибутиве.

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

Обоснуй.

Переаллокация происходит только если новый размер больше текущего capacity. А убирание лишнего if'а на скорости никак не сказывается.

Reset ★★★★★
()
Ответ на: комментарий от Manhunt 
$ ls -s big-file.snappy 
809380 big-file.snappy

Дальнейшее увеличение буфера ни к чему не приводит.

Reset ★★★★★
()
Ответ на: комментарий от Reset 
      void
      resize(size_type __new_size, value_type __x = value_type())
      {
        if (__new_size < size())
          _M_erase_at_end(this->_M_impl._M_start + __new_size);
        else
          insert(end(), __new_size - size(), __x);
      }
Manhunt ★★★★★
()
Ответ на: комментарий от Manhunt

Ну и ? У нас __new_size - size() == 0. Да даже если не ноль, то у нас вектор из char'ов, поэтому эти все erase/insert будут выполняться o(время сжатия).

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

>Здесь asm в 4 раза тормознее асма, так чтоль?

с какой стати си это ассемблер? Ассемблер:
1) однозначно транслируется в машинный код
2) уникален для каждого процессора

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

а то что на си такие корявые операторы и так неудобно писать это не следствие его низкоуровневости, это следствие 48 килобайт оперативки на PDP-11

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

>Пусть у LZO файл меньше, суть не в этом, я говорю про быстродействие.

И толку от быстродействия если размер сжатого файла почти равен размеру исходного?

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

>на си такие корявые операторы и так неудобно писать

Мне на плюсах сильно сложнее писать, чем на plain C

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

>gcc же!

компилятор и ассемблер понятия несовместимые. Ассемблер это сборщик, компилятор - перекомпоновщик. Разницу улавливаем?

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

> У нас __new_size - size() == 0.

Очень сомневаюсь.

поэтому эти все erase/insert будут выполняться o(время сжатия)


Вместо того, чтобы спорить, лучше вынести resize за while и проверить на практике. Там все что угодно может быть. Например, засирание instruction cache развернутым циклом insert-а, засирание предсказателя переходов.

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

> И толку от быстродействия если размер сжатого файла почти равен размеру исходного?

В три с гаком раза меньше исходного: 809380 против 2590932

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

Очень сомневаюсь.

Это всегда так, кроме последней итерации цикла, на которой сработает erase.

Вместо того, чтобы спорить, лучше вынести resize за while и проверить на практике. Там все что угодно может быть. Например, засирание instruction cache развернутым циклом insert-а, засирание предсказателя переходов.

Всего чего угодно там нет, там всё очевидно. resize я вынес, и, как и ожидалось, на скорость это никак не повлияло.

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

то есть ассемблером являются также фортран, паскаль и еще туева хуча зыков поддерживаемых gcc? =)) Плюсы компилирует не gcc а g++

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

>ассемблером

К словам то не придирайся)

Плюсы компилирует не gcc а g++


Оптимизатор у них вроде общий, не?

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

> Здесь си в четыре раза тормознее с++ при то ...

ну прям дет.сад. «один язык» на разных программах сравнивают... )))

mrs
()
Ответ на: комментарий от DNA_Seq

> И толку от быстродействия если размер сжатого файла почти равен размеру исходного?

Файл, сжатый Snappy, весит в два раза меньше, чем исходный файл в примере от Reset. Всё ещё возникает желание утверждать, что его размер почти равен размеру исходного? :)

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

>> Если бы выложили под совместимой с GPL лицензией

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


Линус мог бы не выпендриваться и перевести ядро на GPL v3. Как велел Бородатый.

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

> В два с половиной!

809380 против 2590932 - это в 3.2 раза.

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

>Как велел Бородатый.

Если бы Линус не умел думать своей головой он бы и не линукс написал а очередною недоделку на микроядре. И жда ли бы GNU до сих пор, ну может ядро FreeBSD записили бы в GNU но без Linux'а GNU вообще никому нафиг не упал кроме кучки фанатиков

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

>Файл, сжатый Snappy, весит в два раза меньше, чем исходный файл в примере от Reset.

Что за файл-то? Не верю. lzo то так не сожмет, процентов 30 в лучшем случае (например lzo-сжатие оперативки позволяет выиграть «всего» 10-18%), а тут lzo еще плотнее упаковало

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

>Вот и нечего на гугл пинать.

Как раз создается впечатление что они как в случае с zfs специально такую лицензию выбрали чтоб в ведро запихнуть нельзя было. Ведь Linux уже 20 лет как существует, а этой поделке наврядли больше пары лет, а лицензию буквально позавчера для нее выбрали

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

Так и апачу не первый год уже. И проблеме с совместимостью лицензий тоже. Проблема устранена в GPLv3, но торвальду на всё посрать, верно?

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

На разных типах данных разные упаковщики показывают себя совершенно по разному. Скажем для текста за PPPMd никто не угонится ни по скорости ни по сжатию

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

> Да, да, понятна - http://shootout.alioth.debian.org/u32/benchmark.php?test=binarytrees&lang=gcc

1. binary trees не имеет никакого отношения к многопоточности, о которой шла речь.

2. по результатам shootout, cpython сливает обычному С на порядок. Причем и по потребряемой памяти и по скорости работы.

Так что мне уже совсем непонятно что Вы хотите сказать.

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

>1. binary trees не имеет никакого отношения к многопоточности, о которой шла речь.

это легко распараллеливаемая задача. cpython как раз оптимизирован для подобных задач

cpython сливает обычному С на порядок. Причем и по потребряемой памяти и по скорости работы.


а по скорости разработки? ;) Надо решить задачу а не дрочить на такты. Некоторые программы вообще пишутся для единственного расчета. И пусть для подобных программ лучше кодер работает час и программа выполняется 10 часов чем наоборот

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

> давно апач в линукс-ядре?

Видимо, гуглу хочется, чтобы эту компрессию задвинули в Apache Hadoop. Там лицензия Apache License 2.0. А до закидонов торвальдса им дела нет.

Manhunt ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.
 ← 1 2 3 4 →
Open Source