sb0 changed the topic of #m-labs to: ARTIQ, Migen, MiSoC, Mixxeo & other M-Labs projects :: fka #milkymist :: Logs http://irclog.whitequark.org/m-labs
kuldeep has quit [Ping timeout: 246 seconds]
Gurty has joined #m-labs
kuldeep has joined #m-labs
fengling has joined #m-labs
ylamarre has joined #m-labs
fengling has quit [Ping timeout: 240 seconds]
fengling has joined #m-labs
ylamarre has quit [Quit: ylamarre]
evilspirit has joined #m-labs
rohitksingh has joined #m-labs
<GitHub69> [artiq] sbourdeauducq pushed 1 new commit to master: https://git.io/va50w
<GitHub69> artiq/master 799c2c7 Sebastien Bourdeauducq: runtime/i2c: more conservative timings
<bb-m-labs> build #475 of artiq is complete: Failure [failed python_unittest_1] Build details are at http://buildbot.m-labs.hk/builders/artiq/builds/475 blamelist: Sebastien Bourdeauducq <sb@m-labs.hk>
<whitequark> hm what happened now?
<whitequark> wire disconnected?
<sb0> probably
<sb0> btw we should receive the proper "bnc for ants" connector soon
<whitequark> good
<sb0> whitequark, did you sort out the compiler?
sandeepkr has joined #m-labs
rohitksingh has quit [Quit: Leaving.]
<GitHub14> [artiq] sbourdeauducq pushed 2 new commits to master: https://git.io/va5Kc
<GitHub14> artiq/master 120db8b Sebastien Bourdeauducq: protocols/pipe_ipc: raise line length limit
<GitHub14> artiq/master 168113c Sebastien Bourdeauducq: protocols/pc_rpc: support dynamic target creation
<GitHub22> [artiq] sbourdeauducq pushed 1 new commit to release-1: https://git.io/va5KC
<GitHub22> artiq/release-1 bbef353 Sebastien Bourdeauducq: protocols/pipe_ipc: raise line length limit
<bb-m-labs> build #476 of artiq is complete: Failure [failed python_unittest_1] Build details are at http://buildbot.m-labs.hk/builders/artiq/builds/476 blamelist: Sebastien Bourdeauducq <sb@m-labs.hk>
FabM has quit [Quit: ChatZilla 0.9.92 [Iceweasel 38.7.0/20160308234001]]
FabM has joined #m-labs
acathla has quit [Changing host]
acathla has joined #m-labs
_rht has joined #m-labs
<sb0> bb-m-labs, force build pyqtgraph
<bb-m-labs> build #5 forced
<bb-m-labs> I'll give a shout when the build finishes
<bb-m-labs> Hey! build pyqtgraph #5 is complete: Success [build successful]
<sb0> bb-m-labs, force build pyqtgraph
<bb-m-labs> build forced [ETA 19 seconds]
<bb-m-labs> I'll give a shout when the build finishes
<bb-m-labs> Hey! build pyqtgraph #6 is complete: Success [build successful]
<_florent_> sb0: do you remember why this limitation is here?: https://github.com/m-labs/migen/blob/master/migen/fhdl/simplify.py#L78
<sb0> _florent_, not sure. does it work if you remove the raise?
<sb0> including with the simulator
<_florent_> I'm converting the simulation of my cores with the simulator, I'm going to test that
fengling has quit [Ping timeout: 240 seconds]
evilspirit has quit [Ping timeout: 250 seconds]
evilspirit has joined #m-labs
fengling has joined #m-labs
bb-m-labs has quit [Quit: buildmaster reconfigured: bot disconnecting]
evilspirit has quit [Ping timeout: 244 seconds]
bb-m-labs has joined #m-labs
<whitequark> rjo: FYI I added a firewall since there are some services exposed on lab. (cups, sane) that are probably insecure
<whitequark> /etc/iptables.conf /etc/ip6tables.conf
<sb0> rjo, do you have code to do a 2D Gaussian fit with numba (or something equally fast)?
<sb0> i think i'll have to declare automatic column layout in qt unusable
<sb0> it's ridiculously slow, in addition to the bugs
<sb0> that is, unless whitequark or evilspirit fixes it...
<sb0> it takes hundreds of ms to update one value in a 8x3 table
<whitequark> are you sure that's not python?
<sb0> self.table.header().setSectionResizeMode(QtWidgets.QHeaderView.ResizeToContents) -> makes it ridiculously sluggish
ylamarre has joined #m-labs
<sb0> without it, it's fine
<sb0> also, if the modified items are not being displayed (e.g. they are children of a folded QTreeView) then the speed is also OK
<sb0> so yes, it does look like a Qt bug
<whitequark> no, I don't think so
<whitequark> it has to do a roundtrip to the table model, right?
<whitequark> every time it reads a cell?
<sb0> yes, and when using a model that simply returns empty data, it's also slow
<whitequark> exactly
<whitequark> because what's slow is the calls to python. not qt layout code.
<whitequark> the baseline latency of a call into python is several orders of magnitude higher than an equivalent call into C++
<sb0> but the python code does nothing
<whitequark> yes
<whitequark> invoking the interpreter is expensive enough already
<sb0> and it that's the case, then this feature is unusable with pyqt
<whitequark> yes
<whitequark> binding GUI libraries to dynlangs is a stupid idea that barely works
<sb0> and why doesn't qt cache things anyway?
<whitequark> because this is not a problem in qt
<sb0> and I'm not convinced the problem is really slow python
<whitequark> profile it.
<whitequark> $ perf top -p PID
<whitequark> the cost of fetching data from a C++ array is ~dozens of instructions
<whitequark> the cost of calling an empty python function is ~thousands
<sb0> 52% python, 18% sip.so which is also pyqt stuff
<whitequark> yep.
<sb0> but even with a 2-3x speedup it'll still be too slow
<whitequark> do I need to demonstrate that the equivalent C++ code works quickly?
<sb0> how can it_
<sb0> ?
<whitequark> ok...
<whitequark> 8x3 table?
<whitequark> eight by three?
<whitequark> not eight thousand by three?
<sb0> yes
<whitequark> what
<sb0> actually it's not a table, it's a QTreeView. but the same bug is present with the log
<sb0> https://framapic.org/1ULyPS2SkXSJ/WASWYnsIq4Tu.png then ~100 updates of the rexec_demo stuff per second
<sb0> and watch qt crap out
<sb0> (or pyqt)
<sb0> actually ~20 updates per second are sufficient
<whitequark> ok, so I just made 8000 rows of 1-100 characters
<whitequark> scrolling does not have any noticeable delay. it's 60fps.
<whitequark> qmake .;make should build it
<sb0> you need to change the data with automatic column size enabled
<sb0> changing just a couple cells seems sufficient. my guess is the auto-layout-system will request data from the whole model again
<sb0> one would assume it were smarter, since you have to tell qt what data you have changed
<whitequark> ok, so I change the model every 50ms
<whitequark> scrolling is still 60fps.
<whitequark> see updated zip at the same URL.
<whitequark> are you emitting the correct dataChanged signal?
key2 has joined #m-labs
<whitequark> it does take ~60% on my machine: 30% in harfbuzz, 38% in Qt, 10% in libc
<whitequark> but then again it's a lot of updates...
<sb0> there is no auto-layout, is there?
<whitequark> there is
<sb0> I can resize column 2 manually. when columns are manually resizable, it's also reasonably fast with python.
<whitequark> the flag is only set on column 0
<whitequark> yes, it's not 60fps with flag on columns 0-2
<whitequark> but it's still responsive and the scrolling is smooth
<whitequark> and that's with 8000 rows, not 8..
<sb0> can you do the exact C++ equivalent of self.table.header().setSectionResizeMode(QtWidgets.QHeaderView.ResizeToContents)
<sb0> that's what's in artiq, and what is causing the bug
<whitequark> it takes an index
<whitequark> what I did is
<whitequark> ui->tableView->horizontalHeader()->setSectionResizeMode(0, QHeaderView::ResizeToContents);
<whitequark> ui->tableView->horizontalHeader()->setSectionResizeMode(1, QHeaderView::ResizeToContents);
<whitequark> ui->tableView->horizontalHeader()->setSectionResizeMode(2, QHeaderView::ResizeToContents);
<whitequark> which sets the resize flag on all three sections.
<sb0> why does the python version not take an index?
<whitequark> I have no idea
<whitequark> there is no C++ function "header()" either
<whitequark> only horizontalHeader() and verticalHeader()...
<sb0> okay. it's horizontalHeader for QTableView, and header for QTreeView
<sb0> but there is the version without index for both
<whitequark> ah, wait, it's overloaded
<whitequark> the other version doesn't take an index
<sb0> ok. try that one
<sb0> setStretchLastSection(True) also seems to be a performance killer
rohitksingh has joined #m-labs
<whitequark> updated
<whitequark> ui->tableView->horizontalHeader()->setSectionResizeMode(QHeaderView::ResizeToContents);
<whitequark> ui->tableView->horizontalHeader()->setStretchLastSection(true);
<rjo> whitequark: that broke ipv6 http and ssh at least
<whitequark> odd.
<whitequark> but I do confirm that it did
<rjo> and mosh (udp 60000-61000)
<whitequark> rjo: does it work now?
<rjo> nope
<whitequark> then it's not ip6tables
<whitequark> because I just flushed them.
<whitequark> oh.
<rjo> it also doesn't respond to icmp anymore
<whitequark> yes, I am fixing that now.
<sb0> just for opening the window, Qt calls the model with DisplayRole 295 times ...
<whitequark> yes.
<whitequark> that's how it's supposed to work.
<whitequark> if your model needs caching, it caches everything itself
<sb0> and 2104 times in total
<whitequark> consider: if Qt decided to cache everything, you would complain that it needs too much memory. or something to that extent.
<whitequark> the main problem is slow pyqt. pyqt ought to provide such cached models, or something like them.
<whitequark> I think you can also use Qt TableWidget (not TableView).
<whitequark> that's probably the easiest path with this problematic pyqt stuff
<sb0> sigh
<whitequark> rjo: ok. i blocked icmp (unwittingly). but also the real reason is that i rebooted the machine
<whitequark> for some reason it did not pick up the ipv6 address.
<whitequark> rjo: I put the right thing into /etc/network/interfaces, I think it should work for you now.
<whitequark> let me restart it one more time...
<whitequark> ok. yes. that worked.
<sb0> and this call count is after I made the table 8x3, btw
early has quit [Ping timeout: 250 seconds]
fengling has quit [Ping timeout: 240 seconds]
early has joined #m-labs
<sb0> whitequark, there seem to be a lot of locality in the pattern of accesses to the model
<rjo> whitequark: udp 60000 seems blocked still, v4 and v6
<sb0> so a cache that discards the old entries when adding new ones would probably solve it, without bloating memory usage
<whitequark> it's strictly worse than no cache for simple models (the majority of them)
ylamarre has quit [Ping timeout: 276 seconds]
<sb0> the models I use are simple, and slow.
<whitequark> don't use pyqt.
<sb0> what do you recommend?
<sb0> don't use pyqt, don't use conda, ...
<whitequark> I write GUIs in their native language i.e. usually C++
<whitequark> and I would be quite surprised if you *wanted* to use conda
<sb0> writing that in C++ would have been a terrible mess as well
<sb0> probably worse than fixing the MVC slowness issue
<whitequark> not really... modern C++ with a good compiler (clang) is a reasonable language
<whitequark> what is your objection to using TableWidget?
<whitequark> the type of data you have is quite conductive to using that one
<whitequark> i.e. static rarely changing
<whitequark> append-only even
<sb0> QSortFilterProxyModel
<whitequark> they use a https://doc.qt.io/qt-5/qstandarditemmodel.html internally.
<whitequark> so you can just instantiate that and use a QTableView.
<sb0> well. the speed is alright when autolayout is disabled. I think I'll just disable it, which will work around the layout bugs too...
<sb0> columns are still breaking in the log (rarely)
<rjo> sb0: i can write that. but for a simple gaussian model numba is a bit overkill.
ylamarre has joined #m-labs
fengling has joined #m-labs
key2 has quit [Ping timeout: 244 seconds]
fengling has quit [Ping timeout: 240 seconds]
ylamarre has quit [Quit: ylamarre]
fengling has joined #m-labs
<rjo> whitequark: udp 60000 seems blocked still, v4 and v6
fengling has quit [Ping timeout: 240 seconds]
sandeepkr has quit [Quit: Leaving]
FabM has quit [Quit: ChatZilla 0.9.92 [Firefox 45.0.1/20160315153207]]
fengling has joined #m-labs
<GitHub118> [artiq] sbourdeauducq pushed 4 new commits to master: https://git.io/vaFzP
<GitHub118> artiq/master befbab5 Sebastien Bourdeauducq: gui: add image applet
<GitHub118> artiq/master 0d7d584 Sebastien Bourdeauducq: master/worker_db: add controller_aux_target device_db entry type
<GitHub118> artiq/master e680939 Sebastien Bourdeauducq: protocols: add remote_exec
<bb-m-labs> build #477 of artiq is complete: Failure [failed python_unittest_1] Build details are at http://buildbot.m-labs.hk/builders/artiq/builds/477 blamelist: Sebastien Bourdeauducq <sb@m-labs.hk>
sandeepkr has joined #m-labs
rohitksingh has quit [Ping timeout: 264 seconds]
rohitksingh has joined #m-labs
key2 has joined #m-labs
fengling has quit [Ping timeout: 240 seconds]
key2 has quit [Ping timeout: 240 seconds]
rohitksingh has quit [Quit: Leaving.]
mithro has quit [Ping timeout: 250 seconds]
fengling has joined #m-labs
mithro has joined #m-labs
<GitHub179> [artiq] jordens pushed 1 new commit to master: https://git.io/vabfb
<GitHub179> artiq/master 590bedb Robert Jordens: examples: add fit_image
<rjo> sb0: ^ if you want it to take longer, just crank up the image size. numpy is fast, numba won't help much, nor does coding it in c. i would have to dig out the really expensive models for that to become relevant.
cyrozap has quit [Ping timeout: 250 seconds]
cyrozap has joined #m-labs
<bb-m-labs> build #478 of artiq is complete: Failure [failed python_unittest_1] Build details are at http://buildbot.m-labs.hk/builders/artiq/builds/478 blamelist: Robert Jordens <rj@m-labs.hk>
cyrozap is now known as Guest64468
mindrunner has quit [Ping timeout: 240 seconds]
mindrunner has joined #m-labs
fengling has quit [Ping timeout: 240 seconds]
fengling has joined #m-labs
Guest64468 has quit [Ping timeout: 250 seconds]
cyrozap has joined #m-labs
fengling has quit [Ping timeout: 240 seconds]
fengling has joined #m-labs
fengling has quit [Ping timeout: 240 seconds]