Компания Google открыла под лицензией Apache код библиотеки Snappy (http://code.google.com/p/snappy/), в которую включен набор высокопроизводительных функций для сжатия и распаковки данных. Библиотека не поддерживает совместимость с существующими методами сжатия и не предназначена для обеспечения максимальной степени сжатия. Вместо этого все усилия разработчиков были направлены (http://code.google.com/p/snappy/source/browse/trunk/README) на создание экстремально быстрого способа сжатия и распаковки, при умеренном уровне сжатия.Код Snappy можно считать стабильным, так как он давно и активно используется в первичных проектах Google, от BigTable и MapReduce до внутренних RPC-систем. По заявлению Google, формат кодирования Snappy зафиксирован и не будет меняться в будущих версиях библиотеки. Отдельно отмечается высокая стойкость декодировщика к нарушению целости обрабатываемого потока, который разработан специально с оглядкой на исключение крахов при обработке любых входных данных....
URL: http://code.google.com/p/snappy/
Новость: http://www.opennet.ru/opennews/art.shtml?num=30003
где бы посмотреть на одноядерный CPU Core i7?
Отключить все ядра кроме одного в bios
одноядерным он от этого не станет
grub:nosmp
> где бы посмотреть на одноядерный CPU Core i7?"On a single core of a Core i7 processor" - думаю имелось в виду: "на одном ядре Core i7"
Опять не рыба не мясо. zlib жмёт достаточно быстро, при этом лучше и стандартен. А для более эффективного сжатия есть более другие алгоритмы.
> Опять не рыба не мясо. zlib жмёт достаточно быстро, при этом лучше
> и стандартен. А для более эффективного сжатия есть более другие алгоритмы.До 500MB/sec zlib-у как до луны пешком.
В статье же написано 500 Мб/с.
Мб != Mb
В русском сокращения МБ и Мб традиционно обозначают мегабайт... Мегабит обозначается как Мбит. По крайней мере чаще всего.
В оригинальной новости MB.
> Мб != Mb
> В русском сокращения МБ и Мб традиционно обозначают мегабайт... Мегабит обозначается как
> Мбит. По крайней мере чаще всего.
> В оригинальной новости MB.Не знаю что за традиции и откуда вы их взяли, но всегда считал Мб == Mb. Конечно иногда байты обозначают букой б, а биты Б, но, на мой взгляд, так де лают те личности, которые не понимает разницы: бит-байт.
>Не знаю что за традиции и откуда вы их взялиони вокруг нас
Какие, например?
> Опять не рыба не мясо. zlib жмёт достаточно быстро, при этом лучше
> и стандартен. А для более эффективного сжатия есть более другие алгоритмы.не, zlib жмёт недостаточно быстро.
а вообще, слова "достаточно"/"недостаточно" рекомендуется употреблять в контексте "[не]достаточно для <назначение>", иначе фраза получается слишком мутной
> Опять не рыба не мясо. zlib жмёт достаточно быстро,Такое хорошо чтобы нахаляву диски разогнать :). Если у вас диск записывает со скоростью 150Мбайт/сек, а вы вдруг сжали данные в 2 раза и можете их жать аж со скоростью 500Мбайт/сек, то, очевидно, вы "относительно нахаляву" получили скорость записи на диск 300Мб/сек. Ну и чтение аналогично. В итоге хорошо жмущиеся данные (БД, тексты, етц) от такого сжатия еше и ускорятся, приколитесь? С zlib сие не светит, его двухстадийная схема достаточно тормознута, а за счет мелкого словаря и жмет не особо. В общем у zlib на данный момент пожалуй плюс только в распостраненности и есть. Потому что давно есть и те кто жмет намного лучше, и те кто жмет/расжимается намного быстрее. Намного - это зачастую в РАЗЫ.
И чеб такое в контроллер диска на железе не зафигачить ?
> И чеб такое в контроллер диска на железе не зафигачить ?см. RAID-контролер'с
Ну, RAID это отдельно строить надо, а чеб спрашивается в штатный контроллер диска не встроить, ну да, баксов на 20 допустим дороже получится, но так эффект зато какой, расходилось бы как горячие пирожки.
>а чеб спрашивается в штатный контроллер диска не встроитьГигабайты текстоподобных файлов на обычном диске редко хранят. В штатном случае эффект будет незаметен, так как пишут-читают бинарные/сжатые данные в основном.
В принципе да, но я б не сказал что эффект будет незаметен, всякие папки с доками, xml'ники и пр. барахло тоже частенько переливать приходится. Или вот у меня например инсталляха AdobeCS5 7 гигов, а жатая 5, понятно что там степень сжатия меньше, но всеравно сотни метров можно сэкономить, а еще в архиве дампы базы, на 3 гига, они вообще жмутся хорошо, так что по моему есть варианты, и по скорости, пусть и не в разы, и по объему.
Ну и какой объем у этого диска получится? Он же будет зависеть от того, какие данные на него пишешь. Не говоря уже о прелестях восстановлении после сбоев...
Объем номинальный, точно так же как и при обычном архивировании, вы же не считаете что после этого у вас вырос объем диска. И какие проблемы с восстановлением ?
> И чеб такое в контроллер диска на железе не зафигачить ?В принципе этому ничего не мешает особо. Только проц - вот он, уже есть, потому что без него - никуда. И не факт что на 100% загруженный. А контроллер, знаете ли, покупать еще надо. Что несколько портит карму данному решению. Вот такие решения - они возможность условно-НАХАЛЯВУ повысить скорость работы дисков в некоторых случаях :)
Понятно что будет дороже, но так ли критично, скажем имеете вы диск 150 МБ/сек за 5000 р, и рядом 300 МБ/сек за 6, ну явно спрос будет ;) Технологичнее получается чем ЦП грузить.
> Технологичнее получается чем ЦП грузить.Технологичнее, только процы дуром прут и массово клепаются, а потому дешевые, производительные и не всегда загружены полностью. В итоге получается псевдо-бесплатное решение которое улучшает параметры того что есть, не требуя ничего покупать :).При таких условиях сложно будет клиентов убедить :)
А райд до кучи как обычно будет жать в некий самопальный формат. Его описать ессно забудут, и с форматом соседа с полки магазина с такой же фичой но от иного производителя он ессно будет несовместим. Поэтому если вдруг райд гавкнется и такого же не найдется - вот тут вы пожалуй ощутите все прелести этого подхода. Ну в смысле, админы/юзеры этой железки ощутят. И они как бы себе не враги лишний раз мину замедленного действия то подкладывать :)))
Не, ну понятно что у ЦП тоже варианты есть, как минимум для начала, что же касается дисковых контроллеров, именно их а RAID, то ведь тут тоже дело лишь в массовом внедрении, если клепать начнут то дорого не будет, тем более если это будет не дополнительный контроллер общего назначения на плате, а специализированный модуль внутри штатного контроллера, и единый формат при этом тоже не проблема. Внедрили же всякие NCQ и т.п, и это из той же оперы получается.
>>именно их а RAID, то ведь тут тоже дело лишь в массовом внедрении, если клепать начнут то дорого не будет,12 лет жду дешевого рэйда - а его все нет. 12 лет назад обычным был буфер 16 метров сейчас 256 минимальный. Но дешеветь они и не думают. Программную ерунду вроде интегрированных в чипсеты естественно за RAID не считаю.
Не получили Вы скорость записи на диск в 300Мб/сек, потому что данные вы сжали, но время сжатия не посчитали. Если учтёте, получите ~187 Мб/сек, что не так уж и много.
А зачем его считать если сжатие идет быстрее записи и параллельно ей ?
Ну хорошо, по сжатию в 2 раза хуже zlib, а по скорости при этом как ? Молчек. Если лучше в те же 2 раза то смысла то нет.
Автор говорит, в 10. http://blog.sesse.net/blog/tech/2011-03-22-19-24_snappy.html
Ну тогда серьезно.
Блин, жалко что C++, а то попробывал использовать бы у себя в проекте.
Да, совсем не понятно зачем оно C++
перепишите на яву (или что там у вас), потестируйте. потом узнаете, почему
У меня "там" чистый С.
Перепиши и протестируй. Особенно совместимость посмотри - полезно будет.
extern "C" {} не спасёт?
Прочитал дальше ветку. Извиняюсь.
Впрочем, там код не сложный.
Я бы взялся переписать, если бы мне нужно было/заплатили.
Проблема не в сложности переписывания.
Проблема в необходимости оптимизации переписанного кода, тонком понимании во что это превратится после компиляции и, разумеется, в стабильности. Т.е. код должен быть супер стабильным и вообще без ошибок.
Ценность кода от гугла именно в этом - он прошел экстра-супер-пупер тестирование. в Их проектах.
то есть код ты так и не смотрел? давай, тролль дальше о неких совместимостях и тонкостях оптимизации при переходе с плюсов на си, о хождениях по классам для поиска функций и прочих твоих теоретических выкладках.
> Блин, жалко что C++, а то попробывал использовать бы у себя в
> проекте.Ну так и используйте если хотите, или ваш проект не может пристегивать внешние модули ?
так это ж читать надо. знать, что такое нативная функция... а вообще, мне страшно за такие проекты
Лучше бы на Си.
чем лучше, поясните
> чем лучше, пояснитеТем, что во встраиваемых решениях не попользуешь из-за отсутствия компилятора Си++
приведите, пожалуйста, пример встроенной системы, в которой вы имели бы желание использовать snappy, но вынуждены отказаться в основном ввиду описанных вами выше ограничений
> приведите, пожалуйста, пример встроенной системы, в которой вы имели бы желание использовать
> snappy, но вынуждены отказаться в основном ввиду описанных вами выше ограничениймикроконтроллеры
>> приведите, пожалуйста, пример встроенной системы, в которой вы имели бы желание использовать
>> snappy, но вынуждены отказаться в основном ввиду описанных вами выше ограничений
> микроконтроллерыЕсли в контроллер влезает код библиотеки такого размера - он по определению поддерживает с++.
дык и перепишите. благо, исходники на плюсах именно этого проекта всего лишь 100kB!
> дык и перепишите. благо, исходники на плюсах именно этого проекта всего лишь
> 100kB!А время и желание есть? Зачем переписывать snappy на Си, если есть гораздо более компактные и проверенные временем аналоги типа LZO со сравнимой производительностью?
зачем тогда вообще поднимать сыр-бор из-за каких-то 100 килобайт исходников? есть что-то другое - используйте, кто ж спорит. :)
> Ну так и используйте если хотите, или ваш проект не может пристегивать
> внешние модули ?Нет не может. Есть специфичная железяка и только сишный компилятор, а С++ сильно не допилен.
Ну и вобщем, на мой взгляд подобные библиотеки лучше на Си, проще прикручивать к другим языкам.
А сишный компилер полноценный ? что за железка если не секрет ?
Замечательно что на C++, сейчас других актуальных языков и нет. И что вам мешает использовать библиотеку в проекте?
> Замечательно что на C++, сейчас других актуальных языков и нет.ORLY?
> И что вам мешает использовать библиотеку в проекте?
то, что она на цпп. придётся врапперы ваять. ну её нафиг, такую библиотеку, для zlib ничего писать не надо.
О, как заминусовали-то =) Нет, я не против С++, просто тот проект над которым я работаю предполагает именно Си, и да, С++ вообще нет возможности использовать.
ну неужто там нет простого API? o_O
>ну неужто там нет простого API? o_OА какое там может быть API? Есть набор Си-шных исходников. Они компилируются. В итоге получается некий бинарный образ, который прошивается в железку. Где в этой цепочке может быть какой-то API, который поможет прикрутить код на С++ ?
для особо тяжелых случаев исходники можно и конвертнуть и избавиться от ОО. если вы заглядывали в исходники, то наверняка видели, сколько их там по объему.
>который прошивается в железкупрямо хардкор какой-то. например, линукс-базированные решения, которые тоже прошиваются в железку. и что? у них нет никакого API? не спора ради, просто думается, что товарисч работает всё-таки на обычном компе (ну или ембеддед), с количеством памяти, позволяющим делать malloc для объектов. или он программирует фотоаппараты, или еще что-то такое уж шибко экзотическое? вот в чем вопрос.
> О, как заминусовали-то =) Нет, я не против С++, просто тот проект
> над которым я работаю предполагает именно Си, и да, С++ вообще
> нет возможности использовать.Я думаю, минусанули потому что думали, что подразумевается что-то типа java как "альтернатива". Обычно именно фанаты подобного любят вслух сожалеть о чем-то сделаном на С/C++.
extern "C"
>extern "C"Мимо. Это помогает в обратной ситуации (прикрутить Си-шный код в C++ программу)
>>extern "C"
> Мимо. Это помогает в обратной ситуации (прикрутить Си-шный код в C++ программу)Как раз наоборот.
>>>extern "C"
>> Мимо. Это помогает в обратной ситуации (прикрутить Си-шный код в C++ программу)
> Как раз наоборот.Точнее, в обе стороны работает.
>>>extern "C"
>> Мимо. Это помогает в обратной ситуации (прикрутить Си-шный код в C++ программу)
> Как раз наоборот.а вот здесь мы видим случай так называемого ламеризма.
На чём умеют, на том и пишут.
Было бы не плохо использовать как метод сжатия файловых систем (вместо zlib у btrfs) - я думаю скорость работы существенно возрастет. Хотя могу ошибаться.
Тада. Где-то выхватывал сравнительную таблицу для zlib и lzo, lzo рулил за счёт быстрой распаковки и быстрого определения несжимаемых данных.Хачу в zfs.
> Было бы не плохо использовать как метод сжатия файловых систем (вместо zlib
> у btrfs)1) Там уже поюзали LZO. Он довольно резвый. Не чемпион, но весьма даже шпарит, особенно по скорости декомпрессии.
2) Бакланы из гугли зачем-то поюзали си++. Как вы себе представляете себе оный в ядре? В общем велосипедисты такие велосипедисты :)
Чем Вас не устраивает С++?
Проект был открыт и за это спасибо. А если у некоторых бакланов не получается его пристроить в ядро, то это исключительно их проблемы.
> Чем Вас не устраивает С++?Тем что в ядрах и эмбеддовке он пролетает, разумеется. При том что скорость там как раз обычно важна. Вот тем и не устраивает.
> Проект был открыт и за это спасибо. А если у некоторых бакланов
> не получается его пристроить в ядро, то это исключительно их проблемы.Ну так пристройте, если такой писец умный. В эмбеддовке извините поюзаные гуглем либы легко выжрут всю память под себя. Тогда как какойнить LZO умеет быть и весьма скромным в своих требованиях, например, минимальный декомпрессор - считанные сотни байтов кода, не требуют оперативы (кроме источника и назначения) и никаких либ вообще (в чисто-алгоритмической байде они в общем то понты и навороты). Такой подход сильно расширяет сферу применения, не в обиду велосипедистам гугеля.
>[оверквотинг удален]
> скорость там как раз обычно важна. Вот тем и не устраивает.
>> Проект был открыт и за это спасибо. А если у некоторых бакланов
>> не получается его пристроить в ядро, то это исключительно их проблемы.
> Ну так пристройте, если такой писец умный. В эмбеддовке извините поюзаные гуглем
> либы легко выжрут всю память под себя. Тогда как какойнить LZO
> умеет быть и весьма скромным в своих требованиях, например, минимальный декомпрессор
> - считанные сотни байтов кода, не требуют оперативы (кроме источника и
> назначения) и никаких либ вообще (в чисто-алгоритмической байде они в общем
> то понты и навороты). Такой подход сильно расширяет сферу применения, не
> в обиду велосипедистам гугеля.ты в код смотрел?
связь между языком программирования (в данном случае c/c++), встраиваемыми системами и потреблением памяти существует только в воображении таких горлопанов как ты. аргументируй (фактами, цифрами, ссылками, а не своими безграмотными домыслами) или вали
Плюсам не место в эмбеддед и ядре. Хочешь фактов вот тебе пара. С++ не умеет сериализацию не то что классов, но даже структур. Это раз. Два - это то, что плюсы при правильном (объектном) использовании чрезвычайно много усилий тратят на хождение по классам для поиска функции, подлежащей вызову в данный момент.А теперь попробуй ты представить какие-нибудь факты, цифры и т.д. в полюзу плюсов. Или только яйцами звенеть можешь?
ахаха
аццкий отжиг "хождение по классам для поиска функций" :)
вот такие люди как ты, нихрена не понимающие как плюсы вообще работают, громче всех кричат какие они плохие
погугли что ли что такое таблица виртуальных функций и как она используется
> Плюсам не место в эмбеддед и ядре. Хочешь фактов вот тебе пара.
> С++ не умеет сериализацию не то что классов, но даже структур.
> Это раз. Два - это то, что плюсы при правильном (объектном)
> использовании чрезвычайно много усилий тратят на хождение по классам для поиска
> функции, подлежащей вызову в данный момент.
> А теперь попробуй ты представить какие-нибудь факты, цифры и т.д. в полюзу
> плюсов. Или только яйцами звенеть можешь?Когда-то на заре интернета у меня появилась звуковуха со встроенным FM-ресивером. С ней шла программа на дискетке (на всю дискетку) с кучей интерфейса и минимумом фишек. В памяти жрала несколько метров и судя по всему была написана на сях. Спустя некоторое время я нашёл другую програму, которая могла управлять приёмником. Переборов уже глубоко въевшееся презрение к дельфам и написанному на них софту загрузил. Программа весила 54 килобайта и в памяти занимала где-то 200.
Так я в первый раз понял, что виноваты не дельфы и не паскаль, а идиоты которые лезут писать программы или комментировать чужой код не имея представления ни о программировании ни о возможностях языка.
А вот интересно, если zlib или чтото аналогичное на аппаратном уровне в проце реализовать, ну там типа SSE6, то оно ведь и быстрее и сильнее получится, чеб нет ?
> А вот интересно, если zlib или чтото аналогичное на аппаратном уровне в
> проце реализовать, ну там типа SSE6, то оно ведь и быстрее
> и сильнее получится, чеб нет ?
А оно у них точно лучше чем quicklz? А то на http://quicklz.com/bench.html скорости указаны весьма некислые - и 300 и 500 мб/сек на core i7 есть. Ладно, при случае сравним. Хотя писать такой проект на си++ имхо долбоклюйство. А чего там си++ требует? У них там такие офигенные алгоритмы? Зато во всякие кернелы и половину эмбеддовки оно такое гарантированно не попадет. Я еще понимаю когда на си++ пишут реально мощный компрессор с рекордным сжатием, но либу ориентированную на скорость иожно было бы и на сях родить.
Да уж, если http://quicklz.com/bench.html реально, то значительного опережения никак не получается. Очередной гуглопиар ?
Пиар не пиар а quicklz как минимум не гугла, да и лицензии Apache vs GPL, не в курсе, разница есть ?
> А оно у них точно лучше чем quicklz? А то на http://quicklz.com/bench.html
> скорости указаны весьма некислые - и 300 и 500 мб/сек на
> core i7 есть. Ладно, при случае сравним. Хотя писать такой проект
> на си++ имхо долбоклюйство. А чего там си++ требует? У них
> там такие офигенные алгоритмы? Зато во всякие кернелы и половину эмбеддовки
> оно такое гарантированно не попадет. Я еще понимаю когда на си++
> пишут реально мощный компрессор с рекордным сжатием, но либу ориентированную на
> скорость иожно было бы и на сях родить.Что ты все время недоволен? Множество хороших проектов написано вообще на всяких питонах и жабах. У тебя помещательство на кернелах и ембеддовке. Нужно на С - будь мужиком, возьми и перепиши, а не ной тут.
> Что ты все время недоволен? Множество хороших проектов написано вообще на всяких
> питонах и жабах.Понятия о прекрасном у всех разные.
> У тебя помещательство на кернелах и ембеддовке.
Я не виноват что там быстрые и эффективные алгоритмы в почете. Ы?
> Множество хороших проектов написано вообще на всяких питонах и жабах.например? нет, эклипс — это не «хороший проект». бинс тоже.
Гугл не пишет на C. Вообще. А писано оно "под себя". Теперь вот открыли просто.
\\оффтопик
а когда в линуксе при установке новой/ещё одной библиотеки реализующей сжатие/разжатие бтрфс сразу сможет использовать этот алгоритм ? а ещё бекапер, karc и браузер...есть вобще такие оси ? и чтоб живые оси ?
Нету. Черт побери. Мне вот тоже интересно, когда что-нибудь появится с нормальным компонентным подходом.
> \\оффтопик
> а когда в линуксе при установке новой/ещё однойДа! Почему установленный Info-ZIP после установки unrar из non-free **сразу** не научился rar-архивам?! Сволочи же!!?
В readme к библиотеке сказано, что код оптимизирован для 64-битных систем с x86 архитектурой. Для других систем он вряд ли даст выигрыш в сравнении с тем же LZO. Судя по описанию, он использует чтение 64-битных величин по произвольному адресу - на ARM такое уже не прокатит (там игнорируются младшие биты адреса), компилятор может это и исправит - будет читать 8 байт и складывать в одну переменную (или в две - для 32-битов). Это уже значительное замедление. Если взять процессор по типу XBox-ового, там та же проблема, процессор даже генерит исключение при попытке читать слово по невыровненному адресу. В общем, похоже что этот код имеет плюсы только для одной платформы.
>Если взять процессор по типу XBox-ового, там та же проблема, процессор даже генерит исключение при попытке читать слово по невыровненному адресуЕсли речь идет о Xbox 360, то у PPC невыровненный доступ к памяти не только возможен, но и оптимизирован (в отличие от большинства RISC-архитектур, на которых эта операция запрещена или работает медленно)