Тоді чому 99.99% всіх дронів на фронті на STM32?

А їх вистачає обробляти і передавати відео у реальному часі?

Нічого по цьому посиланню не протирічить тому, що я написав.

Мені здається, що я краще розумію, що саме я хотів сказати.

Що ви хотіли сказати у своєму перекладі, що менше команд процесора — краще (хоча б у сенсі швидкості, тобто просто бистріше), і навпаки? Вірю. Може, це і хотіли сказати. Бо тоді незрозуміло, для чого перекладати це джерело.

Що це так на практиці? Звісно, ні. Я навів поруч, які можуть бути випадки, коли все навпаки.

При всьому позитивному задумі статті деталі в ній, мʼяко кажучи, сумнівні. І Muratori забуває простий принцип: все треба міряти, і міряти потрібні показники напряму, а не свої додумки, як що впливає (як у нього кількість команд на швидкість). Тому ціна його розповідям — коло нуля.

Ви не враховуєте того, что DeepSeek може працювати локально у смартфоні, а це новостворена ніша. Моделі од OpenAI на це не розраховуються. Хоча, мабуть, вони теж почнуть випускати редуковані версії для цього.
Ідеш собі вулицею, а він і каже «зазвичай ти на цьому шляху пʼєш каву, а я знаю, тут нова кавʼярня відкрилась, зайди покуштуй». Ну і 1 гривня з твоєї оплати піде вендору телефона.
NPU в смартфонах вже зʼявляються на рівні вимоги, але поки що були призначені більше для відновлення фото. А тут їм нові задачі. DeepSeek показав, що таке вже можливе. Далі допрацювання...

Хм, з цього виникає питання: коли клавіатури у смартфонах почнуть насильно виправляти за тебе текст, а не тільки пропонувати альтернативні написання?

Що українська — без сумніву, а ось що вірний відтінок — тут не зовсім. Я б сказав «покуштувати». Бо «скуштувати» має стійкий відтінок завершеної дії, всі деталі розпробувані (покуштовані;)), а це для такого ресурсу значить місяці випробування. Може, навіть «причаститись до новинки» (якщо відринути християнські коннотації). Вибачаюсь за нерівний стиль, впасти в режим філолога, який роками тренувався розповідати про кольори у Тичини, тяжко 😏🦆

Загалом, вдячний автору за підняття теми «performance-aware-programming».

Цікаво, де є місця, де така тема _не_ підіймається і всім плювати на швидкість коду. Покажіть мені таке місце... (ну, держконтори не треба, вони у всьому світі однакові)

Вважаю, що також важливим аспектом всієї цієї теми в розрізі компілюємих мов програмування є оптимізації компілятора та особливо його нішові оптимізації.
Так, в деяких випадках умовний gcc виграє clang і навпаки.

Ага-ага, особливо коли у >50% присутніх тут основне де дивляться на швидкість це видача V8 JIT.

Крім того, «Немає такої підлості та гидоти, на яку не пішов би gcc заради безглуздих 5% швидкості в нікому не потрібному синтетичному тесті.» ([один колега])

Мені здається що ви цього посилу, нажаль, не зрозуміли.

Саме він і зрозумів. А ось ви — ні, хоча доброчесно переклали.

Міряти результат за кількістю інструкцій це пʼять. Косяків.

В асемблері може бути нагенеровано будь-що, наприклад, на «холодному шляху», який виконується тільки у catch-блоках. Обʼєм коду там може бути більший за основний в рази, і це не показує, що така реалізація повільніша — навпаки, може бути, що вона бистріша.

Або, реалізація на зразок такої товщіша в десятки разів ніж проста loopne movsb, але теж має швидкість в стільки ж більше.

Якщо задача в оптимізації обʼєму — норма для embedded — то так і кажіть, що оптимізуєте обʼєм. Інакше треба міряти швидкість.

Характер мов з AutoMM може змінювати результати неочікуваним чином. Для Python, наприклад, багато разів писалось, що оптимізації контр-інтуїтивні. За JS не слідкую, але впевнений у схожих ефектах.

Як саме міряти — залежить від. У випадку Javascript я б спочатку згенерував масив на міліон вхідних значень, запустив функцію мапінга в вихідний масив, і зробив би це десяток разів. Тільки після цього можна знімати показання «годинника» системи.

Чому там VS затримує оновлення — ХЗ. Може, у нього така манера взагалі.

Висновок: поки що в статті повна маячня. Як і в джерелі.

ЕС-1022, 512кБ, 4 дисковода по 29МБ, 3 ленточника, 4 дисплея (7066), из которых два в подвале, читалка перфокарт, выводилка на перфокарты, два АЦПУ (одно нормальное, одно убитое) и шик гламура — электрическая пишущая машинка в качестве строчной консоли — бесполезно, зато круто.

Или вопрос про персоналку дома? Oh wait...

Кстати, кто и зачем поднял тему 4-летней давности?

Як (3) і (4) не протирічать одне одному?

а от інженер має розуміти, як ці методи працюють. Які алгоритми в основі і все таке.

В університеті можуть викладати _дещо_ застаріле (не радикально!), але давати гарну теоретичну базу, після якої здогнати самому до актуального рівня не буде проблем.

В «бурсі» можуть виключити частину теоретичної підготовки, але мають викладати актуальне на саме зараз і виключати некорисне.

А ось варіант, коли покроково самі обчислюють md5, не придатний для обох варіантів навчання. Нічого воно тому «інженеру» не дасть ні в якому варіанті.

Скоріш за все це була просто сінекура для старого викладача, в якого мізки задубіли і він вже не вміє нічого, а виганяти не можуть або не хочуть.

ми пів року розбирали як працює якийсь МD5 і на папері пробували щось шифрувати/дешифрувати примінячюи 100500 математичних операцій.

Жах. Де це було і нащо?

Чому Гаррі Поттер цікавіший за Тома Соєра?

Просто більше матеріалу, різноманітніше. Є що обговорювати майже для кожного.

А як ви забезпечите доступність матеріалів?

І ще можна фанфіки використовувати. Їх реально міліони, включаючи високоякісні і обʼємні. І мова сучасна, а не як у Марка Твена, Агати Крісті або тих 100500 класиків, що дебільна мафія «авторських прав» дозволила відкрити і не встигла закрити знову.

а ви не лише не встигали за обговоренням

Ну це вже питання сегментації груп. Стандартного підходу на зразок beginner / intermediate / upper intermediate і т.п. — досить, щоб рівень був у всіх схожий.
Ну і вчитель має контролювати, щоб брали участь хоча б ¾.

И представляю как весело с этим в Канаде, где бывает необходимо иметь обе локали.

В Канаде французская qwerty :)
ergocanada.com/...​ch_canadian_keyboard.html
ergocanada.com/...​im_fr_can_layout_1200.gif
ergocanada.com/...​595_cdn_french_layout.gif
ну и так далее.

На клаві є букави!!! Цікаво для чого вони?

Коли кожен вендор лаптопу вважає що «він митець, він так видить» і переставляє усякі там Insert і PgUp, ви без них не обійдетесь.
А ще є проблема розміщення LSGT, двох позицій для \|, і це все тільки для наших клав.

то хизувався що СМС в кишені набираю

Ну, краще використати ті ресурси мозку для чогось більш корисного:)

Ми можемо сказати «рекомендує»

Хай так, згоден.

писав компілятор асемблеру, і там чомусь виникала проблема в додатковому проході... Але деталі вже не пам’ятаю.

У асемблера є декілька місць на таке. Найпростіший умовний чи безумовний перехід на мітку в коді далі: `je moo` ...якийсь код... `moo:` - і все, не знаючи де це moo буде, не можна скомпілювати зміщення — ось вам вже два проходи. Більш складне: je/jb/etc. компілювати в коротку чи довгу (>=i386, ±32kB/2GB) форму. (Більш того, довга форма в одному місці може викликати подовження коду і вимогу довгої форми в іншому місці! тому треба компілювати так, щоб воно зійшлось дуже швидко, без осцілляцій.) Посилання на змінну, що визначена нижче — що писати в обʼєктний файл, коли треба зміщення. І все таке.
Але це не рівень C, це пізніше. У Паскаля є та ж сама проблема при генерації вихідного машинного коду, це тільки на рівні його вхідного коду можна казати про один прохід.

Але, все ж таки ІМХО, архітектурне рішення з хідерами (та прототипом за замовчуванням) було не дуже вдалим, бо збільшило час компіляції та збільшила кількість помилок.

TurboPascal робився під одну платформу. Ті компільовані модулі не придатні вже для 32-бітного x86, там int ширший. А в початковому Pascal модулів не було, це віддано реалізаціям.

Для C є в багатьох реалізаціях предкомпільовані хедери. Вони справді прискорюють компіляцію.

Щодо помилок, знову це проблема недовизначености функцій або різних опцій компіляції. Я якось вирішував цікавий випадок такого, але зазвичай випадки більш прості.

Добре, як тоді пояснити це?

Саме так, що
1) Мова вимагає предоголошення функцій: тобто, нормально мав бути прототип: `int f2(int);` перед тілом f1().
2) Якщо такого прототипу нема, то спрацьовує фолбек, що декларує `int f2();` що те ж саме що `int f2(...);`, але компілятор видає попередження.
3) Завдяки вимозі, щоб працювало і в такому випадку, правила ABI для випадку еліпсіса зроблені так, що все працює (наприклад, з x86-64/SysV перший аргумент завжди в rdi).

але мова йшла про 90-ті роки.

Угу. І тут все одно не було другого проходу, але працювало саме те, що «вмикається» дефолтне оголошення. (І якщо воно не задовільняє — тобто викликали з несумісними параметрами — чекайте на проблеми.)

бо по суті нам треба лише адреса, а стек прибирає за собою викликаючий код.

Проблема не тільки в стеку. Вся calling convention має бути підлаштована під це.

Ось наприклад соберіть щось найпростіше типу

#include <stdio.h>
#include <stdarg.h>
int my_printf(const char *format, ...) {
  va_list ap;
  va_start(ap, format);
  int rc = fprintf(stdout, format, ap);
  va_end(ap);
  return rc;
}

Скомпілюйте і подивіться на асемблерний результат — це ж буде жах. Під Linux/x86-64:

my_printf:
.LFB23:
        .cfi_startproc
        endbr64
        subq    $216, %rsp
        .cfi_def_cfa_offset 224
        movq    %rsi, 40(%rsp)
        movq    %rdx, 48(%rsp)
        movq    %rcx, 56(%rsp)
        movq    %r8, 64(%rsp)
        movq    %r9, 72(%rsp)
        testb   %al, %al
        je      .L2
        movaps  %xmm0, 80(%rsp)
        movaps  %xmm1, 96(%rsp)
        movaps  %xmm2, 112(%rsp)
        movaps  %xmm3, 128(%rsp)
        movaps  %xmm4, 144(%rsp)
        movaps  %xmm5, 160(%rsp)
        movaps  %xmm6, 176(%rsp)
        movaps  %xmm7, 192(%rsp)
.L2:
        movq    %fs:40, %rax
        movq    %rax, 24(%rsp)
        xorl    %eax, %eax
        movl    $8, (%rsp)
        movl    $48, 4(%rsp)
        leaq    224(%rsp), %rax
        movq    %rax, 8(%rsp)
        leaq    32(%rsp), %rax
        movq    %rax, 16(%rsp)
        movq    %rsp, %rcx
        movq    %rdi, %rdx
        movl    $1, %esi
        movq    stdout(%rip), %rdi
        movl    $0, %eax
        call    __fprintf_chk@PLT
...

Навіщо весь цей адъ і сектор Газа? Чому variadic частина не кладеться на стек? Те ж саме для Linux/x86-32 просте і красиве:

my_printf:
        subl    $12, %esp
        leal    20(%esp), %eax
        subl    $4, %esp
        pushl   %eax
        pushl   24(%esp)
        pushl   stdout
        call    fprintf
        addl    $28, %esp
        ret

А проблема в тому, що C вимагає, щоб при відсутности декларації виклик все одно оброблявся коректно, тому весь хвіст variadic параметрів повинен вкладатись точно так же якби був точно визначений в прототипі — у даному випадку (x86-64/SysV) перший в rdi, другий в rsi, і так далі.

А якщо б взагалі було заборонено викликати функції без прототипу і той прототип мали б декларувати — як зробили в C++ і як Apple робить в своєму діалекті C — то ваш приклад би не зкомпілювався, а мій не мав би для va_start весь цей непотріб.

(Цікаво з MS ABI. У них, наскільки я бачу, variadic частина завжди на стеку, але вони не забороняють компіляцію без декларації. Хм...)

dou.ua/...​-ivanovich-skrypnyk-died
:(

ніж від спілкування 2ма пальцями з вами.

І хто ж винен що ви Дворак вивчили на 10 пальцях, а щось зовсім інше і на 2 не можете?
І що навіть у такому випадку не подумали про розкладки стиля яверти... пробачте, пифгцрл/аоеу/і_так_далі у вашому випадку, щоб використати вже надбану стійку звичку?

Якщо мої вказівні пальці лежать на пімпочках — то «батя в зданії».

З qwerty буде те ж саме. І з колемаком. І з воркманом. І з 100500 новіших розробок. Просто треба звикнути.

Справа в тім що зазвичай прихильники дефолтної кверті говорять що дворак то для машиністок яким треба набирати багато сторінок тексту (на даний момент найбільш залайканий комент). Фігня це а не висновок

Згоден, фігня. Бо розкладка Дворак сама по собі вже фігня, якщо треба оптимізацію під англійську — є новіші кращі розробки, є усталена теорія і методи аналізу. (Це все говорилось тут, але можна і нагадати.) Або ж ми не обмежуємось англійською, тоді зрозуміло, що qwerty це хоча б частково схоже на загальносвітовий стандарт.

PS пфф, а яка норма української мови змушує вас писати це слово з великої?

Це досі власне імʼя автора, ні?