4 ms·

I think this person is not really informed about JIT. Knowing the code at the beginning of the run doesn't make you know its runtime profile, at all. But it's

I think this person is not really informed about JIT. Knowing the code at the beginning of the run doesn't make you know its runtime profile, at all. But it's something the LLVM generation is not aware of. I think that the people who saw only the suits in front of java and C# didn't see what happent on the JVM/CLR side. And a lot of things where shaken there.

pbiggar 17y ago
I'll admit I haven't ever written a JIT, but I wouldn't say I'm not informed about them. Its a question of tradeoffs: JITs can help you get good run-time performance if your types are static for some large portion of run-time, but not really known at compile-time. I would allege that they are available at compile-time. I think my research showed I could prove a type for about 60% of variables/fields/etc, and tie it down to {int,float} or {object,null} in most other cases. I guess I forgot to put that in.
- nraynaud 17y ago
  You are speaking about monomorphic specialization, in the JVM benchmarks they are at 80% of specialized code (correctly guessed concrete type), moreover, the JVM keeps the code for various specializations if it needs too. And the good part is that they don't do all this stuff if it's useless. The entry into JIT is stiff, but you already spent 4years on your static compiler, so basically you had this time to make/reuse/spacialize a JIT interpreter that would just be a drop in replacement.
  - pbiggar 17y ago
    I would understand the term "monomorphic specialization" to mean "can be many dynamic types, but in practice only has one dynamic type". What I'm implying is that the vast majority of values only have one static type, if your static analysis is good enough. The question of "which is better" wasnt really a factor in my decision to build a static compiler instead of a JIT. Building a JIT as a solo effort for a complex language like PHP would probably have prevented me doing enough research to get a PhD. More importantly, I wasn't interested in JIT, I was interested in static analysis and (static) optimization.

pbiggar 17y ago

I'll admit I haven't ever written a JIT, but I wouldn't say I'm not informed about them. Its a question of tradeoffs: JITs can help you get good run-time performance if your types are static for some large portion of run-time, but not really known at compile-time. I would allege that they are available at compile-time. I think my research showed I could prove a type for about 60% of variables/fields/etc, and tie it down to {int,float} or {object,null} in most other cases. I guess I forgot to put that in.

nraynaud 17y ago
You are speaking about monomorphic specialization, in the JVM benchmarks they are at 80% of specialized code (correctly guessed concrete type), moreover, the JVM keeps the code for various specializations if it needs too. And the good part is that they don't do all this stuff if it's useless. The entry into JIT is stiff, but you already spent 4years on your static compiler, so basically you had this time to make/reuse/spacialize a JIT interpreter that would just be a drop in replacement.
- pbiggar 17y ago
  I would understand the term "monomorphic specialization" to mean "can be many dynamic types, but in practice only has one dynamic type". What I'm implying is that the vast majority of values only have one static type, if your static analysis is good enough. The question of "which is better" wasnt really a factor in my decision to build a static compiler instead of a JIT. Building a JIT as a solo effort for a complex language like PHP would probably have prevented me doing enough research to get a PhD. More importantly, I wasn't interested in JIT, I was interested in static analysis and (static) optimization.