4 ms·

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

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

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