Re: bin/50638: Extreme slowness on loading gzipped kernels on old CPUs

[Joerg Sonnenberger <joerg%britannica.bec.de@localhost>]

The following reply was made to PR bin/50638; it has been noted by GNATS.

From: Joerg Sonnenberger <joerg%britannica.bec.de@localhost>
To: gnats-bugs%NetBSD.org@localhost
Cc: gnats-admin%netbsd.org@localhost, netbsd-bugs%netbsd.org@localhost, tsutsui%ceres.dti.ne.jp@localhost
Subject: Re: bin/50638: Extreme slowness on loading gzipped kernels on old
 CPUs
Date: Sun, 10 Jan 2016 22:56:12 +0100

 On Sun, Jan 10, 2016 at 09:20:01PM +0000, Kamil Rytarowski wrote:
 > The following reply was made to PR bin/50638; it has been noted by GNATS.
 > 
 > From: Kamil Rytarowski <n54%gmx.com@localhost>
 > To: gnats-bugs%NetBSD.org@localhost
 > Cc: 
 > Subject: Re: bin/50638: Extreme slowness on loading gzipped kernels on old
 >  CPUs
 > Date: Sun, 10 Jan 2016 22:18:27 +0100
 > 
 >  -----BEGIN PGP SIGNED MESSAGE-----
 >  Hash: SHA256
 >  
 >  On 10.01.2016 19:06, Joerg Sonnenberger wrote:
 >  > On Sun, Jan 10, 2016 at 05:40:00PM +0000, Izumi Tsutsui wrote:
 >  >> (1) leave as is and use the dumb crc32() function (for small
 >  >> binary) (2) pull "DYNAMIC_CRC_TABLE" implementation from zlib
 >  >> into libkern/crc32.c (3) completely disable gunzip crc32()
 >  >> calculation in cread() function
 >  > 
 >  > Another option would be to use a version of what libarchive is
 >  > using in 
 >  > src/external/bsd/libarchive/dist/libarchive/archive_crc32.h. That 
 >  > version is still pretty small.
 >  > 
 >  
 >  Just a note. Recent x86_64 and optionally armv8 ships with intrinsic
 >  functions implemented in their cores for CRC32 functions.
 >  
 >  According to my tests the lookup algorithm is 3-4x slower on x86_64
 >  and armv8 than a function reusing the dedicated CPU instruction.
 
 The point is not that there are faster ways to do, just to do it fast
 enough and in small enough executable footprint to not hurt loading a
 kernel.
 
 Joerg