| *** ricardocrudo has quit IRC | 00:18 | |
| *** Spark[Nick] has quit IRC | 00:33 | |
| *** sigma6 has joined #lv2 | 00:59 | |
| *** trebmuh has quit IRC | 01:25 | |
| ColaEuphoria | can anyone tell me the implications of using openmp in an LV2 plugin? | 01:36 |
|---|---|---|
| ColaEuphoria | it looks attractive so far | 01:36 |
| ColaEuphoria | but i feel like there might be more to it for low latency hard realtime systems running in the same memory space as a host | 01:38 |
| *** falktx` has joined #lv2 | 04:21 | |
| *** falktx has quit IRC | 04:25 | |
| *** edogawa has joined #lv2 | 07:57 | |
| *** dsheeler has joined #lv2 | 09:35 | |
| *** ricardocrudo has joined #lv2 | 10:09 | |
| *** edogawa has quit IRC | 10:17 | |
| *** edogawa has joined #lv2 | 10:19 | |
| *** ricardocrudo has quit IRC | 10:24 | |
| *** ricardocrudo has joined #lv2 | 10:24 | |
| *** ventosus has joined #lv2 | 10:25 | |
| *** ventosus has quit IRC | 10:35 | |
| *** trebmuh has joined #lv2 | 10:47 | |
| *** ricardocrudo has quit IRC | 11:23 | |
| *** edogawa has quit IRC | 11:28 | |
| *** edogawa has joined #lv2 | 11:30 | |
| *** ventosus has joined #lv2 | 12:19 | |
| *** tytel has joined #lv2 | 14:58 | |
| *** gabrbedd has joined #lv2 | 14:59 | |
| *** gabrbedd has quit IRC | 14:59 | |
| *** tytel has quit IRC | 15:04 | |
| *** gabrbedd has joined #lv2 | 15:29 | |
| *** rncbc has joined #lv2 | 15:59 | |
| *** deva has joined #lv2 | 16:17 | |
| *** rncbc has quit IRC | 16:46 | |
| *** rncbc has joined #lv2 | 16:54 | |
| *** tytel has joined #lv2 | 18:07 | |
| HarryHaaren | ColaEuphoria: OpenMP creates and pthread_join-s threads IIRC, which are non-deterministic in timing (AKA, a system call, which should be avoided at all costs) | 18:40 |
| HarryHaaren | ColaEuphoria: do you have something that *really* needs to be threaded that badly? | 18:41 |
| HarryHaaren | remember, Jack2 (if you use that one) will automatically parralelize parts of the graph if it can | 18:42 |
| HarryHaaren | and that the host application will probably try to run you plugin in a seperate thread to other DSP stuff (that also needs to happen before Jack DSP timeout) | 18:42 |
| HarryHaaren | all in all - although awesome to multithread internally, its not a must unless you have a very specific use case, which is really CPU hungery | 18:42 |
| *** jofemodo has joined #lv2 | 19:10 | |
| *** ricardocrudo has joined #lv2 | 20:41 | |
| *** ventosus has left #lv2 | 21:16 | |
| *** deva has quit IRC | 21:17 | |
| *** ricardocrudo has quit IRC | 22:31 | |
| ColaEuphoria | HarryHaaren: i looked more into it and decided to stick with traditional threading. it's apparently too difficult to meet hard real time guarantees with openmp | 22:56 |
| HarryHaaren | i'd guess so yeah | 22:56 |
| HarryHaaren | i tend to avoid (any and all) large frameworks that make life "easy" - they just don't scale to real-time audio | 22:57 |
| ColaEuphoria | in fm synthesis, the system has to account for not only 8 individual oscillators, but also how they route into one another, and for up to 16 voices | 22:57 |
| HarryHaaren | RT audio needs nimble control over resources, and when what happens. Forget large things, plain old C, and think correctly :D | 22:57 |
| falktx` | have you looked into juce? | 22:58 |
| falktx` | it's made with audio in mind | 22:58 |
| ColaEuphoria | this is modeled as an 8x8 transformation matrix which gets multiplied against another matrix representing an amplitude for every voice, so an 8x8 * 8x16 matrix multiplication | 22:58 |
| ColaEuphoria | 1024 operations | 22:58 |
| ColaEuphoria | and even when it's a 8x8 * 8x1 multiplication (monophonic) | 22:58 |
| ColaEuphoria | valgrind tells me that it's still taking up the most time | 22:59 |
| ColaEuphoria | if i can incorporate SIMD and threading, that can reduce the polyphonic multiply from 1024 to 32 operations on a quad core processor | 23:00 |
| ColaEuphoria | <falktx`> have you looked into juce? | 23:00 |
| ColaEuphoria | i have | 23:00 |
| ColaEuphoria | i don't like it | 23:00 |
| ColaEuphoria | :) | 23:00 |
| falktx` | it's not for everyone | 23:01 |
| ColaEuphoria | the biggest gripe i have with it is its license | 23:01 |
| ColaEuphoria | a lot of people here may disagree with me | 23:01 |
| ColaEuphoria | but i'm not too into the whole GNU way of seeing the world | 23:02 |
| *** rncbc has quit IRC | 23:06 | |
| HarryHaaren | ColaEuphoria: idea for vectorization yup, assuming floats, AVX2 has 256 bit-wide simd registers, so will speed up a LOT :D | 23:17 |
| * HarryHaaren recently built new machine, which is an animal for memcpy() due to AVX2 | 23:18 | |
| ColaEuphoria | oh shit really? | 23:19 |
| ColaEuphoria | that's pretty nice | 23:19 |
| ColaEuphoria | thanks! | 23:19 |
| *** edogawa has quit IRC | 23:21 | |
| ColaEuphoria | although it doesn't seem to offer dot product | 23:21 |
| ColaEuphoria | seems like some tests would be needed | 23:21 |
| ColaEuphoria | oh wait | 23:22 |
| ColaEuphoria | that's only for doubles | 23:22 |
| HarryHaaren | ColaEuphoria: do you program intrinsics? Or (like most sane people ;) rely on the compiler to do it? | 23:28 |
| ColaEuphoria | the only intrinsics i really care about are a few select ones that operate on vectors | 23:29 |
| HarryHaaren | I've recently been to some training for HPC and vectorization, it seems so "easy" until you get into the probelms that actually exist, and then suddenly the data-structure and cachelines become really important | 23:29 |
| HarryHaaren | yup, same as most then | 23:29 |
| HarryHaaren | same as me anyway - and even at that, most of my code is scalar.. since that training, I realized there's lots of optimizations possible for the OpenAV code | 23:30 |
| ColaEuphoria | to me, a vector is just another datatype. letting the compiler "figure it out" in this case is as silly as java type promotion imo | 23:30 |
| ColaEuphoria | making certain things a vector to begin with eases off the onus on the compiler to figure out when and where is a good time to convert things | 23:31 |
Generated by irclog2html.py 2.13.0 by Marius Gedminas - find it at mg.pov.lt!