Производительность кода с floating point vs integers

[tessob]

Прошу знатоков подсказать, что будет работать быстрее на современных интеловских процессорах:
1. Работа с рациональными числами, представленными в виде числителя и знаменателя - Java int.
2. Работа с плавающей точкой - Java double.
Оба примитивы.

Второй день сижу читаю интернет и не могу определиться и начать делать. Каких-то экстремально больших или экстремально малых значений не предполагается. Точность тоже не сильно критична, весь упор на производительность. Планируемые операции - только сложение, вычитание, деление и умножение. Никаких степеней, логорифмов и корней не будет.

C/C++ и CUDA пока не рассматриваю. Просто я не думаю, что оверхед перекроется выигрышем от параллелизма. А пробовать запилить два варианта решения, чтоб просто попробовать, нет ни сил, ни задора. У меня, конечно, большая часть логики SIMD, но размеры D примерно ~400'000 чисел на одну Инструкцию. Еще у меня данные хорошо скалируются, т.е. я просто могу взять еще железа и запусить тот же вычислятор за забором из Nginx. Тоже как-то не мотивирует идти с сторону C.

Короче, в раздумьях я...

[tessob]

Да, позволяет. Я могу нормализовать свои данные, затолкав их, скажем, в пространство значений 0-1. Про точность арифметики с плавающей точкой я в курсе, она для меня приемлема и я знаю как минимизировать побочки, подогнав исходные данные к разумному виду. Да, кстати, если у меня вход в диапазоне, 0-1, то он в этих пределах так и останется. Т.е. вероятность получить решение за пределами этого диапазона практически отсутствует.

[mikeG]

Сделал простой ненаучный тест.
Взял первую попавшуюся библиотеку - https://introcs.cs.princeton.edu/java/9 ... .java.html
Перемножил в цикле 100 миллионов чисел.

floating point в 100 раз быстрее.

[tessob]

По поводу Жабы. Я понимаю, что Жаба уступит в производительности С. И мысль написать кусок вычислений на С у меня пока только крепнет, т.к. вариант использовать в перспективе CUDA тоже очень интересен.

По поводу задачи - обычная линейная алгебра. Складываем матрицы, перемножаем матрицы, обращаем матрицы. В целом, в моем случае, это серия итераций над несколькими иммутабельными объектами, в результате которых получается новый вектор. Т.е. самые тяжелые объекты, после создания, я могу не двигать и ни что не мешает их держать в процессорном кеше.

[Boriskin]

По поводу задачи - обычная линейная алгебра. Складываем матрицы, перемножаем матрицы, обращаем матрицы. В целом, в моем случае, это серия итераций над несколькими иммутабельными объектами, в результате которых получается новый вектор. Т.е. самые тяжелые объекты, после создания, я могу не двигать и ни что не мешает их держать в процессорном кеше.

Итерационные методы (аля сопряженных градиентов или что-то в этом роде)? Пользовать double и не париться с дробным представлением. Еще стоит перепроверить, что все минимизировано на уровне алгоритма, типа только одно умножение на матрицу на одну итерацию.

[tessob]

Итерационные методы (аля сопряженных градиентов или что-то в этом роде)?

Не, по сути ближе к обычному симплексу. Мне нужно реализвовать некий тензор состояний (смены базисов), что-бы уметь по нему возвращаться к последнему живому sub-оптимуму и начинать из него, а не из исходного базиса. Короче, в рамках моей логики, я еще не досчитав текущее решение могу создать новый тред и начинать в нем считать следующее. Короче, я хочу решейпать свой политоп за меньшее время, чем из нуля целевой функции. Ну и варианты как политоп может измениться, в моем случае, ограничены, т.е. я предполагаю, что в 90% случаях смогу находить новый оптимум за очень малое число итераций (десятки-сотни). Именно по этой причине я пока и не решаюсь на С. Я могу себе позволить просто запустить несколько серверов, которые будут это считать и мне даже не нужно париться по поводу консистентности данных внутри.

[mikeG]

Об арифметике и производительности.
Я тут на днях столкнулся с куском кода (JavaScript, правда, не Java), где RSA ключи генерируются без использования native библиотеки.
На последнем айфоне пара ключей две минуты генерируется... Переключил на WebCrypto - теперь за секунду.

[mikeG]

Поиск простых чисел - чистая арифметика.
Если именно производительность критична, то джава, скорее всего, не оптимальный вариант.

[Flash-04]

Джависты довольно грамотно аргументируют что таки производителен как C++. Последний проигрывает на управлении памятью.

[flip_flop]

Джависты довольно грамотно аргументируют что таки производителен как C++. Последний проигрывает на управлении памятью.

Слышал такое, но верится с трудом. Вот сравнение для вычислительных задач показывает всё ещё доминирование С/C++

[Medium-rare]

Джависты довольно грамотно аргументируют что таки производителен как C++. Последний проигрывает на управлении памятью.

При неправильном управлении можно ещё не то сломать.

[AndreyT]

Джависты довольно грамотно аргументируют что таки производителен как C++. Последний проигрывает на управлении памятью.

Не совсем понятно, о каком "проигрывании на управлении памятью" идет речь. С++ может проигрывать в легкости управления памятью (в том смысле, что в garbage collected языке управлением памятью можно не занимать вообще). Но С++ без разговоров и с большим отрывом выигрывает в производительности управления памятью.