LINUX.ORG.RU

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

Aswed ★★★★★
()
Ответ на: комментарий от anonymous

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

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

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

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

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

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

Нужна более производительная библиотека, чем 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.

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

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

reprimand ★★★★★
()
Последнее исправление: reprimand (всего исправлений: 1)
Ответ на: комментарий от anonymous

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

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

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

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

reprimand ★★★★★
()
Ответ на: комментарий от reprimand

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

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

reprimand ★★★★★
()
Ответ на: комментарий от anonymous

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

anonymous
()
Ответ на: комментарий от anonymous

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

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

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

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

anonymous
()
Ответ на: комментарий от reprimand

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

anonymous
()
Ответ на: комментарий от anonymous

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

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

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

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

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

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

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

код, сестра!

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

ненужно в ^4

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ох лол

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

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



короче


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

reprimand ★★★★★
()
Ответ на: комментарий от anonymous

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

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

mix_mix ★★★★★
()
Ответ на: комментарий от anonymous

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

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

eao197 ★★★★★
()
Ответ на: комментарий от anonymous

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

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

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

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

anonymous
()
Ответ на: комментарий от anonymous

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

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

anonymous
()
Ответ на: комментарий от anonymous

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

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

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

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

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

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

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

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

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

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

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

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

anonymous
()
Ответ на: комментарий от anonymous

Да, блин...

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

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

eao197 ★★★★★
()

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

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

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

reprimand ★★★★★
()
Ответ на: комментарий от reprimand

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

Pavval ★★★★★
()
Ответ на: комментарий от deep-purple

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

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

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

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

reprimand ★★★★★
()
Ответ на: комментарий от anonymous

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

mix_mix ★★★★★
()
Ответ на: комментарий от anonymous

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

irr123
()
Ответ на: комментарий от MyTrooName

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

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

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

KennyMinigun ★★★★★
()
Последнее исправление: KennyMinigun (всего исправлений: 1)

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 году коды ошибок вообще не надо возвращать ?

anonymous
()
Ответ на: комментарий от mix_mix

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

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

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

anonymous
()
Ответ на: комментарий от anonymous

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

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

anonymous
()
Ответ на: комментарий от Aswed

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

deep-purple ★★★★★
()
Ответ на: комментарий от anonymous

Ты хоть понимаешь о чем говоришь, утырок?
По фен шую для 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

anonymous
()
Ответ на: комментарий от anonymous

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

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

anonymous
()
Ответ на: комментарий от KennyMinigun

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

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

MyTrooName ★★★★★
()
Ответ на: комментарий от anonymous

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 
do {} while();
.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 

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

anonymous
()
Ответ на: комментарий от anonymous

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

$ 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
anonymous
()
Ответ на: комментарий от anonymous

Вот 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, дятел.

anonymous
()
Ответ на: комментарий от MyTrooName

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

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

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

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

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

KennyMinigun ★★★★★
()
Последнее исправление: KennyMinigun (всего исправлений: 2)
Ответ на: комментарий от anonymous

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

anonymous
()
Ответ на: комментарий от Iron_Bug

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

anonymous
()
Ответ на: комментарий от anonymous

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

anonymous
()
Ответ на: комментарий от anonymous

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

anonymous
()
Ответ на: комментарий от anonymous

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

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

Тем временем даже устаревший стандартный компилятор 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 результаты одинаковые

anonymous
()
Ответ на: комментарий от anonymous

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

Оптимизация не включена это -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.
Как говорится: «Плохому танцору „царю“ яйца мешают».

anonymous
()
Ответ на: комментарий от anonymous

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


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

Erfinder
()
Ответ на: комментарий от Erfinder

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

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

anonymous
()

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

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

anonymous
()
Ответ на: комментарий от anonymous

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

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

anonymous
()
Ответ на: комментарий от anonymous

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

anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.