klickverbot has quit [Read error: Connection reset by peer]
klickverbot_ has quit [Read error: Connection reset by peer]
klickverbot has joined #m-labs
klickverbot has quit [Read error: Connection reset by peer]
klickverbot has joined #m-labs
klickverbot has quit [Read error: Connection reset by peer]
klickverbot has joined #m-labs
klickverbot has quit [Read error: Connection reset by peer]
klickverbot has joined #m-labs
fengling has joined #m-labs
klickverbot has quit [Read error: Connection reset by peer]
klickverbot has joined #m-labs
klickverbot has quit [Read error: Connection reset by peer]
klickverbot has joined #m-labs
klickverbot has quit [Read error: Connection reset by peer]
klickverbot has joined #m-labs
klickverbot_ has joined #m-labs
klickverbot has quit [Ping timeout: 252 seconds]
klickverbot_ has quit [Read error: Connection reset by peer]
klickverbot has joined #m-labs
<sb0>
ns3 is fixed
klickverbot has quit [Read error: Connection reset by peer]
<sb0>
whoa, Smiths Connectors finally answered my rfq
<sb0>
amazing
klickverbot has joined #m-labs
klickverbot has quit [Ping timeout: 250 seconds]
klickverbot has joined #m-labs
sb0 has quit [Quit: Leaving]
klickverbot has quit [Read error: Connection reset by peer]
klickverbot has joined #m-labs
rohitksingh_work has joined #m-labs
<whitequark>
sb0: I've implemented the now pinning
<whitequark>
remarkably that had absolutely no effect on test_pulse_rate_dds
<whitequark>
looking further, it looks like the test is measuring something weird.
<whitequark>
specifically, right now there is a bunch of soft-FP hoisted into the while loop header
<whitequark>
if I move it out to the function entry block, the test reports a higher pulse rate (lower result)
<whitequark>
this seems wrong (even if that hoisting should happen for unrelated reasons)
<whitequark>
can you confirm my finding that the test is not measuring what it should?
* whitequark
-> zzz
klickverbot has quit [Ping timeout: 250 seconds]
<cr1901_modern>
whitequark has the best idea. Gaaaah, fuck America tonight.
fengling has quit [Ping timeout: 268 seconds]
sb0 has joined #m-labs
<sb0>
whee, drtio led blinking
fengling has joined #m-labs
klickverbot has joined #m-labs
klickverbot has quit [Ping timeout: 250 seconds]
<sb0>
okay so the sustained DRTIO TTL pulse rate is 1.1us with this protocol and implementation
<sb0>
pulse rate unittest result is 5.56e-07
<sb0>
compared to 5.76e-07 on local rtio? wtf?
<sb0>
let me check older builds...
<sb0>
hm was 6.03e-07 on last passing build
<sb0>
whitequark, I don't confirm your finding. why do you think the test is wrong?
<sb0>
maybe we should look into loading kernels in block RAM. maybe partially with a "with hard_realtime:" block or something
<sb0>
some ARM cores have "tightly coupled memories" that are SRAMs directly into the CPU pipeline. LM32 has something similar iirc. but mor1kx doesn't have an equivalent
bentley` has quit [Remote host closed the connection]
bentley` has joined #m-labs
cr1901_modern has quit [Ping timeout: 256 seconds]
sb0 has quit [Ping timeout: 246 seconds]
bentley` has quit [Ping timeout: 258 seconds]
fengling has quit [Ping timeout: 268 seconds]
fengling has joined #m-labs
klickverbot has joined #m-labs
klickverbot has quit [Ping timeout: 252 seconds]
<whitequark>
sb0: because I don't think it measures the DDS pulse rate, but something else entirely.
<whitequark>
loading kernels into BRAM sounds nightmarish
<rjo>
i would also like to know whether it is not something in the memory controller/caching/cpu that leads to unreasonable slow downs.
<rjo>
whitequark: doesn't measure it because it the quantity is masked by FP? or because it does not factor in at all?
<whitequark>
hm, I think I understand it now
<whitequark>
I get these odd results because what the test measures is:
<whitequark>
a) the execution time of actual code in the tight inner loop (which is currently the minimal or close to)
<whitequark>
as in the code that is in the inner loop after optimization
<whitequark>
b) the execution time of soft-FP operations hoisted out of the inner loop into the outer loop, amortized over all iterations of the inner loop
<whitequark>
this is actually correct and representative of real-world workloads
<GitHub130>
[artiq] whitequark created now-as-ssa (+1 new commit): https://git.io/vXgm8
<GitHub130>
artiq/now-as-ssa 1b9236f whitequark: now as SSA (WIP)
fengling has quit [Ping timeout: 268 seconds]
klickverbot has joined #m-labs
sandeepkr has quit [Ping timeout: 268 seconds]
klickverbot_ has joined #m-labs
klickverbot has quit [Ping timeout: 250 seconds]
klickverbot_ has quit [Ping timeout: 248 seconds]
sb0 has joined #m-labs
sandeepkr has joined #m-labs
rohitksingh_work has quit [Read error: Connection reset by peer]
cr1901_modern has joined #m-labs
<sb0>
whitequark, how does it not measure the dds programming time?
<whitequark>
sb0: above I meant it measures the dds programming time plus other unrelated things also
<whitequark>
but now I have realized they are not unrelated
<whitequark>
currently looking at what can be done to alleviate.
<whitequark>
klickverbot's constant propagation stuff seems relevant but not really enough...
klickverbot has joined #m-labs
klickverbot has quit [Ping timeout: 240 seconds]
<whitequark>
sb0: oh, I found another issue, which is that the kernel invariants LICM metadata is dropped by some pass.
<whitequark>
this should be an easy fix. let's see
klickverbot has joined #m-labs
klickverbot has quit [Ping timeout: 248 seconds]
rohitksingh has joined #m-labs
klickverbot has joined #m-labs
klickverbot has quit [Ping timeout: 260 seconds]
<GitHub13>
[artiq] whitequark pushed 1 new commit to master: https://git.io/vXg2v
<GitHub13>
artiq/master bfbdba9 David Nadlinger: compiler: Emit all-kernel_invariant objects as LLVM constants...
<whitequark>
feel free to rearrange the "next" queue as you see fit, I'll be grabbing the top one every time
<cr1901_modern>
rjo: https://github.com/m-labs/artiq/issues/615 Hrm... I should test the MiSoC version. I bet this had to do with the fact that the same buffer is used to shift in a read value and shift in a right value.
<cr1901_modern>
shift out* a write* value... bleh
klickverbot has joined #m-labs
klickverbot has quit [Ping timeout: 258 seconds]
klickverbot has joined #m-labs
klickverbot has quit [Ping timeout: 248 seconds]
klickverbot has joined #m-labs
<rjo>
cr1901_modern: yep. i had also seen that a while ago. this is independent of the csr stuff. and keeping a single register for read and write is also fine.
<rjo>
it just needs to be done right...
<cr1901_modern>
Well, I could definitely reproduce what he saw when working on the CSR port, but I concluded the same thing as you (that if the transfer is timed properly, the problem disappears). I was just wondering if that was a premature conclusion.
<cr1901_modern>
I.e. I came to the right conclusion (keeping a single register is fine) for the wrong reason (there was another bug I missed when analyzing the sim VCD files).
<rjo>
i do think that there's a bug. the last bit is wrong. and i haven't seen that the right timing resolves it. what resolves it is doing transfers smaller than the register width.
<rjo>
i.e. one could trivially add one bit to the register and then put writes into the part closer to mosi and take reads from the part closer to miso.
<whitequark>
sb0: uhm, I seem to have crashed the kc705 somehow
<whitequark>
oh nvm bad flash
<whitequark>
sb0: nope, the JTAG adapter has crashed *somehow*
<whitequark>
please reboot it
<klickverbot>
whitequark: Thanks for fixing up my PR. Imho, the documentation is still slightly misleading, as it doesn't mention that all attributes of an object have to be constant for my optimisation to kick in. Do you quickly want to fix it up or should I raise an issue/PR?
klickverbot has quit [Remote host closed the connection]
<whitequark>
sb0: can we give klickverbot commit rights?