Skip to content
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

Simulation Struggles With <200 Particles #3

Closed
SGNull opened this issue Jul 29, 2021 · 9 comments
Closed

Simulation Struggles With <200 Particles #3

SGNull opened this issue Jul 29, 2021 · 9 comments
Labels
rework A large-scale, serious problem without an easy fix wontfix This will not be worked on

Comments

@SGNull
Copy link
Owner

SGNull commented Jul 29, 2021

With physics implemented, it is time to address the elephant in the room. The performance was known to be poor from the beginning, but with the addition of physics this has become far more pronounced. This more than likely comes down to optimizations, but it could also have something to do with the graphics.py package.

To be more specific: 200 particles now seriously lags the simulation.

@SGNull SGNull added the rework A large-scale, serious problem without an easy fix label Jul 29, 2021
@SGNull SGNull added this to To do in [CLOSED] Old Simulation via automation Jul 29, 2021
@SGNull SGNull moved this from To do to In progress in [CLOSED] Old Simulation Jul 30, 2021
@SGNull
Copy link
Owner Author

SGNull commented Jul 30, 2021

This is now the main focus of the project. I would really like to aim for 200 particles at 60 fps.

@SGNull
Copy link
Owner Author

SGNull commented Jul 30, 2021

Here's an idea: Create some kind of list of tuples for every particle before running the program. Do this in such a way that it would be sufficient to loop through this list of, say (aparticle, bparticle) and call aparticle.do_the_things(bparticle) followed by bparticle.do_the_things(aparticle), and have calculated all of the interactions between the particles. This would remove the need for a nested for loop.

This might not result in a performance increase, but it feels like it should.

@SGNull
Copy link
Owner Author

SGNull commented Jul 30, 2021

Added that list of tuples, and named it "Universe Pie". It doesn't cause a drastic increase in performance, but I'm pretty sure it improves performance a little bit.

@SGNull
Copy link
Owner Author

SGNull commented Jul 30, 2021

The more optimized I'm making the code, the more I'm starting to think it has something to do with the packages, or even python itself.

@SGNull
Copy link
Owner Author

SGNull commented Jul 31, 2021

Judging by the results of issue #8, it seems more likely that particle physics is the real culprit.

@SGNull SGNull changed the title Low Performance Simulation Struggles With <200 Particles Jul 31, 2021
@SGNull SGNull pinned this issue Jul 31, 2021
@SGNull
Copy link
Owner Author

SGNull commented Jul 31, 2021

I just found the biggest culprit. I noticed that increasing the radius of the particles resulted in significantly worse performance. This kinda would make sense, as particles out of range do less calculations, and the force distance is relative to radius (in the current settings). However, the range increase/decrease is negligible when going from, say, 5 to 7. So, I ran a few tests, and noticed it was taking about 3.5 seconds to do 100 steps, which is about 0.7 more than I was getting with the smaller radius.

I then commented out the draw() function. 1.6 seconds on average to run 100 steps. WOW. Looks like we need a new draw function, or a completely different package than graphics.py.

@SGNull
Copy link
Owner Author

SGNull commented Jul 31, 2021

Made this its own milestone.

@SGNull
Copy link
Owner Author

SGNull commented Jul 31, 2021

Just did some looking, and my older particle simulator was way less optimized, but it ran at 500 particles!!! With all the problems I've been having, I can't believe it! This is either a python thing, or just a combination of drawing and something else. Maybe it's numpy?

@SGNull
Copy link
Owner Author

SGNull commented Jul 31, 2021

I'm at the point where the packages I'm installing to speed things up are written in different languages to bypass python's slowness. This is just going to be easier to write in a different language, plain and simple.

@SGNull SGNull added the wontfix This will not be worked on label Jul 31, 2021
@SGNull SGNull closed this as completed Jul 31, 2021
[CLOSED] Old Simulation automation moved this from In progress to Done Jul 31, 2021
@SGNull SGNull unpinned this issue Jul 31, 2021
@SGNull SGNull moved this from Done to Won't Fix in [CLOSED] Old Simulation Jul 31, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
rework A large-scale, serious problem without an easy fix wontfix This will not be worked on
Projects
Development

No branches or pull requests

1 participant