Java performance issues on ryzen

[chrvanorle]

There are some small changes i made to my runSieve implementation, that should improve performance a little bit. At worst, i figured it wouldn't matter but be cleaner. The I32CSearchNextSize implementation below is what i had originally, and I32CReference is what i have currently (PR coming at some point).

Since maybe the compiler/JIT is doing some things that end up badly for ryzen, i tried some alternatives. On the 8750H, performance is virtually identical, but on ryzen some of the changes halve performance. To be honest, the results don't make sense to me, so i figured maybe someone else has a clue what is going on here.

Edit:
Full code here https://github.com/chrvanorle/Primes/tree/java-ryzen/PrimeJava/solution_5
It seems my unrolled implementations doesn't seem affected, so it might be related to the loop in PrimeSieveBaseBit.java

CPU    implementation                   Best passes out of 20
8750H  I32CQAndSize                     7301
8750H  I32CSearchNextQ                  7345
8750H  I32CSearchNextSize               7346
8750H  I32CReference                    7349

8750H  I32CUnrollSearchNextSize         7542
8750H  I32CUnrollSearchNextQ            8274
8750H  I32CUnrollQAndSize               8377
8750H  I32CUnrollReference              8377

3700x  I32CReference                    4474
3700x  I32CQAndSize                     4480
3700x  I32CSearchNextSize               8391
3700x  I32CSearchNextQ                  9303

3700x  I32CUnrollSearchNextQ            11394
3700x  I32CUnrollSearchNextSize         11482
3700x  I32CUnrollReference              11503
3700x  I32CUnrollQAndSize               11520

// I32CReference, current as planned for future PR
public void runSieve() {
	int q = (int) Math.sqrt(sieveSize);
	for (int factor = 3; factor <= q; factor += 2) {
		if (getBit(factor)) {
			clearBits(factor);
		}
	}
}

// I32CSearchNextSize, with num <= sieveSize in the loop to find the next prime
public void runSieve() {
	int q = (int) Math.sqrt(sieveSize);
	for (int factor = 3; factor <= q; factor += 2) {
		for (int num = factor; num <= sieveSize; num += 2) {
			if (getBit(num)) {
				factor = num;
				break;
			}
		}
		clearBits(factor);
	}
}

//I32CSearchNextQ, with num <= q, q always less then sieveSize so should be faster then I32CSearchNextSize
public void runSieve() {
	int q = (int) Math.sqrt(sieveSize);
	for (int factor = 3; factor <= q; factor += 2) {
		for (int num = factor; num <= q; num += 2) {
			if (getBit(num)) {
				factor = num;
				break;
			}
		}
		clearBits(factor);
	}
}

//I32CQAndSize, if factor <= sieveSize helps, also add check on q to get both benefits?
public void runSieve() {
	int q = (int) Math.sqrt(sieveSize);
	for (int factor = 3; factor <= q && factor <= sieveSize; factor += 2) {
		if (getBit(factor)) {
			clearBits(factor);
		}
	}
}

[ItalyToast]

If you could provide a commit, a branch or code of some kind that is easier for people to run I think you will get more help. I think a lot here will depend on how the JIT is compiling the code. Details such as if sieveSize is a constant/readonly will impact the compiler. Diving in to the ASM should help finding the problem.

My guess is that the JIT have trouble inlining I32CReference for some reason.