Great - thanks Dan. On 3 Mar 2015 20:27, "danle...@gmail.com" <danle...@gmail.com> wrote:
> v1 UUID's are deterministically unique across both space and time. > Random UUID's are random. There is an (infinitesimally small chance of a > duplicate). To my knowledge, the reason random uuid's exist and are part > of the RFC is that they are bone simple to implement, whereas v1 and v3/v5 > involve all kinds of non-obvious supporting facilities such as a monotonic > clock or message-digest algorithm. > > V1 UUID's are uniquified in three different ways: a unique 6 byte node id > is computed (the details are interesting, but refer to the source for > more). It is combined with a thread-safe, concurrent monotonic timestamp > that is guaranteed to generate always increasing values regardless of clock > precision or degree of concurrency. Finally, a 2-byte "clock-seq" value is > randomly seeded at load-time and incorporated into the calculation. So, > even if the system is restarted on the exact same node with the hardware > clock for some reason adjusted backwards and it is attempted to generate > another UUID at the exact "same" millisecond as one which had been > generated prior, there is only a 1 in 65536 chance of issuing a duplicate. > > We do not use the MAC address actually. clj-uuid/node.clj at master · > danlentz/clj-uuid > <https://github.com/danlentz/clj-uuid/blob/master/src/clj_uuid/node.clj> has > more detail, but this topic is specifically addressed by the RFC. the > following excerpt describes the node address calculation: > > ;; "A better solution is to obtain a 47-bit cryptographic quality random > ;; number and use it as the low 47-bits of the Node-ID, with the least > ;; significant bit of the first octet of the Node-ID set to one. This > ;; bit is the unicast/multicast bit, which will never be set in IEEE 802 > ;; addresses obtained from network cards. Hence, there can never be a > ;; conflict between UUID's generated by machines with and without network > ;; cards." > ;; . . . > ;; . . . > ;; "In addition, items such as the computer's name and the name of the > ;; operating system, while not strictly speaking random, will help > ;; differentiate the results from those obtained by other systems... > ;; ... A generic approach... IS TO ACCUMULATE AS MANY SOURCES AS POSSIBLE > ;; INTO A BUFFER, USE A MESSAGE DIGEST SUCH AS MD5 OR SHA1, TAKE AN > ;; ARBITRARY 6 BYTES FROM THE HASH VALUE, AND SET THE MULTICAST BIT > ;; AS DESCRIBED ABOVE." > ;; > ;; -- [RFC4122:4.5 "Node IDs that do not Identify the Host"] > > If there are any good reasons why one should pay 10 times the cost to > generate a UUID randomly, I'd like to hear them. > > > > On Tuesday, March 3, 2015 at 3:11:23 PM UTC-5, Colin Yates wrote: >> >> Are v1 as "unique" as randomUUID()? >> On 3 Mar 2015 20:08, "danl...@gmail.com" <danl...@gmail.com> wrote: >> >>> PS. We are now TEN TIMES faster, so it is a lot easier to compute that >>> percentage: >>> >>> #'uuid/v1: 201 nanoseconds >>> #'java.util.UUID/randomUUID: 2012 nanoseconds >>> >>> >>> Best, >>> Dan >>> >>> >>> On Tuesday, March 3, 2015 at 3:06:35 PM UTC-5, danl...@gmail.com wrote: >>>> >>>> I invoked "engineer's privilege" to quote the number very >>>> conservatively. In one of the later episodes, didn't Scotty confide that >>>> the Enterprise actually went up to warp 11, he just never told anyone? :) >>>> >>>> Actually, you are right -- I noticed it after I hit "send". As you can >>>> tell, the relative performance number has been a little bit of a moving >>>> target as things improved quickly and I grabbed the number from a little >>>> too far back in the REPL. >>>> >>>> Thanks Jacob. I really do hope this is a library that people will find >>>> modestly useful. >>>> >>>> >>>> >>>> On Tuesday, March 3, 2015 at 2:45:38 PM UTC-5, Jacob Strength wrote: >>>>> >>>>> That is pretty amazing, I'll have to remember this library next time I >>>>> need to use UUID's. >>>>> Also I think you meant 450% faster. >>>>> >>>>> On Sunday, March 1, 2015 at 5:35:16 PM UTC-7, danl...@gmail.com wrote: >>>>>> >>>>>> Ok, for anyone following my adventures optimizing clj-uuid, I've >>>>>> gotten another substantial win. >>>>>> Check it out: http://danlentz.github.io/clj-uuid >>>>>> >>>>>> #'uuid/v1: 443 nanoseconds >>>>>> #'java.util.UUID/randomUUID: 2012 nanoseconds >>>>>> >>>>>> Also, the test suite has much greater coverage with individual tests >>>>>> for each v1, v,3, v4, v5 uuid version. >>>>>> And, finally, there more interesting notes about some of the esoteric >>>>>> details of the node-id representation >>>>>> and the way it is calculated to disambiguate it from any legal 802 >>>>>> MAC hardware address. And more.... ;) >>>>>> >>>>>> >>>>>> ============================================================ >>>>>> ========== >>>>>> >>>>>> user> (criterium/bench (uuid/v1)) >>>>>> >>>>>> Evaluation count: 139356300 in 60 samples of 2322605 calls. >>>>>> Execution time mean: 443.707611 ns >>>>>> >>>>>> >>>>>> user> (criterium/bench (java.util.UUID/randomUUID)) >>>>>> >>>>>> Evaluation count : 30850980 in 60 samples of 514183 calls. >>>>>> Execution time mean : 2.012861 µs >>>>>> >>>>>> >>>>>> -- >>> You received this message because you are subscribed to the Google >>> Groups "Clojure" group. >>> To post to this group, send email to clo...@googlegroups.com >>> Note that posts from new members are moderated - please be patient with >>> your first post. >>> To unsubscribe from this group, send email to >>> clojure+u...@googlegroups.com >>> For more options, visit this group at >>> http://groups.google.com/group/clojure?hl=en >>> --- >>> You received this message because you are subscribed to the Google >>> Groups "Clojure" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to clojure+u...@googlegroups.com. >>> For more options, visit https://groups.google.com/d/optout. >>> >> -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with > your first post. > To unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en > --- > You received this message because you are subscribed to the Google Groups > "Clojure" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to clojure+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
