john price wrote:So the short answer is that AOT is better for short term, while JIT is better for long term?
Alex Major wrote:Only the programmer knows beforehand where "real-time" or faster performance is required in the code.
Alex Major wrote:I never understood why no one created a JSR* to have a new annotation or new keyword prependable to a method that tells the JVM to compile the method either ASAP or before program execution. Only the programmer knows beforehand where "real-time" or faster performance is required in the code.
Alex Major wrote:I'm writing music notation software. My initial prototype could play the fastest 32nd notes
Alex Major wrote:I'm writing music notation software. My initial prototype could play the fastest 32nd notes and refresh the display on my old 867 Mhz Mac from 2001, under Java 1.4.2. But I will need to playback and send note data to other music programs via Rewire* at very low latency. I'm hoping multi-core CPUs, which are the norm, will minimize the lag from bytecode interpretation and the JVMs on-the-fly-compilation. I use object pools so that the garbage collector finds nothing to remove. Memory is not an issue anymore. I still have a nagging fear that Java won't cut the mustard. Too bad Excelsior JET* only works with Windows and Linux.
Pat Farrell wrote:
But this has very little to do with JIT compilers or even hand optimization. Its a very specialized need, and it needs specialized engineering.
Tim Holloway wrote:Actually, Project X does video in Java quite nicely.
davian mcllm wrote:Can someone elaborate, why it's necessary to compile that intermediate format just-in-time instead of, say, ahead-of-time during the installation phase.
You showed up just in time for the waffles! And this tiny ad:
Building a Better World in your Backyard by Paul Wheaton and Shawn Klassen-Koophttps://coderanch.com/wiki/718759/books/Building-World-Backyard-Paul-Wheaton