Date: Mon, 21 Nov 2016 19:35:48 +0100 From: Jan Bramkamp <crest@rlwinm.de> To: svn-src-all@freebsd.org Subject: Re: svn commit: r308869 - head/sbin/nvmecontrol Message-ID: <def475f6-09c0-7e44-4d26-71db9c59725d@rlwinm.de> In-Reply-To: <123365400.XYmKG93e4H@ralph.baldwin.cx> References: <201611192146.uAJLkDP5094317@repo.freebsd.org> <123365400.XYmKG93e4H@ralph.baldwin.cx>
next in thread | previous in thread | raw e-mail | index | archive | help
On 21/11/2016 19:07, John Baldwin wrote: > On Saturday, November 19, 2016 09:46:13 PM Warner Losh wrote: >> Author: imp >> Date: Sat Nov 19 21:46:13 2016 >> New Revision: 308869 >> URL: https://svnweb.freebsd.org/changeset/base/308869 >> >> Log: >> i386 turns out to not have __uint128_t. So confusingly use 64-bit math >> instead. Since we're little endian, we can get away with it. Also, >> since the counters in quesitons would require billions of iops for >> tens of billions of seconds to overflow, and since such data rates are >> unlikely for people using i386 for a while, that's OK. The fastest >> cards today can't do even a million IOPs. >> >> Noticed by: dim@ >> Sponsored by: Netflix, Inc > > It probably has it if you compile with -march=<foo> where <foo> is new > enough to have SSE. In that case you have 128-bit registers. Starting with SSE2 you use those registers for 4 x 32-bit integer computations but irrc SSE lacks efficient carry operations. It's probably still more efficient to user 32-bit integer registers for bignum operations unless you want to (ab-)use the 53-bit multipliers hidden inside the FPUs. I don't know if correctly aligned memory transfers between SSE registers and memory are atomic. Unless SSE can provide this guarantee there advantage to polluting the code with SIMD built-ins. > Is nvme inherently x86-only? No.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?def475f6-09c0-7e44-4d26-71db9c59725d>