From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) by finch.gentoo.org (Postfix) with ESMTP id E132B138989 for ; Fri, 1 May 2015 07:44:38 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 3099DE0848; Fri, 1 May 2015 07:44:32 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 2ED44E083B for ; Fri, 1 May 2015 07:44:31 +0000 (UTC) Received: from localhost (sloan0.ut.mephi.ru [85.143.112.33]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: bircoph) by smtp.gentoo.org (Postfix) with ESMTPSA id C40DC340E20 for ; Fri, 1 May 2015 07:44:29 +0000 (UTC) Date: Fri, 1 May 2015 10:44:02 +0300 From: Andrew Savchenko To: gentoo-user@lists.gentoo.org Subject: Re: [gentoo-user] Re: CFLAGs for kernel compilation Message-Id: <20150501104402.27d943c901f638942262d3d1@gentoo.org> In-Reply-To: References: <5540C101.70906@ramses-pyramidenbau.de> <20150430123819.b72d8b39bd60a912b7c7fde5@gentoo.org> X-Mailer: Sylpheed 3.4.1 (GTK+ 2.24.25; i686-pc-linux-gnu) Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-user@lists.gentoo.org Reply-to: gentoo-user@lists.gentoo.org Mime-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg="PGP-SHA512"; boundary="Signature=_Fri__1_May_2015_10_44_02_+0300_H94hnuaXkfRMLoWF" X-Archives-Salt: 192b3c54-fbb9-4e84-b536-4c061e7ef255 X-Archives-Hash: c61392f873ff515d9b46b5951243a5ca --Signature=_Fri__1_May_2015_10_44_02_+0300_H94hnuaXkfRMLoWF Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, 1 May 2015 05:09:51 +0000 (UTC) Martin Vaeth wrote: > Andrew Savchenko wrote: > > > > That's why kernel makes sure that no floating point instructions > > sneaks in using CFLAGS, you may see a lot of -mno-${intrucion_set} > > flags when running make -V. >=20 > So it should be sufficient that the kernel does not use "float" > or "double", shouldn't it? No. Optimizer paths may be very unobvious, i.e. I'll not be surprised if under some conditions vectorizer may use float instructions for int code. > I can hardly imagine that otherwise the compiler converts integer > or pointer arithmetic into floating point arithmetics, or is > this really the case for certain flags? If yes, why should these > flags *ever* be useful? > I mean: The context switching happens for non-kernel code as well, > doesn't it? Yes, context switching happens for all code and have its costs. But for userspace code context switching happens for many other reasons, e.g. on each syscall (userspace <-> kernelspace switching). Also some user applications may need high precision or context switching pays off due to mass parallel data processing, e.g. SIMD instructions in scientific or multimedia applications. But unless special conditions mentioned above, fixed point is still faster in userspace, some ffmpeg codecs have both fixed and floating point implementations, you may compare them. Programming in fixed point is much harder, so most people avoid it unless they have a very goode reason to use it. And dont't forget that kernel is performance critical unlike most of userspace applications. Best regards, Andrew Savchenko --Signature=_Fri__1_May_2015_10_44_02_+0300_H94hnuaXkfRMLoWF Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCgAGBQJVQy7WAAoJEPZTWjO6HuSNTDIQAKI1F0ewzyk5dkCjLZkUC/sb Q67NzWdG/8ucE12NhG/JhStiYPOs4I9HqxpRXwdiS90VZ5Da/zgtkUhSRuBAKr8W wCC+spNKSZrmDLyJ0G+aLrXQOUkg3OvdsdrqN7TNVF8rGlrJRttZE4lrNxctuxuv E6jRco6PKx4QRWfyQJ7TanPbvUm64EWF7gfPjLWmqdCUel4UmiKmitnXjLg34iu9 e0y2aK0YEMezGM8gJsYkoIXVeFUEFioNNx89pgztAXHsB951XjznfSAjOLu/ZEa0 /rtuQbftmwxoUvlMPCS5MarNWLRzDgDrOmoyxDjjDZAUSCho0SlgJe7E6EPfv7oL 70T3nMSBa9aYSfkx0nxKgvgRs1kEQAoQGMgYPw/CcDQKwrNn4btga+hQDxFLtdjd NPQt8+TspIeYMQiTfEcdt97sdNlZsY3O9RJE4a4SV3n+MsZ8gln/eELQN2opgqKv GbKtdk3mfXuugYujP9KNrhsLD5EsbRmBkqs6zPJtPn96NPL/L/LZjjaIn8Ewlfpw O/oENwsCQFVi5IpfMYUhKk93kpIxpdBHmQ3CkU7VSKjTb4L40QWHnTz7ac5If9+U ITjxZQ7K21ZIDrgKp2M1ekFSksNUGyhPClsDVfkHhJka57N8fnC5VC0/scHiByG+ IEs9ONJ7xAGVOS62bc/1 =+rIY -----END PGP SIGNATURE----- --Signature=_Fri__1_May_2015_10_44_02_+0300_H94hnuaXkfRMLoWF--