Is there a way to get the cura slicer to use more than one core in Octoprint (Octopi install on a raspberry pi)?
I notice that discussion is from 2014. I also notice that Slic3r has multi-core support. I also do not think there is a need to have the Cura processing in the same thread as the rest of the operations. A raspberry pi has 4 cores. It might as well use 2 of them, at least. 1 for the main operations and other cores for slicing and misc tasks or at least the portions of those that can be moved to the other cores even if there is a maintainer portion of the main thread since Octoprint is a non-threading application. I have looked at the Octoprint code and I am sure that switching Python base from Flask to Tornado (I think that was the name) or whatever would be a hassle so I simply won’t expect that.
sleep 10 & wait; echo done
That is a simple example of doing something and then waiting on it to complete. I suppose that if I have to I could replace the Cura call to a shell script that does that, but it would benefit more people if some time in the future the standard call did that much. It would at least take the Cura work out of the processor core that does the thread of Octoprint itself.
It seems that doing a command line replacement gets it stuck on slicing. I guess that will not work.
Octoprint print uses both tornado and flask.
CuraEngine is launched as a separate prices so runs on a different core from Octoprint.
Slicing is amenable to multithreading because the problem is partitionable (for example, a thread per slice), but it depends greatly on implementation and cross partition interaction (for example, you may generate support before slicing or you may do it as a side-effect of filling a slice and then backfill support on lower layers). I’m not sure whether CuraEngine circa 15.04 is multi-thread capable or not. I suspect not.
prices->process
I checked top and it said only the first processor core was busy while it was slicing.
Unless OctoPrint just started using Tornado in the last 4-5 years, maybe it was Twisted or something else that I was thinking of. I was positive that there was a limit in the number of simultaneous tasks that OctoPrint could do…and by simultaneous, I mean at the exact same time in different threads in different cores.
That’s true. OctoPrint proper can only use one core most of the time even though it has multiple threads. This is due to Python’s GIL (Global Interpreter Lock).
Yes. And only one core will be busy with the slicer (CuraEngine) and another will be running the python process that is Octoprint and it’ll be in the low single digits of a percent since it will likely have nothing to do while it is waiting for the slicer.