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

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

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

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

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

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

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

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

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

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

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

>не совместима

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

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

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

zlib - snappy - lzo

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

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

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

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

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

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

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

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

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

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

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

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

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

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

победил xz в 8 потоков на их новеньком i7

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

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

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

Закопать

отличные новости!

видимо на 10 раз, на два порядка наврядли.

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

UPD: в 10 раз

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

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

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

wikipedia:

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

Гуглу очередной респект!

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

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

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

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

Дискриминация двоичной системы счисления.

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

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

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

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

snappy::Compress(input, &output);

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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