Все же хотите тащить код из стекфверфлоу в продакшен, ладно.
Представим что у нас матрицы, скажем, элементов по 25 тысяч и их перемножение происходит в цикле. Ваше решение с std:move в коечном итоге постоянно выделяет и убивает на куче эти 25 тысяч, сама по себе это операция не дешевая, так и память по-тихоньку фрагментируется и спустя какое-то время все становится совсем забавно.
Потому что все они разделяемые ресурсы, да, во всех случая, кроме ReferenceFrame можно перейти вообще на сырые ссылки, но последний точно shared_ptr. Но у каждого программиста есть свои шаблоны в голове, когда он пишет код.
И моя основная мысль, что Rust помогает эти шаблоны немного облегчить.
По крайне мере у нас на предприятии требовании к наличию сертификата у языка нету, а заказчики аттестуют по своим правилам и там это тоже подобные вопросы не стоят.
Да, я потратил время на освоение языка, но не считаю, что это было сделано зря. Я уже бывал в ситуации, что неверный выбор языка и фреймворка в начале, приводил к слишком большим трудностям потом.
Плюсы не без недостатков, как по мне, раст позволит двигаться быстрее, тратя меньше времени на отладку. А еще будет больший шанс, что проект будет использоваться в бортовом коде.
Бегло пробежался по коду и в большинстве случаев матрица 3х3 лежит просто во вложенных массивах, вместо чего-то типизированного.
Постойте-постойте, в массовом виде матрицы 3х3 используется у меня в порте liberfa\sofa, там я так делаю для простоты портирования и дальнейшего поддержания в актуальном состоянии. В других ;t местах пользуюсь nalgebra. Да, чтобы отличить сферические от декартовых тут точно нужен новый тип. Да, Rust позволяет их обернуть бесплатно. Тут тоже хорошо. Но следующих ход уже ошибочен, так можно костей не собрать, если соберемся что-то менять. Не раз это проходил.
Нет, RefCell позволяет использовать указатель на мутабельные данные. Что-то похожее на std::unique_ptr в плюсах. Фактически cell часть кончается после borrow_mut.
Посмотрю на него повнимательней, похоже я что-то недопонял.
Ко всему компилятор очень неплохо оптимизирует иммутабельные данные, как в примере, так что избегание клонирования данных есть преждевременная оптимизация
Да, если компилятор знает что данные не меяется, то там целый ворохо оптимизаций. Но на инфраструктуру полагаться полностью не стоит. Она может поменяться, а потом разгребать это очень сложно.
Спасибо за конструктивное обсуждение, буду читать и думать.
Помимо этого кажется не хватает тестов, покрывающих все эти функции.
Тесты да, не хватает, буду писать. В свое оправдание могу сказать,
По-хорошему, если вы преобразуете один тип в другой, то нужно имплементировать трейт From<T1> for T2.
Это да, но мне кажется, что это должно быть что-то вроде "0 as f64" т.е. информация не меняется. А вот в преобразованиях переменных она меняется.
Причем для обсуждаемой функции причина, вынуждающая меня удалить иммутабельность - кеширование результата, т.к. меняется не только и не сколько тип переменных, сколько система координат (а вот тут могут сидеть значительные вычислительные сложности)
Удалять иммутабельность с самого себя плохая идея и необходимо использовать std::cell примитивы для подобного.
Если я правильно разобрался, то cell вызывает clone, т.е. это доп расходы, которые хочется избежать.
Вместо имлементации трейта From у вас какие-то unsafe, указатели и три этажа transform функций.
Можно поподробнее. Если вы про это
unsafe{
let field_ptr = field as *const CashedVariables as *mut CashedVariables;
..........
}
То это используется здесь. Задача: нужно выполнить вычисления, но только в случае их надобности и закешировать. И мне тут не удается обойтись без того, что из &self сделать &mut self. Если подскажите как это сделать, буду только рад.
Да, но корректное сравнение может проводить на двух средних, хотя бы, проектах, имеющих туже функциональность и не испытавших сильного влияния друг друга. На малых тестовых примерах можно сравнить разве что работу компиляторов.
Если вкратце - никто. Ни тот, ни тот язык не имеют внутренних ограничений. Но на практике Rust дает больше шансов оставить в продакшане более быстрый код.
Мне казалось, что вся статья обосновывает это. Хорошо, давайте так, у нас есть вроде один язык с++, но одна и тажа программа скомпилированная msvc, gcc, clang и т.д. будет выполняться за разное время. Но если мы возьмем и видоизменим для каждого компилятора, то сможем добиться равной производительности. Здесь ситуация схожа.
Все же хотите тащить код из стекфверфлоу в продакшен, ладно.
Представим что у нас матрицы, скажем, элементов по 25 тысяч и их перемножение происходит в цикле. Ваше решение с std:move в коечном итоге постоянно выделяет и убивает на куче эти 25 тысяч, сама по себе это операция не дешевая, так и память по-тихоньку фрагментируется и спустя какое-то время все становится совсем забавно.
Потому что все они разделяемые ресурсы, да, во всех случая, кроме ReferenceFrame можно перейти вообще на сырые ссылки, но последний точно shared_ptr. Но у каждого программиста есть свои шаблоны в голове, когда он пишет код.
И моя основная мысль, что Rust помогает эти шаблоны немного облегчить.
М-да, даешь пример, чтобы подсветить идею, а тут начинается...
Вопрос не в том, как оптимальнейшим образом организовать перемножение матриц, а в том, что даже в относительно простых вещах можно ошибиться.
Если же хотите говорить о перемножении матриц, то возьмите eigen; реализация в boost медленнее.
Ну и матрицы можете все не 3x3, а 512x512, хотя бы.
По крайне мере у нас на предприятии требовании к наличию сертификата у языка нету, а заказчики аттестуют по своим правилам и там это тоже подобные вопросы не стоят.
Да, я потратил время на освоение языка, но не считаю, что это было сделано зря. Я уже бывал в ситуации, что неверный выбор языка и фреймворка в начале, приводил к слишком большим трудностям потом.
Плюсы не без недостатков, как по мне, раст позволит двигаться быстрее, тратя меньше времени на отладку. А еще будет больший шанс, что проект будет использоваться в бортовом коде.
Еще раз спасибо за clippy это действительно очень полезный инструмент. Даже ошибки выгребает.
Постойте-постойте, в массовом виде матрицы 3х3 используется у меня в порте liberfa\sofa, там я так делаю для простоты портирования и дальнейшего поддержания в актуальном состоянии. В других ;t местах пользуюсь nalgebra. Да, чтобы отличить сферические от декартовых тут точно нужен новый тип. Да, Rust позволяет их обернуть бесплатно. Тут тоже хорошо. Но следующих ход уже ошибочен, так можно костей не собрать, если соберемся что-то менять. Не раз это проходил.
Посмотрю на него повнимательней, похоже я что-то недопонял.
Да, если компилятор знает что данные не меяется, то там целый ворохо оптимизаций. Но на инфраструктуру полагаться полностью не стоит. Она может поменяться, а потом разгребать это очень сложно.
Спасибо за конструктивное обсуждение, буду читать и думать.
Если походить по всей стандартной библиотеке, то такое там сплошь и рядом. Юпитер, он конечно Зевс, но не до такой же степени....
Тесты да, не хватает, буду писать. В свое оправдание могу сказать,
Это да, но мне кажется, что это должно быть что-то вроде "0 as f64" т.е. информация не меняется. А вот в преобразованиях переменных она меняется.
Причем для обсуждаемой функции причина, вынуждающая меня удалить иммутабельность - кеширование результата, т.к. меняется не только и не сколько тип переменных, сколько система координат (а вот тут могут сидеть значительные вычислительные сложности)
Если я правильно разобрался, то cell вызывает clone, т.е. это доп расходы, которые хочется избежать.
Ну, этот код из liberfa, очень популярной астрономической библиотеки.
Тогда тоже самый cell допускает ub. Т.к. этот трюк я взял из его кода.
Если я правильно понимаю, там оно меняется через копирование.
Можно поподробнее. Если вы про это
То это используется здесь. Задача: нужно выполнить вычисления, но только в случае их надобности и закешировать. И мне тут не удается обойтись без того, что из &self сделать &mut self. Если подскажите как это сделать, буду только рад.
Хорошо Си, но хрен редьки не слаще.
Спасибо, что просветили.
Да, но корректное сравнение может проводить на двух средних, хотя бы, проектах, имеющих туже функциональность и не испытавших сильного влияния друг друга. На малых тестовых примерах можно сравнить разве что работу компиляторов.
Спасибо, за ссылки. Не сомневаюсь, что будет очень полезно.
Если вкратце - никто. Ни тот, ни тот язык не имеют внутренних ограничений. Но на практике Rust дает больше шансов оставить в продакшане более быстрый код.
Ну так я не говорю, что в rust нет умного указателя, более того, я сам упоминаю об std:rc. Я говорю, что в коде на rust удалось от него избавиться.
Мне казалось, что вся статья обосновывает это. Хорошо, давайте так, у нас есть вроде один язык с++, но одна и тажа программа скомпилированная msvc, gcc, clang и т.д. будет выполняться за разное время. Но если мы возьмем и видоизменим для каждого компилятора, то сможем добиться равной производительности. Здесь ситуация схожа.