info
Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
faster "CRC"- / "FNV"-hashing
155 views
Skip to first unread message
Bonita Montero
Oct 10, 2021, 12:52:06 PM10/10/21
to
I derived two hash-algorithms from FNV32/64 and CRC64 that don't yield
the same results, and don't provide the opportunity for error-correction
for CRC, but which have the same equal distribution and are much more
performant on modern OoO-CPUS. How did I do that ?
These are the results on my Linux Ryzen 7 1800X:
fnv streamed 32: : 0.964425 GB/s
fnv blocked 32: : 1.96624 GB/s 104%
fnv streamed 64: : 0.939418 GB/s
fnv blocked 64: : 3.11791 GB/s 232%
crc64: : 0.478093 GB/s
crc64 blocked: : 2.39144 GB/s 400%
the same results, and don't provide the opportunity for error-correction
for CRC, but which have the same equal distribution and are much more
performant on modern OoO-CPUS. How did I do that ?
These are the results on my Linux Ryzen 7 1800X:
fnv streamed 32: : 0.964425 GB/s
fnv blocked 32: : 1.96624 GB/s 104%
fnv streamed 64: : 0.939418 GB/s
fnv blocked 64: : 3.11791 GB/s 232%
crc64: : 0.478093 GB/s
crc64 blocked: : 2.39144 GB/s 400%
Chris M. Thomasson
Oct 10, 2021, 3:36:22 PM10/10/21
to
On 10/10/2021 9:51 AM, Bonita Montero wrote:
> I derived two hash-algorithms from FNV32/64 and CRC64 that don't yield
> the same results, and don't provide the opportunity for error-correction
> for CRC, but which have the same equal distribution and are much more
> performant on modern OoO-CPUS. How did I do that ?
I don't know.
> I derived two hash-algorithms from FNV32/64 and CRC64 that don't yield
> the same results, and don't provide the opportunity for error-correction
> for CRC, but which have the same equal distribution and are much more
> performant on modern OoO-CPUS. How did I do that ?
> These are the results on my Linux Ryzen 7 1800X:
>
> fnv streamed 32: : 0.964425 GB/s
> fnv blocked 32: : 1.96624 GB/s 104%
> fnv streamed 64: : 0.939418 GB/s
> fnv blocked 64: : 3.11791 GB/s 232%
> crc64: : 0.478093 GB/s
> crc64 blocked: : 2.39144 GB/s 400%
>
interested because of my experimental HMAC cipher. I have a C version:
https://groups.google.com/g/comp.lang.c/c/a53VxN8cwkY/m/XKl1-0a8DAAJ
https://pastebin.com/raw/feUnA3kP
Also, I put it up online using a rather inefficient, but working SHA2
lib. I say inefficient because it does not provide an update method.
http://fractallife247.com/test/hmac_cipher/ver_0_0_0_1?ct_hmac_cipher=0422a78fffa58f349a486b3842d2eedfa87985658fb9f011153b896fb97b4b291224ddd327017e9fcdf4b3d8fd5dfde47ae8f23639044f7c5c73a1f0a891087814a139dfe44e47b4300cac921f736776ab7042fb09aae38f8780aa49e5cd128d141e2982d3aa4b288fceef939126c0a319da20b0cf219732504491eb14c691149f
Scott Lurndal
Oct 10, 2021, 6:51:49 PM10/10/21
to
"Chris M. Thomasson" <chris.m.t...@gmail.com> writes:
>
>Btw, if you can come up with a really fast SHA2 impl, I would be
>interested because of my experimental HMAC cipher. I have a C version:
https://en.wikipedia.org/wiki/Intel_SHA_extensions
>
>Btw, if you can come up with a really fast SHA2 impl, I would be
>interested because of my experimental HMAC cipher. I have a C version:
https://developer.arm.com/documentation/100076/0100/a64-instruction-set-reference/a64-cryptographic-algorithms/a64-cryptographic-instructions?lang=en
Branimir Maksimovic
Oct 11, 2021, 1:23:22 AM10/11/21
to
--
7-77-777
Evil Sinner!
with software, you repeat same experiment, expecting different results...
Branimir Maksimovic
Oct 11, 2021, 1:41:17 AM10/11/21
to
On 2021-10-10, Bonita Montero <Bonita....@gmail.com> wrote:
-opyright : (c) 2004 by Dzenis Softic / http://www.dzeni.com
*
* Filename : vmp_crc32.c
*
* Description: Calculates crc32 of string
*
* Company : Seenetix D.O.O.
*
* Authors : B. Maksimovic
*
* $Id$
*
*===========================================================================*/
#include <stddef.h>
static unsigned crc32_table[] =
{
0x00000000, 0x77073096, 0xEE0E612C, 0x990951BA,
0x076DC419, 0x706AF48F, 0xE963A535, 0x9E6495A3,
0x0EDB8832, 0x79DCB8A4, 0xE0D5E91E, 0x97D2D988,
0x09B64C2B, 0x7EB17CBD, 0xE7B82D07, 0x90BF1D91,
0x1DB71064, 0x6AB020F2, 0xF3B97148, 0x84BE41DE,
0x1ADAD47D, 0x6DDDE4EB, 0xF4D4B551, 0x83D385C7,
0x136C9856, 0x646BA8C0, 0xFD62F97A, 0x8A65C9EC,
0x14015C4F, 0x63066CD9, 0xFA0F3D63, 0x8D080DF5,
0x3B6E20C8, 0x4C69105E, 0xD56041E4, 0xA2677172,
0x3C03E4D1, 0x4B04D447, 0xD20D85FD, 0xA50AB56B,
0x35B5A8FA, 0x42B2986C, 0xDBBBC9D6, 0xACBCF940,
0x32D86CE3, 0x45DF5C75, 0xDCD60DCF, 0xABD13D59,
0x26D930AC, 0x51DE003A, 0xC8D75180, 0xBFD06116,
0x21B4F4B5, 0x56B3C423, 0xCFBA9599, 0xB8BDA50F,
0x2802B89E, 0x5F058808, 0xC60CD9B2, 0xB10BE924,
0x2F6F7C87, 0x58684C11, 0xC1611DAB, 0xB6662D3D,
0x76DC4190, 0x01DB7106, 0x98D220BC, 0xEFD5102A,
0x71B18589, 0x06B6B51F, 0x9FBFE4A5, 0xE8B8D433,
0x7807C9A2, 0x0F00F934, 0x9609A88E, 0xE10E9818,
0x7F6A0DBB, 0x086D3D2D, 0x91646C97, 0xE6635C01,
0x6B6B51F4, 0x1C6C6162, 0x856530D8, 0xF262004E,
0x6C0695ED, 0x1B01A57B, 0x8208F4C1, 0xF50FC457,
0x65B0D9C6, 0x12B7E950, 0x8BBEB8EA, 0xFCB9887C,
0x62DD1DDF, 0x15DA2D49, 0x8CD37CF3, 0xFBD44C65,
0x4DB26158, 0x3AB551CE, 0xA3BC0074, 0xD4BB30E2,
0x4ADFA541, 0x3DD895D7, 0xA4D1C46D, 0xD3D6F4FB,
0x4369E96A, 0x346ED9FC, 0xAD678846, 0xDA60B8D0,
0x44042D73, 0x33031DE5, 0xAA0A4C5F, 0xDD0D7CC9,
0x5005713C, 0x270241AA, 0xBE0B1010, 0xC90C2086,
0x5768B525, 0x206F85B3, 0xB966D409, 0xCE61E49F,
0x5EDEF90E, 0x29D9C998, 0xB0D09822, 0xC7D7A8B4,
0x59B33D17, 0x2EB40D81, 0xB7BD5C3B, 0xC0BA6CAD,
0xEDB88320, 0x9ABFB3B6, 0x03B6E20C, 0x74B1D29A,
0xEAD54739, 0x9DD277AF, 0x04DB2615, 0x73DC1683,
0xE3630B12, 0x94643B84, 0x0D6D6A3E, 0x7A6A5AA8,
0xE40ECF0B, 0x9309FF9D, 0x0A00AE27, 0x7D079EB1,
0xF00F9344, 0x8708A3D2, 0x1E01F268, 0x6906C2FE,
0xF762575D, 0x806567CB, 0x196C3671, 0x6E6B06E7,
0xFED41B76, 0x89D32BE0, 0x10DA7A5A, 0x67DD4ACC,
0xF9B9DF6F, 0x8EBEEFF9, 0x17B7BE43, 0x60B08ED5,
0xD6D6A3E8, 0xA1D1937E, 0x38D8C2C4, 0x4FDFF252,
0xD1BB67F1, 0xA6BC5767, 0x3FB506DD, 0x48B2364B,
0xD80D2BDA, 0xAF0A1B4C, 0x36034AF6, 0x41047A60,
0xDF60EFC3, 0xA867DF55, 0x316E8EEF, 0x4669BE79,
0xCB61B38C, 0xBC66831A, 0x256FD2A0, 0x5268E236,
0xCC0C7795, 0xBB0B4703, 0x220216B9, 0x5505262F,
0xC5BA3BBE, 0xB2BD0B28, 0x2BB45A92, 0x5CB36A04,
0xC2D7FFA7, 0xB5D0CF31, 0x2CD99E8B, 0x5BDEAE1D,
0x9B64C2B0, 0xEC63F226, 0x756AA39C, 0x026D930A,
0x9C0906A9, 0xEB0E363F, 0x72076785, 0x05005713,
0x95BF4A82, 0xE2B87A14, 0x7BB12BAE, 0x0CB61B38,
0x92D28E9B, 0xE5D5BE0D, 0x7CDCEFB7, 0x0BDBDF21,
0x86D3D2D4, 0xF1D4E242, 0x68DDB3F8, 0x1FDA836E,
0x81BE16CD, 0xF6B9265B, 0x6FB077E1, 0x18B74777,
0x88085AE6, 0xFF0F6A70, 0x66063BCA, 0x11010B5C,
0x8F659EFF, 0xF862AE69, 0x616BFFD3, 0x166CCF45,
0xA00AE278, 0xD70DD2EE, 0x4E048354, 0x3903B3C2,
0xA7672661, 0xD06016F7, 0x4969474D, 0x3E6E77DB,
0xAED16A4A, 0xD9D65ADC, 0x40DF0B66, 0x37D83BF0,
0xA9BCAE53, 0xDEBB9EC5, 0x47B2CF7F, 0x30B5FFE9,
0xBDBDF21C, 0xCABAC28A, 0x53B39330, 0x24B4A3A6,
0xBAD03605, 0xCDD70693, 0x54DE5729, 0x23D967BF,
0xB3667A2E, 0xC4614AB8, 0x5D681B02, 0x2A6F2B94,
0xB40BBE37, 0xC30C8EA1, 0x5A05DF1B, 0x2D02EF8D,
};
inline static unsigned calc_crc32(unsigned char b, unsigned crc32)
{
return (crc32 >> 8) ^ crc32_table[b ^ (crc32 & 0x000000FF)];
}
unsigned vmp_crc32str(const char* str)
{
unsigned crc32_tmp = 0xFFFFFFFF;
while(*str)
{
crc32_tmp = calc_crc32(*str++, crc32_tmp);
}
crc32_tmp = ~crc32_tmp;
return crc32_tmp;
}
unsigned vmp_crc32(const void* src, size_t size)
{
unsigned crc32_tmp = 0xFFFFFFFF;
int i = 0;
for(;i<size;++i)
{
crc32_tmp = calc_crc32(*(const unsigned char *)src++, crc32_tmp);
}
crc32_tmp = ~crc32_tmp;
return crc32_tmp;
}
/*=============================================================================
* History:
*
* $Log$
* Revision 1.2 2004/04/20 20:08:46 bmaxa
* added vmp_crc32 void version
*
* Revision 1.1 2004/04/20 19:31:53 bmaxa
* crc32 added
*
*
*===========================================================================*/
Bonita Montero
Oct 11, 2021, 2:10:03 AM10/11/21
to
Am 10.10.2021 um 21:36 schrieb Chris M. Thomasson:
> On 10/10/2021 9:51 AM, Bonita Montero wrote:
>> I derived two hash-algorithms from FNV32/64 and CRC64 that don't yield
>> the same results, and don't provide the opportunity for error-correction
>> for CRC, but which have the same equal distribution and are much more
>> performant on modern OoO-CPUS. How did I do that ?
>
> I don't know.
>
>
>> These are the results on my Linux Ryzen 7 1800X:
>>
>> fnv streamed 32: : 0.964425 GB/s
>> fnv blocked 32: : 1.96624 GB/s 104%
>> fnv streamed 64: : 0.939418 GB/s
>> fnv blocked 64: : 3.11791 GB/s 232%
>> crc64: : 0.478093 GB/s
>> crc64 blocked: : 2.39144 GB/s 400%
>>
>
> Btw, if you can come up with a really fast SHA2 impl, I would be
> interested because of my experimental HMAC cipher. I have a C version:
SHA* is completely different and can't be improved how I did it.
> On 10/10/2021 9:51 AM, Bonita Montero wrote:
>> I derived two hash-algorithms from FNV32/64 and CRC64 that don't yield
>> the same results, and don't provide the opportunity for error-correction
>> for CRC, but which have the same equal distribution and are much more
>> performant on modern OoO-CPUS. How did I do that ?
>
> I don't know.
>
>
>> These are the results on my Linux Ryzen 7 1800X:
>>
>> fnv streamed 32: : 0.964425 GB/s
>> fnv blocked 32: : 1.96624 GB/s 104%
>> fnv streamed 64: : 0.939418 GB/s
>> fnv blocked 64: : 3.11791 GB/s 232%
>> crc64: : 0.478093 GB/s
>> crc64 blocked: : 2.39144 GB/s 400%
>>
>
> Btw, if you can come up with a really fast SHA2 impl, I would be
> interested because of my experimental HMAC cipher. I have a C version:
Bonita Montero
Oct 11, 2021, 2:16:05 AM10/11/21
to
Am 11.10.2021 um 07:23 schrieb Branimir Maksimovic:
> On 2021-10-10, Bonita Montero <Bonita....@gmail.com> wrote:
>> I derived two hash-algorithms from FNV32/64 and CRC64 that don't yield
>> the same results, and don't provide the opportunity for error-correction
>> for CRC, but which have the same equal distribution and are much more
>> performant on modern OoO-CPUS. How did I do that ?
>>
>> These are the results on my Linux Ryzen 7 1800X:
>>
>> fnv streamed 32: : 0.964425 GB/s
>> fnv blocked 32: : 1.96624 GB/s 104%
>> fnv streamed 64: : 0.939418 GB/s
>> fnv blocked 64: : 3.11791 GB/s 232%
>> crc64: : 0.478093 GB/s
>> crc64 blocked: : 2.39144 GB/s 400%
>>
> Proprietary?
Of course - but the same equal distribution.
> On 2021-10-10, Bonita Montero <Bonita....@gmail.com> wrote:
>> I derived two hash-algorithms from FNV32/64 and CRC64 that don't yield
>> the same results, and don't provide the opportunity for error-correction
>> for CRC, but which have the same equal distribution and are much more
>> performant on modern OoO-CPUS. How did I do that ?
>>
>> These are the results on my Linux Ryzen 7 1800X:
>>
>> fnv streamed 32: : 0.964425 GB/s
>> fnv blocked 32: : 1.96624 GB/s 104%
>> fnv streamed 64: : 0.939418 GB/s
>> fnv blocked 64: : 3.11791 GB/s 232%
>> crc64: : 0.478093 GB/s
>> crc64 blocked: : 2.39144 GB/s 400%
>>
> Proprietary?
Bonita Montero
Oct 11, 2021, 2:27:32 AM10/11/21
to
Am 11.10.2021 um 07:23 schrieb Branimir Maksimovic:
> On 2021-10-10, Bonita Montero <Bonita....@gmail.com> wrote:
>> I derived two hash-algorithms from FNV32/64 and CRC64 that don't yield
>> the same results, and don't provide the opportunity for error-correction
>> for CRC, but which have the same equal distribution and are much more
>> performant on modern OoO-CPUS. How did I do that ?
>>
>> These are the results on my Linux Ryzen 7 1800X:
>>
>> fnv streamed 32: : 0.964425 GB/s
>> fnv blocked 32: : 1.96624 GB/s 104%
>> fnv streamed 64: : 0.939418 GB/s
>> fnv blocked 64: : 3.11791 GB/s 232%
>> crc64: : 0.478093 GB/s
>> crc64 blocked: : 2.39144 GB/s 400%
>>
> Proprietary?
That's the improved "CRC64":
>> I derived two hash-algorithms from FNV32/64 and CRC64 that don't yield
>> the same results, and don't provide the opportunity for error-correction
>> for CRC, but which have the same equal distribution and are much more
>> performant on modern OoO-CPUS. How did I do that ?
>>
>> These are the results on my Linux Ryzen 7 1800X:
>>
>> fnv streamed 32: : 0.964425 GB/s
>> fnv blocked 32: : 1.96624 GB/s 104%
>> fnv streamed 64: : 0.939418 GB/s
>> fnv blocked 64: : 3.11791 GB/s 232%
>> crc64: : 0.478093 GB/s
>> crc64 blocked: : 2.39144 GB/s 400%
>>
> Proprietary?
#include "crc64.h"
using namespace std;
uint64_t CRC64_ECMA182::operator ()( void const *p, size_t n, uint64_t
startCrc ) const
{
uint64_t crc = startCrc;
uint8_t const *s = (uint8_t *)p,
*end = s + n;
size_t t;
for( ; s != end; ++s )
t = (size_t)(crc >> 56) ^ *s,
crc = table.t[t] ^ (crc << 8);
return crc;
}
uint64_t CRC64_ECMA182::blocked( void const *p, size_t n, uint64_t
startCrc ) const
{
auto crc64_8x8 = []( uint8_t const *s ) -> uint64_t
{
uint64_t crcs[8] =
{
table.t[s[ 0]],
table.t[s[ 8]],
table.t[s[16]],
table.t[s[24]],
table.t[s[32]],
table.t[s[40]],
table.t[s[48]],
table.t[s[56]]
};
size_t t;
uint8_t const *end = ++s + 7;
do
t = (size_t)(crcs[0] >> 56) ^ s[ 0],
crcs[0] = table.t[t] ^ (crcs[0] << 8),
t = (size_t)(crcs[1] >> 56) ^ s[ 8],
crcs[1] = table.t[t] ^ (crcs[1] << 8),
t = (size_t)(crcs[2] >> 56) ^ s[16],
crcs[2] = table.t[t] ^ (crcs[2] << 8),
t = (size_t)(crcs[3] >> 56) ^ s[24],
crcs[3] = table.t[t] ^ (crcs[3] << 8),
t = (size_t)(crcs[4] >> 56) ^ s[32],
crcs[4] = table.t[t] ^ (crcs[4] << 8),
t = (size_t)(crcs[5] >> 56) ^ s[40],
crcs[5] = table.t[t] ^ (crcs[5] << 8),
t = (size_t)(crcs[6] >> 56) ^ s[48],
crcs[6] = table.t[t] ^ (crcs[6] << 8),
t = (size_t)(crcs[7] >> 56) ^ s[56],
crcs[7] = table.t[t] ^ (crcs[7] << 8);
while( ++s != end );
uint64_t crc = 0;
for( size_t i = 0; i != 8; ++i )
crc ^= crcs[i];
return crc;
};
uint8_t const *s = (uint8_t *)p;
uint64_t crc = startCrc;
for( uint8_t const *end = s + (n & -64); s != end; s += 64 )
crc ^= crc64_8x8( s );
crc ^= (*this)( s, n % 64, 0 );
return crc;
}
CRC64_ECMA182::crc64_table::crc64_table()
{
uint64_t const CRC64_ECMA182_POLY = 0x42F0E1EBA9EA3693u;
for( uint64_t i = 0; i != 256; ++i )
{
uint64_t crc = 0,
c = i << 56;
for( unsigned j = 0; j != 8; ++j )
crc = (int64_t)(crc ^ c) < 0 ? (crc << 1) ^ CRC64_ECMA182_POLY : crc
<< 1,
c <<= 1;
t[(size_t)i] = crc;
}
}
CRC64_ECMA182::crc64_table CRC64_ECMA182::table;
Why does it run faster ?
Branimir Maksimovic
Oct 11, 2021, 2:29:14 AM10/11/21
to
from hardware. But, of course faster, better :P
Branimir Maksimovic
Oct 11, 2021, 2:32:34 AM10/11/21
to
On 2021-10-11, Bonita Montero <Bonita....@gmail.com> wrote:
Better to generate table, don't waste time on generation :P
Bonita Montero
Oct 11, 2021, 2:33:43 AM10/11/21
to
Am 11.10.2021 um 08:32 schrieb Branimir Maksimovic:
>> CRC64_ECMA182::crc64_table::crc64_table()
>> {
>> uint64_t const CRC64_ECMA182_POLY = 0x42F0E1EBA9EA3693u;
>> for( uint64_t i = 0; i != 256; ++i )
>> {
>> uint64_t crc = 0,
>> c = i << 56;
>> for( unsigned j = 0; j != 8; ++j )
>> crc = (int64_t)(crc ^ c) < 0 ? (crc << 1) ^ CRC64_ECMA182_POLY : crc
>> << 1,
>> c <<= 1;
>> t[(size_t)i] = crc;
>> }
>> }
>>
>> CRC64_ECMA182::crc64_table CRC64_ECMA182::table;
>>
>> Why does it run faster ?
> Dunno, haven't have need to calculate crc64 yet :P
> Better to generate table, don't waste time on generation :P
Eeeh, I'm using also a table as you can see from above.
>> CRC64_ECMA182::crc64_table::crc64_table()
>> {
>> uint64_t const CRC64_ECMA182_POLY = 0x42F0E1EBA9EA3693u;
>> for( uint64_t i = 0; i != 256; ++i )
>> {
>> uint64_t crc = 0,
>> c = i << 56;
>> for( unsigned j = 0; j != 8; ++j )
>> crc = (int64_t)(crc ^ c) < 0 ? (crc << 1) ^ CRC64_ECMA182_POLY : crc
>> << 1,
>> c <<= 1;
>> t[(size_t)i] = crc;
>> }
>> }
>>
>> CRC64_ECMA182::crc64_table CRC64_ECMA182::table;
>>
>> Why does it run faster ?
> Dunno, haven't have need to calculate crc64 yet :P
> Better to generate table, don't waste time on generation :P
Bonita Montero
Oct 11, 2021, 2:35:07 AM10/11/21
to
Branimir Maksimovic
Oct 11, 2021, 3:47:09 AM10/11/21
to
On 2021-10-11, Bonita Montero <Bonita....@gmail.com> wrote:
https://github.com/intel/isa-l/tree/master/crc
Bonita Montero
Oct 11, 2021, 4:53:39 AM10/11/21
to
Am 11.10.2021 um 09:46 schrieb Branimir Maksimovic:
> On 2021-10-11, Bonita Montero <Bonita....@gmail.com> wrote:
>> Am 11.10.2021 um 08:32 schrieb Branimir Maksimovic:
>>
>>>> CRC64_ECMA182::crc64_table::crc64_table()
>>>> {
>>>> uint64_t const CRC64_ECMA182_POLY = 0x42F0E1EBA9EA3693u;
>>>> for( uint64_t i = 0; i != 256; ++i )
>>>> {
>>>> uint64_t crc = 0,
>>>> c = i << 56;
>>>> for( unsigned j = 0; j != 8; ++j )
>>>> crc = (int64_t)(crc ^ c) < 0 ? (crc << 1) ^ CRC64_ECMA182_POLY : crc
>>>> << 1,
>>>> c <<= 1;
>>>> t[(size_t)i] = crc;
>>>> }
>>>> }
>>>>
>>>> CRC64_ECMA182::crc64_table CRC64_ECMA182::table;
>>>>
>>>> Why does it run faster ?
>>> Dunno, haven't have need to calculate crc64 yet :P
>>> Better to generate table, don't waste time on generation :P
>>
>> Eeeh, I'm using also a table as you can see from above.
>>
>>
> What do you think about following:
> https://github.com/intel/isa-l/tree/master/crc
I won't check this ASM-code. An I don't know why people use ASM.
> On 2021-10-11, Bonita Montero <Bonita....@gmail.com> wrote:
>> Am 11.10.2021 um 08:32 schrieb Branimir Maksimovic:
>>
>>>> CRC64_ECMA182::crc64_table::crc64_table()
>>>> {
>>>> uint64_t const CRC64_ECMA182_POLY = 0x42F0E1EBA9EA3693u;
>>>> for( uint64_t i = 0; i != 256; ++i )
>>>> {
>>>> uint64_t crc = 0,
>>>> c = i << 56;
>>>> for( unsigned j = 0; j != 8; ++j )
>>>> crc = (int64_t)(crc ^ c) < 0 ? (crc << 1) ^ CRC64_ECMA182_POLY : crc
>>>> << 1,
>>>> c <<= 1;
>>>> t[(size_t)i] = crc;
>>>> }
>>>> }
>>>>
>>>> CRC64_ECMA182::crc64_table CRC64_ECMA182::table;
>>>>
>>>> Why does it run faster ?
>>> Dunno, haven't have need to calculate crc64 yet :P
>>> Better to generate table, don't waste time on generation :P
>>
>> Eeeh, I'm using also a table as you can see from above.
>>
>>
> What do you think about following:
> https://github.com/intel/isa-l/tree/master/crc
C / C++ and intrinsics usually result in better code.
Branimir Maksimovic
Oct 11, 2021, 5:12:06 AM10/11/21
to
(without debugger :) )
ASM code is most efficient always and works as tested without
surprises :P
C/C++ you can use after ypou master ASM :P
IMO :P
Bonita Montero
Oct 11, 2021, 5:18:19 AM10/11/21
to
Am 11.10.2021 um 11:11 schrieb Branimir Maksimovic:
> ASM code is most efficient always and works as tested without
> surprises :P
ASM code can be faster in rare cases when you know everyting about
> ASM code is most efficient always and works as tested without
> surprises :P
your OoO-CPU, but in most cases the compiler generates better code.
I've seen code from clang where you might think: there would be no
ASM-programmer that knows all of these optimization-tricks.
Branimir Maksimovic
Oct 11, 2021, 6:42:25 AM10/11/21
to
On 2021-10-11, Bonita Montero <Bonita....@gmail.com> wrote:
compiler generated code, learn and bit it :
Also humans are better in algorithms :P
As major optimisation is *always algorithm* :P
Bonita Montero
Oct 11, 2021, 7:03:51 AM10/11/21
to
Am 11.10.2021 um 12:42 schrieb Branimir Maksimovic:
> Human always beats compiler, as you can always examine
> compiler generated code, learn and bit it :
Humans tend to write Asm that is readable. Compilers generate
> Human always beats compiler, as you can always examine
> compiler generated code, learn and bit it :
Asm that's often not readbale for performance reasons.
Branimir Maksimovic
Oct 11, 2021, 7:12:58 AM10/11/21
to
On 2021-10-11, Bonita Montero <Bonita....@gmail.com> wrote:
Optimize in iterations :P
Bonita Montero
Oct 11, 2021, 7:45:00 AM10/11/21
to
> Readable and compact, not bloated :P
Inlining makes bloat - but is usually more performant.
Loop-unrolling of small loops makes bloat - but is usually
more performant.
> Optimize in iterations :P
Hand-written asm is usually slower because there are only a small
number of asm-writers that know all the optimizaztion-tricks that
compilers have learned for decades. F.e. the code of clang 12 is
meanwhile somewhat faster than that of gcc 11. I think in five
years absoutely no asm writer can beat a compiler.
Bo Persson
Oct 11, 2021, 7:58:43 AM10/11/21
to
I bet they qualify for "you know everything about your OoO-CPU". :-)
David Brown
Oct 11, 2021, 8:23:37 AM10/11/21
to
know about Intel processors. But Intel does not write code - people
working at (or for) Intel write code, and there is absolutely no
guarantee that the person or people who wrote the code know all about
all of Intel's processors - never mind non-Intel x86 processors, or
non-x86 processors, or any other device. At best, you can probably be
quite confident that the code is close to optimal if you run it on the
same processor the assembly author used.
How well it will run on the dozen other current Intel processor
variations is another matter (by "dozen", I am ignoring devices that
differ only in clock speed or core count, and ignoring older devices).
How well it will run on AMD processors is also another matter.
You write these routines in C (or C++), and you tune the optimisation.
You compile with "-fmarch=native", or whatever flag your compiler has to
get the fastest code for your particular processor. You use compiler
features for multi-versioning for target-specific optimisations, so that
the compiler generates versions for different SIMD and other instruction
set extensions, and picks the best version for the real cpu when the
code starts up. You use inline assembly or intrinsics for specific
target versions if you are /sure/ your assembly works faster, and have
measured it.
General use of assembly language is something that comes /way/ down on
the list when you are trying to get fast implementation of code.
Branimir Maksimovic
Oct 11, 2021, 8:56:52 AM10/11/21
to
a chance against dedicated human :P
ONly reason we do not program in assembler is because lerning curve is
steep :P
Bonita Montero
Oct 11, 2021, 9:55:15 AM10/11/21
to
Am 11.10.2021 um 14:56 schrieb Branimir Maksimovic:
> Compiler at best can produce generic optimistic code that does not stand
> a chance against dedicated human :P
It was easy to beat a compiler before 10 years, but today not anymore.
> Compiler at best can produce generic optimistic code that does not stand
> a chance against dedicated human :P
And in five years it will be almost impossible.
David Brown
Oct 11, 2021, 11:19:48 AM10/11/21
to
Branimir Maksimovic
Oct 11, 2021, 12:56:10 PM10/11/21
to
On 2021-10-11, Bonita Montero <Bonita....@gmail.com> wrote:
Branimir Maksimovic
Oct 11, 2021, 12:58:03 PM10/11/21
to
When I write something bigger in it, my brain overheats in
order to undertsand what I wrote before :P
Radica...@theburrow.co.uk
Oct 12, 2021, 5:06:13 AM10/12/21
to
On Mon, 11 Oct 2021 16:55:59 GMT
Branimir Maksimovic <branimir....@icloud.com> wrote:
>On 2021-10-11, Bonita Montero <Bonita....@gmail.com> wrote:
>> Am 11.10.2021 um 14:56 schrieb Branimir Maksimovic:
>>
>>> Compiler at best can produce generic optimistic code that does not stand
>>> a chance against dedicated human :P
>>
>> It was easy to beat a compiler before 10 years, but today not anymore.
>> And in five years it will be almost impossible.
>Look, humans write compilers, start at that :P
Humans wrote AlphaZero. Good luck beating it at chess however.
Branimir Maksimovic <branimir....@icloud.com> wrote:
>On 2021-10-11, Bonita Montero <Bonita....@gmail.com> wrote:
>> Am 11.10.2021 um 14:56 schrieb Branimir Maksimovic:
>>
>>> Compiler at best can produce generic optimistic code that does not stand
>>> a chance against dedicated human :P
>>
>> It was easy to beat a compiler before 10 years, but today not anymore.
>> And in five years it will be almost impossible.
>Look, humans write compilers, start at that :P
Branimir Maksimovic
Oct 12, 2021, 7:01:37 AM10/12/21
to
quality function :P
Compiler is mutch larger byte :P
Radica...@theburrow.co.uk
Oct 12, 2021, 10:49:49 AM10/12/21
to
On Tue, 12 Oct 2021 11:01:26 GMT
>Compiler is mutch larger byte :P
Not really. Both are complex problems.
Branimir Maksimovic <branimir....@icloud.com> wrote:
>On 2021-10-12, Radica...@theburrow.co.uk <Radica...@theburrow.co.uk>
>wrote:
>> On Mon, 11 Oct 2021 16:55:59 GMT
>> Branimir Maksimovic <branimir....@icloud.com> wrote:
>>>On 2021-10-11, Bonita Montero <Bonita....@gmail.com> wrote:
>>>> Am 11.10.2021 um 14:56 schrieb Branimir Maksimovic:
>>>>
>>>>> Compiler at best can produce generic optimistic code that does not stand
>>>>> a chance against dedicated human :P
>>>>
>>>> It was easy to beat a compiler before 10 years, but today not anymore.
>>>> And in five years it will be almost impossible.
>>>Look, humans write compilers, start at that :P
>>
>> Humans wrote AlphaZero. Good luck beating it at chess however.
>>
>AlpaZero is nothing special, just better determination of position
>quality function :P
Its not what it does that matters, its how it does it.
>On 2021-10-12, Radica...@theburrow.co.uk <Radica...@theburrow.co.uk>
>wrote:
>> On Mon, 11 Oct 2021 16:55:59 GMT
>> Branimir Maksimovic <branimir....@icloud.com> wrote:
>>>On 2021-10-11, Bonita Montero <Bonita....@gmail.com> wrote:
>>>> Am 11.10.2021 um 14:56 schrieb Branimir Maksimovic:
>>>>
>>>>> Compiler at best can produce generic optimistic code that does not stand
>>>>> a chance against dedicated human :P
>>>>
>>>> It was easy to beat a compiler before 10 years, but today not anymore.
>>>> And in five years it will be almost impossible.
>>>Look, humans write compilers, start at that :P
>>
>> Humans wrote AlphaZero. Good luck beating it at chess however.
>>
>AlpaZero is nothing special, just better determination of position
>quality function :P
>Compiler is mutch larger byte :P
Chris M. Thomasson
Oct 12, 2021, 4:47:56 PM10/12/21
to
On 10/10/2021 3:51 PM, Scott Lurndal wrote:
> https://developer.arm.com/documentation/100076/0100/a64-instruction-set-reference/a64-cryptographic-algorithms/a64-cryptographic-instructions?lang=en
>
Nice! I failed to notice SHA-384. I like that hash for some reasons.
However, I did notice SHA3, which means they should have it.
> "Chris M. Thomasson" <chris.m.t...@gmail.com> writes:
>
>>
>> Btw, if you can come up with a really fast SHA2 impl, I would be
>> interested because of my experimental HMAC cipher. I have a C version:
>
> https://en.wikipedia.org/wiki/Intel_SHA_extensions
>
>>
>> Btw, if you can come up with a really fast SHA2 impl, I would be
>> interested because of my experimental HMAC cipher. I have a C version:
>
> https://developer.arm.com/documentation/100076/0100/a64-instruction-set-reference/a64-cryptographic-algorithms/a64-cryptographic-instructions?lang=en
>
Nice! I failed to notice SHA-384. I like that hash for some reasons.
However, I did notice SHA3, which means they should have it.
0 new messages