LINUX.ORG.RU

Библиотека для сжатия данных от 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 ()

Правильно. Увидел на опеннете - запили свой вариант на ЛОР.

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

Правильно. Увидел на опеннете - запили свой вариант на ЛОР.

Конечно правильно - опеннет я не читаю, а мнения посмотреть охота.

Ximen ★★★★ ()

Даешь упакованый энторнет!

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

Даешь упакованый энторнет!

А я сразу подумал, что, наверное, для фс оно подходит больше.

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

Ну гугл у меня пока еще ассоцииируется с интернетом. Хотя идея «упакованного» интернета сейчас не актуальна. Быстрый своп...

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

Хотя идея «упакованного» интернета сейчас не актуальна.

Ну да. Торренты и так зажатые, а всё остальное уже не тормозит :)

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

О свопе это.. пардон, в общем, я сегодня особые тупости могу сказать)

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

polym ()

>не совместима
>коэффициент сжатия также далёк

>Так, например, для большинства входных данных Snappy оказывается на порядок быстрее, чем Zlib в режиме максимальной скорости, а результирующие файлы но 20% - 100% больше


конкурент LZO ? иначе что-то малоинтересное получается... сравнение бы

zlib - snappy - lzo

Sylvia ★★★★★ ()

>Вместо этого целью разработки является максимальная скорость работы при сохранении приемлемого сжатия.
Сравнение с gzip в студию!

fractaler ★★★★★ ()

Ждём реализации в железе с упаковкой траффика данных между
процессором и памятью и процессором и периферией :))

sS ★★★★★ ()

Прикольно, гугл молодцы

yoghurt ★★★★★ ()

Ждем нытиков, которые будут вопить про богомерзкий C++, лучше бы на С, и что либо из-за этого не впихнуть в ядро и ембеддовку.

anonymous ()

Нет ничего быстрее -mx=0

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

С костылей на Си нетрудно будет переписать скорее всего.

quantum-troll ★★★★★ ()

>Snappy оказывается на порядок быстрее, чем Zlib в режиме максимальной скорости, а результирующие файлы но 20% - 100% больше
Это значит по степени сжатия до Zlib он не дотягивает?

dkBrazz ()

А почему Google так Apache License любят? Она же плохо совместима с GPL. Лучше бы под модифицированной BSDL или MIT License выпускали, где такой проблемы нет.

Ttt ☆☆☆☆☆ ()

Ждём новостей: Фороникс провёл сравнительное тестирование Zlib, LZO, Snappy.

pimiento ()
Ответ на: комментарий от quantum-troll

Мимолётный взгляд на сорцы говорит, что там и так половина на C.
Вообще не понятно зачем были прикручены плюсы.

И да, пусть гугл перепишет на C. На C++ такое не нужно.

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

> И да, пусть гугл перепишет на C. На C++ такое не нужно.

Кто-то считает, что гугл ему что-то должен?

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

>На порядок быстрее не годится?

на какой именно порядок?

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

Лучше бы выпускали как общественное достояние, лицензии вроде BSD или MIT не нужны.

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

Лучше бы у бабушки был... Под чем выкинули, за то и спасибо.

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

> А почему Google так Apache License любят? Она же плохо совместима с GPL.

Apache PL идеально совместима с современной версией GPL ;)

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

>> на какой именно порядок?

wikipedia:

Порядок величины — количество цифр в числе. О двух величинах говорят, что они одного порядка, если отношение большего к меньшему из них меньше 10. Таким образом, выражение на порядок больше (или меньше) означает приблизительно в 10 раз больше (или меньше), выражение на два порядка больше означает приблизительно в 100 раз больше и т. д.

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

> Ждём реализации в железе с упаковкой траффика данных между процессором и памятью и процессором и периферией :))

Ну, учитывая, что именно соединения становятся узким местом в скорости, я бы не удивился. :)

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

А почему Google так Apache License любят? Она же плохо совместима с GPL.

Она хорошо совместима с GPLv3 =).

mironov_ivan ★★★★★ ()

На одном ядре процессора Core i7 в 64-битном режиме скорость сжатия составляет более 250 Мб/сек

Во-первых, Core i7 бывают разные, модель с студию. Во-вторых, значит ли это, что остальные ядра/потоки простаивали и что будет, если запустить 4 или 8 операций разом (программа-то серверная)? Вопрос не праздный, поскольку непонятно, насколько это критично к размеу кеша, который L3 у Core i7, как известно, общий, и будучи поделён между 8 потоками пропорционально уменьшится. Более того L2 тоже общий на каждую пару потоков.

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

Вопрос не праздный, поскольку непонятно, насколько это критично к размеу кеша

Собрать библиотку - 2 минуты. Пользоваться тоже не сложно:

snappy::Compress(input, &output);
Сделай все необходимые тесты и расскажи, что и как. У меня нет ниодного i7 в пределах досягаемости, а приведённые цифры - это, что гугол посчитал нужным рассказать.

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

Сделай все необходимые тесты и расскажи, что и как. У меня нет ниодного i7 в пределах досягаемости, а приведённые цифры - это, что гугол посчитал нужным рассказать.

Пока некогда, может когда и соберу, ни одного i7 у меня тоже нет, кстати.

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

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

> Пока некогда, может когда и соберу, ни одного i7 у меня тоже нет, кстати.

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

По ссылке в новости сходить - тоже видимо некогда?

Зато по...деть время всегда находится :)

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

>Ждем нытиков, которые будут вопить про богомерзкий C++, лучше бы на С, и что либо из-за этого не впихнуть в ядро и ембеддовку.

Лучше бы на Python, или на Cython если так важна скорость исполнения кода.

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

По ссылке в новости сходить - тоже видимо некогда?

ОК, сходил, порсмотрел. Действительно, теперь источник сих цифр ясен.

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

Зачем ты сбежал из сказки «Три толстяка»?

mono ★★★★★ ()

Zlib явно проиграет в скорости. А вот сравнение с LZO хотелось бы увидеть.

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

>Зачем ты сбежал из сказки «Три толстяка»?

А ты видимо не почитал о том, что такое Cython? Для Ъ: Cython — это почти компилируемый Python с возможностями и скоростью исполнения присущей Си.

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

> А ты видимо не почитал о том, что такое Cython? Для Ъ: Cython — это почти компилируемый Python с возможностями и скоростью исполнения присущей Си.

Стоп, я тоже обожаю Python и Cython, но тут реально толстовато. Cython всё равно использует всю динамику, присущую Python, не может там быть одинаковой скорости с С. Даже, полагаю, если весь код в cdef запхать.

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

У некоторых красноглазых порядки двоичные или шестнадцатиричные.

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

Умник, все верно. Если я задам размерность порядка в двоичном числе, то ничего ни с кем не случится.

Например: «больше на 2 порядка» или «больше на 10 (в двоичном числе) порядка».

anonymous ()

На самом деле плохо понимаю погоню чисто за скоростью сжатия/распаковки. Так можно и простое разделение мантиссы и экспоненты использовать. Надо стараться минимизировать (время_распаковки_сжатия + размер_сжатого_файла).

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

а можно интимный вопрос? зачем Python'овские фичи для написания архиватора?

mono ★★★★★ ()
Ответ на: комментарий от quantum-troll

>С костылей на Си нетрудно будет переписать скорее всего.

Да зачем Си, на Гоу надо все переписывать.

anonymous ()

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

При первом прочтении возник вопрос: «зачем сжимать данные от Googl?»

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