In reply to both John & Garrett,
The only real differences are that you lose the -s/--small flag
which is probably
not a problem on any machine capable of running Solaris.
-s --small
Reduce memory usage, for compression, decompression and
testing. Files are decompressed and tested using a
modified algorithm which only requires 2.5 bytes per
block byte. This means any file can be decompressed in
2300k of memory, albeit at about half the normal speed.
During compression, -s selects a block size of 200k,
which limits memory use to around the same figure, at
the expense of your compression ratio. In short, if
your machine is low on memory (8 megabytes or less),
use -s for everything. See MEMORY MANAGEMENT below.
Decompression from stdin & pipes is still single threaded on pbzip2
but
you don't /lose/ anything per se, you just don't gain anything.
We'd appreciate the guidance of the PSARC members here. If you feel
that we should adjust the case materials to indicate that the
existing bzip2 utility should be replaced with pbzip2 (via the
appropriate symbolic links), please let us know.
Thanks.
-JohnS
On 20-Apr-09, at 10:47 AM, Garrett D'Amore wrote:
> John Levon wrote:
>> On Mon, Apr 20, 2009 at 09:25:51AM -0700, Rich Burridge wrote:
>>
>>
>>> bzip2 is a free and open source block sorting lossless
>>> data compression algorithm with comparatively high
>>> compression efficiency.
>>> pbzip2 is a parallel implementation of the bzip2
>>> algorithm using pthreads written in C++ by Jeff Gilchrist
>>> that retains file compatibility with the common bzip2(1)
>>> application included in Solaris and many other operating
>>> systems
>>>
>>
>> Is there a reason we're not delivering this version as the real
>> bzip2,
>> then just providing a symlink? What is the advantage of the non-
>> parallel
>> implementation exactly to mean it needs a new name?
>>
>
> And an associated question: are there any command line differences?
>
> -- Garrett
>
>> regards
>> john
>>
>
