ВходНаше всё Теги codebook 无线电组件 Поиск Опросы Закон Суббота
20 апреля
1072485 Топик полностью
Adept (27.01.2021 13:11 - 13:18, просмотров: 534) ответил Adept на интересно и эстетично, спасибо.
прикинул, добавив контроль границ массива, но не реализовывая досрочное завершение, которое у меня тоже в комментах. Поздравляю, коллега - 7 тактов на байт в функции "приведения к 256" Вашим методом, и потом 9 тактов на байт при поиске максимума в массиве 256 байт (моим алгоритмом) - от 9 до 2304 тактов (смотря где встретится максимум в первой или последней попытке) 

итого, на блоке в 2К получим 7*2048+(9..2304)=14345..16640 тактов, т.е. 7..8,125 тактов на байт (среднестатистически (т.к. данные рандомные) считаем 7,5 тактов на байт)

на блоке 64К (представим, что у нас есть МК с 64 RAM на борту :) - получим 7*65535+(9..2304)=7 тактов на байт (практически)

всего на 16% медленнее дурацкого и прожорливого тупого линейного побайтового сравнения с непосредственной адресацией.

конечно, на малых массивах (например 256 байт) будет "не айс" (от 7 до 16(!) тактов на байт, (и-за двойного сравнения фактически), но у нас же БОЛЬШУЩЩИЙ МАССИВ :)))

А на большом массиве Ваш алгоритм выигрывает у моего компактного почти треть(!) 28% (7 тактов против 9) - это круто!

Формально же - тупая сравнилка выигрывает, но по красоте алгоритма и соотношению компактности и скорости Ваш вариант с "приведением к 256" - вне конкуренции.

Класс!!

...делать нужно так, как нужно. А как ненужно - делать не нужно (С) Винни-Пух :)