[jcxz 184]

ps проверял на стм32ф103, компилятор иар.

1.Не держите всех тут за дураков: эта ваша "проверка" - это для домохозяек аргумент.

В первом случае что именно проверили? Что в случае цикла и в случае memcpy() компилятор очевидно заменил и то и другое циклом типа:

   MOVS Rn, #32/4
p: LDR Rx, [Ry], #4
   STR Rx, [Rz], #4
   SUBS Rn, Rn, #1
   BNE p

или вообще развернул цикл в линейный код?

Так я об этом ещё много постов назад говорил, что Ваш memcpy() в бОльшей части случаев не даст выигрыша. :laughing:

И далее - нашли какой-то случай, когда определённый компилятор, при определённых ключах компиляции даст небольшой выигрыш?

Так я опять же уже давно говорил, что при определённых условиях и memcpy может быть быстрее.

А теперь попробуйте задать размер переменным и указатели переменными, так чтобы они не могли быть вычислены на этапе компиляции.

Измерить всю функцию а не какой-то непонятно как выбранный участок.

Вывод из этих "проверок" можно сделать только один: компилятор оказался умнее вас. :laughing:

 

2.Измерять миллиметровые расстояния линейкой с метровыми делениями - это типичный ардуино-подход.

Позвольте узнать - сколько времени заняли ваши конструкции с установками/сбросами GPIO? Как они оптимизировались в случаях разных тестов?

У вас они дали больше погрешности чем весь "измеряемый" код.

Нормальное измерение длительностей (тем более таких малых) делают по таймеру, но никак не по GPIO.

 

Вся ваша проверка яйца выеденного не стоит. Этими проверками Вы как раз и показали всем тут свой "уровень" программирования и понимания сего процесса.

И проверять там нечего, достаточно взглянуть на листинг как Вам тут уже неоднократно говорили.

Впрочем похоже для вас это пустой звук. Так же как и о самом предмете оптимального программирования Вы не имеете никакого понятия.

[juvf 10]

ваш ответ - тоже априори. много слюней, воды, телепатии и всё мимо. Так ведут себя диванные эксперты.

 

компилятор очевидно заменил и то и другое циклом типа:

   MOVS Rn, #32/4
p: LDR Rx, [Ry], #4
   STR Rx, [Rz], #4
   SUBS Rn, Rn, #1
   BNE p

даже близко не угадали. ни одной строчки кода ))))

 

или вообще развернул цикл в линейный код?

- опять мимо

что Ваш memcpy() в бОльшей части случаев не даст выигрыша.

ещё раз мимо.

 

Позвольте узнать - сколько времени заняли ваши конструкции с установками/сбросами GPIO?

Сначала проверил, сколько времени будет установка и сброс GPIO - с -Ohs составило 300 нс в каждом тесте. Результат показанный ранее, был с учетом погрешности GPIO.

 

Нормальное измерение длительностей (тем более таких малых) делают по таймеру, но никак не по GPIO.

Нормальные измерения длительностей делают осциллографом, анализаторам, а не внутренними таймерами. Осциллограф даст более точное измерение (тем более он поверенный), нежели внутренний таймер МК, когда частота МК на порядок меньше полосы осциллографа. И генератор МК ±вагонИтележка, по сравнению с поверенными средствами измерения. Что ваш внутренний таймер, когда система должна среагировать на внешние прерывание/событие, обработать данные и выдать признак готовности, например дернуть регистр GPIO/DMA/UART? Это реальное время и реальный мир, а не ваша Нарния ваши фантазии с таймерами. Как раз таки осциллограф даст точность в мкм, а таймер в метрах.

Вы предлагаете Измерять миллиметровые расстояния линейкой с метровыми делениями - это типичный эльфо-подход.

 

И проверять там нечего, достаточно взглянуть на листинг

Дак посмотрите, оторвитесь от дивана и посмотрите, вместо того чтобы тут сочинения писать. Я то посмотрел.... исходный код ТС с << | j более грамоздкий в асме, нежели чем без этих лишних операторов или memcpy(). Впрочем похоже для вас это пустой звук. Так же как и о самом предмете оптимального программирования Вы не имеете никакого понятия.

 

Оставайтесь прибывать в своих фантазиях. :laughing:

[jcxz 184]

Нормальные измерения длительностей делают осциллографом, анализаторам, а не внутренними таймерами. Осциллограф даст более точное измерение (тем более он поверенный),

Да уж... цена вам как специалисту теперь уже достаточно ясна. Понятно почему все вокруг виноваты: и компиляторы и Тексас и другие виноваты в ваших проблемах - то CRC не считается, то SPI не работает, то процессор не отлаживается. Больше говорить с вами не о чем.... :smile3046:

Из-за генератора МК видите ли неточность таймера возникает. А то что и работа GPIO и выполнение этой кучи кода (которая ещё и по-разному может скомпилиться) зависят от этого же самого генератора об этом конечно не подумали? А то что вместо прямого измерения, делается какое-то косвенное на которое кроме кучи разных факторов и режимы работы пинов влияют тоже не подумали? И поверенность осциллографа ещё сюда приплели. :biggrin:

[juvf 10]

Ну, даешь, ядрена вошь!

И олень тебе не гож?

А вчерась мытарил душу:

Вынь оленя да положь!..

 

То дай код, в нём ошибка! то новый вымыслы про стек... то внезапно код мой безразличен... то предложение проверить да проверь... то проверять там нечего... виртуоз-переобувальщик. а когда все таки проверил - вдруг проверка неугодная стала!!!

аргументы кончились, понеслось что-то абстрактное, типа "кучи разных факторов" и оскорбление негативная оценка оппонента, типичное поведения.... ну вы поняли кого...

Попробуйте когда-нить не теоретизировать внустую, а скомпилировать и посмотреть разные варианты с копированием в цикле на разных компиляторах с включённой полной оптимизацией по скорости и с разными условиями цикла (короткий цикл/длинный, условия окончания и указатели - переменные или известны на этапе компиляции). И будете удивлены.

вот тут вы правы, соглашусь!!! Очень удивился. memcpy() на порядок быстрее for-loop. Перепробывал с разными вариантами, с переменными размерами массива и указателями, неизвестными на этапе компиляции. в тактах процессора примерно 90 к 700(без gpio, таймеров и прочей "кучи разных факторов"). Причем оптимизация практически не влияет на memcpy(). Он всегда быстрый. Вашим for даже и не снилась такая скорость.

 

устали вы меня.

[razrab83 17]

1

Изменено 16 февраля, 2019 пользователем razrab83