4 ms·

Horses for courses. Async. architectures are great for distributed back-end systems (God I love making streaming data-science applications) ... but not so great

Horses for courses. Async. architectures are great for distributed back-end systems (God I love making streaming data-science applications) ... but not so great for on-the-metal embedded devices; where static & limited computational capacity & whole-system predictability requirements drive you in the opposite direction. I do a lot of machine vision stuff for embedded systems, and having everything driven by the drum-beat of a frame interval really does simplify things a lot; particularly when it comes to finding the absolute cheapest hardware that will be able to perform a given function.

tlarkworthy 13y ago
I read this awesome book and multi threading embedded systems. "Practical UML Statecharts in C/C++: Event-Driven Programming for Embedded Systems" The author has an amazing stack for psuedo real time scheduling on seriously limited hardware, http://www.state-machine.com/ http://www.state-machine.com/ . QP-nano brings async real time to PIC processors! So there really is little overhead for async architectures. I think async squeezes more out of limited hardware by avoiding busy loops waiting for IO or other synchronizations to align. I agree its more difficult to develop with async, but I strongly disagree going non-async saves you money on hardware
- w_t_payne 13y ago
  It's not really about the overhead. The intrinsic overhead of async. is trivial, anyway. It is more about predictability & how the system is understood. Async architectures let you have simple, easy-to-understand components, but the expense of a more complex macro-control-flow. Hardware and embedded guys spend a lot of time looking at storage 'scopes, and like things to be nice and periodic... it just fits in with the world-view a bit better. It is not so much that one is objectively better than the other, it is just about how different people's mentality works.

tlarkworthy 13y ago

I read this awesome book and multi threading embedded systems. "Practical UML Statecharts in C/C++: Event-Driven Programming for Embedded Systems" The author has an amazing stack for psuedo real time scheduling on seriously limited hardware, http://www.state-machine.com/ http://www.state-machine.com/ . QP-nano brings async real time to PIC processors! So there really is little overhead for async architectures. I think async squeezes more out of limited hardware by avoiding busy loops waiting for IO or other synchronizations to align. I agree its more difficult to develop with async, but I strongly disagree going non-async saves you money on hardware

w_t_payne 13y ago
It's not really about the overhead. The intrinsic overhead of async. is trivial, anyway. It is more about predictability & how the system is understood. Async architectures let you have simple, easy-to-understand components, but the expense of a more complex macro-control-flow. Hardware and embedded guys spend a lot of time looking at storage 'scopes, and like things to be nice and periodic... it just fits in with the world-view a bit better. It is not so much that one is objectively better than the other, it is just about how different people's mentality works.