IRC Logs for #circuits Sunday, 2015-02-08

prologicriot, ok02:02
prologicso what's become slow?02:02
prologicwhat I/O are you responding to?02:02
prologicand by worker processes I mean to use circuits.Worker()02:02
prologici.e: a process pool02:03
prologicwhere you fire task() events at it given a function, *args and **kwargs02:03
prologicAllowing your main process to keep responding to events and I/O in a timely manner02:03
prologiccircuits itself on modern hw can process about ~50k events/s or ~150k events/s (on PyPy) -- So the longer and more CPU intensive your event handlers are the more you hamper event / I/O processing02:04
*** Osso has quit IRC04:28
*** Romster has joined #circuits07:02
*** Osso has joined #circuits10:37
riotprologic: i'd like to work (live) with a video stream, the capture comes in with ~15-20 frames per second (each is 320x240 at rgb) and has to be modified by a chain of components (i'd later like to be able to modify the chain easily to insert FX/controllers/modulators etc) and some of the components (e.g. the colorfilter) do some image processing like applying a color matrix.12:43
rioti'll try to make use of circuits.Worker(), i suspect this will bring a lot12:43
riotbut i also suspect cv to be quite a cycle consument, i tried this "demo" with another framework already - i regard it as "proof-of-framework" ;)12:44
riotbecause it puts similar stress onto a framework/machine, very comparable to a rather serious application i'm building, too.12:45
prologicriot, right13:24
prologicby realtime you mean soft real time?13:24
prologicthere is no way you can capture video and process/display it at the same framework you capture it without some initial delay13:24
prologicbut yeah in general any CPU-bound work you'll want to do in a separate process13:25
riotno fun. I'm getting "MaybeEncodingErrors", what the heck...15:29
riotand it is probably no good that cv2 images are getting pickled here through the multiprocess module15:34
riotat least i can't imagine that doing any good to performance.15:34
rioti'm not keeping them as numpy arrays for fun15:34
riotprologic: i'm working in the audio industry, i know some things about modular systems, buffers and sampling ;)15:37
riotand it is imho ridiculously hard to write a software synth in python..15:38
rioti think, i'd be done a thousand times if i were to use c or even pascal15:38
riotmaybe a lot of the fuss right now is related to cv, but that should really not pose such a problem - at least i've already gotten better results ,)15:39
*** An_Ony_Moose has joined #circuits18:49
*** Osso has quit IRC21:14
*** Osso has joined #circuits21:16
*** Osso has quit IRC21:21
*** Osso has joined #circuits21:25
*** Osso has quit IRC21:26
prologicriot, hmm numpy arrays21:29
prologicIv'e done a bit of work with numpy21:29
prologicnot sure how you'd avoid the pickling though21:29
prologicunless you used shared memory between processes in the pool21:30
prologicriot, don't give up :)21:30
prologicmany Python performance issues are due to understanding not the actual language itself. e.g: data structures, synchornization, etc21:31
*** Osso has joined #circuits21:31
*** Osso has quit IRC21:36
*** Osso has joined #circuits22:24
*** Osso has quit IRC22:25
Worksterpython is pretty damn fast for what it is23:05
Worksternot C speeds but not far off23:05
*** Osso has joined #circuits23:12
*** Osso has quit IRC23:17
prologicit depends on what you're doing23:23
prologicand how you're doing it23:23
prologicoften code written in C won't have the same performance characteristics as written in Python -- you have to think a bit differently about it :)23:24
prologicfor example a list in Python is not the same as an array in C23:24
pdurbinPython is as fast as C?23:32
*** Osso has joined #circuits23:51

Generated by 2.11.0 by Marius Gedminas - find it at!