Date: Sun, 6 May 2007 20:10:20 +1000 From: Peter Jeremy <peterjeremy@optushome.com.au> To: Diomidis Spinellis <dds@aueb.gr> Cc: arch@freebsd.org, Garance A Drosehn <gad@freebsd.org> Subject: Re: Accounting changes Message-ID: <20070506101020.GL825@turion.vk2pj.dyndns.org> In-Reply-To: <463D9A7A.1080800@aueb.gr> References: <19235.1178303887@critter.freebsd.dk> <463BB88F.4020804@aueb.gr> <p06240809c262e5d7ac79@[128.113.24.47]> <463D9A7A.1080800@aueb.gr>
next in thread | previous in thread | raw e-mail | index | archive | help
--uCPdOCrL+PnN2Vxy Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2007-May-06 12:06:02 +0300, Diomidis Spinellis <dds@aueb.gr> wrote: >Garance A Drosehn wrote: >>Does this mean the new accounting record will be using the >>native-hardware format for floating point numbers? Does that mean >>the records produced will be different for different hardware? > >My intention is to use the standard (IEEE 754-1985 / IEEE 854-1987 / IEC= =20 >60559) 32-bit float format. This is the C "float" type on all the=20 >architectures we support. I could add a typedef clarifying this, but I=20 >doubt we'll ever support an architecture (VAX?) where float is a=20 >different format. IEEE-754 etc define how to interpret a 32-bit object as a floating point number. AFAIK, it does not define how that object is laid out in memory so that a float written on SPARC (big-endian) will be different to that written on an i386 (little-endian). Accounting records do not need all the features that a general FP format needs: - No need to support negative numbers - It is easy to define comp_t so there are no negative exponents - No need to support denormals - No need to support NaN - Supporting infinity is optional. This means that it's possible to define a format that is relatively easy to manipulate or convert into a "standard" C FP format. >>I also wonder about using a time_t for ac_btime (starting time). >>Now that we're running freebsd on very fast, multi-processor systems, >>we might care whether "<this>-command" executed before "<that>-command", >>and we might wish to have better resolution for the start-time of a >>given command. On a multi-processor machine, both commands may have begun at the same time (measured to whatever precision you want). There are occasional discussions regarding file timestamps (lack of precision can confuse make) - which is a related issue. The decision as to whether make ac_time a time_t or (eg) struct timespec is not obvious: There is a definite space disadvantage to increasing ac_time precision (though there's only one instance per accounting record so the problem isn't as serious as comp_t). OTOH, I can see theoretical reasons for wanting to know which command came first. This is probably a question that needs wider discussion: Has there been any request for greater precision within the FreeBSD user community? --=20 Peter Jeremy --uCPdOCrL+PnN2Vxy Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQFGPamM/opHv/APuIcRAstHAJwJcziVPZDVoeZgM58mZ11vq2vdfQCfeKPf Q/IU5yS+ZerhrBy5jQCW0lg= =yegx -----END PGP SIGNATURE----- --uCPdOCrL+PnN2Vxy--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20070506101020.GL825>