Date: Fri, 16 Mar 2018 09:12:07 +0100
From: Natanael Copa <ncopa@alpinelinux.org>
To: Steffen Nurpmeso <steffen@sdaoden.eu>
Cc: alpine-user@lists.alpinelinux.org
Subject: Re: [alpine-user] FYI: community/zstd binary much (up to 4x) slower
 than necessary
Message-ID: <20180316091207.3ad9dd48@ncopa-desktop.copa.dup.pw>
In-Reply-To: <20180313180648.kXWsR%steffen@sdaoden.eu>
References: <20180313180648.kXWsR%steffen@sdaoden.eu>
Precedence: list
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

On Tue, 13 Mar 2018 19:06:48 +0100
Steffen Nurpmeso <steffen@sdaoden.eu> wrote:

> Hello, for your possible interest.
> 
> In a thead for the LUGA(ustria) i eventually had to time some
> compression algorithms and wondered why zstd is so slow, but
> especially so the decompressing stage, which a key feature of this
> one.  It turns out that the -Os compilation causes, well, drama-
> tical performance degradation.  I compiled my own with -O3 and the
> difference is up to factor four.  Just one example:
> 
> POSIX standard (C165.txt):
> 
> Alpine, -Os:
>   #?0[steffen@essex tmp]$ time zstd --rm x4.txt
>   x4.txt               : 20.95%   (12513780 => 2621685 bytes, x4.txt.zst)
>       0m00.57s real     0m00.23s user     0m00.12s system
>   #?0[steffen@essex tmp]$ time zstd -d -c x4.txt.zst   >/dev/null
>   x4.txt.zst          : 12513780 bytes
>       0m00.38s real     0m00.15s user     0m00.12s system
> 
>   #?0[steffen@essex tmp]$ time zstd --rm -19 x5.txt
>   x5.txt               : 15.40%   (12513780 => 1926643 bytes, x5.txt.zst)
>       0m16.30s real     0m13.53s user     0m00.27s system
> 
>   #?0[steffen@essex tmp]$ time zstd -d -c x5.txt.zst   >/dev/null
>   x5.txt.zst          : 12513780 bytes
>       0m00.39s real     0m00.12s user     0m00.14s system
> 
> -O3:
>   #?0[steffen@essex tmp]$ time x/zstd/zstd -f x1.txt
>   x1.txt               : 20.95%   (12513780 => 2621685 bytes, x1.txt.zst)
>       0m00.34s real     0m00.12s user     0m00.10s system
>   #?0[steffen@essex tmp]$ time x/zstd/zstd -d -c x1.txt.zst >/dev/null
>   x1.txt.zst          : 12513780 bytes
>       0m00.10s real     0m00.02s user     0m00.05s system
> 
>   #?0[steffen@essex tmp]$ time x/zstd/zstd -19 x1.txt
>   x1.txt               : 15.40%   (12513780 => 1926643 bytes, x1.txt.zst)
>       0m13.29s real     0m11.27s user     0m00.17s system
>   #?0[steffen@essex tmp]$ time x/zstd/zstd -d -c x1.txt.zst >/dev/null
>   x1.txt.zst          : 12513780 bytes
>       0m00.12s real     0m00.02s user     0m00.07s system

Are you compressing the same file? I see x4.txt, x5.txt avs x1.txt.
File content may make difference too.
 
> That makes me actually wonder how ports should deal with CFLAGS.
> Is it acceptable for a port to watch for compiler flags and set
> them, my MUA would go for PIE, relro and all that, then?

I think if the difference is 4x then, yes, I think we should explicitly
set CFLAGS from aport with a reference on why. I do prefer -O2 over -O3
though, so It would be nice to see the numbers with -O2 and also what
the numbers are on different platforms.

We already explicitly set -O2 for zlib, because its a case where we do
want trade more speed at the cost of size.

-nc


---
Unsubscribe:  alpine-user+unsubscribe@lists.alpinelinux.org
Help:         alpine-user+help@lists.alpinelinux.org
---