On 12/20/2015 06:20 PM, Len Ovens wrote: [..] Note that these plots are the best-case. While cyclictest can load the CPU, it does not perform any FPU computation as DSP would. > Hyperthreading does not effect latency?: > https://www.osadl.org/Latency-plot-of-system-in-rack-0-slot.qa-latencyplot-r0s4.0.html?shadow=0 > > (at least this plot seems to say that) It's very application specific, HT can reduce latency for some workloads: mainly application with many branches that cause instruction cache misses. Digital Signal Processing however requires complete attention of the CPU core and does not usually stall (at least well written DSP optimizes code loops and branches to take instruction fetch into account). In this case Hyperthreading leads to increased latency since two DSP threads on the same CPU compete with each other. Intel-Research published a paper about this: https://software.intel.com/en-us/articles/performance-insights-to-intel-hyper-threading-technology > With my old P4 (single core) HT restricted my AI to 64/2 > with the ocasional xrun, HT off would allow solid 16/2 performance. My > new i5 does not have HT, so I am not able to compare. +1 for testing + measuring. Anyway. In most cases the CPU is not the limiting factor. In the vast majority of cases some power-saving (bus-freq, southbridge, SMI) or weird graphics-cards, wifi, etc and/or their drivers are orders of magnitude more limiting. 2c, robin _______________________________________________ Linux-audio-user mailing list Linux-audio-user@xxxxxxxxxxxxxxxxxxxx http://lists.linuxaudio.org/listinfo/linux-audio-user
