Great talk. I amCurious about the potential con's of shared memory model. I understand all the pro's, and was going to ask about the perf hit of not sharing memory. But this was the first question asked. It does seem like a potential blocking point for some people to adopt this model. Unless there is a work around for sharing memory - outside of just not using the component model. When you look at rust, people always like to bring up zero copy. And in a world where many of these components are running and sharing/passing data - copying into a share nothing architecture could be a huge perf hit. You could make perf critical code all in the same component - but that can kind of misses the point. The pro's for shared nothing is huge for security concerns. Sandboxed environments that execute safely. It also makes it much easier for components to plug and play / connect with one another in shared nothing (imo). Great work though and great talk.
As the author mentioned, the workaround for sharing memory is to use resources. Resources also take care of "lifetimes", by providing borrowing, as well as ownership transfer. Its also how native memory is provided to wasm guests (eg: mmap of a file or opengl buffer). The default of shared-nothing is useful because the representation of types may not be the same between different languages. A C++ array of 3 floats is different from a python or js list of 3 numbers.
I would love to find out where this fits on the capability systems heirarchy e.g. how close it is to the model offered to javascript. Are parameters always data, or can I pass encapsulated functions? Does it have native eq - can a caller tell when it is passed the same value twice?
Great talk. I amCurious about the potential con's of shared memory model. I understand all the pro's, and was going to ask about the perf hit of not sharing memory. But this was the first question asked. It does seem like a potential blocking point for some people to adopt this model. Unless there is a work around for sharing memory - outside of just not using the component model. When you look at rust, people always like to bring up zero copy. And in a world where many of these components are running and sharing/passing data - copying into a share nothing architecture could be a huge perf hit. You could make perf critical code all in the same component - but that can kind of misses the point.
The pro's for shared nothing is huge for security concerns. Sandboxed environments that execute safely. It also makes it much easier for components to plug and play / connect with one another in shared nothing (imo). Great work though and great talk.
As the author mentioned, the workaround for sharing memory is to use resources. Resources also take care of "lifetimes", by providing borrowing, as well as ownership transfer. Its also how native memory is provided to wasm guests (eg: mmap of a file or opengl buffer).
The default of shared-nothing is useful because the representation of types may not be the same between different languages. A C++ array of 3 floats is different from a python or js list of 3 numbers.
Great talk
good talk, thanks. I learned a lot :)
Amazing talk, very well explained in simpler words, thanks a lot for it!
He explains well, he also should have used diagrams to explain unshared memory part. But thankx
can we get the slides?
I would love to find out where this fits on the capability systems heirarchy e.g. how close it is to the model offered to javascript. Are parameters always data, or can I pass encapsulated functions? Does it have native eq - can a caller tell when it is passed the same value twice?