LINUX.ORG.RU

Си, «горячий код», несколько версий функции.

 , , , ,


1

3

Привет, кодач девеЛОРч, продолжаю делать очередное OpenSource поделие.

Само поделие тут.

Это будет либа с оценивающими фильтрами.

Особенности:

  • Старался писать КАК ДИДЫ в программе «Аполон».
  • No dynamic memory allocation.
  • Использование [ну типа] cache-aware алгоритмов.
  • Выполнение на архитектурах с аппаратной плавающей точкой.
  • Использование стабилизированных численных методов.
  • Принятие того факта, что у нас тут не NASA, соответственно, пользователи могут косячить в моделях процессов и наблюдений. Использование алгоритмов, которые позволяют хоть как-то сгладить последствия этих косяков.
  • Принятие того факта, что шумы могут быть не Гауссовы. Использование алгоритмов, которые позволяют хоть как-то сгладить последствия неверных гипотез о шумах.
  • Прототипирование на Python c использованием буквально тех же реализаций алгоритмов, что и в продакшоне, посредством Cython-обертки над либой.

Итак, ближе к сути: есть несколько версий функций (в данный момент - две, запланировано до четырёх), например: раз и два.

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

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

Вопрос к знатокам:

Стоит ли делать несколько вариантов функций, как сейчас, или оставить самый сложный?

З.Ы.: И да, если это применять, например, при адаптивном подавлении шумов от производственного оборудования в наушниках у рабочего, то частоты вызова могут быть несколько килогерц (в данном случае - от восьми) для нескольких объектов, и звук будет идти с нескольких микрофонов.

★★★★★

Последнее исправление: shkolnick-kun (всего исправлений: 6)

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

dvetutnev
()

Завтра ты придумаешь третью функцию, после ещё одну… Заведи

enum update_mode 
{
   UPDATE_MODE_1,
   UPDATE_MODE_2,
   UPDATE_MODE_3,
}


bierman_scalar_update(enum update_mode,yakfBaseSt * self, yakfInt i)
{
   swith(update_mode)
   {
     case нутыпонял
   }
}

И будет гибко и удобно. Режим UPDATE_MODE можно ещё разрешить из env устанавливать.

LINUX-ORG-RU ★★★★★
()
Ответ на: комментарий от LINUX-ORG-RU

Так оно же встраиваемое. Будет ли у юзера возможность подстраивать поведение? Если нет, то нафига неиспользуемый код в каждом экземпляре таскать с собой?

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

Switch действительно не вариант.

А не для switch: --ffunction-sections --fdata-sections и --gc-sections спасут от неиспользуемого кода.

shkolnick-kun ★★★★★
() автор топика
Последнее исправление: shkolnick-kun (всего исправлений: 2)

Стоит ли делать несколько вариантов функций, как сейчас, или оставить самый сложный?

Для тестирования - стоит (это однозначно), а дальше оставить то, что выжило.

Имхо, выживает простейшее.

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

У инженера есть доступ (на редактирование) к коду? «Выживает простейшее» - это из опыта сопровождения исходника разными участниками (и редактирования настроек админами).

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

эти ключи замедляют сгенерированный код

anonymous
()

Ничего не понятно, но очень интересно.

_DO_V[X|R]N(name, op) -> _DO_V_op_N(name, op1, op2)

anonymous
()

На си еще можно писать большие макросы в таком стиле

main.c

#define op -
#define fnName doSub
#include gen.c


#define op +
#define fnName doAdd
#include gen.c

gen.c

int fnName(int a, int b) {
	return a op b;
}

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

Маленький, это сколько?

Тут всего-то несколько функций…

shkolnick-kun ★★★★★
() автор топика
Ответ на: комментарий от shkolnick-kun

Андефы забыл.

Он их спрятал в подключаемом файле

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