Re: [ARTIQ] scans and generators on core device?
On 2017-10-19 16:36, Slichter, Daniel H. (Fed) via ARTIQ wrote: Judging from the absence of replies to this email, we will not support generators on the core device nor MultiScanManager. My main question with this is about time efficiency -- if you were to go to the effort to support this on the core device, will it end up taking a lot longer (i.e. processor slack) than the current way of just passing a list to the kernel which it can step through to scan something? Slightly slower for integer-only (after optimization) scans, and quite a bit slower for FP scans, than just traversing the list. However, compiling and loading very large lists as parts of kernels is slow, so there's a spectrum from 1-10 steps (unrolled list is clearly better) to 10,000-100,000 steps (generators are clearly better), with some mixture of these in between. -- Peter Zotov ___ ARTIQ mailing list https://ssl.serverraum.org/lists/listinfo/artiq
Re: [ARTIQ] ARTIQ implementation
On Thursday, September 29, 2016 10:28 AM, Trung Nguyen wrote: The target is incorrect. It was "or1k-unknown" but I read the note in released manual as below: We’re using an |or1k-linux| target because it is necessary to enable shared library support in |ld|, not because Linux is involved. from this link: https://m-labs.hk/artiq/manual-release-2/installing_from_source.html#install-from-source So I tried to change the target to "or1k-linux" but it does work. The note about using the or1k-linux target only refers to building binutils, as it is a workaround to its undesirable behavior. Everything else uses the target or1k-unknown as it is the correct one. -- Peter Zotov ___ ARTIQ mailing list https://ssl.serverraum.org/lists/listinfo/artiq
[ARTIQ] Storage for static experiments
Hello, In the spec for device storage, there is this item: 4. Storage on the core device. The following items shall be implemented: * Storage for static experiments. What does it mean? -- Peter Zotov ___ ARTIQ mailing list https://ssl.serverraum.org/lists/listinfo/artiq
[ARTIQ] New compiler announcement
Hi all, I have recently landed a new compiler for the ARTIQ Python dialect. The major improvement it brings is diagnostics; the goal is to ensure that no programmer error would result in a compile-time (unhandled exception in ARTIQ) or run-time (memory corruption) crash, but rather display a useful, human-readable diagnostic at compile time and raise an exception at run-time. It also recognizes a much larger subset of Python without degradation of performance via judicious use of an ML-style type system, e.g. closures are now supported as long as they do not escape their parent function, and the compiler verifies that they indeed do not, or rejects the code. Some other changes I'd like to highlight: * Nested lists are supported everywhere. * Extended slices (e.g. `x[1:5:2]`) are supported. * Strings can be passed to RPCs. * print() now prints into core device log, not host console; it is much faster but limited by ringbuffer size. * The 'assert' statement has gained much functionality; in an expression like `assert h() == 1 and g() == []`, when an assertion failure is detected, the values of h() and g() will be printed into core device log. In practice, of course, any large feature will contain bugs. Thus I ask everyone to test their existing code on the new compiler and otherwise stretch its limits. Currently known deficiencies: * Conda package for Windows are not yet updated. * Loop unrolling (for interleaving) does not yet work. * It is possible to cause memory corruption via infinite recursion. -- Peter Zotov ___ ARTIQ mailing list https://ssl.serverraum.org/lists/listinfo/artiq
