Comments (19)
Thanks for your advice and help, I will try to migrate MPPI to Eigen.
from navigation2.
@guoxxiong any thoughts / have some cycles to look into it?
from navigation2.
Can you back up that claim or provide any other detail?
from navigation2.
Because my hardware does not support xsimd acceleration, and xtensor does not support gcc-7, while other programs rely on gcc-7, so I want to know whether the performance will be weakened by using Eigen instead of xtensor for the tensor of 2000x50.
from navigation2.
That's not sufficient to prevent us from looking into it as a potential course of action.
from navigation2.
For a 2000*60 array, run following code, it outputs:
dot_product_xt: 240000
xtensor dot product took 0.00535805 seconds.
dot_product_eigen: 240000
Eigen dot product took 0.000759429 seconds.
Code:
#include
#include
#include <xtensor/xarray.hpp>
#include "/usr/include/eigen3/Eigen/Dense"
constexpr int rows = 2000;
constexpr int cols = 60;
int main()
{
xt::xarray<double> A_xt({rows, cols}, 1.0);
xt::xarray<double> B_xt({rows, cols}, 2.0);
Eigen::MatrixXd A_eigen(rows, cols);
Eigen::MatrixXd B_eigen(rows, cols);
A_eigen.setOnes();
B_eigen= B_eigen.setOnes() * 2.0;
double dot_product_xt = 0.0;
double dot_product_eigen = 0.0;
auto start_xtensor = std::chrono::steady_clock::now();
dot_product_xt = xt::sum(A_xt * B_xt)();
std::cout << "dot_product_xt: " << dot_product_xt << std::endl;
auto end_xtensor = std::chrono::steady_clock::now();
std::chrono::duration<double> elapsed_xtensor = end_xtensor - start_xtensor;
std::cout << "xtensor dot product took " << elapsed_xtensor.count() << " seconds." << std::endl;
auto start_eigen = std::chrono::steady_clock::now();
dot_product_eigen = (A_eigen.array() * B_eigen.array()).sum();
std::cout << "dot_product_eigen: " << dot_product_eigen << std::endl;
auto end_eigen = std::chrono::steady_clock::now();
std::chrono::duration<double> elapsed_eigen = end_eigen - start_eigen;
std::cout << "Eigen dot product took " << elapsed_eigen.count() << " seconds." << std::endl;
return 0;
}
from navigation2.
That would seem to evidence that Eigen is faster than xtensor, not slower by a factor of over 7x! That would point to the fact that we should consider using Eigen instead of xtensor - which is why its mentioned in the MPPI ticket as something that we should seriously look to evaluate instead of using xtensor for an acceleration boost.
I don't understand your ticket's claim then that xtensor is slower and shouldn't be analyzed?
from navigation2.
The xtensor should be analyzed. I just want to try to replace the xtensor in MPPI with eigen, and I do not know whether the original control frequency can be maintained.
from navigation2.
That is not what your initial ticket title implies, but OK - maybe just a misunderstanding.
Yes, I definitely support some help in trying to migrate MPPI to Eigen to see if its an improvement.
and I do not know whether the original control frequency can be maintained.
No one knows to be able to tell you for certain. However, metrics I see make me think that its a worthwhile direction to explore and that it might actually make it run faster. Are you interested in spending some time working on this yourself?
from navigation2.
OK. I renamed the ticket to be in line with our discussion.
I'd recommend outright ignoring the critics to get started and focus on the core Optimizer/Noise Generator/utils. I think that should make it clear from benchmarking whether its faster or not than xtensor without going through the more laborious task of migrating the critics (which some are easy, some are not). Also, don't fret if immediately the performance isn't as good; there may be steps we can take to improve things. There were several cycles of optimizations and testing on xtensor to get the performance we have now and I would expect the same from Eigen. However, the benchmark on Eigen views makes me think we can save some compute time.
Do you have a general sense of the priority of this task or when you expect to make some progress? I'd be happy to answer any questions or see how I can help if you work on this on a Nav2 fork that is public.
from navigation2.
Hi~, I have initially migrated MPPI to Eigen in Nav1 and conducted a rough comparison experiment. Specifically, Eigen::Array is used instead of xt::xtensor.
Params: model_dt = 0.1, time_step = 32, batch_size = 1800, all Critics
Processor: I5 12400F
Control loop execution time in Eigen Array (ROS1): average: 5 [ms], max: 7 [ms], min: 3 [ms] .
Control loop execution time in xt::xtensor (ROS1): average: 5 [ms], max: 8 [ms], min: 3 [ms].
The conclusion is that using Eigen Array instead of xtensor will not significantly improve the calculation speed.
from navigation2.
Can you share the source? Iโd like to spend a day or two playing around to make sure I find the same behavior and see if I can tweak it at all to improve things.
Did you look at using Eigenโs tensor library instead of Array? The tensor views are supposedly much faster from open source benchmarking Iโve seen
from navigation2.
source: https://github.com/guoxxiong/mppi_local_planner
Because the tensor used by MPPI is at most two-dimensional, I used Array. Eigen : : Tensor may be faster for high-dimensional tensor calculation, but it is more complicated to operate.
from navigation2.
The tensor views have the ability to process information without direct copies, which array I believe lacks. There may be some efficiency gains using Eigen tensor views that arrays don't have. For example, I'm seeing some for
loops in your code that could be handled with Tensors that would likely be more efficient by using simd vectorization or even later GPU support
I think it is worth trying to use Eigen Tensor & views over creating everything as a looping function on arrays. That could give you that edge in run-time speed
from navigation2.
Yes, when I increased the array to 2000 * 56, Eigen::Array
was much slower than xtensor, xtensor(15 ms) vs Eigen::Array(30 ms).
from navigation2.
I wonder if Eigen::Ref
works, Eigen::Array
allows the use of references (Eigen::Ref
) to modify elements in an array without data copying, which is similar to xt::view
in xtensor.
from navigation2.
I think its worth testing with Eigen Tensors themselves instead of trying to work around them with Arrays https://eigen.tuxfamily.org/dox/unsupported/eigen_tensors.html
from navigation2.
@SteveMacenski ๏ผI used Eigen::replicate
, Eigen::Map
, Eigen::TensorMap
to improve performance, it can indeed achieve better results in CPU occupancy and speed.
from navigation2.
Great! Can you share some metrics and and potential paths forward? ๐
This would be a great contribution to Nav2 / the community to speed things up!
from navigation2.
Related Issues (20)
- Removing AMCL from nav2_bringup launch HOT 2
- Error codes in NavigateToPose/NavigateThroughPoses
- Hi, I am building the package of nav2_waypoint_follower and facing that errors, HOT 2
- New "Configure" transition for the LifecycleManager HOT 2
- Accessing waypoints inside a controller plugin HOT 3
- Fix flaky spin test
- Nav2 Stalling on Multiple Robots? HOT 9
- Robot using nav2 begins pathfollowing but never finishes HOT 3
- MPPI cannot follow global path accurately HOT 1
- [Collision_monitor] Approach polygon time=0 step is not processed HOT 7
- The lidar point cloud of NAV2 shifted significantly after being stationary for 5 minutes. HOT 5
- Errors with controller_server using GPS for Navigation HOT 4
- Obstacle Position Shift in Map after Loading HOT 2
- Full footprint collsion distance in MPPI obstacle critic and use of collision_margin_distance. HOT 13
- local_costmap does not respect the use_sim_time parameter HOT 12
- Vector polygon - Collision Monitor is not available for ROS2 humble HOT 5
- [collision_monitor] Add temporal axis to min_points behavior HOT 2
- [ERROR] [1716697697.080277840] [rviz2]: Lookup would require extrapolation into the future. Requested time 1716697697.040514 but the latest data is at time 1716697697.039929, when looking up transform from frame [laser_frame] to frame [odom]
- Laser Scan rotates with robot ------- [ERROR] [1716697697.080277840] [rviz2]: Lookup would require extrapolation into the future. Requested time 1716697697.040514 but the latest data is at time 1716697697.039929, when looking up transform from frame [laser_frame] to frame [odom] HOT 1
- [for help] action `follow_path` doesn't work (humble) HOT 7
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. ๐๐๐
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google โค๏ธ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from navigation2.