У меня тут назрел вопрос о использовании оптимизаций в движках, а конкретно оптимизации математики (учитывая как много происходит расчётов матриц, векторов и т.п.).
Вопрос об использовании библиотек Eigen, ACML, MKL и т.п.
Какая ситуация в использовании таких оптимизаций в движках местного разлива ?
А в коммерческих ?
Я работал слушал лекции про CUBLAS, так вот там память маллокается в вызове каждой функции. Это, может быть, и оправдано при решении СЛАУ офигенного размера, но в движках таких расчётов обычно нет. Максимум матрицы 3х3 да 4х4.
Самая главная апчхимизхация математических рассчётов - это кеширование результатов, там где это по смыслу даст прирост.
Либо как lord Havok сидеть и считать операции в каждой мат.функции, пытаясь её апчхимизировать. Правда от евонных апчхимизаций оно глючить начинает в некоторых случаях.
Любимое упражнение в учебниках по С++ – это создание класса, инкапсулирующего векторы и матрицы. Таких классов созданы сотни, но все они имеют крайне низкую производительность и никогда не используются для серьезных задач. Компилятор С++, в отличие от Fortran, даже не подозревает, что векторы и матрицы надо обрабатывать поэлементно.
В результате, в сумме матриц:
mat1 = mat2 + mat3
сначала будет вычислена правая часть и присвоена временному объекту. Затем временный объект будет скопирован в mat1 и разрушен. Ясно, что вызов конструктора и деструктора временного объекта и копирование данных совершенно излишни.
Цитата:
Любой мало-мальски сложный вычислительный алгоритм включает в себя действия с векторами и матрицами. По большому счету, почти все вычислительное программирование держится на операциях над одно- или двумерными массивами. Массивы С++ для таких операций приспособлены плохо.
Каждый массив – это всего лишь указатель, по которому приходится вручную выделять и освобождать память. Для матриц это приходится делать для каждой строки, что является сомнительным удовольствием. Массивы не знают своего размера, так что приходится использовать с каждым из них отдельную переменную с числом элементов. Любые действия
с массивами как с целым приходиться расписывать поэлементно в виде циклов. Если используются только векторы (что бывает редко), то некоторую помощь дает класс std::valarray из STL. Если же нужно работать с матрицами, то волей-неволей приходится использовать сторонние библиотеки.
и это не считая векторизации (про неё 2 страницы текста)
тут вопрос именно в скорости выполнения кода (разнице оптимизированного под вычисления и написанного в надежде на магию компилятора)
это, я извиняюсь, бред понаписан.
во первых почему это обязательно в виде циклов?
во вторых, кто мешает заставляет динамически выделять память под матричные операции?
В третьих, что это за идиотская операция такая - сложение матриц?
Может быть имелась в виду конкатенция?
написал именно чтобы разобраться (сам нуб нубом, потому и собираю умные мысли)
чаще всего в том тексте были отсылке к коду генерируемому компилятором
т.е. если дать на откуп компилятору, то выйдет мягко говоря не самый быстрый код
p.s. яндекс на фразу "сумма матриц" выдаёт даже специальный инструмент по вычислениям матриц =)
да ково. Я вон в ксаш-моде кэширование вертексов замутил. Еле-еле 5 фпс выиграл на карте freeman.bsp из моего знаменитого бенчмарка.
Шо вы там надеетесь апчхимизировать?
И эта. Ачхимизированная матчлиба зачастую брешет. И брешет достаточно сильно.
Дядя Миша писал: И эта. Ачхимизированная матчлиба зачастую брешет. И брешет достаточно сильно.
чем она может брешить ?
эти библиотеки разрабатываю для удобства вычисления (синтаксис ближе к математическому) и повышению скорости проектов с сильным использованием математики.
неужели ты думаешь, что разработчики идиоты и пишут то, что будет мешать их вычислениям ?
другое дело непривычный синтаксис и написание могут натолкнуть на ошибки логики программы, которые по первости не сразу заметишь
тем что используются приближенные методы вычислении чего либо, что уменьшает точность и повышает скорость.
__________________
Трагическая новость: Пятеро инженеров Casio умерли от смеха, узнав что Samsung анонсировали часы с заявленным временем работы в 25 часов
underworlddemon писал: неужели ты думаешь, что разработчики идиоты и пишут то, что будет мешать их вычислениям ?
разработчики этих библиотек крайне далеки от разработки, собственно игр. Я на собственном опыте убедился, что самое надежное - это использовать стандартный матчлиб из WInAPI.
Цитата:
XaeroX писал: Стандартная операция покомпонентного сложения матриц.
XaeroX писал: Да хотя бы использование float вместо double.
Или GPGPU вычисления без ECC.
бегло просматривая не заметил подобного
только свёртка-развёртка кода так, чтобы компилятору было удобнее генерировать наибыстрейшие последовательности
хотя я нуб
p.s. что-то вы зациклились на непогрешимости компилятора
вы считаете автоматика может предусмотреть все варианты и выбрать наилучший, что верите так религиозно в это ?
| IP: 
10-06-2012 12:59
Это, может быть, и оправдано при решении СЛАУ офигенного размера, но в движках таких расчётов обычно нет. Максимум матрицы 3х3 да 4х4.
