Hej Konrad, >>I can't hold back my curiosity, so I've got to ask: why? Why would you >>do that? Why do you assume you know better than the operating system?
I totally understand the question and agree to anything else you state in your email below, however, I am dealing with a non-standard use case with comparably tough delay restrictions. I do it for R&D reasons related to remote music performances and the project where this works has been going into: https://www.soundjack.eu/ https://www.soundjack.eu/publications/ In this domain we are constantly seeking opportunities to improve audio/video low(est)-latency on x-platform standard hardware. Especially on cheaper hardware such as the Raspi thread distribution was a benefit in that regard especially when processing audio with 32 samples/block and probably less but I need to compare and evaluate it more intensively now. Best Alex -- http://www.carot.de Email : alexan...@carot.de Tel.: +49 (0)177 5719797 > Gesendet: Mittwoch, 28. Dezember 2022 um 15:57 Uhr > Von: "Konrad Rosenbaum" <kon...@silmor.de> > An: interest@qt-project.org > Betreff: Re: [Interest] Thread-To-CPU-Core distribution > > Hi, > > On 28/12/2022 11:08, Alexander Carôt wrote: > > in a special use case I launch audio- and video streaming classes in my Qt > > main thread and also a web browser as an interface (webview or webengine) > > but I want to have their operation consciously separated over available cpu > > cores such as > > > > Core 1: Audio Callback Thread > > Core 2: Video Callback Thread > > Core 3: Web browser > > > > and not let the system decide what runs on which core. > > I can't hold back my curiosity, so I've got to ask: why? Why would you > do that? Why do you assume you know better than the operating system? > > > There are subtleties in what core is assigned to which task. The kernel > knows stuff like IRQ affinities, hardware bus connections, IO port > assignments and so on that are fairly hard to guess for you in user > space. Normally the kernel will find a good balance between cache > affinity, short call paths into hardware and load distribution, so there > is usually no need for you to meddle in this. > > > Unless you've found that rare unicorn of a real scheduling problem in > your OS _and_ your program only needs to run on that one machine... > don't meddle. Once you optimized for one machine, things will perform > (much) worse on different machines. > > > Usually if your program does not perform well it is one of those problems: > > a) you have unnecessarily complicated call paths in your program: you > need to shorten them > > b) bad math: sometimes it is worth spending hours simplifying an > algorithm to save on a few microseconds - billions of microseconds in a > loop are hours after all. > > c) too many context switches: use FEWER threads, not more, reduce > dependencies between threads > > d) your hardware is not powerful enough for what you want to do: save > some money, get better hardware > > e) you are waiting for the hard disk or network: use a cache (big > problem on Windows, Linux already does this for you) > > > > With audio and video this works fine already according to > > > > https://eli.thegreenplace.net/2016/c11-threads-affinity-and-hyperthreading > > > > because I am using pthreads for them anyways. > > > > Now I wonder if this is also possible for Qt and my web browser instance in > > particular. > You can always call sched_setaffinity with pid==0 from within that thread. > > > > Konrad > > > _______________________________________________ > Interest mailing list > Interest@qt-project.org > https://lists.qt-project.org/listinfo/interest > _______________________________________________ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
