Средства и методы разработки

Скажем, у меня есть ассемблерная библиотека примитивов, которая фактически стала неотъемлемой частью любого моего проекта. Писать ее начала давно, когда SSE и AVX еще не было (по крайней мере, у моего процессора). Подвигло меня к этому понимание того, что компилятор C/C++ использует FPU-сопроцессор исключительно примитивно, не используя в полной мере его стековых возможностей. Т.е. речь идет о том, что у FPU87 есть 8 регистров, тогда как компилятор использовал не более двух из них - самых младших. Типа того, чтобы запихнуть сначала первый сомножитель, потом второй (первый при этом проталкивается глубже), а потом их перемножить, очистив второй. После этого у меня наступил период ассеблерописательства :), когда я использовала FPU на всю катушку - т.е. все его внутренние регистры для хранения промежуточных результатов. Очень похоже на язык FORTH (не путать с Фортраном) или на старые советские калькуляторы с "обратной польской записью" операций. Вычисление скалярных произведений было как раз самой насущной моей потребностью по этой части, т.к. обмен данных с памятью тогда происходил довольно долго (сравнимо со скорость самой операции, поскольку в double было 64 разряда, а работа с памятью 32-битная). В результате родился алгоритм накопления произведений в еще одном регистре самого процессора, что избавляло от необходимости держать сумматор в памяти. Понятное дело, что на C/C++ такого никогда не запрограммируешь, т.к. на этом языке невозможно определить сумматор на регистре сопроцессора. Кстати, это оказалось непосильно для всех компиляторов, т.к. в FPU87 регистры перемещаются после каждой операции, а доступ есть только к топовому. Видимо, именно по этой причине от стековой модели отказались и теперь к регистрам SSE/AVХ есть отдельный доступ и положение их зафиксировано. Апофеозом этой деятельности явилась процедура диагонализации квадратной симметричной матрицы (т.е. задача нахождения ее собственных значений и векторов) написанная с максимальны использованием FPU87. Причем мне тогда удалось совсем обойтись без хранения промежуточных переменных в памяти, а осталась только работа по перестроению самих матриц. Время от времени возникали еще похожие задачи, эффективно реализуемые на сопроцесоре. Например, вычисление суммы квадратов отклонений (погрешности аппроксимации), когда требуется получить сумму квадратов разностей между элементами двух массивов без порчи/модификации их содержимого. Эта задача решается совершено аналогично скалярному произведению с добавление операции вычитания, и вычислялось у меня за одно и тоже время. Со временем я создала для себя "матричную библиотеку" (это уже когда C++ постигла), которая производила арифметические операции над матрицами и векторами в привычной нам алгебраической записи (путем переопределения арифметических операторов у векторных и матричных классов). Ну, и все остальное, что бы связано с матрицами тоже было туда вбухано. При этом сами эти операции осуществлялись путем обращения к библиотеке ассемблерных примитивов, а потому работали примерно за тоже время. И вот только сейчас я испытываю сомнения с тем, стоит ли мне и далее идти по этому пути. И нынче уже склоняюсь к тому, что использование готовых библиотек (типа Intel MKL) в настоящее время предпочтительнее самоделок, т.к., в отличие от них, охватывает весь "зоопарк" процессов и операционных систем. Вот и сейчас эта проблема наружу влезла - один и тот же процессор в одной операционке поддерживает AVX/AVX2, а в другой не поддерживает.