[Pharo-project] About sqnappy and LZ4
Hi, I was checking https://github.com/mumez/sqnappy. Some time ago I wrote bindings for LZ4: http://smalltalkhub.com/#!/~marianopeck/LZ4 Do you know which are the differences? It looks both are intended for the same purpose: speed in decompression/compression over compression ratio. From what I can see in http://fastcompression.blogspot.fr/p/lz4.html it says encoding 555 MB/s decoding 1.80 GB/ while in https://code.google.com/p/snappy/ it says "Snappy compresses at about 250 MB/sec or more and decompresses at about 500 MB/sec or more." So...doesn't LZ4 seem to be faster than sqnappy? And I already wrote the bindings for LZ4...so I was wondering that... Best regards, -- Mariano http://marianopeck.wordpress.com
Hi, Actually, I have never noticed that you have LZ4 bindings already. It is indeed a great news! I would never have started sqnappy if I knew the fact. As you say, the project has a similar goal. Anyway, it is good to have another option. Some Sqnappy characteristics: - it has a minimum dependency (it does not use FFI, NativeBoost) so that it can be run on older images - Streaming format support (to be soon) - you can compress very big data with relatively small memory footprint. Best regards, 2013/4/18 Mariano Martinez Peck <marianopeck@gmail.com>:
Hi,
I was checking https://github.com/mumez/sqnappy. Some time ago I wrote bindings for LZ4: http://smalltalkhub.com/#!/~marianopeck/LZ4
Do you know which are the differences?
It looks both are intended for the same purpose: speed in decompression/compression over compression ratio. From what I can see in http://fastcompression.blogspot.fr/p/lz4.html it says encoding 555 MB/s decoding 1.80 GB/ while in https://code.google.com/p/snappy/ it says "Snappy compresses at about 250 MB/sec or more and decompresses at about 500 MB/sec or more."
So...doesn't LZ4 seem to be faster than sqnappy? And I already wrote the bindings for LZ4...so I was wondering that...
Best regards,
-- Mariano http://marianopeck.wordpress.com -- [:masashi | ^umezawa]
On 18 April 2013 06:25, Masashi UMEZAWA <masashi.umezawa@gmail.com> wrote:
Hi,
Actually, I have never noticed that you have LZ4 bindings already. It is indeed a great news! I would never have started sqnappy if I knew the fact. As you say, the project has a similar goal.
Anyway, it is good to have another option.
Some Sqnappy characteristics: - it has a minimum dependency (it does not use FFI, NativeBoost) so that it can be run on older images
- having a separate plugin/VM , which users always have trouble dealing wih :)
- Streaming format support (to be soon) - you can compress very big data with relatively small memory footprint.
Best regards,
2013/4/18 Mariano Martinez Peck <marianopeck@gmail.com>:
Hi,
I was checking https://github.com/mumez/sqnappy. Some time ago I wrote bindings for LZ4: http://smalltalkhub.com/#!/~marianopeck/LZ4
Do you know which are the differences?
It looks both are intended for the same purpose: speed in decompression/compression over compression ratio. From what I can see in http://fastcompression.blogspot.fr/p/lz4.html it says encoding 555 MB/s decoding 1.80 GB/ while in https://code.google.com/p/snappy/ it says "Snappy compresses at about 250 MB/sec or more and decompresses at about 500 MB/sec or more."
So...doesn't LZ4 seem to be faster than sqnappy? And I already wrote the bindings for LZ4...so I was wondering that...
Best regards,
-- Mariano http://marianopeck.wordpress.com -- [:masashi | ^umezawa]
-- Best regards, Igor Stasenko.
Hi,
Some Sqnappy characteristics: - it has a minimum dependency (it does not use FFI, NativeBoost) so that it can be run on older images
- having a separate plugin/VM , which users always have trouble dealing wih :)
You may recompile SnappyPlugin as an internal plugin. It is nice. ;) Actually Snappy itself is optimized for 64-bit platform. So you may need a recompilation if you try it in 64 bit VM. Best regards, -- [:masashi | ^umezawa]
On 18 April 2013 13:33, Masashi UMEZAWA <masashi.umezawa@gmail.com> wrote:
Hi,
Some Sqnappy characteristics: - it has a minimum dependency (it does not use FFI, NativeBoost) so that it can be run on older images
- having a separate plugin/VM , which users always have trouble dealing wih :)
You may recompile SnappyPlugin as an internal plugin. It is nice. ;) Actually Snappy itself is optimized for 64-bit platform. So you may need a recompilation if you try it in 64 bit VM.
yeah yeah.. recompile VM.. think how many users will stop right at this point and go no further :) Anyways, my sarcasm was not to discourage you, just wanted to point out that making plugin and selling it as "having less dependencies" or "less work for users" , not really true :)
Best regards, -- [:masashi | ^umezawa]
-- Best regards, Igor Stasenko.
Hi,
Anyways, my sarcasm was not to discourage you, just wanted to point out that making plugin and selling it as "having less dependencies" or "less work for users" , not really true :)
I know what you mean. We live in a DLL hell. But what I really meant was that it has minimum dependency to 'other Squeak/Pharo class libraries'.
From the image perspective, Sqnappy core just consists of two classes. It is easy to install to older or stripped images (yep, for non CogVM, we need to recompile the plugin source. ;) Probably I should have said 'no need to install any other prerequisites' or something. Sorry for the confusion.
Best regards, -- [:masashi | ^umezawa]
participants (3)
-
Igor Stasenko -
Mariano Martinez Peck -
Masashi UMEZAWA