[Dprglist] Multi-threading on multi-cores

[Chris N]

Murray,

My 2 cents  regarding 
“I wonder if anyone on the DPRG mailing list has any experience with the Orange Pi or NanoPi boards they'd like to share”
“…running a multi-threaded Python application on eight cores means you get real multi-threading rather than simulated multi-threading”
“…a subsumption architecture for a robot OS in multi-threaded Python”


• I think that an easy to use reusable Python-based framework for implementing subsumption could be something that other Python fans would want to see and use.  That said, I would not worry too much about multi-threaded vs not and multi-core vs single-core.  Instead, your first priority should be the user experience, where the “user” in this context is the Developer, i.e. you and potentially others.    What APIs and abstractions should your framework provide, so that your subsumption logic is easier to create, read and debug?

• I only have experience with the Raspberry Pi series of boards and BeagleBone Black.   That said, I think they are all equally (ill) suited for robotics.   Sure, you get a ton of compute power and memory for very little money, but you usually get almost none of the I/O you need.   The BeagleBone Blue is maybe a notable exception, but still only a “nice try” since its built-in DC motor drivers are underpowered and the the A2D inputs only tolerate 1.8V.

• Apart from the lack of built-in rugged I/O,  the power consumption of most of these boards is also not that great (maybe less of an issue on larger robots; but definitely an issue for bolting one onto a 3pi which is powered from 4xAAA).   

• In addition, the lack of “instant on” – “instant off” is annoying.   Yes it is possible to bring boot time on Linux way down, and I have experience in doing this, but you give up a ton of flexibility.

• Of course our hardware should be powerful enough so we don’t get bogged down by having to optimize code all the time, and so that we can afford to run Python and whatever else we need to be productive. But unless you are into ROS,  image processing, 360deg spinning Lidar or all of the above at the same time,  you won’t be able to really take full advantage of more than 2 cores.   

• Do not make your application logic too dependent upon specifics of the underlying hardware platform – in this context: presence or absence of multiple cores.   

• Of course you know this already, so just a reminder: Multiple cores and hence multiple threads actually running truly in parallel can get you into trouble quickly if you are not careful.    On a single core, any given thread can make the assumption that no other lower-priority thread will “interrupt” the currently running thread.   With multiple cores, you can have situations where lower-priority threads access the same data literally at the same time, so more explicit synchronization is needed.  


From: Murray Altheim via DPRGlist
Sent: Monday, October 19, 2020 6:22 AM
To: dprglist at lists.dprg.org
Subject: [Dprglist] Multi-threading on multi-cores


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.dprg.org/pipermail/dprglist-dprg.org/attachments/20201019/b80004b7/attachment.html>