There are alternative ways to orchestrate your API. Given the always-on-duty nature of your microagents and the fact that (once configured and mapped into the software as a useable description) it is helpful that your information propagators are persistent (oscilloscope A measures properties prop1..N and analyzes behaviours analysis1..N). You may find it useful to think about minimizing the real time work of the app, trading some real time activity for work done both before and after scanning, scooping and styling the datastream. Organizing the app to keep even small self-contained stages of action or reflection very loosely coupled and choosing types/structures to ease specific subtasks also may help.
On Sunday, March 27, 2016 at 9:51:18 AM UTC-4, Jeffrey Sarnoff wrote: > > Assuming your handshaking and signal management is keeping information > available in some easy to discern and decode manner and you are not pushing > latency issues, Julia should be a good platform for that. Compilation time > usually is not a concern -- and you can make your package autoprecompile > (which it will do when loaded the first time and after alteration). If you > pay attention to the general guidelines here performance tips > <http://docs.julialang.org/en/release-0.4/manual/performance-tips/> and this > note (still quite useful) > <http://www.juliabloggers.com/fast-numeric-computation-in-julia-2/>, see > how Ian Dunning improved this code > <http://stackoverflow.com/questions/30447286/how-can-i-improve-the-performance-of-my-julia-program-for-excellent-numbers> > and > use the Devectorize package <https://github.com/lindahua/Devectorize.jl> if > you find yourself writing that sort of code. > > > > On Sunday, March 27, 2016 at 8:34:31 AM UTC-4, Oliver Schulz wrote: >> >> Hello, >> >> I'm designing a scheme to control and read out hardware devices (mostly >> lab instruments) via Julia. The basic idea is that each device type is >> characterized by a set of features/properties that have a value type and >> dimensionality and that can be read-only or read/write (a bit like SCPI or >> VISA, conceptually). >> >> Features/properties would be things like "InputVoltage" for a multimeter, >> "Waveform", "TriggerLevel", etc. for an oscilloscope, and so on. They would >> be represented by (abstract or singleton) types. Obviously, certain >> features would be supported by many different device classes. >> >> For the API, I was thinking of an interface like this: >> >> current_feature_value = mydevice[SomeDeviceFeature] >> mydev[SomeDeviceFeature] = new_feature_value >> >> resp. things like >> >> mydev[SomeMultiChannelFeature, channel] >> >> for feature with multiple instances (e.g. in muli-channel devices). The >> implementation would, of course, be >> >> getindex(dev::SomeDeviceType, ::Type{SomeDeviceFeature}) = ... >> setindex!(dev::SomeDeviceType, value, ::Type{SomeDeviceFeature}) = ... >> >> etc. This would mean having a large number of classes for all features >> (let's say around 200), and an even larger number of methods ( >> O(number_of_device_classes * typical_number_of_features_per_device), let's >> say around 5000) for getindex and setindex!. Can Julia handle this, or >> would this result in long compile times and/or bad performance? >> >> An alternative would be, of course, to represent each feature by a >> specific set of methods like "trigger_level_set, "trigger_level_get", etc. >> However, I like the idea of representing a device feature as something that >> can be passed around (possibly between hosts). Also, there may be other >> feature operations beyond a simple set and get, which would many several >> functions for each feature. >> >> Any insights? >> >> >> Cheers, >> >> Oliver >> >
