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
>
