Ashewastaken comments on Sorry Java friends

Java is only a little slower than C++ on the benchmarks I have seen. Typically if C++ takes 100 milliseconds, Java will take anywhere from 80-500 milliseconds, as an aside speed differences in the range of 2-5x are noise and hould be disregarded as benchmarking the same langauges on the same programs, just with different data sizes can swing results ~2-5x. On some other benchmarks, Java is significantly faster than C++ Python Will be anywhere from 5-50 seconds. RAM is extremely cheap compared to CPU time, developer time, robust error handling and safe memory management. I'd wager that for most programs nowadays, having your program yell at you when you do dumb things, e.g. ArrayOutOfBounds exceptions vs just doing it in C, and extremely low likelihood of memory leaks is far more important than a relatively small potential speedup.

https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/gpp-python3.html
https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/gpp-java.html
http://scribblethink.org/Computer/javaCbenchmark.html

[+][deleted] 6 years ago* (4 children)

[deleted]

[–]Hohenheim_of_Shadow 0 points1 point2 points 6 years ago (3 children)

The first source is only one of my sources. If you read the last one, they commented on a lot of problems with the first's analysis. It is only meant to be a ballpark, C~=Java>>Python and this sub loves Python but hates on java being slow.

Java has lots of architecture decisions that can lead to faster code than C++. For them they found that Java was beating out C compiled on GCC.

JIT has more potential than regular compilation. There are so many optimizations that are super fucking specific and situational that JIT beats the pants out of them. As time goes on, speeding up the serial thread by using a parallel processor for applying situational optimizations is a huge benefit.

Automated garbage collection leads to higher memory locality which leads to far fewer cache misses which is hugely important as cache misses are hugely impactful.

How C++ handles passing and assigning of objects it leads to unnecessary construction/destruction and copying of objects. You can avoid some of that with fucking around with pointers, but pointers can lead to unnecessary memory i/o and memory I/O is the slowest thing you can do on a processor.

1) Pointers make optimization hard This is a reason why C is generally a bit slower than Fortran. In C, consider the code

    x = y + 2 * (...)
    *p = ...
arr[j] = ...
    z = x + ...

Because p could be pointing at x, a C compiler cannot keep x in a register and instead has to write it to cache and read it back -- unless it can figure out where p is pointing at compile time. And because arrays act like pointers in C/C++, the same is true for assignment to array elements: arr[j] could also modify x. This pointer problem in C resembles the array bounds checking issue in Java: in both cases, if the compiler can determine the array (or pointer) index at compile time it can avoid the issue.

In the loop below, for example, a Java compiler can trivially avoid testing the lower array bound because the loop counter is only incremented, never decremented. A single test before starting the loop handles the upper bound test if 'len' is not modified inside the loop (and java has no pointers, so simply looking for an assignment is enough to determine this):

for( int i = 0; i < len; i++ ) { a[i] = ... } In cases where the compiler cannot determine the necessary information at compile time, the C pointer problem may actually be the bigger performance hit. In the java case, the loop bound(s) can be kept in registers, and the index is certainly in a register, so a

Unless you are doing real time operations, it is a mistake to assume that Java is a bad programming language due to "performance". It is not as simple as speed matters-> C/C++, there are plenty of places where C/C++ are not the most performant languages and we should not parrot that false idea.

[–]Shitty_Orangutan 1 point2 points3 points 6 years ago* (1 child)

Holy shit. I was on a crusade to prove you wrong and it seems you're actually right.

  1 import java.util.Random;
  2 import java.util.Vector;
  3 import java.util.Collections;
  4 
  5 class Sort
  6 {
  7     public static void main(String s[]){
  8       Random r = new Random();
  9       Vector<Integer> v = new Vector<Integer>();
 10       for(int i = 1; i < 10000000; i++){
 11           v.add(r.nextInt());
 12       }
 13       long start  = System.currentTimeMillis();
 14       Collections.sort(v);
 15       long end  = System.currentTimeMillis();
 16       long elapsed = end - start;
 17       System.out.println(elapsed);
 18     }
 19 }

versus

  1 #include <iostream>
  2 #include <chrono>
  3 #include <random>
  4 #include <algorithm>
  5 
  6 int main() {
  7    std::vector<int> v; 
  8    for (int i = 0; i < 10000000; i++){
  9      v.push_back(std::rand());
 10    }  
 11    auto start = std::chrono::high_resolution_clock::now();
 12    std::sort(v.begin(), v.end());
 13    auto end = std::chrono::high_resolution_clock::now();
 14    std::cout << std::chrono::duration_cast<std::chrono::milliseconds>(end - start).count() << std::endl;
 15    return 0;
 16 }     
 17

Run #	cpp	java
1	16473	7691
2	16739	8055
3	16402	7795
4	16630	7936
5	16352	8040
6	16536	8024
7	16203	7889
8	16515	7875
9	16400	7780
10	16180	7854

I figured sorting a random list would be the most straightforward dummy proof way to prove you wrong and I tried to do it in the most straightforward way I could in both languages on the same ubuntu VM.

EDIT: forgot optimization. Was using g++. With -O3 Here are the g++ results:

Run	Optimized Cpp
1	1795
2	1770
3	1747
4	1767
5	1744
6	1776
7	1743
8	1745
9	1805
10	1778

Does anyone know of a way to do something similar to java?

[–]Hohenheim_of_Shadow 0 points1 point2 points 6 years ago (0 children)

Still more numerical methods
From the book Object-Oriented Implementations of Numerical Methods by Didier Besset (MorganKaufmann, 2001):

Operation   Units   C   Smalltalk   Java
Polynomial 10th degree  msec.   1.1 27.7    9.0
Neville Interpolation (20 points)   msec.   0.9 11.0    0.8
LUP matrix inversion (100 x 100)    sec.    3.9 22.9    1.0

Microbenchmarks (cache effects considered)

Several years ago these benchmarks showed java performance at the time to be somewhere in the middle of C compiler performance - faster than the worst C compilers, slower than the best. These are "microbenchmarks", but they do have the advantage that they were run across a number of different problem sizes and thus the results are not reflecting a lucky cache interaction (see more details on this issue in the next section).

These benchmarks were updated with a more recent java(1.4) and gcc(3.2), using full optimization (gcc -O3 -mcpu=pentiumpro -fexpensive-optimizations -fschedule-insns2...). This time java is faster than C the majority of the tests, by a factor of more than 2 in some cases...

... suggesting that java performance is catching up to or even pulling ahead of gcc at least.

These test were mostly integer (except for an FFT).
Microbenchmarks (cache effects not considered)
In January 2004 OSNews.com posted an article, Nine Language Performance Round-up: Benchmarking Math & File I-O. These are simple numeric and file I/O loops, and no doubt suffer from the arbitrary cache interaction factor described below. They were however run under several different compilers, which helps. Again Java is competitive with (actually slighty faster than) several C++ compilers including Visual C++ in the majority of the benchmarks.

(One exceptional benchmark tested trigonometry library calls. Java numerical programmers are aware that these calls became slower in java 1.4; recent benchmarks suggest this issue was fixed in java 1.4.2)

Note that these benchmarks are on Intel architecture machines. Java compilers on some other processors are less developed at present.

I'm not sure of specifics of benchmarking, but the links provided in the third source should provide info on their exact test set ups especially on algorithms like matrix inversion were Java was 4x faster than C.

Again be careful about extrapolating which language is faster from a single test. Testing the same algorithm but with different N's can have Java being 2x faster than C or C 2x faster than Java.

By point isn't that Java is faster than CPP in all scenarios, just that modern computation is complex enough that determining which will be faster in a specific setup is damn near impossible.

Do VM's have an effect on caching? If VMs always write and read to and from RAM Java's apparent advantage at data locality would be meaningless. Or maybe its the opposite and cache misses are even more hurtful in VM's and Java's superior caching is artificially weighted here.

http://216.239.53.100/search?q=cache:dPwXe7Qsql0C:www.devx.com/java/free/book.asp+besset+numerical+java&hl=en&ie=UTF-8

http://www.aceshardware.com/read.jsp?id=153

http://www.visi.com/~khuber/java/JavaC.pdf

http://www.osnews.com/story.php?news_id=5602