The OpenNET Project / Index page

[ новости /+++ | форум | wiki | теги | ]

форумы  помощь  поиск  регистрация  майллист  вход/выход  слежка  RSS
"Компания Google открыла код Snappy, библиотеки для сжатия да..."
Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Изначальное сообщение [ Отслеживать ]

"Компания Google открыла код Snappy, библиотеки для сжатия да..."  +/
Сообщение от opennews (??) on 23-Мрт-11, 12:59 
Компания 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

Ответить | Правка | Cообщить модератору

Оглавление

Сообщения по теме [Сортировка по времени | RSS]


1. "Компания Google открыла код Snappy, библиотеки для сжатия да..."  +4 +/
Сообщение от Timka (??) on 23-Мрт-11, 12:59 
где бы посмотреть на одноядерный CPU Core i7?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

3. "Компания Google открыла код Snappy, библиотеки для сжатия да..."  +/
Сообщение от Аноним (??) on 23-Мрт-11, 13:17 
Отключить все ядра кроме одного в bios
Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

7. "Компания Google открыла код Snappy, библиотеки для сжатия да..."  +4 +/
Сообщение от Timka (??) on 23-Мрт-11, 13:51 
одноядерным он от этого не станет
Ответить | Правка | ^ к родителю #3 | Наверх | Cообщить модератору

30. "Компания Google открыла код Snappy, библиотеки для сжатия да..."  +2 +/
Сообщение от pavlinux (ok) on 23-Мрт-11, 15:31 
grub:

nosmp

Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

61. "Компания Google открыла код Snappy, библиотеки для сжатия да..."  +1 +/
Сообщение от Brick (??) on 23-Мрт-11, 21:53 
> где бы посмотреть на одноядерный CPU Core i7?

"On a single core of a Core i7 processor" - думаю имелось в виду: "на одном ядре Core i7"

Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

2. "Компания Google открыла код Snappy, библиотеки для сжатия да..."  +/
Сообщение от Аноним (??) on 23-Мрт-11, 13:06 
Опять не рыба не мясо. zlib жмёт достаточно быстро, при этом лучше и стандартен. А для более эффективного сжатия есть более другие алгоритмы.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

5. "Компания Google открыла код Snappy, библиотеки для сжатия да..."  +4 +/
Сообщение от Аноним (??) on 23-Мрт-11, 13:24 
> Опять не рыба не мясо. zlib жмёт достаточно быстро, при этом лучше
> и стандартен. А для более эффективного сжатия есть более другие алгоритмы.

До 500MB/sec zlib-у как до луны пешком.

Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

9. "Компания Google открыла код Snappy, библиотеки для сжатия да..."  +1 +/
Сообщение от Nxx email(ok) on 23-Мрт-11, 14:06 
В статье же написано 500 Мб/с.
Ответить | Правка | ^ к родителю #5 | Наверх | Cообщить модератору

36. "Компания Google открыла код Snappy, библиотеки для сжатия да..."  +/
Сообщение от Аноним (??) on 23-Мрт-11, 16:43 
Мб != Mb
В русском сокращения МБ и Мб традиционно обозначают мегабайт... Мегабит обозначается как Мбит. По крайней мере чаще всего.
В оригинальной новости MB.
Ответить | Правка | ^ к родителю #9 | Наверх | Cообщить модератору

72. "Компания Google открыла код Snappy, библиотеки для сжатия да..."  +/
Сообщение от Аноним (??) on 24-Мрт-11, 11:41 
> Мб != Mb
> В русском сокращения МБ и Мб традиционно обозначают мегабайт... Мегабит обозначается как
> Мбит. По крайней мере чаще всего.
> В оригинальной новости MB.

Не знаю что за традиции и откуда вы их взяли, но всегда считал Мб == Mb. Конечно иногда байты обозначают букой б, а биты Б, но, на мой взгляд, так де лают те личности, которые не понимает разницы: бит-байт.

Ответить | Правка | ^ к родителю #36 | Наверх | Cообщить модератору

94. "Компания Google открыла код Snappy, библиотеки для сжатия да..."  +/
Сообщение от Аааа on 30-Мрт-11, 10:28 
>Не знаю что за традиции и откуда вы их взяли

они вокруг нас

Ответить | Правка | ^ к родителю #72 | Наверх | Cообщить модератору

11. "Компания Google открыла код Snappy, библиотеки для сжатия да..."  +/
Сообщение от FractalizeR email(ok) on 23-Мрт-11, 14:10 
Какие, например?
Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

19. "Компания Google открыла код Snappy, библиотеки для сжатия да..."  +4 +/
Сообщение от 123456 (??) on 23-Мрт-11, 14:29 
> Опять не рыба не мясо. zlib жмёт достаточно быстро, при этом лучше
> и стандартен. А для более эффективного сжатия есть более другие алгоритмы.

не, zlib жмёт недостаточно быстро.

а вообще, слова "достаточно"/"недостаточно" рекомендуется употреблять в контексте "[не]достаточно для <назначение>", иначе фраза получается слишком мутной

Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

23. "Компания Google открыла код Snappy, библиотеки для сжатия да..."  +/
Сообщение от User294 (ok) on 23-Мрт-11, 14:37 
> Опять не рыба не мясо. zlib жмёт достаточно быстро,

Такое хорошо чтобы нахаляву диски разогнать :). Если у вас диск записывает со скоростью 150Мбайт/сек, а вы вдруг сжали данные в 2 раза и можете их жать аж со скоростью 500Мбайт/сек, то, очевидно, вы "относительно нахаляву" получили скорость записи на диск 300Мб/сек. Ну и чтение аналогично. В итоге хорошо жмущиеся данные (БД, тексты, етц) от такого сжатия еше и ускорятся, приколитесь? С zlib сие не светит, его двухстадийная схема достаточно тормознута, а за счет мелкого словаря и жмет не особо. В общем у zlib на данный момент пожалуй плюс только в распостраненности и есть. Потому что давно есть и те кто жмет намного лучше, и те кто жмет/расжимается намного быстрее. Намного - это зачастую в РАЗЫ.

Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

26. "Компания Google открыла код Snappy, библиотеки для сжатия да..."  +/
Сообщение от Аноним (??) on 23-Мрт-11, 14:46 
И чеб такое в контроллер диска на железе не зафигачить ?
Ответить | Правка | ^ к родителю #23 | Наверх | Cообщить модератору

32. "Компания Google открыла код Snappy, библиотеки для сжатия да..."  +1 +/
Сообщение от pavlinux (ok) on 23-Мрт-11, 15:32 
> И чеб такое в контроллер диска на железе не зафигачить ?

см. RAID-контролер'с


Ответить | Правка | ^ к родителю #26 | Наверх | Cообщить модератору

59. "Компания Google открыла код Snappy, библиотеки для сжатия да..."  +/
Сообщение от Аноним (??) on 23-Мрт-11, 21:42 
Ну, RAID это отдельно строить надо, а чеб спрашивается в штатный контроллер диска не встроить, ну да, баксов на 20 допустим дороже получится, но так эффект зато какой, расходилось бы как горячие пирожки.


Ответить | Правка | ^ к родителю #32 | Наверх | Cообщить модератору

62. "Компания Google открыла код Snappy, библиотеки для сжатия да..."  +/
Сообщение от filosofem (ok) on 23-Мрт-11, 22:37 
>а чеб спрашивается в штатный контроллер диска не встроить

Гигабайты текстоподобных файлов на обычном диске редко хранят. В штатном случае эффект будет незаметен, так как пишут-читают бинарные/сжатые данные в основном.

Ответить | Правка | ^ к родителю #59 | Наверх | Cообщить модератору

63. "Компания Google открыла код Snappy, библиотеки для сжатия да..."  +/
Сообщение от Аноним (??) on 23-Мрт-11, 23:00 
В принципе да, но я б не сказал что эффект будет незаметен, всякие папки с доками, xml'ники и пр. барахло тоже частенько переливать приходится. Или вот у меня например инсталляха AdobeCS5 7 гигов, а жатая 5, понятно что там степень сжатия меньше, но всеравно сотни метров можно сэкономить, а еще в архиве дампы базы, на 3 гига, они вообще жмутся хорошо, так что по моему есть варианты, и по скорости, пусть и не в разы, и по объему.
Ответить | Правка | ^ к родителю #62 | Наверх | Cообщить модератору

69. "Компания Google открыла код Snappy, библиотеки для сжатия да..."  +/
Сообщение от вася (??) on 24-Мрт-11, 10:59 
Ну и какой объем у этого диска получится? Он же будет зависеть от того, какие данные на него пишешь. Не говоря уже о прелестях восстановлении после сбоев...
Ответить | Правка | ^ к родителю #59 | Наверх | Cообщить модератору

73. "Компания Google открыла код Snappy, библиотеки для сжатия да..."  +/
Сообщение от Аноним (??) on 24-Мрт-11, 13:02 
Объем номинальный, точно так же как и при обычном архивировании, вы же не считаете что после этого у вас вырос объем диска. И какие проблемы с восстановлением ?
Ответить | Правка | ^ к родителю #69 | Наверх | Cообщить модератору

37. "Компания Google открыла код Snappy, библиотеки для сжатия да..."  +/
Сообщение от User294 (ok) on 23-Мрт-11, 16:53 
> И чеб такое в контроллер диска на железе не зафигачить ?

В принципе этому ничего не мешает особо. Только проц - вот он, уже есть, потому что без него - никуда. И не факт что на 100% загруженный. А контроллер, знаете ли, покупать еще надо. Что несколько портит карму данному решению. Вот такие решения - они возможность условно-НАХАЛЯВУ повысить скорость работы дисков в некоторых случаях :)

Ответить | Правка | ^ к родителю #26 | Наверх | Cообщить модератору

60. "Компания Google открыла код Snappy, библиотеки для сжатия да..."  +/
Сообщение от Аноним (??) on 23-Мрт-11, 21:52 
Понятно что будет дороже, но так ли критично, скажем имеете вы диск 150 МБ/сек за 5000 р, и рядом 300 МБ/сек за 6, ну явно спрос будет ;) Технологичнее получается чем ЦП грузить.
Ответить | Правка | ^ к родителю #37 | Наверх | Cообщить модератору

64. "Компания Google открыла код Snappy, библиотеки для сжатия да..."  +/
Сообщение от User294 (ok) on 23-Мрт-11, 23:27 
> Технологичнее получается чем ЦП грузить.

Технологичнее, только процы дуром прут и массово клепаются, а потому дешевые, производительные и не всегда загружены полностью. В итоге получается псевдо-бесплатное решение которое улучшает параметры того что есть, не требуя ничего покупать :).При таких условиях сложно будет клиентов убедить :)

А райд до кучи как обычно будет жать в некий самопальный формат. Его описать ессно забудут, и с форматом соседа с полки магазина с такой же фичой но от иного производителя он ессно будет несовместим. Поэтому если вдруг райд гавкнется и такого же не найдется - вот тут вы пожалуй ощутите все прелести этого подхода. Ну в смысле, админы/юзеры этой железки ощутят. И они как бы себе не враги лишний раз мину замедленного действия то подкладывать :)))

Ответить | Правка | ^ к родителю #60 | Наверх | Cообщить модератору

65. "Компания Google открыла код Snappy, библиотеки для сжатия да..."  +/
Сообщение от Аноним (??) on 23-Мрт-11, 23:43 
Не, ну понятно что у ЦП тоже варианты есть, как минимум для начала, что же касается дисковых контроллеров, именно их а RAID, то ведь тут тоже дело лишь в массовом внедрении, если клепать начнут то дорого не будет, тем более если это будет не дополнительный контроллер общего назначения на плате, а специализированный модуль внутри штатного контроллера, и единый формат при этом тоже не проблема. Внедрили же всякие NCQ и т.п, и это из той же оперы получается.
Ответить | Правка | ^ к родителю #64 | Наверх | Cообщить модератору

87. "Компания Google открыла код Snappy, библиотеки для сжатия да..."  +/
Сообщение от letsmac (ok) on 24-Мрт-11, 22:11 
>>именно их а RAID, то ведь тут тоже дело лишь в массовом внедрении, если клепать начнут то дорого не будет,

12 лет жду дешевого рэйда - а его все нет. 12 лет назад обычным был буфер 16 метров сейчас 256 минимальный. Но дешеветь они и не думают. Программную ерунду вроде интегрированных в чипсеты естественно за RAID не считаю.

Ответить | Правка | ^ к родителю #65 | Наверх | Cообщить модератору

55. "Компания Google открыла код Snappy, библиотеки для сжатия да..."  +/
Сообщение от ascrzy on 23-Мрт-11, 20:35 
Не получили Вы скорость записи на диск в  300Мб/сек, потому что данные вы сжали, но время сжатия не посчитали. Если учтёте, получите ~187 Мб/сек, что не так уж и много.
Ответить | Правка | ^ к родителю #23 | Наверх | Cообщить модератору

58. "Компания Google открыла код Snappy, библиотеки для сжатия да..."  +2 +/
Сообщение от Аноним (??) on 23-Мрт-11, 21:30 
А зачем его считать если сжатие идет быстрее записи и параллельно ей ?
Ответить | Правка | ^ к родителю #55 | Наверх | Cообщить модератору

4. "Компания Google открыла код Snappy, библиотеки для сжатия да..."  +/
Сообщение от Аноним (??) on 23-Мрт-11, 13:22 
Ну хорошо, по сжатию в 2 раза хуже zlib, а по скорости при этом как ? Молчек. Если лучше в те же 2 раза то смысла то нет.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

6. "Компания Google открыла код Snappy, библиотеки для сжатия да..."  +/
Сообщение от Andrey Mitrofanov on 23-Мрт-11, 13:39 
Автор говорит, в 10. http://blog.sesse.net/blog/tech/2011-03-22-19-24_snappy.html
Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

14. "Компания Google открыла код Snappy, библиотеки для сжатия да..."  +/
Сообщение от Аноним (??) on 23-Мрт-11, 14:21 
Ну тогда серьезно.
Ответить | Правка | ^ к родителю #6 | Наверх | Cообщить модератору

8. "Компания Google открыла код Snappy, библиотеки для сжатия да..."  –18 +/
Сообщение от xxx (??) on 23-Мрт-11, 13:52 
Блин, жалко что C++, а то попробывал использовать бы у себя в проекте.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

10. "Компания Google открыла код Snappy, библиотеки для сжатия да..."  –13 +/
Сообщение от mine (ok) on 23-Мрт-11, 14:09 
Да, совсем не понятно зачем оно C++
Ответить | Правка | ^ к родителю #8 | Наверх | Cообщить модератору

12. "Компания Google открыла код Snappy, библиотеки для сжатия да..."  +4 +/
Сообщение от Карбофос (ok) on 23-Мрт-11, 14:14 
перепишите на яву (или что там у вас), потестируйте. потом узнаете, почему
Ответить | Правка | ^ к родителю #10 | Наверх | Cообщить модератору

76. "Компания Google открыла код Snappy, библиотеки для сжатия да..."  +/
Сообщение от mine (ok) on 24-Мрт-11, 15:20 
У меня "там" чистый С.
Перепиши и протестируй. Особенно совместимость посмотри - полезно будет.
Ответить | Правка | ^ к родителю #12 | Наверх | Cообщить модератору

82. "Компания Google открыла код Snappy, библиотеки для сжатия да..."  +/
Сообщение от funny_falcon on 24-Мрт-11, 18:31 
extern "C" {} не спасёт?
Ответить | Правка | ^ к родителю #76 | Наверх | Cообщить модератору

83. "Компания Google открыла код Snappy, библиотеки для сжатия да..."  +/
Сообщение от funny_falcon on 24-Мрт-11, 18:33 
Прочитал дальше ветку. Извиняюсь.
Ответить | Правка | ^ к родителю #82 | Наверх | Cообщить модератору

84. "Компания Google открыла код Snappy, библиотеки для сжатия да..."  +/
Сообщение от funny_falcon on 24-Мрт-11, 18:51 
Впрочем, там код не сложный.
Я бы взялся переписать, если бы мне нужно было/заплатили.
Ответить | Правка | ^ к родителю #83 | Наверх | Cообщить модератору

85. "Компания Google открыла код Snappy, библиотеки для сжатия да..."  –3 +/
Сообщение от mine (ok) on 24-Мрт-11, 19:27 
Проблема не в сложности переписывания.
Проблема в необходимости оптимизации переписанного кода, тонком понимании во что это превратится после компиляции и, разумеется, в стабильности. Т.е. код должен быть супер стабильным и вообще без ошибок.
Ценность кода от гугла именно в этом - он прошел экстра-супер-пупер тестирование. в Их проектах.
Ответить | Правка | ^ к родителю #84 | Наверх | Cообщить модератору

91. "Компания Google открыла код Snappy, библиотеки для сжатия да..."  +/
Сообщение от Карбофос (ok) on 25-Мрт-11, 10:42 
то есть код ты так и не смотрел? давай, тролль дальше о неких совместимостях и тонкостях оптимизации при переходе с плюсов на си, о хождениях по классам для поиска функций и прочих твоих теоретических выкладках.
Ответить | Правка | ^ к родителю #76 | Наверх | Cообщить модератору

15. "Компания Google открыла код Snappy, библиотеки для сжатия да..."  +/
Сообщение от Аноним (??) on 23-Мрт-11, 14:23 
> Блин, жалко что C++, а то попробывал использовать бы у себя в
> проекте.

Ну так и используйте если хотите, или ваш проект не может пристегивать внешние модули ?

Ответить | Правка | ^ к родителю #8 | Наверх | Cообщить модератору

22. "Компания Google открыла код Snappy, библиотеки для сжатия да..."  +/
Сообщение от Карбофос (ok) on 23-Мрт-11, 14:32 
так это ж читать надо. знать, что такое нативная функция... а вообще, мне страшно за такие проекты
Ответить | Правка | ^ к родителю #15 | Наверх | Cообщить модератору

28. "Компания Google открыла код Snappy, библиотеки для сжатия да..."  +3 +/
Сообщение от IGX on 23-Мрт-11, 15:04 
Лучше бы на Си.
Ответить | Правка | ^ к родителю #15 | Наверх | Cообщить модератору

45. "Компания Google открыла код Snappy, библиотеки для сжатия да..."  +/
Сообщение от stom on 23-Мрт-11, 18:05 
чем лучше, поясните
Ответить | Правка | ^ к родителю #28 | Наверх | Cообщить модератору

51. "Компания Google открыла код Snappy, библиотеки для сжатия да..."  +1 +/
Сообщение от IGX on 23-Мрт-11, 19:34 
> чем лучше, поясните

Тем, что во встраиваемых решениях не попользуешь из-за отсутствия компилятора Си++

Ответить | Правка | ^ к родителю #45 | Наверх | Cообщить модератору

52. "Компания Google открыла код Snappy, библиотеки для сжатия да..."  +/
Сообщение от stom on 23-Мрт-11, 19:45 
приведите, пожалуйста, пример встроенной системы, в которой вы имели бы желание использовать snappy, но вынуждены отказаться в основном ввиду описанных вами выше ограничений
Ответить | Правка | ^ к родителю #51 | Наверх | Cообщить модератору

67. "Компания Google открыла код Snappy, библиотеки для сжатия да..."  +1 +/
Сообщение от IGX on 24-Мрт-11, 02:26 
> приведите, пожалуйста, пример встроенной системы, в которой вы имели бы желание использовать
> snappy, но вынуждены отказаться в основном ввиду описанных вами выше ограничений

микроконтроллеры

Ответить | Правка | ^ к родителю #52 | Наверх | Cообщить модератору

88. "Компания Google открыла код Snappy, библиотеки для сжатия да..."  +1 +/
Сообщение от letsmac (ok) on 24-Мрт-11, 22:13 
>> приведите, пожалуйста, пример встроенной системы, в которой вы имели бы желание использовать
>> snappy, но вынуждены отказаться в основном ввиду описанных вами выше ограничений
> микроконтроллеры

Если в контроллер влезает код библиотеки такого размера - он по определению поддерживает с++.

Ответить | Правка | ^ к родителю #67 | Наверх | Cообщить модератору

71. "Компания Google открыла код Snappy, библиотеки для сжатия да..."  +/
Сообщение от Карбофос (ok) on 24-Мрт-11, 11:29 
дык и перепишите. благо, исходники на плюсах именно этого проекта всего лишь 100kB!
Ответить | Правка | ^ к родителю #28 | Наверх | Cообщить модератору

74. "Компания Google открыла код Snappy, библиотеки для сжатия да..."  +/
Сообщение от IGX on 24-Мрт-11, 14:19 
> дык и перепишите. благо, исходники на плюсах именно этого проекта всего лишь
> 100kB!

А время и желание есть? Зачем переписывать snappy на Си, если есть гораздо более компактные и проверенные временем аналоги типа LZO со сравнимой производительностью?

Ответить | Правка | ^ к родителю #71 | Наверх | Cообщить модератору

75. "Компания Google открыла код Snappy, библиотеки для сжатия да..."  +1 +/
Сообщение от Карбофос (ok) on 24-Мрт-11, 14:52 
зачем тогда вообще поднимать сыр-бор из-за каких-то 100 килобайт исходников? есть что-то другое - используйте, кто ж спорит. :)
Ответить | Правка | ^ к родителю #74 | Наверх | Cообщить модератору

44. "Компания Google открыла код Snappy, библиотеки для сжатия да..."  +1 +/
Сообщение от xxx (??) on 23-Мрт-11, 18:02 
> Ну так и используйте если хотите, или ваш проект не может пристегивать
> внешние модули ?

Нет не может. Есть специфичная железяка и только сишный компилятор, а С++ сильно не допилен.

Ну и вобщем, на мой взгляд подобные библиотеки лучше на Си, проще прикручивать к другим языкам.


Ответить | Правка | ^ к родителю #15 | Наверх | Cообщить модератору

53. "Компания Google открыла код Snappy, библиотеки для сжатия да..."  +/
Сообщение от Аноним (??) on 23-Мрт-11, 20:09 
А сишный компилер полноценный ? что за железка если не секрет ?
Ответить | Правка | ^ к родителю #44 | Наверх | Cообщить модератору

29. "Компания Google открыла код Snappy, библиотеки для сжатия да..."  +1 +/
Сообщение от Аноним (??) on 23-Мрт-11, 15:17 
Замечательно что на C++, сейчас других актуальных языков и нет. И что вам мешает использовать библиотеку в проекте?
Ответить | Правка | ^ к родителю #8 | Наверх | Cообщить модератору

47. "Компания Google открыла код Snappy, библиотеки для..."  +/
Сообщение от anonymous (??) on 23-Мрт-11, 18:40 
> Замечательно что на C++, сейчас других актуальных языков и нет.

ORLY?

> И что вам мешает использовать библиотеку в проекте?

то, что она на цпп. придётся врапперы ваять. ну её нафиг, такую библиотеку, для zlib ничего писать не надо.

Ответить | Правка | ^ к родителю #29 | Наверх | Cообщить модератору

42. "Компания Google открыла код Snappy, библиотеки для сжатия да..."  +/
Сообщение от xxx (??) on 23-Мрт-11, 17:56 
О, как заминусовали-то =) Нет, я не против С++, просто тот проект над которым я работаю предполагает именно Си, и да, С++ вообще нет возможности использовать.
Ответить | Правка | ^ к родителю #8 | Наверх | Cообщить модератору

50. "Компания Google открыла код Snappy, библиотеки для сжатия да..."  +/
Сообщение от Карбофос (ok) on 23-Мрт-11, 18:56 
ну неужто там нет простого API? o_O
Ответить | Правка | ^ к родителю #42 | Наверх | Cообщить модератору

56. "Компания Google открыла код Snappy, библиотеки для сжатия да..."  –1 +/
Сообщение от Ytch on 23-Мрт-11, 21:24 
>ну неужто там нет простого API? o_O

А какое там может быть API? Есть набор Си-шных исходников. Они компилируются. В итоге получается некий бинарный образ, который прошивается в железку. Где в этой цепочке может быть какой-то API, который поможет прикрутить код на С++ ?

Ответить | Правка | ^ к родителю #50 | Наверх | Cообщить модератору

70. "Компания Google открыла код Snappy, библиотеки для сжатия да..."  +/
Сообщение от Карбофос (ok) on 24-Мрт-11, 11:08 
для особо тяжелых случаев исходники можно и конвертнуть и избавиться от ОО. если вы заглядывали в исходники, то наверняка видели, сколько их там по объему.
>который прошивается в железку

прямо хардкор какой-то. например, линукс-базированные решения, которые тоже прошиваются в железку. и что? у них нет никакого API? не спора ради, просто думается, что товарисч работает всё-таки на обычном компе (ну или ембеддед), с количеством памяти, позволяющим делать malloc для объектов. или он программирует фотоаппараты, или еще что-то такое уж шибко экзотическое? вот в чем вопрос.

Ответить | Правка | ^ к родителю #56 | Наверх | Cообщить модератору

57. "Компания Google открыла код Snappy, библиотеки для сжатия да..."  +1 +/
Сообщение от Ytch on 23-Мрт-11, 21:29 
> О, как заминусовали-то =) Нет, я не против С++, просто тот проект
> над которым я работаю предполагает именно Си, и да, С++ вообще
> нет возможности использовать.

Я думаю, минусанули потому что думали, что подразумевается что-то типа java как "альтернатива". Обычно именно фанаты подобного любят вслух сожалеть о чем-то сделаном на С/C++.

Ответить | Правка | ^ к родителю #42 | Наверх | Cообщить модератору

80. "Компания Google открыла код Snappy, библиотеки для сжатия да..."  +/
Сообщение от vasya (??) on 24-Мрт-11, 16:42 
extern "C"
Ответить | Правка | ^ к родителю #8 | Наверх | Cообщить модератору

86. "Компания Google открыла код Snappy, библиотеки для сжатия да..."  +/
Сообщение от Ytch on 24-Мрт-11, 20:49 
>extern "C"

Мимо. Это помогает в обратной ситуации (прикрутить Си-шный код в C++ программу)

Ответить | Правка | ^ к родителю #80 | Наверх | Cообщить модератору

89. "Компания Google открыла код Snappy, библиотеки для сжатия да..."  +/
Сообщение от vasya (??) on 25-Мрт-11, 08:11 
>>extern "C"
> Мимо. Это помогает в обратной ситуации (прикрутить Си-шный код в C++ программу)

Как раз наоборот.


Ответить | Правка | ^ к родителю #86 | Наверх | Cообщить модератору

90. "Компания Google открыла код Snappy, библиотеки для сжатия да..."  +/
Сообщение от vasya (??) on 25-Мрт-11, 08:13 
>>>extern "C"
>> Мимо. Это помогает в обратной ситуации (прикрутить Си-шный код в C++ программу)
> Как раз наоборот.

Точнее, в обе стороны работает.

Ответить | Правка | ^ к родителю #89 | Наверх | Cообщить модератору

93. "Компания Google открыла код Snappy, библиотеки для..."  +1 +/
Сообщение от anonymous (??) on 25-Мрт-11, 11:48 
>>>extern "C"
>> Мимо. Это помогает в обратной ситуации (прикрутить Си-шный код в C++ программу)
> Как раз наоборот.

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

Ответить | Правка | ^ к родителю #89 | Наверх | Cообщить модератору

13. "Компания Google открыла код Snappy, библиотеки для сжатия да..."  +/
Сообщение от Григорий (??) on 23-Мрт-11, 14:16 
На чём умеют, на том и пишут.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

17. "Компания Google открыла код Snappy, библиотеки для сжатия да..."  +2 +/
Сообщение от Аноним (??) on 23-Мрт-11, 14:27 
Было бы не плохо использовать как метод сжатия файловых систем (вместо zlib у btrfs) - я думаю скорость работы существенно возрастет. Хотя могу ошибаться.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

21. "Компания Google открыла код Snappy, библиотеки для сжатия да..."  +/
Сообщение от arcade (ok) on 23-Мрт-11, 14:32 
Тада. Где-то выхватывал сравнительную таблицу для zlib и lzo, lzo рулил за счёт быстрой распаковки и быстрого определения несжимаемых данных.

Хачу в zfs.

Ответить | Правка | ^ к родителю #17 | Наверх | Cообщить модератору

25. "Компания Google открыла код Snappy, библиотеки для сжатия да..."  +1 +/
Сообщение от User294 (ok) on 23-Мрт-11, 14:39 
> Было бы не плохо использовать как метод сжатия файловых систем (вместо zlib
> у btrfs)

1) Там уже поюзали LZO. Он довольно резвый. Не чемпион, но весьма даже шпарит, особенно по скорости декомпрессии.
2) Бакланы из гугли зачем-то поюзали си++. Как вы себе представляете себе оный в ядре? В общем велосипедисты такие велосипедисты :)

Ответить | Правка | ^ к родителю #17 | Наверх | Cообщить модератору

34. "Компания Google открыла код Snappy, библиотеки для сжатия да..."  +1 +/
Сообщение от Анон on 23-Мрт-11, 16:24 
Чем Вас не устраивает С++?
Проект был открыт и за это спасибо. А если у некоторых бакланов не получается его пристроить в ядро, то это исключительно их проблемы.
Ответить | Правка | ^ к родителю #25 | Наверх | Cообщить модератору

38. "Компания Google открыла код Snappy, библиотеки для сжатия да..."  +5 +/
Сообщение от User294 (ok) on 23-Мрт-11, 16:59 
> Чем Вас не устраивает С++?

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

> Проект был открыт и за это спасибо. А если у некоторых бакланов
> не получается его пристроить в ядро, то это исключительно их проблемы.

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

Ответить | Правка | ^ к родителю #34 | Наверх | Cообщить модератору

46. "Компания Google открыла код Snappy, библиотеки для сжатия да..."  –7 +/
Сообщение от stom on 23-Мрт-11, 18:10 
>[оверквотинг удален]
> скорость там как раз обычно важна. Вот тем и не устраивает.
>> Проект был открыт и за это спасибо. А если у некоторых бакланов
>> не получается его пристроить в ядро, то это исключительно их проблемы.
> Ну так пристройте, если такой писец умный. В эмбеддовке извините поюзаные гуглем
> либы легко выжрут всю память под себя. Тогда как какойнить LZO
> умеет быть и весьма скромным в своих требованиях, например, минимальный декомпрессор
> - считанные сотни байтов кода, не требуют оперативы (кроме источника и
> назначения) и никаких либ вообще (в чисто-алгоритмической байде они в общем
> то понты и навороты). Такой подход сильно расширяет сферу применения, не
> в обиду велосипедистам гугеля.

ты в код смотрел?
связь между языком программирования (в данном случае c/c++), встраиваемыми системами и потреблением памяти существует только в воображении таких горлопанов как ты. аргументируй (фактами, цифрами, ссылками, а не своими безграмотными домыслами) или вали

Ответить | Правка | ^ к родителю #38 | Наверх | Cообщить модератору

68. "Компания Google открыла код Snappy, библиотеки для сжатия да..."  –6 +/
Сообщение от mine (ok) on 24-Мрт-11, 10:40 

Плюсам не место в эмбеддед и ядре. Хочешь фактов вот тебе пара. С++ не умеет сериализацию не то что классов, но даже структур. Это раз. Два - это то, что плюсы при правильном (объектном) использовании чрезвычайно много усилий тратят на хождение по классам для поиска функции, подлежащей вызову в данный момент.

А теперь попробуй ты представить какие-нибудь факты, цифры и т.д. в полюзу плюсов. Или только яйцами звенеть можешь?

Ответить | Правка | ^ к родителю #46 | Наверх | Cообщить модератору

81. "Компания Google открыла код Snappy, библиотеки для сжатия да..."  +1 +/
Сообщение от anonymous (??) on 24-Мрт-11, 17:42 
ахаха
аццкий отжиг "хождение по классам для поиска функций" :)
вот такие люди как ты, нихрена не понимающие как плюсы вообще работают, громче всех кричат какие они плохие
погугли что ли что такое таблица виртуальных функций и как она используется
Ответить | Правка | ^ к родителю #68 | Наверх | Cообщить модератору

95. "Компания Google открыла код Snappy, библиотеки для сжатия да..."  +1 +/
Сообщение от arcade (ok) on 09-Апр-11, 14:04 
> Плюсам не место в эмбеддед и ядре. Хочешь фактов вот тебе пара.
> С++ не умеет сериализацию не то что классов, но даже структур.
> Это раз. Два - это то, что плюсы при правильном (объектном)
> использовании чрезвычайно много усилий тратят на хождение по классам для поиска
> функции, подлежащей вызову в данный момент.
> А теперь попробуй ты представить какие-нибудь факты, цифры и т.д. в полюзу
> плюсов. Или только яйцами звенеть можешь?

Когда-то на заре интернета у меня появилась звуковуха со встроенным FM-ресивером. С ней шла программа на дискетке (на всю дискетку) с кучей интерфейса и минимумом фишек. В памяти жрала несколько метров и судя по всему была написана на сях. Спустя некоторое время я нашёл другую програму, которая могла управлять приёмником. Переборов уже глубоко въевшееся презрение к дельфам и написанному на них софту загрузил. Программа весила 54 килобайта и в памяти занимала где-то 200.

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

Ответить | Правка | ^ к родителю #68 | Наверх | Cообщить модератору

18. "Компания Google открыла код Snappy, библиотеки для сжатия да..."  +/
Сообщение от Аноним (??) on 23-Мрт-11, 14:28 
А вот интересно, если zlib или чтото аналогичное на аппаратном уровне в проце реализовать, ну там типа SSE6, то оно ведь и быстрее и сильнее получится, чеб нет ?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

33. "Компания Google открыла код Snappy, библиотеки для сжатия да..."  +1 +/
Сообщение от pavlinux (ok) on 23-Мрт-11, 15:39 
> А вот интересно, если zlib или чтото аналогичное на аппаратном уровне в
> проце реализовать, ну там типа SSE6, то оно ведь и быстрее
> и сильнее получится, чеб нет ?

http://mxt.sourceforge.net/

Ответить | Правка | ^ к родителю #18 | Наверх | Cообщить модератору

20. "Компания Google открыла код Snappy, библиотеки для сжатия да..."  +1 +/
Сообщение от User294 (ok) on 23-Мрт-11, 14:31 
А оно у них точно лучше чем quicklz? А то на http://quicklz.com/bench.html скорости указаны весьма некислые - и 300 и 500 мб/сек на core i7 есть. Ладно, при случае сравним. Хотя писать такой проект на си++ имхо долбоклюйство. А чего там си++ требует? У них там такие офигенные алгоритмы? Зато во всякие кернелы и половину эмбеддовки оно такое гарантированно не попадет. Я еще понимаю когда на си++ пишут реально мощный компрессор с рекордным сжатием, но либу ориентированную на скорость иожно было бы и на сях родить.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

24. "Компания Google открыла код Snappy, библиотеки для сжатия да..."  +/
Сообщение от Аноним (??) on 23-Мрт-11, 14:38 
Да уж, если http://quicklz.com/bench.html реально, то значительного опережения никак не получается. Очередной гуглопиар ?
Ответить | Правка | ^ к родителю #20 | Наверх | Cообщить модератору

27. "Компания Google открыла код Snappy, библиотеки для сжатия да..."  +/
Сообщение от Аноним (??) on 23-Мрт-11, 14:57 
Пиар не пиар а quicklz как минимум не гугла, да и лицензии Apache vs GPL, не в курсе, разница есть ?
Ответить | Правка | ^ к родителю #24 | Наверх | Cообщить модератору

35. "Компания Google открыла код Snappy, библиотеки для сжатия да..."  +3 +/
Сообщение от Анон on 23-Мрт-11, 16:30 
> А оно у них точно лучше чем quicklz? А то на http://quicklz.com/bench.html
> скорости указаны весьма некислые - и 300 и 500 мб/сек на
> core i7 есть. Ладно, при случае сравним. Хотя писать такой проект
> на си++ имхо долбоклюйство. А чего там си++ требует? У них
> там такие офигенные алгоритмы? Зато во всякие кернелы и половину эмбеддовки
> оно такое гарантированно не попадет. Я еще понимаю когда на си++
> пишут реально мощный компрессор с рекордным сжатием, но либу ориентированную на
> скорость иожно было бы и на сях родить.

Что ты все время недоволен? Множество хороших проектов написано вообще на всяких питонах и жабах. У тебя помещательство на кернелах и ембеддовке. Нужно на С - будь мужиком, возьми и перепиши, а не ной тут.

Ответить | Правка | ^ к родителю #20 | Наверх | Cообщить модератору

39. "Компания Google открыла код Snappy, библиотеки для сжатия да..."  –1 +/
Сообщение от User294 (ok) on 23-Мрт-11, 17:13 
> Что ты все время недоволен? Множество хороших проектов написано вообще на всяких
> питонах и жабах.

Понятия о прекрасном у всех разные.

> У тебя помещательство на кернелах и ембеддовке.

Я не виноват что там быстрые и эффективные алгоритмы в почете. Ы?

Ответить | Правка | ^ к родителю #35 | Наверх | Cообщить модератору

49. "Компания Google открыла код Snappy, библиотеки для..."  +/
Сообщение от anonymous (??) on 23-Мрт-11, 18:45 
> Множество хороших проектов написано вообще на всяких питонах и жабах.

например? нет, эклипс — это не «хороший проект». бинс тоже.

Ответить | Правка | ^ к родителю #35 | Наверх | Cообщить модератору

40. "Компания Google открыла код Snappy, библиотеки для сжатия да..."  +/
Сообщение от Crazy Alex email(??) on 23-Мрт-11, 17:51 
Гугл не пишет на C. Вообще. А писано оно "под себя". Теперь вот открыли просто.
Ответить | Правка | ^ к родителю #20 | Наверх | Cообщить модератору

31. "Компания Google открыла код Snappy, библиотеки для сжатия да..."  +/
Сообщение от JL2001 (ok) on 23-Мрт-11, 15:31 
\\оффтопик
а когда в линуксе при установке новой/ещё одной библиотеки реализующей сжатие/разжатие бтрфс сразу сможет использовать этот алгоритм ? а ещё бекапер, karc и браузер...

есть вобще такие оси ? и чтоб живые оси ?

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

41. "Компания Google открыла код Snappy, библиотеки для сжатия да..."  +/
Сообщение от Crazy Alex email(??) on 23-Мрт-11, 17:52 
Нету. Черт побери. Мне вот тоже интересно, когда что-нибудь появится с нормальным компонентным подходом.
Ответить | Правка | ^ к родителю #31 | Наверх | Cообщить модератору

43. "Компания Google открыла код Snappy, библиотеки для сжатия да..."  +/
Сообщение от Andrey Mitrofanov on 23-Мрт-11, 18:01 
> \\оффтопик
> а когда в линуксе при установке новой/ещё одной

Да! Почему установленный Info-ZIP после установки unrar из non-free **сразу** не научился rar-архивам?! Сволочи же!!?

Ответить | Правка | ^ к родителю #31 | Наверх | Cообщить модератору

66. "Компания Google открыла код Snappy, библиотеки для сжатия да..."  +2 +/
Сообщение от gildor on 24-Мрт-11, 00:15 
В readme к библиотеке сказано, что код оптимизирован для 64-битных систем с x86 архитектурой. Для других систем он вряд ли даст выигрыш в сравнении с тем же LZO. Судя по описанию, он использует чтение 64-битных величин по произвольному адресу - на ARM такое уже не прокатит (там игнорируются младшие биты адреса), компилятор может это и исправит - будет читать 8 байт и складывать в одну переменную (или в две - для 32-битов). Это уже значительное замедление. Если взять процессор по типу XBox-ового, там та же проблема, процессор даже генерит исключение при попытке читать слово по невыровненному адресу. В общем, похоже что этот код имеет плюсы только для одной платформы.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

96. "Компания Google открыла код Snappy, библиотеки для сжатия да..."  +/
Сообщение от annulen (ok) on 22-Ноя-13, 18:54 
>Если взять процессор по типу XBox-ового, там та же проблема, процессор даже генерит исключение при попытке читать слово по невыровненному адресу

Если речь идет о Xbox 360, то у PPC невыровненный доступ к памяти не только возможен, но и оптимизирован (в отличие от большинства RISC-архитектур, на которых эта операция запрещена или работает медленно)

Ответить | Правка | ^ к родителю #66 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Спонсоры:
Слёрм
Inferno Solutions
Hosting by Ihor
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2019 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру