Как писать на C в 2016 году

По моему делать вместо int int32_t неправильно. Т.е. оно конечно более понятно и прозрачно, но вместо 3 букв 5 да еще и с переключением на шифт - неудобно. Почему не int32 или i32?

Я не пишу говно, особенно которое может оценить публика.

поэтому я прошу НЕ говно, которое может оценить публика

окей, пусть будет не публика. Давай обозначим целевую аудиторию как «заинтересованные».

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

Хочешь моего кода - выкатывай интересные задачки

да пожалуйста. Сейчас ВСЕ юзают юникод для передачи и хранения строковых данных.

Нужна более производительная библиотека, чем libicu.
Говно типа wchar не считается. Другие кодировки кроме utf-8 можно не поддерживать. Минимальное кол-во доступных твоей библиотекой функций == 3. Пусть это будут strlen, strcmp, strseek

Давай тогда обрисую задачу чуть иначе:

Есть строка с utf-8 текстом, который мы ввели в stdin. Там как латиница, так и кириллица, так и иероглифы всякие. Всё вперемешку. Твои реализации strlen() и strcmp() должны корректно работать.

функция char *strseek(const char *utf8_string, size_t n) должна возвращать указатель на начало символа по n смещению (причем n, естественно, не кол-во байт, а именно символов) в строке utf8_string.

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

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

Когда-то на лоре какой-то пацан выкатил тему, где на на какой-то скул-фигне(вроде на скулайте) переделывает из номера телефона в ид оператора или как-то так.

ну так сделай как мужик

создай репу и описывай в ней что происходит

а то будут сцать в лужу все кому ни попадя, думая «что за хрень я только что увидел»

функция char *strseek(const char *utf8_string, size_t n) должна возвращать указатель на начало символа по n смещению (причем n, естественно, не кол-во байт, а именно символов) в строке utf8_string

Надо бы еще ширину символа. Тогда лучше возвращать структуру с
size_t seek
char width

Ты просил реальную задачу. Получай.

Задачу всмысле кода. Ты не понимаешь, что:

придумать оптимальную методика очисткт изображения от шумов

В основе своей имеет придумывание методики и разбирание с твоей специализацией, а не задачи смысле реализации.

Я нигде не говорил, что я эксперт в матане, анализе изображей и фильтров.

Ну так и отвали. Твой код на гитхабе и т.п. никто никогда не видел. Вывод: ты — обычное школоло с чрезмерным ЧСВ!

А за счёт чего ты сделал такой вывод? Я разве где-то говорил, что я лучше или ещё что-то - нет, это лишь твоя интерпритация.

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

Я уличаю кого-то в балабольстве чётко и по делу. Т.е. не «ты говно, потому что я так сказал, а слушать меня надо, ибо я эксперт и у меня есть», а «ты говно, потому что ты не смог потому-то и потому-то».

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

GUI там нафиг не втарахтелось.

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

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

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

Фильтры я уже и сам пилю потихоньку, т.к. помощи ждать неоткуда! Почитываю Гонсалеса-Вудса, да пилю...

А, т.е. ты сам не запилил, хотя это твоя задача. А хочешь, чтобы я запилил форфан только потому, что какой-то анонимус на лоре меня в чём-то уличает? Ну прям ахрененная история.

Помощи знать есть откуда - я уже написал. Если ты возмёшь на себя ту узкоспециализированную часть, что к коду отношения не имеет - я могу попытаться. superhackprokiller1997@gmail.com

Всё что требуется - ввести меня в курс дела, описать те варианты, которые у тебя есть на уровне матана первого курса. После чего я уже провожу анализ твоих портянок и указываю причины, по которым они вменяемо не реализуются. Далее ты/мы устраняем/игнориуем эти убогости и я пишу реализации под те таргеты, реализация под которые даст вменяемый профит. Вывести общее решение - ты можешь и сам, либо я его могу накидать.

Да элементарный там матан. Принцип такой: есть у нас N изображений, каждое взято недеструктивным считыванием через k секунд. Общее время экспозиции, соответственно, составляет N*k.

При получении изображения имеем дробовой шум типа «соль» от космики + пуассоновский тепловой + немного гауссова шума. Таким образом, в каждом пикселе i-го изображения будет энергия (i-1)-го + k*n электронов от свеженакопленных фотонов + e электронов от нового шума. Элементарный анализ на выбросы (энергия накапливалась линейно, вдруг получили бросок до максимума) позволит удалить космику, сохранив при этом (как линейную экстраполяцию) данные в поврежденных пикселях. Аналогичная линейная интерполяция по всем остальным пикселям позволит выявить модель шумов и значительно уменьшить сигму шума по изображению.

Нужно: а нужно тупо ускорить процесс линейной интерполяции нескольких сотен двухмегабайтных изображений 1к х 1к, чтобы обработка длилась не сутки, а хотя бы полчаса!

Как видишь, параллелится задача идеально. Проблема в ограниченности ресурса: зачастую все изображения в память загнать не удастся (особенно если это видеопамять), т.к. не останется места под промежуточные результаты. Остается лишь держать открытыми дофигища файлов и потихоньку обрабатывать. Вот тут задача и упирается в дисковое IO. Финиш.

да пожалуйста. Сейчас ВСЕ юзают юникод для передачи и хранения строковых данных.

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

Динамически юников ТОЛЬКО для компактной передачи.

Другие кодировки кроме utf-8 можно не поддерживать.

Как раз таки и другие кодировки являются вменяемыми для обработки текста. Для 99% случаев хватает утф16.

Есть строка с utf-8 текстом, который мы ввели в stdin. Там как латиница, так и кириллица, так и иероглифы всякие. Всё вперемешку. Твои реализации strlen() и strcmp() должны корректно работать.

Задача уровня помойки, вся пропитана некомпетентностью тех, кто вбил тебе в голову это дерьмо.

Вменяемая юникод либа должна уметь:

а) Декодирование утф8. б) В таблицы утф16/32. в) В динамические таблицы. г) Енкодировать в утф8.

Если ты не понимаешь зачем и почему нужны какие-то пунктны - я тебе могу объяснить. Как я уже писал - никакие либы для ламерков я никогда не пишу.

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

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

Задача не имеет смысла и во вменяемых реализациях такого не будет. Нет смысла в производительности того, что изначально является дерьмом, понимаешь? Добавляется производительность дерьму только тогда, когда это единственное решение - здесь же это не то, что не единственное - а самое убогое и сложное из решений.

А числодробилки которые ты любишь не нужны

Числодробилки тут непричём. Я хоть и не хочу тебя обижать, но мне и самим числодробилкам мало интересно мнение веб-нуля.

т.к. это узкоспециализированные задачи.

Нет. Опять же, либо врёшь, либо не понимаешь.

Ты уже одну отвергнул, которую аноним предложил.

Зачем ты врёшь? Где я отвергал. Я отвергал саму постановку задачи, которая строится не 99% не относящемуся к делу вещами.

Поиск решения, либо вывод алгоритмического решения - это настолько редкая задача, что к реальному миру редко имеет отношение. Обычно всё сводится к реализации готового.

Адепты даже в таблицу символов не могу - куда там про вывод алгоритмов.

Проблемы ламерков меня не интересуют.

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

Только идиот будет использовать динамический юникод для хранения и обработки.

95% населения идиоты. И пока ПО пишут под них, идиоты останутся кормом для программистов.
Посему от utf-8, как бы он тебе не нравился, отказаться не удастся.

Динамически юников ТОЛЬКО для компактной передачи.

да-да, когда среди 10к символов латиницы появляется пара иероглифов или кириллицы - это очень эффективно держать в памяти

Задача уровня помойки, вся пропитана некомпетентностью тех, кто вбил тебе в голову это дерьмо.

код, сестра!

Вменяемая юникод либа должна уметь:
а) Декодирование утф8. б) В таблицы утф16/32. в) В динамические таблицы. г) Енкодировать в утф8.

ненужно в ^4

еще раз, гнутая либа и libicu уже есть, 3-ю нахрен не надо

Если ты не понимаешь зачем и почему нужны какие-то пунктны - я тебе могу объяснить.

когда мне оно будет нужно - использую уже имеющуюся либу

Как я уже писал - никакие либы для ламерков я никогда не пишу.

неа, пишешь. Та простыня с кейсами чьих рук дело?

Ты откликнулся на просьбу «как надо», ты думаешь «не ламерок» спросил бы такое? Он бы тут даже нос не совал а спокойно пилил что ему нужно без советов от суперхаккиллеров.

Числодробилки тут непричём

а ты всё-таки веди историю своих постов. Чтобы за слова можно было отвечать пруфцами

Я хоть и не хочу тебя обижать

хочешь и обижаешь

но мне пофиг, я могу нормально стерпеть обиду лишь бы увидеть код. Потому что слова ничего не стоят, в отличие от кода.

но мне и самим числодробилкам мало интересно мнение веб-нуля

так чего жопу рвёшь на форуме?
кстати, определи понятие «веб-ноль», пожалуйста

Нет смысла в производительности того, что изначально является дерьмом, понимаешь?

огласите весь список дерьма, пожалуйста!

чтобы в след. раз когда ты придешь на ЛОР и будешь что-то говорить, можно было сразу либо удалять либо вступившим в разговор с тобой людям закрыть кабину твоими же словами

Поиск решения, либо вывод алгоритмического решения - это настолько редкая задача, что к реальному миру редко имеет отношение. Обычно всё сводится к реализации готового.

ох лол

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

ты случаем не трансгендер? у тебя энтропия в голове, девочки тоже страдают «я не могу определить чего я хочу, но вот ЭТО мне не нравится! давай еще!»



короче


код либо балабол

а) Декодирование утф8. б) В таблицы утф16/32. в) В динамические таблицы. г) Енкодировать в утф8.

Нормализацию должна уметь же, ну.

Я пишу а) так, как хочу я. б) под то, что хочу я.

Если это так, то покажите ну хоть что-нибудь из того, что вы написали так как вы хотели и под то, что вам хотелось.

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

Ну уж линейную интерполяцию данных объяснять — это уже чересчур!

Задачу я уже сформулировал. По-простому она сводится к параллелизации и наибольшему ускорению вычисления линейной аппроксимации большого количества данных. Грубо говоря, на входе есть миллион массивов (одномерных) с данными (интенсивность). На выходе должны быть а) коэффициенты линейной интерполяции I=a*t + b для «небитых» пикселей и то же самое, но за время до попадения космики (+ особая отметка) для битых.

Дальше уже дело техники, что с этими данными сделать.

Или тебе и эта элементарная формулировка непонятна?

Анскилыш, которого здесь называют «царем», даже не знает, что обратное чтение памяти бывает тормозным. Его код:

void processAddBytesOverflow(uint8_t * input, uint32_t len) {
  while(len) *input += input[--len];
}

Ну уж линейную интерполяцию данных объяснять — это уже чересчур!

Да. Я же писал - на уровне арифметики. Тыж на уровне языка объясняешь интерполяцию конпелятору и не жалуешься.

Задачу я уже сформулировал.

Нет. Это не формулировка - это «сделай за меня всё» из невнятной хренпойми чего.

Я уже пытался с пацанов по такой схеме действовать, наверное для вас это через чур сложно. Мне уж проще самому всё это изучить, чем что-то спрашивать с вас. Зачем ты мне пытаешь пересказывать свои абстракции? На уровне реализации нет такого понятия «интенсивность» - это понятией твой модели. С чего я должен изучать твои модели? Лишь из-за того, что ты не пытаешься сформулировать свою задачу вмеянемо?

Ты описываешь форматы данных, параметры обхода. Описываешь модель доступа для каждого шага к данным и операции над ними. Далее уже паттерн записи этих данных либо отдельно, либо туда же.

У тебя должно получиться 3функции:

data[] = float[];//формат входных данных.
ctx = acces_pattern(data, ...)//по всем шагам. Реузльтат набор значений для следующей функции.
res = work(ctx)//операции над значениями, полученными на этом шаге. 
store(res, data)//запись полученных значений из work() куда следует.

Всё. Уже потом я тебе расскажу что можно с этого получить.

Или тебе и эта элементарная формулировка непонятна?

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

Задачи решаются на уровне арифметики и описание решений так же на уровне арифметики. Тебе это не понятно?

Да, блин...

data[] = float[];//формат входных данных.
ctx = acces_pattern(data, ...)//по всем шагам. Реузльтат набор значений для следующей функции.
res = work(ctx)//операции над значениями, полученными на этом шаге. 
store(res, data)//запись полученных значений из work() куда следует.

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

И все же автор почему-то использует uintmax_t

а что, надо конвертить в uint8_t и обратно?

хотел всё-таки добиться от тебя кода, и даже ответить аргументированно на целых 2 твоих поста, но

Оценки нонейм-глисты моего величества меня не волнуют.

посему - в удаленные

(для тех, кто только зашел: в свежеудаленных кода всё так же нет)

Ты код пишешь или от шифтов и кол-ва символов бегаешь, дядя?

Пусть это будут strlen, strcmp, strseek

А давай я бабахну. А царь потом ежели пожелает — микрооптимизирует.

А давай я бабахну.

С удовольствием!

А царь потом ежели пожелает — микрооптимизирует.

не нужно, он уже обосрался

По идее, современные процы должны детектить обратное чтение и врубать prefetch. По крайней мере, Optimization Reference Manual штеуда уверяет в этом.

Я тут своим комментом просто оставлю лайк царю.

И все же автор почему-то использует uintmax_t

а что, надо конвертить в uint8_t и обратно?

Идеологически правильно было бы использовать size_t. Но что бы подчекнуть малый размер массива, можно было бы использовать uint8_t (умный компилятор сам разрулит в оптимальный код).

For success/failure return values, functions should return true or false, not an int32_t return type with manually specifying 1 and 0 (or worse, 1 and -1 (or is it 0 success and 1 failure? or is it 0 success and -1 failure?)).

в 2016 году коды ошибок вообще не надо возвращать ?

Меня_напрягают_излишние_нижние_черточки. ДляКогоКамелКейсПридумалиЕпт?

По идее, современные процы должны детектить обратное чтение и врубать prefetch. По крайней мере, Optimization Reference Manual штеуда уверяет в этом.

В ARM-ах проблема встречается, не во всех. Само собой, что это еще зависит и от реализации конкретного контроллера памяти.

П.С: Совсем забыл, что для «царя» не существует иных процессоров кроме штеуда.

горбатый_кейс_сосет

В ARM-ах проблема встречается,

дурачек - почитай референсы для ARM по оптимизации циклов, у царевны как раз все по феншую сделано.

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

Ты хоть понимаешь о чем говоришь, утырок?
По фен шую для arm-а:

do {} while(--i);

.L4:
        sub     r1, r1, #1
        ldrb    r2, [r0, r1]    @ zero_extendqisi2
        ldrb    r3, [r0, #0]    @ zero_extendqisi2
        add     r3, r2, r3
        strb    r3, [r0, #0]
        cmp     r1, #0
        bne     .L4
        bx      lr

.L7:
        ldrb    ip, [r3, #1]!   @ zero_extendqisi2
        ldrb    r2, [r0, #0]    @ zero_extendqisi2
        add     r2, ip, r2
        strb    r2, [r0, #0]
        subs    r1, r1, #1
        bne     .L7
        bx      lr

Считай сколько строк в цикле

без флагов оптимизации компилировал да под старую архитектуру ? на свежем проце и компиляторе ты вообще разницы не увидишь

умный компилятор сам разрулит в оптимальный код

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

gcc-4.6, armv7-a, -O1.
А это -O2:
while(){};

.L3:
        sub     r1, r1, #1
        cmp     r1, #0
        ldrb    r2, [r0, r1]    @ zero_extendqisi2
        add     r3, r3, r2
        uxtb    r3, r3
        strb    r3, [r0, #0]
        bne     .L3
        bx      lr 

.L7:
        ldrb    ip, [r3, #1]!   @ zero_extendqisi2
        add     r2, ip, r2
        cmp     r3, r1
        uxtb    r2, r2
        strb    r2, [r0, #0]
        bne     .L7
        bx      lr 

Заново считай.

Сам считай дятел

$ cat tst.c
#include <stdint.h>

void processAddBytesOverflow_1(uint8_t * input, uint32_t len) {
  while(len) *input += input[--len];
}

void processAddBytesOverflow_2(void *input, uint32_t len) {
    uint8_t *bytes = input;

    for (uint32_t i = 0; i < len; i++) {
        bytes[0] += bytes[i];
    }
}

tst.o:     file format elf32-littlearm


Disassembly of section .text:

00000000 <processAddBytesOverflow_1>:
   0:	b141      	cbz	r1, 14 <processAddBytesOverflow_1+0x14>
   2:	7803      	ldrb	r3, [r0, #0]
   4:	4401      	add	r1, r0
   6:	f811 2d01 	ldrb.w	r2, [r1, #-1]!
   a:	4413      	add	r3, r2
   c:	4281      	cmp	r1, r0
   e:	b2db      	uxtb	r3, r3
  10:	7003      	strb	r3, [r0, #0]
  12:	d1f8      	bne.n	6 <processAddBytesOverflow_1+0x6>
  14:	4770      	bx	lr
  16:	bf00      	nop

00000018 <processAddBytesOverflow_2>:
  18:	b161      	cbz	r1, 34 <processAddBytesOverflow_2+0x1c>
  1a:	7803      	ldrb	r3, [r0, #0]
  1c:	4401      	add	r1, r0
  1e:	4602      	mov	r2, r0
  20:	b410      	push	{r4}
  22:	f812 4b01 	ldrb.w	r4, [r2], #1
  26:	4423      	add	r3, r4
  28:	428a      	cmp	r2, r1
  2a:	b2db      	uxtb	r3, r3
  2c:	7003      	strb	r3, [r0, #0]
  2e:	d1f8      	bne.n	22 <processAddBytesOverflow_2+0xa>
  30:	f85d 4b04 	ldr.w	r4, [sp], #4
  34:	4770      	bx	lr
  36:	bf00      	nop

Вот gcc-4.6 armv7-a, -O2

Это оригинал:

processAddBytesOverflowOrig:
        @ args = 0, pretend = 0, frame = 0
        @ frame_needed = 0, uses_anonymous_args = 0
        @ link register save eliminated.
        cmp     r1, #0
        bxeq    lr
        ldrb    r2, [r0, #0]    @ zero_extendqisi2
        add     r1, r1, r0
        mov     r3, r0
.L3:
        ldrb    ip, [r3], #1    @ zero_extendqisi2
        add     r2, ip, r2
        cmp     r3, r1
        uxtb    r2, r2
        strb    r2, [r0, #0]
        bne     .L3
        bx      lr 
        .size   processAddBytesOverflowOrig, .-processAddBytesOverflowOrig

processAddBytesOverflowTsar:
        @ args = 0, pretend = 0, frame = 0
        @ frame_needed = 0, uses_anonymous_args = 0
        @ link register save eliminated.
        cmp     r1, #0
        bxeq    lr
        ldrb    r3, [r0, #0]    @ zero_extendqisi2
.L8:
        sub     r1, r1, #1
        cmp     r1, #0
        ldrb    r2, [r0, r1]    @ zero_extendqisi2
        add     r3, r3, r2
        uxtb    r3, r3
        strb    r3, [r0, #0]
        bne     .L8
        bx      lr 

У «царя» на одну инструкцию _в_цикле_ больше.
И это, научись пользоваться ключем -S, дятел.

умный компилятор сам разрулит в оптимальный код

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

Оно то так, но можно сгенерировать, например, такой код:

; stdcall 
push ebp
call strtoul
and eax, 0xFF
add esp, eax ; или add sp, ax

Впрочем, это не так важно пока вот этот код с кастованием size_t -> unit8_t -> size_t не является bottleneck'ом или дырой безопасности. Код пишется в первую очередь для людей, а уже потом для компилятора.

Си это кроссплатформенный ассемблер, говорили они. Ты пишешь сразу под все платформы, говорили они.

читайте внимательней. акцентировал внимание на специализированных цпу, и там gccдостаточно убог в плане отпимизаций - как правило одного md не достаточно чтобы раскрыть весь потенциал. к тому же вендоры стали поумней и если не аутсорят у тогоже гринхилс, то берут за основу llvm и хакают его уже со всех сторон. например, из относительно новых концептов - mill запилили сперва свой компилятор и сравнительно недавно стали посматривать какие изменения нужны в llvm и там все было не просто и безусловно потребует кропотливой работы с сообществом чтобы удовлетворить всех. но вендорам, как правило не до этого. я их не защищаю, мой поинт в том что для специализированных цпу лучше вендоровского вряди что-либо найдете, а почему вы не находите той же функциональности в gcc или llvm уже другая история.

tl,dr можно вкраце какого рода цпу оптимизацию эти тесты должны подтердить или опровергнуть? спасибо. мимокрокодил.

Этот тест подтверждает что старые компиляторы с отключенной оптимизацией код не оптимизируют.

тю, тоже мне новость..

Ну там пуканистый анон-недотестер почему-то думает что все во всем мире пользуются каким-то дерьмовым компилятором как у него

У «царя» на одну инструкцию _в_цикле_ больше.

Тем временем даже устаревший стандартный компилятор Linaro показывает противоположную картину

$ cat tst.c
#include <stdint.h>

void processAddBytesOverflow_1(uint8_t * input, uint32_t len) {
  while(len) *input += input[--len];
}

void processAddBytesOverflow_2(void *input, uint32_t len) {
    uint8_t *bytes = input;

    for (uint32_t i = 0; i < len; i++) {
        bytes[0] += bytes[i];
    }
}

arm-linux-gnueabihf-gcc -g -std=c99 -O1 -c tst.c && arm-linux-gnueabihf-objdump -d tst.o

tst.o:     file format elf32-littlearm


Disassembly of section .text:

00000000 <processAddBytesOverflow_1>:
   0:	b159      	cbz	r1, 1a <processAddBytesOverflow_1+0x1a>
   2:	b410      	push	{r4}
   4:	1841      	adds	r1, r0, r1
   6:	4604      	mov	r4, r0
   8:	7802      	ldrb	r2, [r0, #0]
   a:	f811 3d01 	ldrb.w	r3, [r1, #-1]!
   e:	4413      	add	r3, r2
  10:	7003      	strb	r3, [r0, #0]
  12:	42a1      	cmp	r1, r4
  14:	d1f8      	bne.n	8 <processAddBytesOverflow_1+0x8>
  16:	f85d 4b04 	ldr.w	r4, [sp], #4
  1a:	4770      	bx	lr

0000001c <processAddBytesOverflow_2>:
  1c:	b159      	cbz	r1, 36 <processAddBytesOverflow_2+0x1a>
  1e:	b410      	push	{r4}
  20:	4602      	mov	r2, r0
  22:	1841      	adds	r1, r0, r1
  24:	f812 4b01 	ldrb.w	r4, [r2], #1
  28:	7803      	ldrb	r3, [r0, #0]
  2a:	4423      	add	r3, r4
  2c:	7003      	strb	r3, [r0, #0]
  2e:	428a      	cmp	r2, r1
  30:	d1f8      	bne.n	24 <processAddBytesOverflow_2+0x8>
  32:	f85d 4b04 	ldr.w	r4, [sp], #4
  36:	4770      	bx	lr

а с оптимизацией -O2 и -O3 результаты одинаковые

Этот тест подтверждает что старые компиляторы с отключенной оптимизацией код не оптимизируют.

Оптимизация не включена это -O0.

Но бестолковый анон не знает, что оптимизировать можно и нужно еще и по размеру исполняемого кода.
Впрочем... для его «Hello, world»-а на «малинке» в этом нет необходимости, он везде и всегда просто лепит -O3,
а про LTO и PGO слышал лишь краем уха.
----------
А теперь еще и для x86-64:

void processAddBytesOverflowOrig(void *input, uint32_t len) {
   uint8_t *bytes = input;
   for (uint32_t i = 0; i < len; i++) {
         bytes[0] += bytes[i];
   }
}

void processAddBytesOverflowTsar(uint8_t * input, uint32_t len) {
   while(len) *input += input[--len];
}

И компилируем это: gcc-4.7 -march=x86-64 -std=c99 -S -O3 tsar.c
Получаем для оригинала:

processAddBytesOverflowOrig:
.LFB0:
        .cfi_startproc
        testl   %esi, %esi
        je      .L1
        movzbl  (%rdi), %edx
        xorl    %eax, %eax 
        .p2align 4,,10
        .p2align 3
.L3:
        addb    (%rdi,%rax), %dl
        addq    $1, %rax
        cmpl    %eax, %esi
        movb    %dl, (%rdi)
        ja      .L3   
.L1:
        rep
        ret
        .cfi_endproc

processAddBytesOverflowTsar:
.LFB1:
        .cfi_startproc
        testl   %esi, %esi
        je      .L7
        movzbl  (%rdi), %eax
        .p2align 4,,10
        .p2align 3
.L9:
        subl    $1, %esi
        movl    %esi, %edx
        addb    (%rdi,%rdx), %al
        testl   %esi, %esi
        movb    %al, (%rdi)
        jne     .L9
.L7:
        rep
        ret
        .cfi_endproc

Как видим здесь «царь» снова обделался.
В цикле у него 5 инструкций, против 4-х в оригинале.

А изначальная предъява была к тому, что читать байтовые массивы с декрементацией индекса это не комильфо,
т.к. на некоторых платформах это работает медленнее, чем чтение с инкрементацией.
А дальше еще вспыло, что «царский код» сам по себе тормознее, если не применять свежие компиляторы и оптимизацию -O3.
Как говорится: «Плохому танцору „царю“ яйца мешают».

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

Я мимокрокодил. Только байтовых? На каких платформах? Где можно почитать на эту тему?

Только байтовых? На каких платформах? Где можно почитать на эту тему?

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

The first rule of C is don't write C if you can avoid it.

Ой, достали уже со своей боязнью C :-) Это отличный язык. Скорее всего, самый практичный, лаконичный и быстрый из всех существующих, несмотря на свою ущербность :-) Но только в умелых руках :-)

JB, mono, true_admin, toney, riki, fallout4all, Licwin, anonymous_incognito, catap, beastie

товарищи модераторы, ну сколько можно терпеть этот бред от придурка, который себя "царем" величает? Ну ужас же!!!!!

Это где же сишечка ущербна?

У меня на ней все: от мелких скриптиков до числодробилок. И даже веб-сервисы на сишечке. Кошерненький язык. Честь и хвала святым Кернигану и Ритчи!

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