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 ()
Последнее исправление: shahid (всего исправлений: 3)
Ответ на: комментарий от DNA_Seq

> исходники в тестах приведены

это ничтожные исходники, иначе не было бы такой разницы. крайне сомневаюсь, что программа на C может быть медленнее чем на C++, и наоборот. в общем, это либо пиар, либо дилетанты занимались тестированием... вот если бы ты сказал, что программа на PHP медленнее чем на C++ в 4 раза, то это более правдоподобное заявление, но при правильном подходе к решению задачи тоже маловероятно.

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

>программа на C может быть медленнее чем на C++, и наоборот.

могут, если используют разные библиотеки. Местами кстати жаба на первом месте =))

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

>> если используют разные библиотеки

ах ну да, теперь понятно, ключевое слово - «библиотека»... можно к примеру взять роман «Войну и мир», прочитать и забыть, а можно пролистать пару стихотворений Пушкина и понять смысл бытия... использование языка, не есть использование библиотеки, не нужно путать.

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

>использование языка, не есть использование библиотеки,

чаще всего так и есть. Вот допустим использовали в программе вместо си-строк класс string и получили мягко говоря отличные от сишных результаты. Цель сравнений выявлять не сходство но различия

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

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

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

> Что за файл-то? Не верю.

Это к Reset вопросы.

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

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

А зачем вы вообще смотрите на Cython? И сравниваете с С? Скоростной Python - это же PyPy (http://pypy.org). JIT-компиляция на месте. Продолжение проекта Psycho, на котором работает YouTube.

И вообще, а в чем смысл сравнивать C и Python? Горячее с мягким вроде как не сравнивают обычно, не?

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

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

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

Вот это жесть. В сорцах PPMd.exe и в makefile'е gcc пытается запуститься командой Gcc :) Что-то я уже сомневаюсь, что эта программа будет работать если соберется :)

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

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

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

Отлично. Покажете ссылку на сравнение производительности решения этой задачи на C и Python, где было бы произведено это самое распараллеливание?

Пока же я вижу, что в однопоточном варианте CPython слил просто позорно. И я все еще считаю, что настоящего параллелизма на нем до сих пор нет.

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

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

В жизни много чего бывает. И, к сведению, бывает так, что разница в скорости выполнения очень даже существенна. Надеюсь, с этим спорить не будете? :)

Что до скорости разработки - Haskell меня больше радует. Да и скорость исполнения там лучше. Ну и в довесок, он таки поддерживает SMP в отличии от этих CPython.

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

> И вообще, а в чем смысл сравнивать C и Python? Горячее с мягким вроде как не сравнивают обычно, не?

Не я начал. См. изначальный пост. Там sans-serif'ом по background'у написано, что дескать CPython так же быстр как C.

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

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

Это gil'ом то? Спасибо, посмеялся.

И пусть для подобных программ лучше кодер работает час и программа выполняется 10 часов чем наоборот

Тебя обманули, python медленнее в 100 раз, поэтому программа работать будет 100 часов. Именно поэтому на python'е пишут только мелкие скрипты и гуйню, а не серьезные приложения.

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

Не работает оно даже с бубунтоидными патчами. Сегфолтится. В общем не судьба.

Reset ★★★★★
()
Ответ на: комментарий от DNA_Seq
$ time -p 7z a -t7z /dev/shm/archive.7z big-file -m0=PPMd

7-Zip 4.57  Copyright (c) 1999-2007 Igor Pavlov  2007-12-06
p7zip Version 4.57 (locale=ru_RU.UTF-8,Utf16=on,HugeFiles=on,16 CPUs)
Scanning

Creating archive /dev/shm/archive.7z

Compressing  big-file      

Everything is Ok
real 202.05
user 200.80
sys 1.25

$ ls -s /dev/shm/archive.7z
251048 /dev/shm/archive.7z

Получаем 12.82M/s. В общем, неюзабельно.

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