интервал по сравнению с арифметической эффективностью плавающей в Java
Я пишу приложение, которое использует алгоритм Dijkstra для нахождения минимальных путей в графике. Веса узлов и краев в графике float числа, таким образом, алгоритм, делающий многих арифметика на числах плавающих. Я мог получить время выполнения, улучшаются, если я преобразовываю весь вес в ints? Международные арифметические операции, быстрее в Java, затем пускают в ход?
Я пытался записать простой сравнительный тест для проверки этого, но я не удовлетворен результатами, которые я получил. Возможно компилятор оптимизировал некоторые части программы, таким образом, результаты не делают взглядов, хороших для меня.
Править:
Проблема, которую я пытаюсь решить, находится в поле Information Retrieval. Приложение должно показать, что ответы на запрос изобразили из себя ряд ключевых слов.
Моя структура данных является взвешенным ориентированным графом. Учитывая ряд вершин я должен найти самое маленькое дерево, которое соединяет эти узлы, и покажите ответ пользователю. Веса присвоены функцией взвешивания, базирующейся частично на tf/idf технике. Пользователь не знает, какие веса я присваиваю узлам и краям, он просто хочет видеть ответы, относящиеся к запросу, который он изложил. Таким образом, точные результаты не требуются, просто возможность перечислить ответы согласно их веса. Просто собственное использование функции взвешивания (поскольку я упомянул это, основано на tf/idf), дает веса плавающие, таким образом, я использовал плавания до сих пор.
Я надеюсь, что это добавляет некоторые предпосылки к вопросу.
6 ответов
Как и всегда, с подобными вещами вы должны поставить себе цели по производительности, а затем профилировать приложение, чтобы увидеть, соответствует ли оно им.
Часто результаты могут быть неожиданными; что на затраченное время практически не влияет базовый числовой тип, или что ваш алгоритм неоптимален.
А что касается оптимизации компилятора - это реальная и действительная часть оптимизации производительности.
Если использование типа A теоретически быстрее, чем использование типа B, но ваш компилятор может оптимизировать тип B, чтобы он был быстрее в реальном сценарии, то это ценное свидетельство, а не источник разочарований.
Я думаю, что производительность во многом зависит от алгоритма и платформы, на которой работает программное обеспечение.
Если вы выполняете расчеты матрицы / массива на платформе X86, среда выполнения может оптимизировать ее для использования SSE, который представляет собой расширенный набор инструкций только с плавающей запятой / двойной точностью.
На других платформах среда выполнения может оптимизироваться для OpenCL (я не верю, что кто-то делает это прямо сейчас, но это может случиться :). Я понятия не имею, что быстрее всего работает на такой платформе и при каких условиях. Возможно, OpenCL оптимизирован для работы с целыми числами.
В этих обстоятельствах я бы сделал вывод, что на данном этапе нецелесообразно оптимизировать тип данных (float или int), а просто оптимизировать читаемость кода.
Если ваш код очень важен для производительности и вы точно знаете, на каком оборудовании будет работать система сейчас и в будущем, вы можете протестировать типичные рабочие нагрузки с различными алгоритмами и выбрать тот, который лучше всего соответствует вашим потребностям.
Но, как правило, просто используйте алгоритм, который вы можете понять, сохраняйте читабельность кода и, следовательно, количество ошибок будет низким. Быстрый код не стоит так дорого, если результаты неверны :)
Я так не думаю.
Число с плавающей запятой составляет 4 байта. И Int в java тоже 4 байта.
Почему бы не использовать дату (java.util.Date) для получения времени выполнения?
Вы можете определить граф, в котором находятся 100000 узлов. Затем рассчитайте это.
Как правило, вам не следует беспокоиться о выборе между int и float по соображениям производительности.
Вот выдержка из приложения Java Puzzlers :
Арифметика с плавающей точкой неточна. Не используйте числа с плавающей запятой там, где требуются точные результаты; вместо этого используйте целочисленный тип или
BigDecimal. Предпочитайтеdoublefloat.
Если у вас нет действительно веской причины, вы обычно должны предпочесть double float , если вам необходимо использовать операцию с плавающей запятой. Если требуется точный результат, используйте BigDecimal ; это будет медленнее, так как это не примитив, но если профилирование не покажет, что это неприемлемо, часто это лучший вариант.
Если вы должны использовать операцию с плавающей запятой, то попытка оптимизировать ее с помощью int не рекомендуется. Скорее всего, это будет преждевременная оптимизация и только усложнит ненужный код. Напишите это наиболее естественным и читаемым способом. Не усложняйте код без надобности ради небольшого увеличения производительности.
Если вам на самом деле не нужны операции с плавающей запятой, то непременно используйте вместо них int или long .
для простых операций int работает быстрее, однако с int вам, возможно, придется проделать больше работы, чтобы получить тот же результат. например
как float
float f = 15 * 0.987;
как int
int i = 15 * 987 / 1000;
Дополнительное деление означает, что операция int может занять больше времени.
Если вы просто хотите сравнить веса, вам следует предпочесть int, а не float.