5 ms·

[Having "a mix of pod structs and function pointers" is analogous to having an interpreter for some scripting language.] Yes, it might be similar at the core,

by iammyIP 10y ago

[Having "a mix of pod structs and function pointers" is analogous to having an interpreter for some scripting language.] Yes, it might be similar at the core, but i would guess the usual audio pod-struct/function mix is many times less complex than a full jit language interpreter. What does chasing pointer mean to slowness then? My understanding is that its similar to data pointers, that a certain region of memory needs to be looked up and be fed into the instruction cache. If the process is layed out so that instruction cache misses are minimised, whats so bad about it?

vardump 10y ago
> whats so bad about it? Other than executing a lot of useless instructions, causing pipeline stalls due to indirection, potentially mispredicted branches, etc. I guess nothing. Just remember if the actual operation is just a few instructions, the price for all that extra work can be 1-2 orders of magnitude. If you only need to chase pointers say a million times per second or less, go for it. It won't matter so much. In worst cases you might lose 10% (of total cpu core capacity) performance, if even that. If it's in tens of millions or more, it's pretty likely to be a significant bottleneck. What does your profiler say? What kind of ILP you're getting?
- iammyIP 10y ago
  The current code with the function pointers and pods works ok for me, its about in the million per second range and i didn't profile any alternative to it. How would you implement such an alternative with jit code generation into this pod/function c code setup without major rewrites? Seems to me like a completely different system which is bound to llvm (i use gcc)? edit: since you were mentioning jit optimisation and code generation - this is a field i do not have any experience, but my impression so far is that this runtime re-arrangement of code can yield quite a big performance increase for higher level languages (jvm does this afaik). Is the link you provided the same idea for statically compiled c/c++ code?
  - vardump 10y ago
    If the chain of operations change rarely, you might even get away with calling clang or whatever compiler and actually compiling a chain of filter source code mashed together.
    - iammyIP 10y ago
      So how would you raw-structure a performance critical (audio) program that needs some flexible path for the data processing, like with a 128 sample buffer and about 3-10 choices along the processing path. Processing path should be switchable per buffer frequency. The function pointers were the best solution i could come up with, but maybe that doesnt really eliminate branching cache misses and stalling and its impact on performance, but just hides it in plain-text.
      - vardump 10y ago
        How many permutations? If not too many, maybe just compile them all. Sometimes you do need to use function pointers. It's just if it's in a performance critical path, you might want to consider alternatives.
        iammyIP 10y ago
        Permutations are for my own case pretty low, it's just a replacement for a handful of switches, otherwise the flow is pretty straightforward. But i see that if one wants to restructure the whole program flow on-the-fly it might lead to problems. What are the alternatives? The link you provided is for graphics, and does not seem to be generalised. Do you suggest a complete switch to a jit interpreted codebase?
        vardump 10y ago
        Graphics and audio are usually pretty similar, other than the volume of data is usually quite a bit larger for graphics than for audio. There's no silver bullet how to structure such flexible, dynamically configurable high performance system.

by iammyIP 10y ago

vardump 10y ago

> whats so bad about it? Other than executing a lot of useless instructions, causing pipeline stalls due to indirection, potentially mispredicted branches, etc. I guess nothing. Just remember if the actual operation is just a few instructions, the price for all that extra work can be 1-2 orders of magnitude. If you only need to chase pointers say a million times per second or less, go for it. It won't matter so much. In worst cases you might lose 10% (of total cpu core capacity) performance, if even that. If it's in tens of millions or more, it's pretty likely to be a significant bottleneck. What does your profiler say? What kind of ILP you're getting?

iammyIP 10y ago
The current code with the function pointers and pods works ok for me, its about in the million per second range and i didn't profile any alternative to it. How would you implement such an alternative with jit code generation into this pod/function c code setup without major rewrites? Seems to me like a completely different system which is bound to llvm (i use gcc)? edit: since you were mentioning jit optimisation and code generation - this is a field i do not have any experience, but my impression so far is that this runtime re-arrangement of code can yield quite a big performance increase for higher level languages (jvm does this afaik). Is the link you provided the same idea for statically compiled c/c++ code?
- vardump 10y ago
  If the chain of operations change rarely, you might even get away with calling clang or whatever compiler and actually compiling a chain of filter source code mashed together.
  - iammyIP 10y ago
    So how would you raw-structure a performance critical (audio) program that needs some flexible path for the data processing, like with a 128 sample buffer and about 3-10 choices along the processing path. Processing path should be switchable per buffer frequency. The function pointers were the best solution i could come up with, but maybe that doesnt really eliminate branching cache misses and stalling and its impact on performance, but just hides it in plain-text.
    - vardump 10y ago
      How many permutations? If not too many, maybe just compile them all. Sometimes you do need to use function pointers. It's just if it's in a performance critical path, you might want to consider alternatives.
      - iammyIP 10y ago
        Permutations are for my own case pretty low, it's just a replacement for a handful of switches, otherwise the flow is pretty straightforward. But i see that if one wants to restructure the whole program flow on-the-fly it might lead to problems. What are the alternatives? The link you provided is for graphics, and does not seem to be generalised. Do you suggest a complete switch to a jit interpreted codebase?
        vardump 10y ago
        Graphics and audio are usually pretty similar, other than the volume of data is usually quite a bit larger for graphics than for audio. There's no silver bullet how to structure such flexible, dynamically configurable high performance system.