Sam James via Gcc-patches writes:
>> On 8 Nov 2022, at 07:14, Sam James wrote:
>>
>> 1. This should speed up decompression for folks, as parallel xz
>> creates a different archive which can be decompressed in parallel.
>>
>> Note that this different method is enabled by default in a new
>>
> On 8 Nov 2022, at 07:14, Sam James wrote:
>
> 1. This should speed up decompression for folks, as parallel xz
> creates a different archive which can be decompressed in parallel.
>
> Note that this different method is enabled by default in a new
> xz release coming shortly anyway (>=
> On 8 Nov 2022, at 07:14, Sam James wrote:
>
> 1. This should speed up decompression for folks, as parallel xz
> creates a different archive which can be decompressed in parallel.
>
> Note that this different method is enabled by default in a new
> xz release coming shortly anyway (>=
On 11/9/22 03:06, Xi Ruoyao via Gcc-patches wrote:
On Wed, 2022-11-09 at 01:52 +, Joseph Myers wrote:
On Tue, 8 Nov 2022, Xi Ruoyao via Gcc-patches wrote:
I'm wondering if running xz -T0 on different machines (with different
core numbers) may produce different compressed data. The
On Wed, 2022-11-09 at 01:52 +, Joseph Myers wrote:
> On Tue, 8 Nov 2022, Xi Ruoyao via Gcc-patches wrote:
>
> > I'm wondering if running xz -T0 on different machines (with different
> > core numbers) may produce different compressed data. The difference can
> > cause trouble distributing
On Tue, 8 Nov 2022, Xi Ruoyao via Gcc-patches wrote:
> I'm wondering if running xz -T0 on different machines (with different
> core numbers) may produce different compressed data. The difference can
> cause trouble distributing checksums.
gcc_release definitely doesn't use any options to make
> On 8 Nov 2022, at 08:52, Jakub Jelinek wrote:
>
> On Tue, Nov 08, 2022 at 07:40:02AM +, Sam James wrote:
>>> On 8 Nov 2022, at 07:33, Xi Ruoyao wrote:
>>> I'm wondering if running xz -T0 on different machines (with different
>>> core numbers) may produce different compressed data. The
On Tue, Nov 08, 2022 at 07:40:02AM +, Sam James wrote:
> > On 8 Nov 2022, at 07:33, Xi Ruoyao wrote:
> > I'm wondering if running xz -T0 on different machines (with different
> > core numbers) may produce different compressed data. The difference can
> > cause trouble distributing checksums.
> On 8 Nov 2022, at 07:36, Sam James wrote:
>
>
>
>> On 8 Nov 2022, at 07:34, Eric Botcazou wrote:
>>
>>> I build GCC regularly from the weekly snapshots
>>> and so the decompression time adds up.
>>
>> But is very largely dwarfed by the build time of the compiler, isn't it?
>>
>
> It
> On 8 Nov 2022, at 07:33, Xi Ruoyao wrote:
>
> On Tue, 2022-11-08 at 07:14 +, Sam James via Gcc-patches wrote:
>> 1. This should speed up decompression for folks, as parallel xz
>>creates a different archive which can be decompressed in parallel.
>>
>>Note that this different
> On 8 Nov 2022, at 07:34, Eric Botcazou wrote:
>
>> I build GCC regularly from the weekly snapshots
>> and so the decompression time adds up.
>
> But is very largely dwarfed by the build time of the compiler, isn't it?
>
It is. It's no big deal if the patch isn't accepted, it's just
>I build GCC regularly from the weekly snapshots
>and so the decompression time adds up.
But is very largely dwarfed by the build time of the compiler, isn't it?
--
Eric Botcazou
On Tue, 2022-11-08 at 07:14 +, Sam James via Gcc-patches wrote:
> 1. This should speed up decompression for folks, as parallel xz
> creates a different archive which can be decompressed in parallel.
>
> Note that this different method is enabled by default in a new
> xz release
1. This should speed up decompression for folks, as parallel xz
creates a different archive which can be decompressed in parallel.
Note that this different method is enabled by default in a new
xz release coming shortly anyway (>= 5.3.3_alpha1).
I build GCC regularly from the weekly
14 matches
Mail list logo
