Re: Useful list-indexing trick
Re: Useful list-indexing trick The delay line implementation is include/synthizer/block_delay_line.hpp. Example usage is in src/hrtf.cpp, starting in HRTFPanner::run, starting just above input_line.runReadLoopSplit(...).I haven't benchmarked it against the naive implementation, but basically what's going on is that if you know the maximum amount you're going to want to delay, you can use that to know whether or not delaying by that amount can ever wrap up front. As the lines get longer, say on the order of a second but you're only doing 100ms delay, the amount of time you spend in the modulus slow path and the modulus-specific generated code asymptotically approaches zero. For something like reverb, delay lines on the order of a second but we only use 100ms of it are actually relatively typical: you need the extra space if we go from bathroom to cathedral. And if you start using powers of 2, that quickly starts being a lot of wasted spaceat that size.I haven't tested it heavily. I know that it works, but it might very well do something stupid like "haha, I'm only ever calling the modulus version", I dunno. But it's fast enough to get upwards of 10 HRTF sources in a debug build with like 1% CPU usage. I'll be more scientific about it when Synthizer is further along.as far as I know this is unique to me, I imagine because you need post-C++14 generic lambdas to even make it close to ergonomic. URL: https://forum.audiogames.net/post/576121/#p576121 -- Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
Re: Useful list-indexing trick
Re: Useful list-indexing trick @6, which files is that in? I'm curious now to go check that out. URL: https://forum.audiogames.net/post/576088/#p576088 -- Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
Re: Useful list-indexing trick
Re: Useful list-indexing trick @4Sorry, turning doesn't involve a list. I thought the whole thought, and only typed half of it.Thanks so much for the info. URL: https://forum.audiogames.net/post/576080/#p576080 -- Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
Re: Useful list-indexing trick
Re: Useful list-indexing trick @5slow is only one of the problems. The hardware implementation also doesn't match up with the math. If you do anything that's not trivial and which would really take full advantage, you still have to guard, because negative numbers don't work right. Fortunately for Python people, Python doesn't have that problem. But it's really annoying that 5%-2 isn't 3. The knock-on effect is that if you have to use % for DSP stuff, the magical incantation is actually (length + index - delay) % length, not just (index - delay) % length.I'm not going to try to explain it here because it's very complicated, but Synthizer has an entire thing in it about being able to iterate over ringbuffers, only applying modulus where necessary. I haven't benchmarked it so grain of salt and all, but the problem with power-of-2 tricks is you waste a ton of memory, and fortunately for us (or, well, me) C++ has templated lambdas these days, so with a bit of work you can actually get something like iterate(length, callback_lambda) at zero cost, where the C++ compiler compiles two versions of callback_lambda for you, specialized to whether or not modulus is required (yes, instruction caches, but it turns out that in practical use cases the happy path is 90% not needing it). But I won't go further because you need basically a complete knowledge of C++ up to SFINAE and beyond to follow the code, and you're the only one I can think of offhand who might even have a chance of following it. SO read if you're curious. URL: https://forum.audiogames.net/post/576072/#p576072 -- Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
Re: Useful list-indexing trick
Re: Useful list-indexing trick Yeah, the % operator is really useful. Its useful for ensuring that an integer always remains within a particular range (you'll never suffer array out-of-bound errors if you use it right, because you'll always have indices within the range of the array). Its slow, though, as Camlorn said (I wonder why its not implemented in hardware by now?). URL: https://forum.audiogames.net/post/576068/#p576068 -- Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
Re: Useful list-indexing trick
Re: Useful list-indexing trick Why would turning involve a list? or are you asking if you can do (degrees + change) % 360? If it's (degrees + change) % 360, that's fine and will do what you expect, but turning shouldn't ever involve needing to index into a list, and if it does you probably have much bigger problems.In python, most operators are effectively the same, because Python is slow enough that the difference is hidden. At the level of assembly however, there's something like a factor of 50 between the cheapest instructions and the most expensive, and if you also factor in how pipelining works, it goes up easily to around a factor of 100. For example, you can do the equivalent of this Python:x = (a*b, c*d, e*f, g*h)In just 0.5 cycles on a modern processor, assuming everything involved is floats (which sadly aren't Python floats, Python floats are actually doubles which are the same but twice the size). If you feel like choosing to say "sorry, if you have a netbook, screw you", you can go further and do up to *16* pairs of multiplication in parallel in around a clock cycle. By contrast, a simple integer division can easily take upward of 15 cycles. Not 4 of them in parallel, just one. Unfortunately, modulus falls on the slower side of this spectrum, but bitwise and doesn't, and iuf you're doing modulus by a power of 2, you can replace it with the bitwise and trivially, at which point cue major speedups. C compilers actually do some of this for you when they can prove it, and even something like x / y may not actually compile to the division assembly instruction: there's a bunch of tricks you can do instead that are faster if you can prove properties about the numbers, and if you're doing tens of thousands of divisions by the same number there's one that's really expensive that I don't remember that can cut the time in half.But: none of this matters in Python. However it does definitely matter for things like Synthizer, and even more so for work's custom database offering, which is where I learned some of it (we can query tables that are something like 500 gb+ in size in seconds, which is one of our selling points). URL: https://forum.audiogames.net/post/575994/#p575994 -- Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
Re: Useful list-indexing trick
Re: Useful list-indexing trick So for something like calculating degrees when turning, should I stick to the tried-and-tested method of checking for overflows?I never even considered that some operators might be more expensive than others. URL: https://forum.audiogames.net/post/575986/#p575986 -- Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
Re: Useful list-indexing trick
Re: Useful list-indexing trick It's called a ringbuffer and is popularly used in lots of things, high-volume logging libraries and work queues for example, just not usually in Python. Synthizer has lots of these because, with some additional magic, it turns into a really efficient way to stream audio between threads.Also note that you can start from any index, i.e.:for i in range(len(list)): something(list[(4+i)%len(list)])And you'll still cover the whole list, just with an offset and doing the beginning at the end.In general modulus is expensive, however. In Python, not more expensive than the if statement, but it's usually best to just iterate with a standard loop when you can.The typical formulation in C for this is to make the list a power of 2, then replace %len(list) with list[i & (size - 1)] or, precomputing size-1 for efficiency, list[i & mask]. In Python this brings no real advantage, but in C that can be a major speed-up (though for fixed-size ones, the compiler will know how to get rid of modulus, as long as it's off a constant size). URL: https://forum.audiogames.net/post/575961/#p575961 -- Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
