2

So I am aware the java has just in time compilation (the JIT), which gives it an advantage over statically compiled languages like C++. Are there any examples illustrating the java JIT? Possible examples could be outperforming C or C++ code for a given algorithm? Or showing an algorithm's iterations getting faster with time (I am unsure if that would be an instance of the JIT). Or just any example which can show some sort of measurement of the existence of the JIT doing this? I ask this question because I have only ever read about the JIT and wish to prove it's existence as opposed to just believing in it like some sort of religious God.

Remark - If this question is too opinionated please comment and let me know why. I am just curious about the JIT and after using java for a few years still to this day am unaware of how I benefit from it, and if it lives up to the hype of outperforming its statically compiled counterparts.

Additional Information - I have read about when it does it, and am not looking for more information I will just need to believe is true, I want to see something which shows me doing what it is suppose to do.

EDIT - Good that I have allot of responses, what has been said is that comparing speed alone JIT optimised vs. C++ is not a good approach, and that a pure java comparison would be the least horrible. What about an example showing this with java:

Possible profile of example

So a JIT and Non-JIT optimised program doing the same are executed. At the start the JIT has not kicked in, and the program begins getting quicker whilst the static always has the same performance. Then the conditions change at 5.5 seconds or so and the application is being used slightly differently. The JIT has the ability to adapt to these changes again, firstly the time spikes and then it begins optimising again and can even reach a better optima becaue the application is being used slightly different. Would this be an acceptable example to show a JIT? (I will endevour to achieve this and review everyones links and videos).

Derrops
  • 7,651
  • 5
  • 30
  • 60
  • Maybe this http://www.beyondjava.net/blog/a-close-look-at-javas-jit-dont-waste-your-time-on-local-optimizations/ is along the lines, but the example only contains primitives... I ideally I want GC to get in on the action as well. – Derrops Jul 06 '15 at 04:55
  • You can study the effect of JIT by comparing java with and without -Xint on anything that interests you. But note that microbenchmarks for Java are a fickle thing, due to GC's influence, even if you exclude JITing. – laune Jul 06 '15 at 05:11
  • There are some who would say that "compile once, run anywhere" is the greater benefit of the JIT technology, and not whether you can beat C or C++ by microseconds. Note that much of what happens at Java runtime is written in C anyway, so what are you proving if Java is faster or slower on this or that algorithm? – laune Jul 06 '15 at 05:14
  • Run a program with `-xint` to disable the jit, and see how its performance is affected. Any change in performance must be due to the jit (or lack thereof). Make sure to first read up on writing a good benchmark on Java (it's not trivial). As for a specific jit optimisation, I have a repo on github that you might find interesting: https://github.com/yshavit/jitperf – yshavit Jul 06 '15 at 05:18

4 Answers4

3

I do not think you can convincingly prove that java using JIT is faster than C/C++ statically compiled code.

You could find some code in java that beat its c/c++ implementation. For that you need to search for keywords like (benchmark,Java,JIT,C,C++ )

I have purposely not mentioned any code or links for the above because of my point below.

Most of the times people show java code beating statically compiled c/c++ in following ways

  1. Find part where java is fast compared to c/c++(memory allocation)and write only code to highlight it.
  2. Find weak points of c/C++ code and try to write java code that beat the c/c++ code in achieving the result.
  3. Run code in environment where you have advantage like having fast hardware and good amount of memory .

My point being you are trying to find exception where java is faster that C/C++ and then generalizing it to the whole language. You could easily find more more examples of c/c++ beating java code just by using pointer in many algorithm.

Such code benchmark testing is of no value in real life application development.

Summarizing ( in real life application development )

  1. Java was slow compared to c/c++ when it first came out. But in the past decade improvements made in JVM coupled with JIT,Hotspot etc have made java as good as C/C++. Java is not slow nowadays. But I would not call it fast over c/c++. Any difference in real life application development in negligible because of language improvement as well as better hardware.

  2. You cannot generalize that java is faster than c/c++ by beating it one time in a particular environment with a particular algorithm or code.

You might find some interesting info in the following links

  1. https://softwareengineering.stackexchange.com/questions/110634/why-would-it-ever-be-possible-for-java-to-be-faster-than-c

  2. Is Java really slow?

Since question has been edited to now try and find the performance improvement of using JIT , I am editing my answer to add a few more points.

My understanding of JIT is that it improves the code that is most executed , to a version that can be run really fast by compiler. Most of the examples of JIT optimisation techniques I have come across shows actions which could also be done by the programmer but then would affect the readability of the program or may not confirm to the framework or coding styles the programmer is/has to use.

So what I am trying to say here is if you write a program that can be improved by JIT it will do so and you will see an increase in performace. But if you are someone who understand JVM and write java code that is already optimized then JIT may not give you much benefit.

So in effect if you see a performace improvement when running a program using JIT that improvement is not guaranteed for all java programs. It depends on the program.

These links below show some JIT improvements using code examples.

http://www.infoq.com/articles/Java-Application-Hostile-to-JIT-Compilation

https://plumbr.eu/blog/java/do-you-get-just-in-time-compilation

Anyway if we need to to differentiate the performance while using JIT, we would run a java program with JIT enabled and run the same program again with JIT disabled.

This link http://www.javacodegeeks.com/2013/07/java-just-in-time-compilation-more-than-just-a-buzzword.html has a case study on this topic and recommends the following

Assessing the JIT benefits for your application

In order to understand the impact of not using JIT for your Java application, I recommend that you preform the following experiment:

  1. Generate load to your application with JIT enabled and capture some baseline data such as CPU %, response time, # requests etc

  2. Disable JIT

  3. Redo the same testing and compare the results.

This link http://people.cse.iitd.ac.in/~sbansal/csl862-virt/readings/CompileJava97.pdf does benchmark JIT and shows speed improvements over basic JVM interpretations.

To understand what JIT does to your code , you could use the tool JITwatch.

https://github.com/AdoptOpenJDK/jitwatch

The links below explain its utility.

http://www.oracle.com/technetwork/articles/java/architect-evans-pt1-2266278.html

http://zeroturnaround.com/rebellabs/why-it-rocks-to-finally-understand-java-jit-with-jitwatch/

Community
  • 1
  • 1
Raj
  • 1,945
  • 20
  • 40
  • Thanks for comments but not really interested in benchmarking java vs c++, but just the JIT itself. If comparing java to c++ is not a good approach to seeing the JIT in action I shall try something else. – Derrops Jul 06 '15 at 06:07
1

First, you want to watch this video. It gives you tools to see the JIT in action.

Where I believe your questions is misled is that you are asking for an example of tailored code where you could potentially measure faster performance in some JVM-based language X vs some non JVM-based language Y (where, for instance, X is Java and Y is C).

This is not the way to think about the JIT. Unless you actually write a compiler for the JVM language by yourself, or have to debug some serious performance issue, and only after you have considered refactoring your code and seen it fail then you can delve that deep into details.

But otherwise, the principle is simple: the JIT is your friend and it does things right; all you have to do is write code which just works; if there are ways that the JIT can make it faster at runtime, it will most certainly do so.

fge
  • 119,121
  • 33
  • 254
  • 329
  • Yes I want the JIT to be my friend, but instead it is like a supernatural being whose existence I cannot directly observe, only read about in literature and then use the information what I read to explain things about java which I don't understand. Much like what humans have done in past when they didn't have good science. – Derrops Jul 06 '15 at 06:11
  • Well then watch the video I linked to and start playing :) – fge Jul 06 '15 at 06:18
  • I want to but I'm at work ): plus I didn't bring my headpones otherwise I'd get away with it ( ; but I will let you know how I found the video after I watched it. – Derrops Jul 06 '15 at 06:21
  • The JIT is not supernatural, and it can be directly observed. Please stop comparing a long-standing JVM feature to a mysterious deity. – dimo414 Jul 06 '15 at 06:25
  • But I find it to be a useful Analogy – Derrops Jul 06 '15 at 06:27
1

JIT Just in Time compilation is a sort of pre compilation that is done prior of execution of byte code. From ORacle site:

"In theory, the JIT comes into use whenever a Java method is called, and it compiles the bytecode of that method into native machine code, thereby compiling it “just in time” to execute"

The most reliable effect of JIT is visible comparing java itself with and without jit.

JIT (Just In Time compilation) was introduced in java 1.2 so the best is to execute the same code with java 1.1 and java 1.2 and check the performances.

Prior to java 1.2 java was considered a very slow language and only after the introduction of JIT it has been extensively used in any field.

Instead is difficult to compare C++ or C and java. Potentially C++ is faster then java, because also with JIT java is an interpreted language. JIT compilation helps because the code that is executed more often is interpred only one time instead of each time it is executed. Differences between java and C++ can involve how libraries are designed, presence or absence of certain primitive types, how code is compiled, level of optimizations, in case of java how gc is configured and so on.

Note that there can be differences also between java and java also with same jdk and same jvm depending on compilation parameters and execution parameters.

It is not possible to say that Java is faster than C or viceversa, too many parameters are involved in this kind of comparison. Sometime C++ is faster, sometime java is the best.

Here is a reference from Oracle on JIT compilation: http://docs.oracle.com/cd/E13150_01/jrockit_jvm/jrockit/geninfo/diagnos/underst_jit.html

Davide Lorenzo MARINO
  • 26,420
  • 4
  • 39
  • 56
  • "JIT Just in Time compilation is a sort of pre compilation that is done prior of execution of byte code." - This is not correct. – Derrops Jul 06 '15 at 05:34
  • From oracle site: In theory, the JIT comes into use whenever a Java method is called, and it compiles the bytecode of that method into native machine code, thereby compiling it “just in time” to execute – Davide Lorenzo MARINO Jul 06 '15 at 05:44
  • Yeah but that phrase is for AOC, JIT happens after the code has been running, then before the next time runs it is optimised. Not before it is ever run. – Derrops Jul 06 '15 at 06:30
1

There are countless examples on Stack Overflow of questions like "why is my code running faster all of a sudden?" - usually when people try to benchmark their code. The answer is, invariably, because the JIT was able to make optimizations mid-benchmark.

See: How do I write a correct micro-benchmark in Java?, What is going on in this java benchmark?, and Java benchmarking - why is the second loop faster? for some examples.

I have only ever read about the JIT and wish to prove it's existence as opposed to just believing in it like some sort of religious God.

This is an unnecessary line of thinking; there's a lot going on between your keyboard and your monitor that you've never noticed or don't understand. The JIT is documented behavior of the JVM, that's all you need to know. It's fine if you don't understand it and want to learn more, but it's not some mythical, ethereal construct.

Community
  • 1
  • 1
dimo414
  • 47,227
  • 18
  • 148
  • 244
  • Understood, don't like that, would still like to see it in a measureable way if possible, if not possible then sad face ): – Derrops Jul 06 '15 at 06:06
  • Run any number of simplistic benchmarks, like the linked questions are trying to do. You will "see" the effects of the JIT when the same code run repeatedly takes less time in successive iterations. – dimo414 Jul 06 '15 at 06:07
  • I think that is not enough to prove it. You would need something like what my picture shows? Otherwise the optimisation could be explained by other factors like the jvm thread not grabbing all of the CPU it wants at the start and getting what it wants as it maintains its business, is that possible? – Derrops Jul 06 '15 at 06:14
  • It is strange to ask for "proof" of a JVM feature. It's [well documented](https://en.wikipedia.org/wiki/Just-in-time_compilation#References) to exist, we're not on an archaeological dig here. – dimo414 Jul 06 '15 at 06:21
  • If you want proof, the documentation should suffice. If you want to see it in action, run a benchmark. – dimo414 Jul 06 '15 at 06:22
  • Documented ≠ Proof, I documented that I am superman, therefore I am superman with that logic. I want to see the effects not documentation. – Derrops Jul 06 '15 at 06:24
  • That's a straw man argument, you aren't the creator of the universe. The JVM authors *are* the creators of the JVM. The documentation they write about the JVM is canonical. If neither an extended body of literature nor the ability to easily run a benchmark and *see the JIT in action* counts as "proof" for you, I don't know what you're looking for. – dimo414 Jul 06 '15 at 06:29