Megapahit's fork of the Second Life viewer. https://megapahit.org/viewer.git/atom?h=cef_147 2025-05-12T13:07:02Z 2025-05-12T13:07:02Z Erik Kundiman erik@megapahit.org 2025-05-12T13:07:02Z urn:sha1:d43c417a737d9f48fece51d084a85e3fad86382b 2024-05-16T05:52:40Z Erik Kundiman erik@megapahit.org 2024-05-16T05:52:40Z urn:sha1:6d51e91895a7f2435c46a876410ccc6c63fe8c82 source for viewer 7.1.7.8974243247 2024-04-29T04:56:09Z Andrey Lihatskiy alihatskiy@productengine.com 2024-04-29T04:43:28Z urn:sha1:1b68f71348ecf3983b76b40d7940da8377f049b7 2023-07-19T03:01:37Z Erik Kundiman erik@megapahit.org 2023-07-12T06:46:32Z urn:sha1:fc6d2ad320b35a7ea4dfa33d88e1bdd54d21904d 2023-01-31T20:05:42Z Andrey Kleshchev andreykproductengine@lindenlab.com 2023-01-31T16:48:16Z urn:sha1:b5b0a3fbf6b58c7f1a7e4377bfeb6adb3337e4bf 2023-01-31T20:04:14Z Henri Beauchamp sldevel@users.noreply.github.com 2023-01-31T16:42:51Z urn:sha1:473ade269628d1fb6cbc7b96a91e1c0aec1b8e59 This commit adds the HBXX64 and HBXX128 classes for use as a drop-in replacement for the slow LLMD5 hashing class, where speed matters and backward compatibility (with standard hashing algorithms) and/or cryptographic hashing qualities are not required. It also replaces LLMD5 with HBXX* in a few existing hot (well, ok, just "warm" for some) paths meeting the above requirements, while paving the way for future use cases, such as in the DRTVWR-559 and sibling branches where the slow LLMD5 is used (e.g. to hash materials and vertex buffer cache entries), and could be use such a (way) faster algorithm with very significant benefits and no negative impact. Here is the comment I added in indra/llcommon/hbxx.h: // HBXXH* classes are to be used where speed matters and cryptographic quality // is not required (no "one-way" guarantee, though they are likely not worst in // this respect than MD5 which got busted and is now considered too weak). The // xxHash code they are built upon is vectorized and about 50 times faster than // MD5. A 64 bits hash class is also provided for when 128 bits of entropy are // not needed. The hashes collision rate is similar to MD5's. // See https://github.com/Cyan4973/xxHash#readme for details. 2023-01-31T17:35:10Z Andrey Kleshchev andreykproductengine@lindenlab.com 2023-01-31T17:35:10Z urn:sha1:a6615b3264011f186678e7d0380291dd3bedc9aa 2023-01-31T17:17:34Z Andrey Kleshchev andreykproductengine@lindenlab.com 2023-01-31T16:48:16Z urn:sha1:851815442625f0378cb21ffdb8dd588122087e18 2023-01-31T16:42:51Z Henri Beauchamp sldevel@users.noreply.github.com 2023-01-31T16:42:51Z urn:sha1:9438ef5f79fdac11080c3fa10c518e335fd7d8d6 This commit adds the HBXX64 and HBXX128 classes for use as a drop-in replacement for the slow LLMD5 hashing class, where speed matters and backward compatibility (with standard hashing algorithms) and/or cryptographic hashing qualities are not required. It also replaces LLMD5 with HBXX* in a few existing hot (well, ok, just "warm" for some) paths meeting the above requirements, while paving the way for future use cases, such as in the DRTVWR-559 and sibling branches where the slow LLMD5 is used (e.g. to hash materials and vertex buffer cache entries), and could be use such a (way) faster algorithm with very significant benefits and no negative impact. Here is the comment I added in indra/llcommon/hbxx.h: // HBXXH* classes are to be used where speed matters and cryptographic quality // is not required (no "one-way" guarantee, though they are likely not worst in // this respect than MD5 which got busted and is now considered too weak). The // xxHash code they are built upon is vectorized and about 50 times faster than // MD5. A 64 bits hash class is also provided for when 128 bits of entropy are // not needed. The hashes collision rate is similar to MD5's. // See https://github.com/Cyan4973/xxHash#readme for details.