Revision history [back]

I believe #q230972 explains it quite well, but to phrase that answer differently: node graph participants in ROS can be mapped onto either processes or threads. When mapped onto processes we call them nodes. When mapped onto threads they're called nodelets.

Since nodes are computing processes

Well, nodes are, but not all participants in a nodegraph would have to be (as they could be nodelets), so your statement is not entirely true.

Could someone please provide a simple example to understand nodelets and why they are useful when we have got nodes already?

Processes on many OS are typically isolated from each other (memory, cpu, etc). That is a good thing, but also hinders things like communication, in which you need to cross a number of boundaries in order to exchange information.

The separated address spaces of nodes in particular prevent two nodes from directly accessing each others data (ie: memory) and also from making any assumptions about the layout of data structures in the memory of another node (again: a good thing). These two constraints (but there are more) require that the sending process first transforms whatever it wants to send to some other process into a shared, well-known representation. The other side can then reconstitute the message inside its own address space in the correct form. This process is called (de)serialisation.

The problem with that is that it is slow. So much so that for larg(e)(ish) messages (typicall anything above the L1 cache size of your cpu) the time spend on (de)serialisation can actually start to dominate the time it takes to send and receive a message. It would be nice if we could avoid (de)serialising messages all together, but due to the isolation that processes 'enjoy', we can't.

Enter nodelets: threads by definition share a single address space (as they live in a single process), which basically means that they share each other's memory. This completely removes the need for (de)serialisation and thus the overhead incurred by that process and makes it possible to exploit something called zero-copy data-transfer, which in this case comes down to exchanging pointers to message objects instead of copying message objects.

Using shared-memory between nodes is actually also possible, but requires some changes to your configuration. A package that makes this possible is ethzasl_message_transport.

I believe #q230972 explains it quite well, but to phrase that answer differently: node graph participants in ROS can be mapped onto either processes or threads. When mapped onto processes we call them nodes. When mapped onto threads they're called nodelets.

Since nodes are computing processes

Well, nodes are, but not all participants in a nodegraph would have to be (as they could be nodelets), so your statement is not entirely true.

Could someone please provide a simple example to understand nodelets and why they are useful when we have got nodes already?

Processes on many OS are typically isolated from each other (memory, cpu, etc). That is a good thing, but also hinders things like communication, in which you need to cross a number of boundaries in order to exchange information.

The separated address spaces of nodes in particular prevent two nodes from directly accessing each others data (ie: memory) and also from making any assumptions about the layout of data structures in the memory of another node (again: a good thing). These two constraints (but there are more) require that the sending process first transforms whatever it wants to send to some other process into a shared, well-known representation. The other side can then reconstitute the message inside its own address space in the correct form. This process is called (de)serialisation.

The problem with that is that it is slow. So much so that for larg(e)(ish) messages (typicall anything above the L1 cache size of your cpu) the time spend on (de)serialisation can actually start to dominate the time it takes to send and receive a message. It would be nice if we could avoid (de)serialising messages all together, but due to the isolation that processes 'enjoy', we can't.

Enter nodelets: threads by definition share a single address space (as they live in a single process), which basically means that they share each other's memory. This completely removes the need for (de)serialisation and thus the overhead incurred by that process and makes it possible to exploit something called zero-copy data-transfer, which in this case comes down to exchanging pointers to message objects instead of copying message objects.

Using shared-memory between nodes is actually also possible, but requires some changes to your configuration. A package that makes this possible is ethzasl_message_transport.

I believe #q230972 explains it quite well, but to phrase that answer differently: node graph participants in ROS can be mapped onto either processes or threads. When mapped onto processes we call them nodes. When mapped onto threads they're called nodelets.

Since nodes are computing processes

Well, nodes are, but not all participants in a nodegraph would have to be (as they could be nodelets), so your statement is not entirely true.

Could someone please provide a simple example to understand nodelets and why they are useful when we have got nodes already?

Processes on many OS are typically isolated from each other (memory, cpu, etc). That is a good thing, but also hinders things like communication, in which you need to cross a number of boundaries in order to exchange information.

The separated address spaces of nodes in particular prevent two nodes from directly accessing each others data (ie: memory) and also from making any assumptions about the layout of data structures in the memory of another node (again: a good thing). These two constraints (but there are more) require that the sending process first transforms whatever it wants to send to some other process into a shared, well-known representation. The other side can then reconstitute the message inside its own address space in the correct form. This process is called (de)serialisation.

The problem with that is that it is slow. So much so that for larg(e)(ish) messages (typicall (typically anything above the L1 cache size of your cpu) the time spend on (de)serialisation can actually start to dominate the time it takes to send and receive a message. It would be nice if we could avoid (de)serialising messages all together, but due to the isolation that processes 'enjoy', we can't.

Enter nodelets: threads by definition share a single address space (as they live in a single process), which basically means that they share each other's memory. This completely removes the need for (de)serialisation and thus the overhead incurred by that process and makes it possible to exploit something called zero-copy data-transfer, which in this case comes down to exchanging pointers to message objects instead of copying message objects.

Using shared-memory between nodes is actually also possible, but requires some changes to your configuration. A package that makes this possible is ethzasl_message_transport.