Блог

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

Что я принимаю во внимание, компилятор — это потрясающе, сейчас я знаю, что не могу быть умнее компилятора, но я хочу помочь ему по максимуму. C 11 приносит хорошие вещи, такие как семантика перемещения и другие вещи, такие как std::tuple ….

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

Где я немного потерялся и нуждаюсь в дополнительной информации:

A) Должны ли данные быть: value_type[Строки * Cols] (простой массив c) или value_type * (выделяются в куче строк размера * Cols) или использовать что-то вроде std::tuple

Б) Также наследование или композиция / агрегация У меня мог бы быть базовый класс шаблона для данных, или я мог бы сделать это с помощью композиции / агрегации

В) я видел 3 макета данных

• структура и объединение (как в этой статье http://www.gamasutra.com/view/feature/4248/designing_fast_crossplatform_simd_.php )
• простая переменная-член
• другой использовал статический указатель на элемент вместо объединения. (http://www.gamedev.net/topic/261920-a-slick-trick-in-c /)

D) Также в статье gamasutra (которая кажется старой, а компилятор сейчас лучше) Он говорит, что класс не должен иметь перегрузки оператора и вместо этого следует использовать глобальную функцию. Например, функция CrossProduct, чтобы сделать ее нечленом вместо функции-члена.

У меня есть все эти вопросы, я знаю, что их много. Что вы думаете о них, особенно о A и C.

Редактировать:

Спасибо всем за ответы на пункт A, я должен сказать, что на данный момент мой самый большой вопрос связан с пунктом C, извините, я знаю, что это было непонятно. Пункт c действительно касается дизайна классов. Я видел 2 варианта (вроде трех, если учесть этот статический трюк http://www.gamedev.net/topic/261920-a-slick-trick-in-c /) Я мог бы иметь для Вектора4, например, я мог бы иметь общедоступные элементы x, y, z и w, или я мог бы также объединить эти элементы и массив, или я мог бы иметь только массив и иметь функции X(), Y(), Z(), W() для средства доступа. И, наконец, есть статический трюк, который я предоставил по ссылке чуть выше, но я бы предпочел, чтобы x, y, z и w были статическими, а массив был бы элементом данных.

Обратитесь к Blitz . Также посмотрите его страницу «About«, чтобы получить представление об этом. Это одна из популярных математических библиотек промышленного уровня, написанных на C . Хотя вы не спросили, на какую библиотеку ссылаться, я привожу это главным образом потому, что вы можете извлечь уроки из некоторых вариантов дизайна, сделанных в этой библиотеке. Вы можете найти ответы на те самые вопросы, которые вы обдумываете.

Для небольшой матрицы 4×4 я бы избегал динамического выделения памяти в куче… простого одномерного массива, который вы можете индексировать как 2D-массив, должно быть достаточно (т. Е. Значение упорядоченной пары (x, y) будет matrix_array[COLUMNS * y x] ), особенно учитывая, что загрузка любого отдельного значения в массив также приведет к сохранению смежных значений в строке кэша процессора, ускоряядоступ к любым смежным элементам. Загрузка кэша может происходить и с выделенной памятью в куче, но основная причина, по которой следует избегать выделения кучи, если это возможно, для небольших матриц, заключается в том, что многие последовательные математические операции потребуют от вас возврата временного значения, а без ссылок на r-значения вы в конечном итоге будете выполнять много вызовови new delete внутри конструкторов копирования этих временных объектов, которые значительно замедлят работу по сравнению с быстрым выделением памяти в стеке.

Во-вторых, я бы посоветовал вам использовать шаблонный подход, так как это позволит вам определять матрицу не только для простых старых типов данных double , таких как и т.д., Но и для любых вторичных составных типов, которые вы можете решить определить позже, или импортировать из другой библиотеки, такой как рациональные числа, комплексные числаи т.д. Решите ли вы добавить перегрузки операторов, действительно зависит от вас … некоторым людям это не нравится, потому что оно «скрывает» сложность того, что может происходить под капотом (т.Е. A * B for doubles будет намного проще, чем A * B для 4×4 matrix<double> ). С другой стороны, это может значительно упростить объем кода, который вы пишете для сложных математических операций.