По «условию задачи» инлайн запрещён, так что пункт 1 можно исключить. Получается, что не так страшен Натив, как сперва кажется. Хотя и 20% это может быть принципиальной разницей. Видимо, по умолчанию надо пытаться избегать нативного кода, а если есть реальная необходимость использования, то там явно что-то нетривиальное и разница в скорости выполнения нативного кода будет покрывать потерю на вызове функции. А для простого кода чистый Java будет и быстрее и удобнее для программирования.
Разумеется, это в том случае, если программист умеет и в JVM и в натив примерно на одном хорошем уровне и не будет писать что-то сильно неудачое просто от того, что не может на другом языке реализовать.
Есть результат для расчёта Фибонначи в Java, тем же алгоритмом, что и в нативном коде?
Догаываюсь, что в Java выходит быстрее, но интересно знать прям цифры, чтобы вопрос окончательно закрыть :)
Ещё вопрос. На какой архитектуре проводились тесты? Наверняка на х86, x64 и ARM будут различные результаты, ведь разные реализации JVM и целевая архитектура разная.
В попугаях разница устрашающая, но в абсолютных величинах это сколько? Например, по сравнению со сложением или умножением двух вещественных чисел?
Интуитивно кажется очевидным, что для масипусеньких фукнций JN(J) вызовы лучше не делать, но если фукнция выполняет какую-то более сложную работу, чем ничего, то будет ли влияние хоть сколько-то заметно? Что-нибудь простое если делать, например, суммировать элементы массива, то с какого числа элементов влияние способа вызова перестаёт иметь значение?
Нужна самая важная и самая интересная статистика: Сколько победивших «независимых» кандидатов вступило в «Единую Россию» в течении месяца после подведения итогов голосования?
Ну с мигающей или перегоревшей прокатит, а удаётся поменять потускневшую? Т.е. она светит, но не на 100, а на 80 ватт (условно). Т.е. воткнут, скажут, что светит и пошлют в пешее путешествие. Вот сейчас у меня две «как 100 ватт» дают света примерно как одна нормальная 100 ваттная. Но не мигают, не звенят…
Это не к Гауссу, это ко всем лампам на рынке. По деньгам выгоднее 100 ваттные лампы накаливания вкручивать, чем каждый год дорогие светодиодные покупать. Хотя, я дороже 500 рублей лампочки не брал, так что не могу вообще за все говорить, но если по 1000 рублей брать, то лампы накаливания тем более выгоднее в рублях выходят.
В интернете… Я пока изучаю вопрос, личного опыта нет. Пишут, что float до 32 раз быстрее считает, в зависимости от размеров данных. Причём на TESLA (вспомнил название) разница в скорости не столь большая.
Так то очевидно, что double вдвое больше нагружает шину и, если объёмы огромные, то будет заметная разница в скорсоти из-за бОльших издержек. Потому я и пишу, что интересно сравнение именно на больших объёмах данных, а не на игрушечных массивах в 100 тыссяч элементов.
NVidia хочет деняк, поэтому на игровых GPU порезали скорость вычислений double. Хочешь считать double — покупай Quadro или как там у них про-карточки называются и внешние девайсы специальные.
А можно подробнее про «последствия» (вы ж инсайдер) или ссылку на информацию. По идее, там жидкость диэлектрическая, так что даже патрон закоротить не должен, если и прольётся.
На всякий случай уточню, что речь про вот такие лампочки. Просто светодиодные, без ртути. Какие были последствия? У меня просто драйвер сломался через несколько лет, не разлилось ничего.
Энергоэффективные лампочки берут только ради экономии. У ламп накаливания в абсолютном большинстве случаев свет приятнее глазу. При цене $80, я лучше 2-3 штуки 100 ваттных вкручу, всё-равно дешевле выйдет.
Лампочки с жидкостью не разбиваются при падении. Проверял :) Вернее, мне сперва сказали, что они скорее всего не разобьются, а уже после этого я проверял. В любом случае, я за всю жизнь разбил всего пару лампочек: в одну папала стрела (я был суровым индейцем), а во вторую стрельнул из брызгального пистолета. Как у людей лампочки массово разбивается — не представляю.
Достаточно мощный CPU и очень слабый GPU. И то разница есть в пользу GPU.
Но объёмы вычислений всё-равно микроскопические в тестах, ещё и последовательно вычисления идут (идеально в плане кэширования). Хотелось бы что-нибудь типа умножения матриц размером 10К*10К. Там уже «в лоб» будут проблемы с кэшированием и процессор гарантированно начнёт страдать, а вот поведение GPU было бы интересно. Ну и с double проблемы возникнут уже на GPU (от NVidia), а особенно интересно именно вычисление даблами…
Мне интересно. Но я пока только с силами собираюсь, чтобы за изучение OpenCL взяться.
В любом случае, спасибо за статью. Не хватает исходников.
Жду вторую часть, очень интересно и актуально. Интересны тесты на относительно больших объёмах данных. Хотя бы пару гигабайт чтобы вектора были. Маленькие объёмы очевидно будут быстрее на CPU, т.к. нет накладных расходов на передачу данных на GPU и обратно (я же правильно понял, что compute::vector это уже копирование в видеопамять? Или это копия в оперативной памяти и это удваивает требования к объёму оперативной памяти?). Интересно, на каких примерно объёмах вычислений GPU становится эффективнее.
Разумеется, это в том случае, если программист умеет и в JVM и в натив примерно на одном хорошем уровне и не будет писать что-то сильно неудачое просто от того, что не может на другом языке реализовать.
Догаываюсь, что в Java выходит быстрее, но интересно знать прям цифры, чтобы вопрос окончательно закрыть :)
Ещё вопрос. На какой архитектуре проводились тесты? Наверняка на х86, x64 и ARM будут различные результаты, ведь разные реализации JVM и целевая архитектура разная.
Интуитивно кажется очевидным, что для масипусеньких фукнций JN(J) вызовы лучше не делать, но если фукнция выполняет какую-то более сложную работу, чем ничего, то будет ли влияние хоть сколько-то заметно? Что-нибудь простое если делать, например, суммировать элементы массива, то с какого числа элементов влияние способа вызова перестаёт иметь значение?
Жаль, что удалили. Теперь рекрутерам даже спросить нечего на собеседовании…
Сколько победивших «независимых» кандидатов вступило в «Единую Россию» в течении месяца после подведения итогов голосования?
Так то очевидно, что double вдвое больше нагружает шину и, если объёмы огромные, то будет заметная разница в скорсоти из-за бОльших издержек. Потому я и пишу, что интересно сравнение именно на больших объёмах данных, а не на игрушечных массивах в 100 тыссяч элементов.
На всякий случай уточню, что речь про вот такие лампочки. Просто светодиодные, без ртути. Какие были последствия? У меня просто драйвер сломался через несколько лет, не разлилось ничего.
Но объёмы вычислений всё-равно микроскопические в тестах, ещё и последовательно вычисления идут (идеально в плане кэширования). Хотелось бы что-нибудь типа умножения матриц размером 10К*10К. Там уже «в лоб» будут проблемы с кэшированием и процессор гарантированно начнёт страдать, а вот поведение GPU было бы интересно. Ну и с double проблемы возникнут уже на GPU (от NVidia), а особенно интересно именно вычисление даблами…
Мне интересно. Но я пока только с силами собираюсь, чтобы за изучение OpenCL взяться.
В любом случае, спасибо за статью. Не хватает исходников.
А квадратный корень почему для int считается?