Спасибо за комментарий, вариант с DoubleArray уже посоветовали, пробую - есть отдельная ветка где все складывается в DoubleArray, пока ничего это не дало) А так я вроде ничего не "хаял")
Согласен конечно. Если обратите внимание , есть уже вариант где все double хранятся тоже как объекты в векторе std::vector<unique_ptr<double>> вроде близко к тому что происходит в котлин, то есть это уже не примитивы но пока это ничего не дало в плане времени выполнения.
сделать не vector double, а vector<unuqie_ptr<double>> и тоже создавать и складывать в массив объекты
Попробовал
std::vector<std::unique_ptr<double>> points;
//в цикле складываем умные указатели на double в массив
points.emplace_back(std::make_unique<double>(x));
points.emplace_back(std::make_unique<double>(y));
// по итогу вычислений пробегаемся по массиву c указателями,
// разименовываем их и складываем в обычный вектор double
// std::vector<double> resVector;
resVector.reserve(points.size());
for (auto it=points.begin();it!=points.end();++it){
resVector.push_back(**it);
}
сейчас залью в отдельную ветку ,особо так медленнее но все равно не сильно влияет на результат)
Пока я пришел к мнению что все что можно cделать на Kotlin, нужно делать на котлин, а если придется упереться в какие-то супер вычисления думать о native или GLSL
Я думаю все тормоза в создании объектов Complex на каждой итерации, а куда складываются даблы в результате вычислений, уже не так и важно, основная масса итераций это создание объектов Complex, там сильно завышена верхняя планка по количеству операций, если ее хоть чуток снизить, все летает. Думаю это и есть узкое место в программе, куча созданных в куче объектов, которые потом сборщик мусора собирает, ну собственно это я их хотел сделать)
Хотелось бы видеть расширенное сравнение, нет даже, исследование на эту тему. У вас в статье даже профайлер не включён. Не понятно на что тратится и где время.
Согласен полностью,хотелось бы их увидеть. Я осознаю, моих знаний недостаточно,чтобы что-то утверждать,я публикую свой взгляд на проблему и, повторюсь, не претендую на истину.
На счет Kotlin Native - самому очень интересно. Есть более серьезные исследования, ссылки на них прикреплены к работе. Я же старался найти ответы на те вопросы на которые не нашел ответы в сети.
Если честно, тест был задуман только в контексте ART vs NDK, не ставил себе цели определить какой язык лучше, цель стояла простая - выяснить бывают ли случаи, когда есть смысл использовать NDK. На мой взгляд все понятно
В целом можно с уверенностью сказать, что существуют случаи, когда производительность нативного кода колоссально превосходит производительность JVM и, несмотря на некоторое усложнение проекта, имеет смысл реализовать с помощью NDK
Потому как на момент задумки, были сомнения, все таки AOT компиляция, профилирование выглядят как серьезные аргументы.
Создаем массив DoubleArray размером 3млн Double складываем туда координаты точек, теперь мы знаем точно количество точек, оборачиваем в asList, применяем границы с помощью subList
Да, это быстрее ,идея хорошая, но тут мы пошли на хитрость - используем массив фикс. размера, добавил Apk в ветку DoublуАrray, вроде особо быстрее не стало, или я неправильно понял вашу идею?
Да, это факт, с которым спорить трудно, но сколько я не перекапывал docs, я не смог найти никакого сравнения,если бы хотя бы написали работать будет на 2% быстрее, а так просто используйте NDK, если нужно выжать производительность.... Сколько производительности ? Это же не лимон, который можно выжать)
Да про примитивы слышал, но мы говорим про объекты, как я создам примитивный объект пользовательского класса, тут моих знаний не хватает. Я понимаю, что в случае с примитивами картина будет другой, спасибо.
ps. Этот эксперимент - альтернатива тысяче и одному эксперименту с кучкой примитивов, которых и так достаточно.
Да, вы правы. Я просто просто беру коллекцию куда я могу складывать double и при этом не знаю заранее ее размер,то есть применена стандартная коллекция языка - контейнер с автоматическим расширением размера - можно сказать динамический массив. А так можно и std::vector реализовать на kotlin. Вы абсолютно правы,можно использовать массив DoubleArray и управлять его размером, это поле для экспериментов, но есть сомнения что даже в таком случае Kotlin отработает быстрее native.
Я предполагаю, что основные тормоза в создании и удалении Complex, а не в типе контейнера,и замена контейнера не сильно поможет делу, проверю обязательно, спасибо.
В начале поста - я осознанно сделал пояснения к выбору алгоритма, пункту номер 4, что здесь будет рассмотрена именно работа с кучей, так как JVM не дает большого выбора как создавать объекты, замечу что С++ делает все тоже самое, выделяет память в куче и занимается "дробилками". А в целом да
Kotlin плохо подходит для написания числодробилок из-за своих ограничений,
Отлично сказано, только я бы добавил Kotlin на JVM ART плохо подходит для "зубодробилок", потому как не удивлюсь, если на ПК или Kotlin Native результат будет противоположный
Замечу, что не ставил перед собой цель начать холивар, я просто искал ответ на вопрос на который ответа не было и делюсь своими скромными результатами. Многие задачи и несут в себе "перетусовки" объектов в памяти. Данный алгоритм может и перегибает палку, но зато наглядно.
Если делать упор на оптимизацию, то для данного алгоритма есть чисто математические способы оптимизации, которые превзойдут любые "фокусы" в коде. Идея была реализовать простой алгоритм который будет работать именно с объектами - с большим их количеством, большим количеством итераций и сравнить как поведет себя JVM и Garbage Collector в сравнении с Native. Готов согласиться со всем, кроме
она просто выполняет код
То есть, можно сказать что искусственно создана ситуация, когда сборщик мусора будет "пыхтеть", да это не оптимально, но согласитесь, интересно
Если честно я ожидал совсем другого результата, уже была заготовлена фраза - что-то вроде "использование С++ усложняет проект, а разница во времени выполнения незначительна", поэтому, собственно и написал пост, интересно что скажут профи или просто умные люди)
100% может быть улучшено, повторюсь, идея заключалась в сравнении "в лоб". Не исключаю также, что где-то закралась критическая ошибка, если найду, обязательно дополню.
Спасибо за комментарий, вариант с DoubleArray уже посоветовали, пробую - есть отдельная ветка где все складывается в DoubleArray, пока ничего это не дало) А так я вроде ничего не "хаял")
GeekBench 1082 ! Очень мощный телефон, спасибо, у меня с таким бенчмарком ничего нет)
Сделал
Прилетает DoubleArray, заворачивается в List, прямо как в С++
Согласен конечно. Если обратите внимание , есть уже вариант где все double хранятся тоже как объекты в векторе std::vector<unique_ptr<double>> вроде близко к тому что происходит в котлин, то есть это уже не примитивы но пока это ничего не дало в плане времени выполнения.
Да и в котлине нет примитивов)
Попробовал
сейчас залью в отдельную ветку ,особо так медленнее но все равно не сильно влияет на результат)
ветка arrayOfSmartPointers
Пока я пришел к мнению что все что можно cделать на Kotlin, нужно делать на котлин, а если придется упереться в какие-то супер вычисления думать о native или GLSL
Я думаю все тормоза в создании объектов Complex на каждой итерации, а куда складываются даблы в результате вычислений, уже не так и важно, основная масса итераций это создание объектов Complex, там сильно завышена верхняя планка по количеству операций, если ее хоть чуток снизить, все летает. Думаю это и есть узкое место в программе, куча созданных в куче объектов, которые потом сборщик мусора собирает, ну собственно это я их хотел сделать)
Согласен полностью,хотелось бы их увидеть. Я осознаю, моих знаний недостаточно,чтобы что-то утверждать,я публикую свой взгляд на проблему и, повторюсь, не претендую на истину.
На счет Kotlin Native - самому очень интересно. Есть более серьезные исследования, ссылки на них прикреплены к работе. Я же старался найти ответы на те вопросы на которые не нашел ответы в сети.
Если честно, тест был задуман только в контексте ART vs NDK, не ставил себе цели определить какой язык лучше, цель стояла простая - выяснить бывают ли случаи, когда есть смысл использовать NDK. На мой взгляд все понятно
Потому как на момент задумки, были сомнения, все таки AOT компиляция, профилирование выглядят как серьезные аргументы.
Создаем массив DoubleArray размером 3млн Double складываем туда координаты точек, теперь мы знаем точно количество точек, оборачиваем в asList, применяем границы с помощью subList
Да, это быстрее ,идея хорошая, но тут мы пошли на хитрость - используем массив фикс. размера, добавил Apk в ветку DoublуАrray, вроде особо быстрее не стало, или я неправильно понял вашу идею?
Тут появилось предложение сложить в котлине все в массив DoubleArray, попробую проверить
Да, это факт, с которым спорить трудно, но сколько я не перекапывал docs, я не смог найти никакого сравнения,если бы хотя бы написали работать будет на 2% быстрее, а так просто используйте NDK, если нужно выжать производительность.... Сколько производительности ? Это же не лимон, который можно выжать)
Да про примитивы слышал, но мы говорим про объекты, как я создам примитивный объект пользовательского класса, тут моих знаний не хватает. Я понимаю, что в случае с примитивами картина будет другой, спасибо.
ps. Этот эксперимент - альтернатива тысяче и одному эксперименту с кучкой примитивов, которых и так достаточно.
Да, вы правы. Я просто просто беру коллекцию куда я могу складывать double и при этом не знаю заранее ее размер,то есть применена стандартная коллекция языка - контейнер с автоматическим расширением размера - можно сказать динамический массив. А так можно и std::vector реализовать на kotlin.
Вы абсолютно правы,можно использовать массив DoubleArray и управлять его размером, это поле для экспериментов, но есть сомнения что даже в таком случае Kotlin отработает быстрее native.
Я предполагаю, что основные тормоза в создании и удалении Complex, а не в типе контейнера,и замена контейнера не сильно поможет делу, проверю обязательно, спасибо.
В начале поста - я осознанно сделал пояснения к выбору алгоритма, пункту номер 4, что здесь будет рассмотрена именно работа с кучей, так как JVM не дает большого выбора как создавать объекты,
замечу что С++ делает все тоже самое, выделяет память в куче и занимается "дробилками".
А в целом да
Отлично сказано, только я бы добавил Kotlin на JVM ART плохо подходит для "зубодробилок", потому как не удивлюсь, если на ПК или Kotlin Native результат будет противоположный
Замечу, что не ставил перед собой цель начать холивар, я просто искал ответ на вопрос на который ответа не было и делюсь своими скромными результатами. Многие задачи и несут в себе "перетусовки" объектов в памяти. Данный алгоритм может и перегибает палку, но зато наглядно.
Если делать упор на оптимизацию, то для данного алгоритма есть чисто математические способы оптимизации, которые превзойдут любые "фокусы" в коде. Идея была реализовать простой алгоритм который будет работать именно с объектами - с большим их количеством, большим количеством итераций и сравнить как поведет себя JVM и Garbage Collector в сравнении с Native. Готов согласиться со всем, кроме
То есть, можно сказать что искусственно создана ситуация, когда сборщик мусора будет "пыхтеть", да это не оптимально, но согласитесь, интересно
Если честно я ожидал совсем другого результата, уже была заготовлена фраза - что-то вроде "использование С++ усложняет проект, а разница во времени выполнения незначительна", поэтому, собственно и написал пост, интересно что скажут профи или просто умные люди)
Все верно, так и было задумано, проверить с объектами, а не с примитивами, на примитивах таких тестов хватает на просторах сети.
100% может быть улучшено, повторюсь, идея заключалась в сравнении "в лоб". Не исключаю также, что где-то закралась критическая ошибка, если найду, обязательно дополню.