-
Notifications
You must be signed in to change notification settings - Fork 3
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Lazy evaluation/cache for most acme objects #21
Comments
@StoccoDavide, I've implemented the version with
As a reference, the graph contains more than 300.000 segments and up to 2 million triangles, which must verify a hundred million wall crossings. On average, this small #21 PR produces a 1.25x performance improvement. I don't know how much it can be improved if I can implement the cache on every object if you agree with these changes 😄 (for new v5). Now I'll update our acme objects and see which is the performance improvement by adding cache to PD: obviously, all tests passed |
Hi! Cheers, |
Let me know which is the performance improvement on your software! 😁 |
I think the #21 approach is better, as manually calling Now, to maintain the same consistency on getting non-const references, maybe Now, for cache, I stored TEST(AcmeTest, CachedTriangle) {
auto t1 = high_resolution_clock::now();
triangle t(acme::point(0, 0, 0), acme::point(1, 1, 0), acme::point(0.5, 0.5, 0));
for (int i = 0; i < 1000000; i += 1) {
ASSERT_TRUE(IsParallel(t, t));
}
duration<double, std::milli> ms_double = high_resolution_clock::now() - t1;
std::cout << "Triangle parallel " << ms_double.count() / 1000 << " s" << std::endl;
} I got the following results:
Which represents an x8.5 improvement (note that this factor should be near 1 when comparing two triangles once, but generally, we tend to compare the same triangle with many others, many times). To do so, I needed to remove Now, for my software, I made a comparison with cache & non-cache (measures in seconds), running it many times:
This should be the performance improvement for a real-case scenario. Now, I have to do more checking between the same segments (for multiple pipelines); thus, the performance should increase as the segments are stored as pointers, thus, the cached properties will be reused many times. |
I agree with you on the fact that I don't know if at this point it would be better for you to implement an extended (inherited) class of the Cheers, Davide |
Hi; during the profiling of our app, I noticed that a significant amount of samples during segment collinear checking belong to
toUnitVector
. This method is called million times; thus, I thought of caching the unit vector, vector, and length just to test how the performance changes.As you can see in #20, I stored these values (by calling a new method
update()
) and got a massive performance change. My test:Without using any cache (the current acme):
Using cache:
That is a massive x3.5 performance improvement. However, my proposal in #20 is not the best approach, mainly because I need to call
update()
each time a vertex is changed. However, if the segment vertex reference is removed:And we introduce a method named
segment.updateVertex(point &p1, point &p2)
, this method can callupdate()
automatically. Also, we can further improve the performance by assembling each value granularly; that is, we compute the vector once it is required (lazy evaluation).This cache could also be propagated to the rest of the acme objects. Let me know what you think
The text was updated successfully, but these errors were encountered: