Как стать автором
Обновить
23
0
Проскурин Олег @3036662

Пользователь

Отправить сообщение

Мне 36, всю дорогу работал в продажах в компаниях, есть несколько лет опыта в качестве мелкого предпринимателя, банально стало скучно офис, 1с, кулер, план продаж, решил что нужно сделать middle life career change, программирование всегда было как хобби, начиная ещё от ассемблера и masm, долго думал как это провернуть, поступил на дистанционку по направлению it, понял что нужно высвободить побольше времени, оставил свой магазинчик товарищу, поехал работать водителем в Германию, свободного времени стало много, работал в графике 4 недели работаешь, две отпуск, так прошло два года, в итоге я в Москве, заканчиваю 4 курс, продолжаю изучение различных технологии OpenGL, базы данных, kotlin, C++ последнее время тоже разработку под Android, пробую откликаться на вакансии джуна, пока безуспешно, хотя попадались небольшие подработки, скажу, что даже не имея детей, это отнимает практически все свободное время, а вероятность, что в России возьмут на работу 40летнего джуна видится мне очень небольшой... Но я любом случае буду доводить дело до конца)

Все правильно WebView уже не работает, а вот custom tabs работает и будет работать. Поэтому и делал через custom tabs.

Через WebView прилетает ошибка "неправильный user_agent"

Да, мне тоже люботно, думаю это будет битва компиляторов,я перекопал массу публикаций на тему "Android Java vs C++" и да, были случаи когда вычисления с плавающей точкой на Java работали быстрее, но во всех таких случаях использовались какие-то очень древние компиляторы С++. В случае с Rust , я ставлю на то что результаты тестов буду "плавать" с выходом новых версий компиляторов, но рассуждать бесполезно, нужно просто проверить) Так же остается вопрос еще как поведет себя Kotlin Native.

Если честно, не ставил целью сравнение языков, основная идея была сравнить выполнение кода в контексте виртуальной машины и сборщика мусора против выполнения native C++, поэтому алгоритм был осознанно написан таким образом, чтобы поставить сборщик мусора в неудобную ситуацию. Оптимизацию с удалением объектов Complex я добавил по той причине, что в комментариях было много людей, которые считали что я хочу "очерить котлин". Лично мне неважно как называется язык, тут важен сам факт того, что использовать нативный код легко и работает он быстрее,для каких то задач это может быть полезно. Я думаю Rust будет +- даст те же результаты, что и С++, но постараюсь проверить.

Языки были выбраны просто по принципу - рекомендованные в developer.android.com

Самого бесит) Я бы сказал "одинаково плохо знают оба")

Сделано уже С++ все равно в два раза быстрее, добавляем в статью. Переиспользуемые объект этот "возврат" к старым добрым вычислениям на примитивах, потому как там внесены изменения в методы самого объекта таким образом, чтобы не создавались новые объекты, а все вычислялось в примитивах ( в полях объекта)

Да, это война в другую сторону, с ускорением Котлин уже справились - нужно просто перестать создавать горы объектов в Complex в куче , тогда все работает быстро, иначе в С++ все уходит вперед с большим отрывом, как бы мы не старались его замедлить)

Я думаю все тормоза в создании объектов Complex на каждой итерации, а куда складываются даблы в результате вычислений, уже не так и важно, основная масса итераций это создание объектов Complex, там сильно завышена верхняя планка по количеству операций, если ее хоть чуток снизить, все летает.

Ну вот - снимаю шляпу, предположение мое подтвердилось узким местом было создание объектов Complex в каждой итерации, если от этого уйти, все становится на свои места, остается еще проверить версию про Kotlin Native

Резервирую только 300тыс, как и в Котлин, массив же почти в 8 раз больше, то есть будет несколько реалокаций с расширением контейнера.

В варианте с shared_ptr вообще не резервируется память, просто с нуля всё складывается в пуиой массив. Это не особо влияет на результат

Совет с DoubleArray был принят к исполнению, но пока что ничего этот не дало.

Я буду рад, если код Котлин получится значительно улучшить без значительных компромиссов, на мой взгляд использование фиксированного по размеру массива это уже компромисс, так можно и на си отказаться от вектора, тоже даст пару миллисекунд, избежим реалокации, я ставлю на kotlin native. Буду рад дельным советам)

Код лежит на GitHub, ветки по советам из комментариев созданы, apk лежат в ветках в папках apk. Не соглашусь по поводу негатива, не было его, мне нравится Котлин, если есть критическая ошибка в коде на Котлин, буду рад испытать после её исправления, пока два дельных предложения было, оба пробую

Спасибо за комментарий, вариант с DoubleArray уже посоветовали, пробую - есть отдельная ветка где все складывается в DoubleArray, пока ничего это не дало) А так я вроде ничего не "хаял")

GeekBench 1082 ! Очень мощный телефон, спасибо, у меня с таким бенчмарком ничего нет)

Сделал

 return  points.copyOf(index + 1).asList()

Прилетает DoubleArray, заворачивается в List, прямо как в С++

Согласен конечно. Если обратите внимание , есть уже вариант где все 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);
}

сейчас залью в отдельную ветку ,особо так медленнее но все равно не сильно влияет на результат)

ветка arrayOfSmartPointers

Информация

В рейтинге
Не участвует
Дата рождения
Зарегистрирован
Активность