Re: [4diac-dev] 回复: CSinglyLinkedList improvements

[Alois Zoitl <alois.zoitl@xxxxxx>]

On Mon, 2022-05-02 at 14:24 +0200, Davor Cihlar wrote:
> 
> On 4/29/22 11:31, Jörg Walter wrote:
>  
> > On 2022-04-29 11:03, alois.zoitl@xxxxxx wrote: 
> >  
> > > On Fri, 2022-04-29 at 10:32 +0200, Davor Cihlar wrote: 
> > >  
> > > > So there are no more platforms that doesn't support STL? 
> > >  
> > >  AFAIK no. But up to now I'm personally considering STL mostly for new code. Haven't yet found time and need to rework the existing code. 
> >  
> >  Given that we are about to move beyond C++11, STL is a required dependency anyway. Even when targeting a freestanding C++11 implementation on
> > microcontrollers, there are libraries out there that provide lightweight implementations of the more common STL parts. Not that I would expect this to work
> > out-of-the-box, AFAIK such small targets haven't been tested for a while. 
> My colleague recently tested something on STM32 and it appeared to have some potential, but it had unreliable ethernet interface so he aborted further work on
> that hardware and we're currently waiting for our own custom hardware.
> > >  
> > > > Has anyone considered boost? I know it's often times avoided, but it has some more embedded friendly implementations. I.e. lists with static allocation.
> > > > But I 
> > > >  never had an opportunity to work with it so I don't have any experience with it. 
> > >  we use boost for the test framework. But never looked beyond that. 
> >  
> >  In C++11, there is std::pmr::*, that would be a boost-less alternative to more controlled memory management for constrained targets. Even just some
> > strategically placed vector::resize calls could eliminate any problems that might exist -- and like Alois I doubt that there is a problem in the first
> > place. Don't optimize prematurely, i.e. until you have shown (measured) there is actually a problem. 
> I didn't know for std::pmr::*. I only saw some "DIY" allocators that others have made. So thank you for that. :)
> My only concern are embedded devices without an MMU. I don't know (yet? :)) how internals of Forte work and how those lists are used. If the memory
> fragmentation is an actual concern then it would limit the possibilities of an embedded device and a lot of memory would just be unused (to allow headroom on
> heap).

we mostly build up these lists on deployment and most of them are not changed during normal operation.


> But if most lists need only a few elements, then everything would be allocated at startup and no reallocations would occur and that would be completely fine
> with an ordinary std::vector.

Even if you constantly change elements in the lists std:list has especially for embedded systems a much worse performance and memory overhead. You have two
pointers (e.g. 32Bit each) overhead for the next and prev and all the malloc overhead if you are allocating each list node individually. The std::vector is
growing much slower and needs only a few allocations. Therefore you don't have that malloc overhead. 

I used 4diac FORTE on rather samll embedded systems (e.g., 64k RAM) and the malloc overhead is somthing that you most not neglect. So working with lists you
need your own node pool. Which again is not fun. 

As stated my goal for 4diac FORTE would be to replace more lists with vectors and see where we are getting. 


> So my suggestion for static allocation is only for parts of Forte that are expected to run on embedded devices and only if it poses a thread of memory
> fragmentation.
> 
> But on the other hand, statically allocated lists also guarantee memory consumption. With them you can exactly know how much memory is needed. It can also
> increase application robustness.
> I do understand that it can complicate things quite a bit, and it also seems like Forte is not exactly designed for embedded device. It's just a nice
> possibility to be able to run it on them. So I guess I just need to wait for that hardware to arrive and collect some experiences with how demanding Forte on
> embedded actually is.
> 
>  
> >  
> >  
> >  
> > >  
> > > > I also have some other suggestions: 
> > > >    * use std::thread and synchronization mechanisms from STL, that can be ported to embedded devices with not too much effort 
> > >  Here I'm not sure. It definitly is worth a look. But I have no experience about it. 
> >  
> >  I think this will not be practical, due to the very different RTOSes that FORTE supports. 
> >  
> >  An example from personal experience: For FreeRTOS, there is a C++11 compatibility library out there that would allow this, but std::thread depends on
> > thread-local storage. That needs explicit support from all of: device, toolchain, C library, and RTOS. In FreeRTOS, each and every board has a different
> > approach to TLS, often none at all. The C library (newlib, picolibc, ...) must have matching support code, and the compiler must use the same mechanism. 
> I did that once from scratch for STM32+FreeRTOS, and I don't remember it being it too hard to do. But I didn't support the whole standard. Only thread, mutex,
> chrono, and a few other minor things. I've made std::thread to act like the real one and it didn't require TLS. To support stack size I needed to add
> specialized functions, outside of C++ standard. I can imagine implementing condition variables would be a pain, and especially on many different platforms,
> but the question is if it's really needed. Currently Forte uses semaphores instead.
> So I'm suggesting using std::mutex and other constructs just as simple wrappers for OS. It would be just like it's currently implemented, but with a different
> namespace and class names (the C++11 standard ones).
> A developer only needs to be aware that if a code needs to run on embedded devices then only a subset of C++11 threading features can be used. Or do you thing
> it would be too confusing?
> _______________________________________________
> 4diac-dev mailing list
> 4diac-dev@xxxxxxxxxxx
> To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/4diac-dev