On 18 August 2017 at 15:06, Karl Palsson wrote:
>
> Bjørn Mork wrote:
>> This looks yucky. Experimenting a bit, I see that the result
>> with
>>
>> a) -T 0 depends on multi-core vs single-core
>> b) -T 1 is always different from the output of -T x where x > 1
>> c) -T x where x > 1 is indepen
Bjørn Mork wrote:
> This looks yucky. Experimenting a bit, I see that the result
> with
>
> a) -T 0 depends on multi-core vs single-core
> b) -T 1 is always different from the output of -T x where x > 1
> c) -T x where x > 1 is independent of both x and the actual number of
> cores
>
>
This looks yucky. Experimenting a bit, I see that the result with
a) -T 0 depends on multi-core vs single-core
b) -T 1 is always different from the output of -T x where x > 1
c) -T x where x > 1 is independent of both x and the actual number of
cores
So you will not get reproducible resul
On 18-08-17, Karl Palsson wrote:
> > This means that the archive will have a different checksum, and
> > thus affects reproducability. [1] suggests this is because of a
> > different block size default, but unfortunately there seems to
> > be no way to set the block size in an attempt to make it us
Jonas Gorski wrote:
> >
> > Previously: (xz -7e)
> > real3m13.631s
> >
> > Now: (xz -T 0 -7e)
> > real1m23.051s
>
> After playing around with it, it seems enabling multiple
> threads makes it compress slightly worse, at least in case of
> the linux kernel sources (86.8 MiB single thread
Hi,
On 17 August 2017 at 15:05, Karl Palsson wrote:
> xz has supported multithreaded compression since 5.2 in 2014. Enable
> it's automatic support for this via the "-T 0" flag.
its ;p
>
> Previously: (xz -7e)
> real3m13.631s
>
> Now: (xz -T 0 -7e)
> real1m23.051s
After playing around
xz has supported multithreaded compression since 5.2 in 2014. Enable
it's automatic support for this via the "-T 0" flag.
Previously: (xz -7e)
real3m13.631s
Now: (xz -T 0 -7e)
real1m23.051s
Signed-off-by: Karl Palsson
---
target/sdk/Makefile | 2 +-
1 file changed, 1 insertion(+), 1 d
