3 ms·

disagree, an audio application (e.g. a livestream) will have audio changing at runtime, therefore, the critical hot and cold codepaths change at runtime, which

disagree, an audio application (e.g. a livestream) will have audio changing at runtime, therefore, the critical hot and cold codepaths change at runtime, which a JIT will handle optimally with dynamic optimizations and deoptimizations. A statis PGO profile can and does help AOT by marking functions as cold and hot however a single profile is very weak/unsufficent against the general variety of runtime uses/inputs. Hence a JIT is much more usage resilient in its performance profile, aside from the initial (and pre-warmable) cold start.

withinboredom 4y ago
You can disagree if you want to, but that doesn’t change the facts.
- SemanticStrengh 4y ago
  your disagreement doesn't change the fact AOT programs can become pathological by their a priori and not a posteriori tagging of hot and cold functions but hey free country, not assimilating valid arguments and being in denial is a human right. Also I realize you said "pausing the world", are you confusing JITs with GCs? Or enlighten me what in a JIT induce a stop the world pause besides a GC. As for this, it is hortogonal indeed, AOT java/C# still has a GC and has indeed SOTA submillisecond GC pauses with e.g. ZGC.
  - withinboredom 4y ago
    The fact is you don’t want unpredictable latency when processing audio. JIT produces unpredictable latency. This is a fact. You are saying that doesn’t matter, because in the end it is faster, but it totally misses the point about latency.
    - bob1029 4y ago
      I have to say I am really appreciating the amount of conversation that arose here. My reading of this thread so far leaves me with: > AOT may be bad for real time audio due to compile-time assumptions and other heuristics that are limited by the lack of run-time history. > JIT is probably bad for real time audio, unless you take special precautions to pre-condition the execution context with a workload that approximate the live one. How does this sound?
      - SemanticStrengh 4y ago
        This sounds like we don't know how to sound.
      - withinboredom 4y ago
        If you are doing anything realtime, it's also going to depend on your hardware as much as your software. The real answer, is it depends and it's all tradeoffs. There's no "right" answer, but generally, you want things to be predictable (something that AOT gets you), but if your performance budget gives you the ability to stop the world and JIT (because hardware), then that's ok too.
  - tsegratis 4y ago
    loading memory from outside of L1 cache is enough to cause stutter in realtime audio You could presumably JIT to a page, warm it up by running in a separate thread, then swap it in... But for me, I'm not sure what gain that gives over AOT, and certainly adds background churn
viraptor 4y ago
Audio doesn't change in those applications in a way that would affect the profile. They're very math-heavy pipelines (if we're talking about vst-style effect stacking) where branching is avoided as much as realistically possible. What's in the studio stream itself is largely irrelevant.

withinboredom 4y ago

You can disagree if you want to, but that doesn’t change the facts.

SemanticStrengh 4y ago
your disagreement doesn't change the fact AOT programs can become pathological by their a priori and not a posteriori tagging of hot and cold functions but hey free country, not assimilating valid arguments and being in denial is a human right. Also I realize you said "pausing the world", are you confusing JITs with GCs? Or enlighten me what in a JIT induce a stop the world pause besides a GC. As for this, it is hortogonal indeed, AOT java/C# still has a GC and has indeed SOTA submillisecond GC pauses with e.g. ZGC.
- withinboredom 4y ago
  The fact is you don’t want unpredictable latency when processing audio. JIT produces unpredictable latency. This is a fact. You are saying that doesn’t matter, because in the end it is faster, but it totally misses the point about latency.
  - bob1029 4y ago
    I have to say I am really appreciating the amount of conversation that arose here. My reading of this thread so far leaves me with: > AOT may be bad for real time audio due to compile-time assumptions and other heuristics that are limited by the lack of run-time history. > JIT is probably bad for real time audio, unless you take special precautions to pre-condition the execution context with a workload that approximate the live one. How does this sound?
    - SemanticStrengh 4y ago
      This sounds like we don't know how to sound.
    - withinboredom 4y ago
      If you are doing anything realtime, it's also going to depend on your hardware as much as your software. The real answer, is it depends and it's all tradeoffs. There's no "right" answer, but generally, you want things to be predictable (something that AOT gets you), but if your performance budget gives you the ability to stop the world and JIT (because hardware), then that's ok too.
- tsegratis 4y ago
  loading memory from outside of L1 cache is enough to cause stutter in realtime audio You could presumably JIT to a page, warm it up by running in a separate thread, then swap it in... But for me, I'm not sure what gain that gives over AOT, and certainly adds background churn

viraptor 4y ago

Audio doesn't change in those applications in a way that would affect the profile. They're very math-heavy pipelines (if we're talking about vst-style effect stacking) where branching is avoided as much as realistically possible. What's in the studio stream itself is largely irrelevant.