Date: Fri, 16 Aug 2002 08:50:00 +0200 From: Poul-Henning Kamp <phk@critter.freebsd.dk> To: David Greenman-Lawrence <dg@dglawrence.com> Cc: Alfred Perlstein <bright@mu.org>, cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/kern uipc_socket2.c Message-ID: <8515.1029480600@critter.freebsd.dk> In-Reply-To: Your message of "Thu, 15 Aug 2002 22:32:11 PDT." <20020815223211.F42978@nexus.root.com>
next in thread | previous in thread | raw e-mail | index | archive | help
In message <20020815223211.F42978@nexus.root.com>, David Greenman-Lawrence writ es: >>> I'm looking at calcru() as well, since is does four 64bit divides and >>> was as expensive as sbreserve() in my profiles. The __qdivrem function >>> that does the 64bit divide appears to consume several thousand instructions >>> in the common case. Something to avoid if at all possible. >> >>Any idea on how to setup warnings when some threshold of 64 bit >>math is reached? I know this entirely arbitrary, but it would be >>interesting and obviously benificial if we could easily find and >>fix more instances of this in a somewhat automated fashion. > > Hmmm...not sure if I'm following you. The 64bit math happens when quad >variables are involved in the divide. It might be possible to come up with >an optimization to qdivrem (and similar functions) that check the dividend >and divisor to see if the two values are less than 32 bits large, and then >do a standard 32bit/32bit hardware divide. I think this might catch a vary >common case where 64bit math wasn't really needed and save a few thousand >instructions as a result. > Calcru() is a tough critter - it would be real nice if Bruce (or anyone) >could give me some thoughts on that. We may have arrived at the point where it is cheaper to timestamp at all boundary conditions instead of doing statistical redistribution. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?8515.1029480600>