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.
_______________________________________________
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
