After a post in the new sdk thread I intended to have a "quick look" at the shared memory stuff and offer a critique but I now realise it will take much more work than that - work that would be better spent just rewriting it and most of the memory handling in elib/ehal.
So instead i'll ask just what is it meant to be for?
Looking at the code, I can see some hints. It seems to be for persistent multi-process access, and it also seems to be for simple named buffer sharing between a workgroup and it's host, but ...
(i realise i'm mixing implementation and interface details here, but it's all i've got to go on here).
o It's not useful as a multi-(linux)process resource management scheme because it has no namespaces and refcounting can't be made reliable in this context.
o It's not useful as a general purpose dynamic memory allocator because it's only got 64 slots and allocations have a massive overhead (something like 300+ bytes per allocation). The compiler can already do static allocation and if e-hal exposed symbolic lookup that would cover most use cases.
o It's not useful as a multi-library resource management scheme because it has no namespace stuff.
o There's no allocation access on-core.
o It's not very efficient.
I presume it should however do or be all of those things, depending on the first point (i.e. is it supposed to support two or more separate linux processes sharing the epiphany as a resource, perhaps concurrently - although we know of course this is impossible with the current sdk in the general case).
To be honest i had a bit more of a think about it while this was sitting here and the api as is has got a pretty hard time justifying it's existence to begin with. The closest thing I can think of to it is sysv shared memory segments (and does anyone outside of maybe oracle use that horrible stuff anymore?) or shared memory files which are of very limited "system-type" use. Surely just passing pointers (relative to epiphany-space) around is more familiar/flexible/efficient than trying to rendezvous on blocks by name. e.g. in ezesdk i just have a "malloc" which returns both a host pointer and an epiphany pointer pair which can both be used naturally on each respective end.
On a related note I just don't see the point of the memory-as-object abstraction. It's rather confusing and bulky and inefficient. Given the already high cognitive load of dealing with concurrent hardware and the lack of on-core space, these all seem to be big negatives for the maybe-chance of some weak "type and array bounds safety" at runtime.
"shared memory" interface.
by notzed » Tue Dec 02, 2014 11:45 pm
- notzed
- Posts: 331
- Joined: Mon Dec 17, 2012 12:28 am
- Location: Australia
) 
