История изменений

В точку, я выше написал что сильно налажал с тестами. Но! Если имплементить всё в одной цели компиляции то выигрывает хеш, gcc при -O3 очень хорошо всё разруливает когда весь код вместе, а вот при вызове из вне приходится исполнять как есть, даже инлайн не спасёт ибо дело не в том. Так что если полагаться на оптимизацию компилятора и весь код в одном компилируемом файле, то будет почти 4х кратный прирост, если из вне всё ломается и либо разницы нет (особенно если намеренно снизить частоту CPU до констанных тактов например 800Mz) и всё идёт вровень почти ибо да и тут strcmp чуть выигрывает. Но и тут не всё так гладко, если я отрубаю из своих 6 ядер 5. Оставляя 1 ядро на с принудительной частотой в 800Mz то выигрывает снова хеш при условии что при условии что весь код хеша и функция сравнения находятся в том же компилируемом файле что и рабочий код, но это при условии обязательного -O3 и ручки к нему в молитве что бы оптимизация таки была. Хотя даже тут не всё гладко если при использовании возврата значения по указателю из функции которая в библиотеке то всё быстрее по понятным причинам, если же всё в одном файле то время двойного доступа к памяти из за использования указателя накладывает расходы и получается медлене, то есть для локального вызова лучше использовать возврат по значению даже для жирного union, видать gcc видит что я использую его только как int и приводит к int запихивая его вообще в регистр. Короче, нечего выёживатся strcmp вполне себе норм (жёстко оптимизирован (спасибо разрабам) и переплюнуть его сложно для общего случая), поверху ещё openmp и всё, так или иначе вот прямо сейчас я не упираюсь в редере с скорость получения данных материала, поэтому что-то ещё делать смысла нет, разве что завесить openmp что бы был дополнительный бюджет миллисекунд.

В точку, я выше написал что сильно налажал с тестами. Но! Если имплементить всё в одной цели компиляции то выигрывает хеш, gcc при -O3 очень хорошо всё разруливает когда весь код вместе, а вот при вызове из вне приходится исполнять как есть, даже инлайн не спасёт ибо дело не в том. Так что если полагаться на оптимизацию компилятора и весь код в одном компилируемом файле, то будет почти 4х кратный прирост, если из вне всё ломается и либо разницы нет (особенно если намеренно снизить частоту CPU до констанных тактов например 800Mz) и всё идёт вровень почти ибо да и тут strcmp чуть выигрывает. Но и тут не всё так гладко, если я отрубаю из своих 6 ядер 5. Оставляя 1 ядро на с принудительной частотой в 800Mz то выигрывает снова хеш при условии что при условии что весь код хеша и функция сравнения находятся в том же компилируемом файле что и рабочий код, но это при условии обязательного -O3 и ручки к нему в молитве что бы оптимизация таки была. Хотя даже тут не всё гладко если при использовании возврата значения по указателю из функции которая в библиотеке то всё быстрее по понятным причинам, если же всё в одном файле то время двойного доступа к памяти из за использования указателя накладывает расходы и получается медлене, то есть для локального вызова лучше использовать возврат по значению даже для жирного union, видать gcc видит что я использую его только как int и приводит к int запихивая его вообще в регистр. Короче, нечего выёживатся strcmp вполне себе норм, поверху ещё openmp и всё, так или иначе вот прямо сейчас я не упираюсь в редере с скорость получения данных материала, поэтому что-то ещё делать смысла нет, разве что завесить openmp что бы был дополнительный бюджет миллисекунд.