01:46 <GitHub-m-labs> [artiq] sbourdeauducq commented on issue #1133: Note that the DACs are not properly synchronized with SC1:... https://github.com/m-labs/artiq/issues/1133#issuecomment-413069231

01:47 <GitHub-m-labs> [artiq] sbourdeauducq commented on issue #1133: Note that the DACs are not properly synchronized with SC1:... https://github.com/m-labs/artiq/issues/1133#issuecomment-413069231

03:16 <GitHub-m-labs> [artiq] sbourdeauducq commented on issue #1128: The current code isn't optimized (e.g. a lot of it is in plain - slow - interpreted Python), so it is certainly possible to speed it up. But someone has to study and implement the best ways to do it, it's not trivial. https://github.com/m-labs/artiq/issues/1128#issuecomment-413082027

03:18 <GitHub-m-labs> [artiq] sbourdeauducq commented on issue #1126: Other programs running on your machine - is this Windows? Network problems? Have you reproduced it with artiq_compile? https://github.com/m-labs/artiq/issues/1126#issuecomment-413082291

04:22 <GitHub-m-labs> [artiq] sbourdeauducq commented on issue #1080: @gkasprow What was the problem? Why was it not found when measuring the clocks? https://github.com/m-labs/artiq/issues/1080#issuecomment-413090264

04:25 <whitequark> rjo: rustup update nightly, then `cargo rustc -- --emit=asm -Z asm-comments`

04:26 <whitequark> it now has comments like: @DEBUG_VALUE: mask <- $r2

05:05 <whitequark> rjo: so I figured out what's happening

05:06 <whitequark> afaict, rust/llvm lift the x slice in macc() to an array, then read the entire array into an LLVM register, then legalize it into many architecture registers, then spill them because the architecture doesn't have so many of them

05:07 <whitequark> mark IIR::apply and FIR::update with #[inline(never)] and take a look at the assembly

05:07 <whitequark> I might be wrong but it looks much nicer from here

05:32 <whitequark> rjo: ok nevermind, I'm wrong

06:43 <whitequark> rjo: ok, I was *almost* right

06:43 <whitequark> what it does is not just reads the entire array into an LLVM register, but rather unrolls the loop

06:43 <whitequark> different path, same semantics

06:55 <whitequark> rjo: unfortunately, fixing this is really hard

06:55 <whitequark> not only doesn't rustc expose any knobs to tune the behavior of optimizer, but you probably *want* loop unrolling here

06:55 <whitequark> judging by the #[inline(always)], anyway

06:56 <whitequark> so the root cause is the optimizer having no insight into the register allocator, and there's no good fix for that

06:58 <whitequark> actually, I have an idea

07:01 <rjo> whitequark: right. i definitely want loop unrolling.

07:05 <rjo> whitequark: yes. inline=never on macc is more like the code i am looking for.

07:06 <whitequark> rjo: is this sufficient or should I continue looking?

07:07 <whitequark> code sinking didn't work on this code, but I have a few ideas left

07:07 <rjo> whitequark: not terribly important. the insight that is not my fault and that is is tricky to fix but should be fixable is good enough.

07:07 <rjo> whitequark: thanks a lot.

07:08 <whitequark> rjo: ack.

07:08 <whitequark> rjo: wait, you said inline(never) on macc

07:09 <whitequark> that will unnecessarily pessimize the code

07:09 <whitequark> rjo: what is the "width" "shift" and "offset" fields in FIR/IIR?

07:09 <whitequark> if you explain their semantics I think I can show you a way to write this that's nicer

07:09 <rjo> whitequark: yes. i tried inline(never) on macc _or_ on appply/update.

07:10 <rjo> both are ok-ish code. on macc it doesn't unroll the loop.

07:10 <rjo> and both are actually slower than the original code.

07:10 <whitequark> ah, amusing.

07:10 <whitequark> but that's to be expected

07:11 <whitequark> rjo: I imagine you want macc to be compile-time generic over width

07:12 <whitequark> you can't do that with const generics (because they don't exist) but you can do something with associated constants, to not rely on optimizer propagating that

07:12 <whitequark> though I guess not having width known at compile time isn't very expensive

07:12 <rjo> macc(y0, x, a, width, shift) = clip((y0 + dot(x, a)) >> shift, -(1<<mask), (1<<mask) - 1)

07:13 <rjo> whitequark: yes. const generics would be nice. but i can live fine without here.

07:15 <rjo> that's what macc is supposed to do.

07:16 <whitequark> rjo: http://play.rust-lang.org/?gist=745c41dd4161fbb2cbf066d0d5836a70&version=nightly&mode=debug&edition=2015

07:17 <rjo> hmm.

07:24 <rjo> whitequark: width can actually go away. it'll always be 16-1

09:32 <GitHub-m-labs> [artiq] jordens commented on issue #1133: @marmeladapk referring to your experiment above and assuming you are running this on a fresh boot (with the default values of accumulator auto clear), the phase of SAWG channel `n` should be `2*pi*f*(t + n*dt)` up to a common constant. With `f=7*MHz` and `dt=2*ms` and for all the frequency values you give above that phase is zero modulo `2*pi`. I.e. you for those values

15:44 <GitHub-m-labs> [artiq] jbqubit commented on issue #1126: No network problems that I've seen. Running Ubuntu with Linux kernel 4.15.0-30. ... https://github.com/m-labs/artiq/issues/1126#issuecomment-413239797

15:57 <GitHub-m-labs> [artiq] sbourdeauducq commented on issue #1126: They are not silently dropped, you get a compilation error if you attempt RPCs. https://github.com/m-labs/artiq/issues/1126#issuecomment-413243724

16:03 <GitHub-m-labs> [artiq] sbourdeauducq commented on issue #1126: Likely the "pauses" are in the compiler, or the rest of the Python program on the PC, or in your network. Try profiling artiq_run plus checking wireshark traces for problems. https://github.com/m-labs/artiq/issues/1126#issuecomment-413245542

16:27 <GitHub-m-labs> [artiq] jbqubit commented on issue #1126: @sbourdeauducq Have you tried my code? If you can't reproduce I'll look to a problem that's unique to my setup. https://github.com/m-labs/artiq/issues/1126#issuecomment-413253000

16:29 <GitHub-m-labs> [artiq] sbourdeauducq pushed 3 new commits to nix: https://github.com/m-labs/artiq/compare/ec97d636170f...0b1ce0ea3236

16:29 <GitHub-m-labs> artiq/nix 0b1ce0e Sebastien Bourdeauducq: nix: use original pyqtgraph and pyserial

16:29 <GitHub-m-labs> artiq/nix 487720d Sebastien Bourdeauducq: nix: remove sphinx (used for building doc, not running ARTIQ)

16:29 <GitHub-m-labs> artiq/nix 7003835 Sebastien Bourdeauducq: nix: update license

17:02 <GitHub-m-labs> [artiq] sbourdeauducq pushed 1 new commit to nix: https://github.com/m-labs/artiq/commit/73cf071b1a88dabcfead6e9c8b1536b4d49c1d09

17:02 <GitHub-m-labs> artiq/nix 73cf071 Sebastien Bourdeauducq: nix: update LLVM and llvmlite, remove clang (not needed for running)

18:05 <GitHub-m-labs> [artiq] jbqubit commented on issue #675: @hartytp Yes, this is funded. The contract calls for "SAWG monitoring and injection (sum only)." The detail is provided in the artiq-hardware writeup written with @jordens. [L195-6](https://github.com/m-labs/artiq-hardware/blob/1cec6224bfaf148cba14a5a1f69f537966d6887b/artiq_hardware.tex#L195)... https://github.com/m-labs/artiq/issues/675#issuecomment-413283781

18:50 <GitHub-m-labs> [artiq] vmsch commented on issue #1110: Sorry for the slow reply.... https://github.com/m-labs/artiq/issues/1110#issuecomment-413297439

19:40 <GitHub-m-labs> [artiq] hartytp commented on issue #675: @jbqubit in the original SU-servo contract I allocated funds for moninj support. However, on more detailed discussion with @jordens, it turned out that moninj support was going to be a lot more work than I'd anticipated. Discussing this with the other ARTIQ-users at Oxford, we agreed that, given the workflow we have in our experiments, SU-servo moninj wasn't going to be

19:52 <cr1901_modern> So I take it you like nix, sb0 :P

20:34 <GitHub-m-labs> [artiq] philipkent opened issue #1134: Connection reset by peer error breaks DDS/TTL panel https://github.com/m-labs/artiq/issues/1134

20:47 <GitHub-m-labs> [artiq] jbqubit commented on issue #801: This was funded 4/18/2017. The implementation detail is provided in the artiq-hardware writeup written with @jordens. [L245](https://github.com/m-labs/artiq-hardware/blob/1cec6224bfaf148cba14a5a1f69f537966d6887b/artiq_hardware.tex#L245) Here's a rendered version. ... https://github.com/m-labs/artiq/issues/801#issuecomment-413330645

21:56 <GitHub-m-labs> [artiq] jbqubit commented on issue #675: The only problem I'm aware of with moninj has to do with the GUI layout. An analysis of the resource consumption of moninj in a new Issue would help clarify the situation. https://github.com/m-labs/artiq/issues/675#issuecomment-413351007

23:58 <GitHub-m-labs> [artiq] sbourdeauducq commented on issue #1134: Is restarting the dashboard sufficient or do you *have* to restart the core device as well?... https://github.com/m-labs/artiq/issues/1134#issuecomment-413376935

23:58 <GitHub-m-labs> [artiq] sbourdeauducq commented on issue #1134: Is restarting the dashboard sufficient or do you *have* to restart the core device as well? Most certainly, you don't have to restart the master.... https://github.com/m-labs/artiq/issues/1134#issuecomment-413376935

23:59 <GitHub-m-labs> [artiq] sbourdeauducq commented on issue #1134: Is restarting the dashboard sufficient or do you *have* to restart the core device as well? Most certainly, you don't have to restart the master.... https://github.com/m-labs/artiq/issues/1134#issuecomment-413376935