On Tue, Nov 25, 2014 at 8:24 PM, Sébastien Bourdeauducq <s...@m-labs.hk> wrote: > In addition to a lack of support for custom classes, there are lots of > corner cases with JSON which are potential stumbling blocks when > writing or using controllers: dictionary keys are turned into strings, > tuples into lists, etc. That would make RPC far from transparent.
RPC will never be transparent if you pass mutable objects. > To clean up all those special cases, and support custom classes, the > required amount of annotation/encapsulation is substantial and makes the > wire protocol ugly and the transform code about as complex as writing a > new parser (how to handle a Numpy array which is an element of a tuple > which is a value of a dictionary keyed by integer tuples?). Prohibit that then. Sounds like people will stumble over the problem of mutable objects or their own custom classes before they hit this. > On the other hand, PYON is quite straightforward and writing a parser in > those languages that have flex/bison-like tools should not be a big deal > - it's more or less the same level of complexity as the "calculator" > example that comes with many beginner tutorials for such tools. I can > provide a grammar definition file if that helps. An implementation in Matlab, Mathematica, Origin... would be the required, not just the grammar. They all have JSON already. > The inline transform turns all kernels into one big function and does > the writeback only once at the end (not everytime an attribute is > written - they reside as local variables in the meantime), so the > overhead should be small. Otherwise, yes, it would be quite > straightforward to add writeback exclusion support. Looking at the call (of a kernel from a non-kernel) itself the overhead of write-back is likely to be the dominant one once compilations are cached. > What is more concerning are the consequences of turning everything into > one big function - doing so enables the interleave transform to work > properly across functions and permits certain optimizations, but it > restricts the use of "return" (as it cannot branch to the calling > function anymore) and may increase code size. Hmm. Yes. Would the following behaviour help/be possible? * the interleaving pass forces inlining when in (possibly indirect) parallel context * otherwise let llvm inline according to its own heuristics (which I presume it has) Would the scoping of variables/attributes be a problem here? On Tue, Nov 25, 2014 at 8:39 PM, Sébastien Bourdeauducq <s...@m-labs.hk> wrote: > On 11/26/2014 11:24 AM, Sébastien Bourdeauducq wrote: >> The inline transform turns all kernels into one big function and does >> the writeback only once at the end > > There is still the problem that if you RPC from a kernel a function that > reads attribute modified by the kernel, you get the old values. > Similarly, if the RPCd function modifies the attributes, the kernel will > not see the updated values. And mutable objects as arguments. > What I propose is that: > 1) in a RPCd function, reading attributes modified by a kernel and > modifying attributes read by a kernel is not permitted. > 2) if synchronization of attributes between a kernel and a RPCd function > is necessary, the kernel should use RPCs to call setter/getter functions > for those attributes. Yes. As hinted above RPC will be different from local calls. I would just assume RPCs can not have (local) side effects, just their return value. Same for kernel invocation. This also sounds more like the common interpretation of RPC. That however would make more powerful return values from kernels a nice feature (tuples, dicts). -- Robert Jordens. _______________________________________________ ARTIQ mailing list https://ssl.serverraum.org/lists/listinfo/artiq
