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

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

:) Забываю, видимо, потихоньку, как писать по-русски.

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

> Лучше бы на PHP, или на PHP c Zend если так важна скорость исполнения кода. /fixed

Тролить, так тролить, чего уж мелочиться...

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

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

Зачем, если можно использовать не переписывая?

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

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

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


Ну, если кепка от Fred Perry, майка от Adidas, а штанцы и кроссы от Puma, то данные обязательно от Google.

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

майка от Adidas, а штанцы и кроссы от Puma

Фу, Ну разве так можно? Смешивать Риту а Абибос не красиво.

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

граммар-наци

результирующие файлы но на 20-100% больше


Пофиксите уже, глаза режет!

vspider ★★
()

Респект гуглу! Некрософтокапец уже не за горами.

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

И сейчас ты нам всем расскажешь, какие преимущества и кому даёт несовместимость с предыдущей версией GPL.

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

Я если читаю об улучшении или ускорении или увеличении на 2-3 порядка, то мысленно прикидываю как двоичные порядки, ну максимум - четверичные.

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

DarkFlame ★★
()

Очень актуально. Как раз в новом проекте сейчас lzo стал использовать для максимизации скорости. Пока еще есть возможность сменить алгоритм сжатия.

Reset ★★★★★
()

>далёк от рекордных показателй

показателй


БЕЗНОГNМ

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

Как раз в новом проекте сейчас lzo стал использовать для максимизации скорости.

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

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

Как оно по сравнению с lzo?

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

Я мог бы ответить, но вслух как-то стыдно произносить...

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

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

Это значит по степени сжатия до Zlib он не дотягивает?

Видимо это значит, что он

а) работает быстрее Zlib

б) иногда не сжимает, а растягивает файлы

Короче, мощная штукенция. Первая в своей нише. :)

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

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

победит как всегда убунта?

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

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

с возможностями и скоростью исполнения присущей Си.

...

И что, действительно так быстро работает? Ссылку на бенчмарки скинуть слабо?

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

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

Python - тормоз by-design. Быстрым его сделать не получится.

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

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

По поводу высказывавшихся выше про реализацию на Python, или Cython - вы что бля курили? Cython - полумертвое убогое гавно, которое нужно выкинуть за наличием гораздо более мощного и умного PyPy. А реализовать библиотеку для сжатия на Python, мог предложить только идиот. Другое дело, если к библиотеке на C/C++ сделать биндинг в качестве либы для Python - другой разговор. Это основной подход реализации критичных алгоритмов на Python, да и практически на любом интерпретируемом языке.

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

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

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

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

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

Python - тормоз by-design. Быстрым его сделать не получится.

Он и не проектировался как супер скоростной. Интепретируемый язык по определению не на целен на скоростные ниши нативных языков. Он имеет другие приоритеты. А для критичных задач, используется написание библиотек на том же C, с дальнейшей привязкой как библиотека Python. Если кто то сомневается в возможности быстрых программ на Python: DropBox(серверная часть, и клиентская), YouTube, Sublime Text(GUI редактор, вот вам и пример быстрого питона, когда на нем пишут правильно).

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

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

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

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

да уж точно, между C и C++ такая разница гигантская, это же языки совершенно разного уровня, поэтому не удивительно!

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

Как человек, который этот вопрос задал, объясняю: я на свой вопрос не ответил.

Если бы гугл страдал такой ненавистью к GPL, как всякие iZEN'ы то он бы в ведроиде использовал FreeBSD, а не Linux, и на своих серверах тоже.

А выпуск сабжа под Apache License вместо BSDL/MIT никакой пользы ему не принесёт: если кто захочет на основе сабжа сделать продукт под копилефт-лицензией, то он его сделает. А трудности будут только при желании включить сабж в уже существующую программу, которая под GPL2 only. И Столлман тут ни при чём, он под GPLvN-only выпускать не учил.

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

> то он бы в ведроиде использовал FreeBSD, а не Linux

Linux гуглу не принадлежит и используют его только потому что дешевле использовать Linux чем пилить свою поделку. Вот с жаба-машиной решили что своя поделка будет дешевле

А трудности будут только при желании включить сабж в уже существующую программу


Думаешь гугл хочет чтоб сабж включали в уже существующие программы? ;) Поднасрать Гугл любит не меньше Мелкосакса

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

>И Столлман тут ни при чём, он под GPLvN-only выпускать не учил.

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

DNA_Seq ★★☆☆☆
()

Интересно было бы посмотреть на опциональное применение такой штуки в БД, в частности в MongoDB

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

>да уж точно, между C и C++ такая разница гигантская

Разница на 4 потоках ровно в 4ре раза =)

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

В GPL3 написано:

Следующие версии лицензии могут давать Вам дополнительные или другие разрешения. Несмотря на это, дополнительные обязательства не возлагаются на автора или правообладателя как результат Вашего выбора следующих версий.


Так что можно подписываться, ничего плохого не будет.

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

>Linux гуглу не принадлежит и используют его только потому что дешевле использовать Linux чем пилить свою поделку.

А зачем пилить, если есть FreeBSD? Оно ведь умеет работать.

Думаешь гугл хочет чтоб сабж включали в уже существующие программы?


А зачем тогда выложил?

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

Думаю гуглу не жалко, чтобы его софт использовали. В частности, если знать политику гугла, то наверное 95%, если не 100% разработчиков гугла, пилят свои проекты, на что гугл еще и дает один день на рабочей неделе. И таки, эти наработки весьма вероятно используются и в самом гугле, а авторам не жалко выложить эти наработки в общественное пользование.

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

>А зачем пилить, если есть FreeBSD? Оно ведь умеет работать.

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

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

Если бы выложили под совместимой с GPL лицензией, этот пиар-ход был бы немного более продуктивным при абсолютно тех же затратах.

Ttt ☆☆☆☆☆
()

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

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

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

При записи на физический диск, а не в /dev/null?

Кто тебе такое сказал?

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

>А зачем пилить, если есть FreeBSD? Оно ведь умеет работать.

Да ну? Неужели? А почему новости на главной об этом не было?

Led ★★★☆☆
()

Затестил на своих данных.

$ ls -s big-file 
2590932 big-file

$ ls -s big-file.snappy 
1030744 big-file.snappy

$ ls -s big-file.lzo 
659332 big-file.lzo

$ cat big-file | cpipe   -vt  | lzop --fast > /dev/null
...
thru:   0.176ms at  621.4MB/s ( 130.3MB/s avg)    2.5GB

$cat big-file | cpipe   -vt  | ./a.out > /dev/null
....
thru:   0.581ms at  188.3MB/s ( 170.1MB/s avg)    2.5GB
Reset ★★★★★
()
Ответ на: комментарий от eveel 
$ g++ -O2 do-all.cpp .libs/libsnappy.a
$ cat do-all.cpp 
#include <stdio.h>

#include <string>
#include <vector>

#include "snappy.h"

using namespace std;

int main(int argc, char ** argv)
{
        char buf[8129];
        size_t bytes;
        vector < char > output;
        FILE * f = stdin;

        while ((bytes = fread(buf, 1, sizeof(buf), f)) > 0) {
                output.resize(snappy::MaxCompressedLength(bytes));
                size_t output_length;
                snappy::RawCompress(buf, bytes, &output[0], &output_length);
                fwrite(&output[0], 1, output_length, stdout);
        }
        return 0;
}
Reset ★★★★★
()
Ответ на: комментарий от Ttt

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

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

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