Date: Thu, 28 Feb 2013 19:37:32 +0200 From: Alexander Motin <mav@FreeBSD.org> To: Alexey Dokuchaev <danfe@FreeBSD.org> Cc: Davide Italiano <davide@FreeBSD.org>, svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org Subject: Re: svn commit: r247460 - head/sys/dev/acpica Message-ID: <512F95DC.1040005@FreeBSD.org> In-Reply-To: <20130228162522.GA41693@FreeBSD.org> References: <201302281127.r1SBR2VE068276@svn.freebsd.org> <20130228162522.GA41693@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 28.02.2013 18:25, Alexey Dokuchaev wrote: > On Thu, Feb 28, 2013 at 11:27:02AM +0000, Davide Italiano wrote: >> New Revision: 247460 >> URL: http://svnweb.freebsd.org/changeset/base/247460 >> >> Log: >> MFcalloutng (r247427 by mav): >> We don't need any precision here. Let it be fast and dirty shift then >> slow and excessively precise 64-bit division. >> >> - if (sbt >= 0 && us > sbt / SBT_1US) >> - us = sbt / SBT_1US; >> + if (sbt >= 0 && us > (sbt >> 12)) >> + us = (sbt >> 12); > > Does this really buy us anything? Modern compilers should be smart enough to > generate correct code. Do you have evidence that this is not the case here? > Not to mention that it obfuscates the code by using some magic constant. SBT_1US is 4294 (0x10c6). The best that compiler may do is replace division with multiplication. In fact, Clang even does this on amd64. But on i386 it calls __divdi3(), doing 64bit division in software. Shift is definitely cheaper and 5% precision is fine here. -- Alexander Motin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?512F95DC.1040005>