Маленькие тонкости большого дела

[ToxaBes]

Решение это хорошее, но на данном железе абсолютно бестолковое

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

Вообще, это похоже на частный случай метода Комбы.

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

В них все оптимизации на низком уровне сьест nvcc оптимизатор сделав свой вариант.

Для реального ускорения лучше реализовать GLV метод и лестницу Монтгомери прямо на GPU в cuda kernel (.cu). Я так на 3 порядка ускорял расчеты.

[wataru]

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

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

Еще, просто вывалить 2 простыни ассемблерного кода - такое себе. Хоть бы объяснили подробно, в чем ваша изящная и замечательная идея заключается, почему оно работает. Я так вижу, что вы просто переставили местами операции. Эта микрооптимизация похоже увеличенивает параллельность кода потому что позволяет суперскалярным процессорам лучше загружать конвеер?

Поэтому и понятно, почему оно не ускоряет работу на видяхах - там процессоры не такие суперскалярные как cpu.

Кроме того, стоит отдельно описать, почему этот код корректен. Не теряется ли там пренос из-за скачков через разряд?