ак, мужики, отвлеклись от темы на посторонние разговоры.
прекращаем этот базар про разные "породы" МК.

Так-то тема интересная. Может модераторы вынесут оффтоп в отдельную ветку?

этот базар про "породы" МК я могу только удалить совсем - он не достоин отдельной темы.

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

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


Это вы с флагами накосячили. Смотрите, я там -mtune=cortex-m0 написал, но видите всякие movge, которых у M0 быть не должно? ) Для ARM нужно использовать -mcpu, а -mtune за набор инструкций не отвечает, как какой-то generic набор...

Сначала пишите о том, что МК и/или технологии программирования раз в квартал устаревают, а потом сожалеете, что все меньше и меньше адекватных программистов...

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

Вангую, что через пару лет мигание на светодиоде будет делаться так: берем нейросеть универсальную, даем ей на вход текстовую строку "менять уровень на 6й ножке", и все это заливаем в МК за 22 цента с 100500 гигабайт ОЗУ и в 1024 раза большим флешем, работающем на 1024 терегерцах. А чо, оптимальный код же! Даже идеальный, потому что для переделки его в музыкальную шкатулку или в навигатор дрона надо поменять только текстовую строку на входе... Порог вхождения в программирование ниже плинтуса... Замечательно же!!!!?

Добавлено after 5 minutes 14 seconds:
В принципе, на всяких растах и пайтонах (привет ESP32!) УЖЕ можно так писать... ИИ справится

ARV, ИИ вообще для простых и средней по сложности задач и теперь справляется.

Copilot на Bing, LED blink с STM32F103.

задача:

предлагаемое решение:


Запуск в IDE и компиляция:


Объем памяти вообще не "терабайты":

Симуляция в Proteus:


Оставалось только поставить макет на пробное испытание на раб. столе . Более-менее корректируем опорная частота MK, время, выводы и т.д.

Мое время выполнения: 20 секунд (схема в симуляторе у меня уже была нарисована). Поменял только int -> volatile int.
Все не так пессимистично, как описываете. Попробуйте. Будете удивлены. Если не для полного решения, то, по крайней мере, сокращает бесконечный поиск. Иногда направление для решения имеет важное значение. Это похоже на разговор с другом-экспертом. Конечно, внимательно проверяйте все, что он предлагает.

Работа с ИИ напоминает старую знакомую сказку
"Трое из ларца, одинаковы с лица":
"... а вы и жрать за(вместо) меня будете?!!!... "

В том-то и дело, что и жрать будет. Просто сейчас это кажется смешным, а когда станет не смешным, будет поздно.

Добавлено after 2 minutes 49 seconds:
veso74, надеюсь, вы не из тех, кто сетует, что вменяемых программистов все меньше, а говнокода всё больше?

(Не очень понимаю нелитературный русский язык). Мы "ревнуем" по прогр. коду. Но процесс необратим. Раньше так говорили и про php (vs html), и про C (vs ASM, Fortran и т.д), и про Arduino, и о пластиковой обуви в сравнении с деревянной (бг: налъм, ру: деревянные лапти?) .

Если хорошо понимаешь, какой код тебе нужен от AI, то он заметно ускоряет работу. В VS Code активно пользуюсь Codeium. Случаи, когда он выдает действительно ровно то, что тебе нужно не так часты, но корректировка его кода занимает заметно меньшее время, чем написание кода с нуля.

Развитие ИИ (и конечный результат) давно предсказано в "ТЕРМИНАТОР"е.

Но не всем из нас удастся до того времени дожить (хотя совсем мало осталось).

Я бы сказал, что количество адекватных программистов в абсолютном выражении даже больше и больше. Их меньше и меньше в относительном, так как само количество разработчиков растет.


Намного чаще не некогда, а элементарно лениво. 40 лет уже разработкой занимаюсь, а всё равно постоянно приходится учиться. И совсем не факт, что ассемблер AVR сложней освоить, чем, для примера, MQTT. Особенно когда требуются распределенные транзакции.
Следует просто понимать, что сейчас на МК решаются такие задачи, которые еще не так давно физически нельзя было вообще решить вычислительной техникой.
Вы бы на АСУ ТП ЕвроХим в Невинномысcке посмотрели. Тогда сразу же осознали, что с AVR и ассемблером подобную задачу решить физически не реально. Говорю о том, где реально сам руки приложил.

Во-первых, AI помогает и на ассемблере.

Спойлер

AVR assembler LED blink

Код:

; Define the clock frequency
.equ F_CPU = 16000000

; Define the LED pin
.equ LED_PIN = PB0

; Define the delay loop counter
.equ DELAY_COUNTER = 0xFF

; Initialize the stack pointer
.org 0x00
jmp start

; Main program
start:
  ; Set the LED pin as output
  ldi r16, (1 << LED_PIN)
  out DDRB, r16

loop:
  ; Turn the LED on
  ldi r16, (1 << LED_PIN)
  out PORTB, r16

  ; Delay for a short period
  ldi r17, DELAY_COUNTER
delay_loop:
  dec r17
  brne delay_loop

  ; Turn the LED off
  ldi r16, (0 << LED_PIN)
  out PORTB, r16

  ; Delay for a short period
  ldi r17, DELAY_COUNTER
delay_loop2:
  dec r17
  brne delay_loop2

  ; Repeat the loop
  rjmp loop

Во-первых, непонятен выпад в сторону Rust, так как он конкурент в большей степени C, чем C++. С последним конкурировать ему не просто, например, из-за отсутствия наследования.
В-третьих, большая наивность считать, что AI способен писать код, а не оказывать помощь в его написании.
В-четвертых, 99.9% постановок содержит неточности, ошибки и неоднозначности, которые без коммуникации между заказчиком, аналитиком и разработчиком никакой AI решить не сможет. Последние годы я не менее, чем половину рабочего времени, только этим занимаюсь.

Добавлено after 18 minutes 23 seconds:

В сфере использования AI как раз больше и всего пугает доверие некоторых людей к его результатам. А ведь AI по определению должен не только ошибаться, но и быть склонен к систематическим ошибкам.
AI обучается под управлением человека и на том, что уже создано человеком. Со всеми человеческими ошибками, заблуждениями и выше упомянутым гвонокодом.
Поэтому и следует ожидать от него не меньше заблуждений, ошибок и говнокода, чем от человека. Просто делает он их на порядки быстрее )
Например, несмотря на почти год обучения модели прогнозирования длительности рейсов вагонов по сети РЖД, при кроссвалидации она проигрывает обыкновенной ARIMA в 20% случаев.
Я уже молчу о более понятных обывателю случаях со штрафами от AI на камерах контроля за дорожным движением.

Ну вот все говорите верно, а выводы пытаетесь делать не правильные. Не помню, как такое когнитивное искажение называется?

Если рассматривать отношение количества адекватных программостов к общему количеству, то мои слова "их меньше и меньше" придется отнести к этому отношению, независимо от абсолютных значений.

Изучать новое, конечно, и в 70 лет не грех, но... Что я вижу вокруг себя? Берут программиста-новичка, выпускника бакалавриата. И ставят задачу: мы тут 20 лет используем вот такую систему программирования - ХХХХХ - слыхал? Не слыхал? Ну ничего, разберешься. Надо, чтобы ты завтра на ней сделал сервер ИИ. Посмотри, как мы 20 лет делали сервер БД, и сделай по образцу. Сдаём через месяц. Справишься?

В итоге этот новичок, если не сбегает, выпучив глаза копипастит код из прежних проектов, ни на секунду не задумываясь, как оно устроено, иначе в сроки не уложиться. И если оно потом заработает (а рано или поздно заработает), оно становится частью той самой базы "мы 20 лет". В итоге после года работы профессиональный рост такого программиста равен 0, но от реальности он отстал почти на бесконечность.

Именно поэтому и прибегает к ИИ-генераторам кода. Программист делает так код, тестировщик так делает тесты, в итоге ИИ обучается генерировать тестопроходные коды, и кто будет проверять?! Чтобы проверять, надо понимать, а уже сейчас практически никто не понимает, как ИИ работает, и (см. выше) число тех, кто понимает результат его работы, все меньше. В итоге все больше доверие к ИИ, ибо "компьютер не ошибается".

Чтобы это говнище ворочалось, выпускаются более мощные процессоры. Более мощные процессоры порождают желание наговнокодить то, что вчера считалось невозможным... И круг замыкается.

ПростоНуб, ловите пузырьковую и не ворованную у вас median5 ) Алгоритм простейший: тремя перестановками передвигаем в конец наибольшее из 4-х значений, оно нам больше не нужно, то же самое повторяем для оставшихся четырех, осталось 3 значения из которых наибольшее и будет искомым. 1000 итераций для O3 выполняются за 31029 и 27050 тактов в мою пользу, с O2 вы выигрываете 33 такта )

Если вернуться к области МК, то непромышленное их применение, сводится к совершенно бесполезным вещам, которые, как тут верно было подмечено, "еще вчера были нереализуемыми".

Кстати, и промышленное применение зачастую этим страдает. Например, у многих есть мультиварки. Но, имхо, спустя пару месяцев игр, 99,99% всех пользователей из тех, кто не забросил ее вообще, используют 1 или 2 поограммы в ней. То же самое со смартфонами и т.п. бытовыми устройствами. Т.е. реализуются ранее невозможные БЕСПОЛЕЗНЫЕ функции.

Недавно впервые зашел на сайт известного Алекса Гайвера... Увидел там проект вентилятора, который нацеливается на лицо методом распознавания лица на видео. Еще вчера это было невозможно, теперь с этим справился самодельщик. И? Ни один человек в мире не будет пользоваться таким вентилятором иначе, как хвастаясь перед другими.

В общем, кризис жанра полный

Не вижу. Полностью профилирующий код опять ведь не привели.
А я привожу:

Спойлер

Код:

#include <algorithm>
#include <cstdint>
#include <stdbool.h>
#include <stdio.h>
#include <stdlib.h>
#include <time.h>

#define BUF_SIZE 400000*77
#define MIN(a,b) (((a)<(b))?(a):(b))
#define MAX(a,b) (((a)>(b))?(a):(b))
#define SWAP(a,b,type) {type ttttttttt=a;a=b;b=ttttttttt;}

int median5_adrift(int* arr)
{
   int a = arr[0], b = arr[1], c = arr[2], d = arr[3], e = arr[4];

   if (a > b) std::swap(a, b);
   if (b > c) std::swap(b, c);
   if (c > d) std::swap(c, d);
   if (a > b) std::swap(a, b);
   if (b > c) std::swap(b, c);
   if (c > e) std::swap(c, e);
   if (a > b) std::swap(a, b);
   return (b > c) ? b : c;
}

int median3 (int a, int b, int c) {
  return MAX(MIN(a,b),MIN(c,MAX(a,b)));
}

int median5 (int *v) {
  return median3(
        v[4],
        MAX(MIN(v[0], v[1]), MIN(v[2], v[3])),
        MIN(MAX(v[0], v[1]), MAX(v[2], v[3]))
    );
}

void do_only_mean(int *rand_buf, int *res_buf) {
  for (int i = 0; i < BUF_SIZE - 5; i++) {
    res_buf[i] = median5(rand_buf++);
  }
  return;
}

void adrift_do_only_mean(int *rand_buf, int *res_buf) {
  for (int i = 0; i < BUF_SIZE - 5; i++) {
    res_buf[i] = median5_adrift(rand_buf++);
  }
  return;
}

int main() {
  int *rand_buf = (int*) malloc(BUF_SIZE*sizeof(int));
  int *res_buf = (int*) malloc(BUF_SIZE*sizeof(int));

  srand(time(NULL));
  for ( int i = 0; i < BUF_SIZE; i++) {
    rand_buf[i] = rand();
  }

  clock_t start = clock() ;
  adrift_do_only_mean(rand_buf, res_buf);
  clock_t end = clock() ;
  double adrift_elapsed_time = (end - start) / (double)CLOCKS_PER_SEC;

  start = clock() ;
  do_only_mean(rand_buf, res_buf);
  end = clock() ;
  double mean_elapsed_time = (end - start) / (double)CLOCKS_PER_SEC;

  printf("%f -- %f => %f\n", adrift_elapsed_time, mean_elapsed_time, adrift_elapsed_time / mean_elapsed_time);
}

Без оптимизации мой код выигрывает в 2 раза (gcc ./median.cpp)
1.701809 -- 0.775227 => 2.195240
С оптимизацией в 3.5 раза (gcc -O3 ./median.cpp)
0.116901 -- 0.032853 => 3.558305

На самом деле, это давно известно, что std::swap не векторизуется. Ну хоть убейся. А сравнения - легко и просто.
Если заинлайнить median3(), то median5() будет всего 16 команд.

Спойлер

Код:

   vmovd   (%rdi), %xmm2
   vmovd   4(%rdi), %xmm4
   vmovd   8(%rdi), %xmm0
   vpminsd   %xmm4, %xmm2, %xmm1
   vmovd   12(%rdi), %xmm5
   vpminsd   %xmm5, %xmm0, %xmm3
   vpmaxsd   %xmm4, %xmm2, %xmm2
   vpmaxsd   %xmm5, %xmm0, %xmm0
   vpmaxsd   %xmm1, %xmm3, %xmm3
   vpminsd   %xmm2, %xmm0, %xmm0
   vmovd   16(%rdi), %xmm1
   vpmaxsd   %xmm3, %xmm1, %xmm2
   vpminsd   %xmm3, %xmm1, %xmm1
   vpminsd   %xmm2, %xmm0, %xmm0
   vpmaxsd   %xmm1, %xmm0, %xmm0
   vmovd   %xmm0, %eax
   ret

А портянку median5_adrift() остается на регистрах общего назначения из 34 команд

Спойлер

Код:

   movl   (%rdi), %r8d
   movl   4(%rdi), %edx
   movl   8(%rdi), %eax
   movl   12(%rdi), %ecx
   movl   16(%rdi), %esi
   cmpl   %edx, %r8d
   jg   .L2
   cmpl   %eax, %edx
   jle   .L8
   movl   %edx, %edi
   movl   %r8d, %edx
   movl   %edi, %r8d
.L3:
   cmpl   %r8d, %ecx
   movl   %eax, %edi
   cmovg   %r8d, %ecx
   cmpl   %edx, %eax
   cmovge   %edx, %eax
   cmovge   %edi, %edx
.L4:
   cmpl   %ecx, %edx
   movl   %ecx, %edi
   cmovle   %edx, %ecx
   cmovle   %edi, %edx
   cmpl   %ecx, %eax
   cmovl   %ecx, %eax
   cmpl   %edx, %esi
   cmovle   %esi, %edx
   cmpl   %edx, %eax
   cmovl   %edx, %eax
   ret
   .p2align 4
   .p2align 3
.L2:
   cmpl   %eax, %r8d
   jg   .L3
   cmpl   %ecx, %eax
   cmovle   %eax, %ecx
   movl   %edx, %eax
   movl   %r8d, %edx
   jmp   .L4

Предвидя возражения, что используете легаси архитектуру без поддержки векторизации, предложу подумать, а что будет, когда потребуется сменить МК на более современный. Переписывать код будете?

Добавлено after 32 minutes 29 seconds:

А можно уточнить, в каких системных интеграторах или IT компаниях Вы такое видите?
Вот я не вижу. Если берем стажера после бакалавриата, то в более-менее свободное плавание он допускается только через полгода, не ранее. И все отдают отчет, что в течении этого полугода такой джун - убыточен. Каждая строчка его кода проходит очень жесткий code review и его PR сливается с основной веткой, порой, чуть ли не с десятой попытки. Уж простите, но утверждать PR моя прямая задача, как лида. Поэтому знаю о чем пишу.


Я же выше написал, как используются ИИ в профессиональной разработке. Если и находится разработчик, доверяющий AI, то он или очень быстро перестанет ему доверять, или я с ним расстанусь.


Прежде чем писать код, сначала надо осмыслить постановку, найти в ней ошибки, противоречия и неоднозначности, устранить их все вместе с аналитиком и заказчикам. И именно в этом заключается львиная часть работы разработчика.


Не для этого они выпускаются, а для того, чтобы можно было решать задачи, которые еще лет 10 назад были доступны только суперкомпьютерам, да и то не всем.
А уж кто и как свою дурь и лень при этом проявляет - отдельная тема и явно уже вне данного топика.


Опять видите только осколки вершины айсберга, да и то, выборочно. А ведь, если говорить об МК, то Espressif фактически совершил революцию своими дешевыми МК с WiFi и BLE.


Именно в таком применении - вряд ли кто будет. А вот себе на автоматические раздвижные ворота я бы, возможно, такую разработку поставил. Иногда идешь с тачкой, руки заняты и приходится ставить тачку и лезть в карман за мобилой или брелком, чтобы открыть ворота в пешеходном режиме. А так они будут сами открываться, причем только увидев меня, а не кого-то иного.
Это я к тому, что несмотря на то, что большинство подобных идей нежизнеспособны, именно благодаря их генерации их гор шлака выделяются жемчужины, которых иначе не возникло бы.
Я это только приветствую. Пробуйте, экспериментируйте, изобретайте. Даже если из тысячи попыток только одна окажется удачна - это уже движение вперед.

Назовите мне, для примера, STM32 с поддержкой векторизации? Я подскажу, релиз первого такого мк на M55, где будет Helium, запланирован на 2026 год и это будет самый мощный их мк. У вас в листинге инструкции из SSE 4.1, вы вообще осознаете, что пишете на форуме где далеко не все в принципе смогли на хоть какие-то 32-х битные мк перейти, а у большинства их тех кто таки смог мк с векторизацией не будет никогда? )

Это что? https://github.com/rohanverma94/stm32f4xxx-SIMD-add
И на STM32 свет что ли клином сошелся?
Например, ESP32-S3, выпущенный в 2020 году, поддерживает векторизацию.


Какая разница? Я же главную суть указал:



По этой логике получается, если далеко не все поставили себе на даче автоматические раздвижные ворота, то о них и писать нельзя?


Подозреваю, что у многих уже такие МК есть, просто об этом не догадываются. Где-нибудь в часах, видеорегистраторах, радардетекторах и т.п.

P.S, Не употребляйте слово "никогда" в подобных утверждениях. Это ключевой признак демагогии. Со всеми вытекающими.

У меня, скорее всего, никогда не будет личного самолета. Но чем чёрт не шутит. Вдруг зять мне свой подарит, а себе купит новый?

Это жалкое подобие векторизации, которое у более продвинутого M33 тоже есть, а вы сами мне только что сказали, что у M33 векторизации нет, от этого и пляшу ) Там регистры 32-х битные, у нас в массиве 32-х битные числа, векторизовать можно максимум 16-ти битные, набор команд, естественно, и близко не сравним со 128-ми битным SSE 4.1. Ради интереса поменял тип на uint8_t, никаких инструкций векторизации ожидаемо не появилось, это вам не ПК )

Одно из немногих исключений, лично я XTensa терпеть не могу ) И то что векторизация там есть вовсе не означает, что компилятор для далеко не самого популярного ядра автоматически сгенерит код в котором она будет задействована.


Писать можно, но ведь с чего все началось? Вам сказали, что пузырьковая сортировка вполне справляется с задачами когда нужно отсортировать 5 элементов, в ответ вы предоставили бенчмарк на ПК с векторизацией ) Затем я привел пример того, что пузырьковая сортировка может быть даже быстрее вашего алгоритма, на M33, а значит весьма вероятно и на других кортексах тоже. В ответ вместо признания этого факта опять идут апелляции к тестам на ПК. Подходы к написанию софта на ПК и мк разные, это вроде очевидная истина...