ChipAbuse: Mathtester's misbegotten child

[DrMrLordX]

UPDATE

02/27/2015 version now available. Not much different than before, though it isn't as messy. Links below take you to the new version. Virustotal says it's safe.

https://www.virustotal.com/en/file/...2fd9da32f3d5d04f5b169f09/analysis/1425098355/

So I've been plugging away at Mathtester, trying to improve its performance in Java without causing the JVM to start ignoring important code segments by converting them to NOOPs. Things were going along nicely, but then I decided to get fancy. What I did was:

1). unroll the internal loop
2). Switch from using simple integer/float variables in the calculations to using a 128-entry array of integers/floats. Each array entry is randomly generated at the beginning of the program with values ranging from 1 to 1025.
3). Get rid of all '++' incrementation operations.

The JVM started over-optimizing by ignoring a lot of the unrolled loops. Bummer. But the standard IntegerLoop still worked, and it had the curious side-effect of making my A10-7700k run hotter than anything else I had ever run on it. Hotter than Prime95, hotter than linpack, hotter than y-cruncher (the previous champion). I tested it on an E1-2500 and the IntegerLoop code was barely beaten out by y-cruncher (y-cruncher: 62C, IntegerLoop, 61C). Interesting.

So I packaged the unrolled version of IntegerLoop into a new program (also under a BSD 2-clause license) called ChipAbuse. Links!

https://www.dropbox.com/s/lj65iqihiom193c/chipabuseclasses02272015.zip?dl=0
ChipAbuse .class files. Download this, unzip, and run abuseme.bat to run the program under Windows. Any other operating system: you figure it out. Requires Oracle JDK 8 or equivelant (OpenJDK 8?).

https://www.dropbox.com/s/zo1543de0zl2dzr/chipabusesource02272015.zip?dl=0
ChipAbuse source files.

12/30/2014 build:
Both IntegerAbuser and FloatAbuser are now functional, thanks to some timely application of the volatile prefix.

01/28/2015 build:
12/30 build is now essentially obsolete. The code path from that build is present in the newer 01/28/2015 build. The experimental code *might* allow the JVM to translate microcode into SIMD instruction, maybe.

01/31/2015 build:
I've revamped how the code handles ExecutorService creation and initialization. Instead of constantly creating and destroying the ExecutorService periodically (which was a waste of CPU time and caused lulls in heat), I've caused the worker threads to become infinite loops. You now have to hit ctrl-c to end the program. I'm not overly-pleased with this solution, but later on maybe I can set up an event handler or something to take the user back to the main menu after a certain keypress. IF that doesn't compromise the temps generated by the program. Regardless, this version runs a bit hotter, and you should see 100% CPU utilization all of the time.

02/27/2015 build:
I reduced the number of threads created by the program and set it up to close itself properly when you enter 'x' at a prompt instead of having to enter ctrl-c. Otherwise the program runs the same way.

Keep them results coming! The Piledriver results have been interesting.

 

[DrMrLordX]

Huzzah! Use of the volatile prefix has solved the problem of over-zealous NOOPing on the part of the JVM. Now the FloatAbuser works as well, and the code/source have been updated accordingly.

Some CPUs will get higher heat from the integer code, while others will get it from the floating-point code. My Steamroller likes the integer stuff while the Jaguar, interestingly enough, requires floating-point abuse to reach its max temp.

I pushed the Jaguar to 64C, 2 degrees higher than the previous champion on that machine. As for the Steamroller, temp monitoring is a little weird but it looks like I've got Prime95 Large FFT (previous champ on that box) beat. CPU temp is 34C for both Prime95 and ChipAbuse, but the core temp is only 16C for Prime95 but goes up to 26C for ChipAbuse.

Again, if anyone out there would be willing to run this against linpack, prime95, or whatever else you use for stress testing, I'd love to hear about your respective temperatures. Don't forget to try y-cruncher! That thing can bring some serious heat.

Haswell users: please let me know if you are using Prime95 28.5 since that version will probably overvolt your CPU. Don't think ChipAbuse will do that, but you never know . . .

 

[Phynaz]

the core temp is only 16C for Prime95 but goes up to 26C for ChipAbuse.

You see no problem with reported temps being below ambient?

 

[Nothingness]

Haswell users: please let me know if you are using Prime95 28.5 since that version will probably overvolt your CPU. Don't think ChipAbuse will do that, but you never know . . .

Prime95 doesn't overvolt Haswell: it's using AVX in general that requires extra voltage. This also applies to IBT (Linpack) for instance.

 

[Lepton87]

Ok I'm doing it.

IBT V 2.54 problem size 12GB 88C

Chips abuse

INT: 77C
FLT: 78C after some time 80C

 

[DrMrLordX]

dupe sorry

 

[DrMrLordX]

You see no problem with reported temps being below ambient?

Oh, there's plenty wrong there. The reported core temperatures for Kaveri start at 0C @ idle no matter what the idle temperature and goes from there. Here's the best explanation I've seen for this effect thus far.

Prime95 doesn't overvolt Haswell: it's using AVX in general that requires extra voltage. This also applies to IBT (Linpack) for instance.

Right, AVX/AVX2 is the trigger. Wasn't aware that linpack was doing it too, but that does make sense.

Ok I'm doing it.

IBT V 2.54 problem size 12GB 88C

Chips abuse

INT: 77C
FLT: 78C after some time 80C

This confirms my suspicion that the JVM isn't using AVX (IBT most certainly is). Haswell will never get as hot running ChipAbuse. Thanks!

 

[DrMrLordX]

Looks like my decision to use the volatile prefix may be preventing the JVM from using some/all types of SIMD instructions. Hmm! Bears further investigation.

Anyone with an FX chip want to take a crack at it? Or a non-AVX2 Intel chip?

 

[DrMrLordX]

So there's a new build of ChipAbuse available:

https://www.dropbox.com/s/sjpph0gfj7pebyv/chipabuseclasses01282015.zip?dl=0
.class files, just unzip and run abuseme.bat under Windows. Other OSes: java chipabuse.ChipAbuse should work (also works in Windows, obviously).

https://www.dropbox.com/s/o5zbnrsakkw4vmi/chipabusesource01282015.zip?dl=0
source for 01/28/2015 build

virustotal says that the .class archive is legit:

https://www.virustotal.com/en/file/...ecbd7bb68047c75a8028140f/analysis/1422511880/

So what did I change? For starters, nothing: the original ChipAbuse code from 12/30/2014 is still in there, under options 1 and 2 for integer and floating-point code, respectively.

The experimental code might allow the JVM to use SIMD instructions. Your mileage may vary. Will it spit out AVX2 instructions for Haswell CPUs? I have no idea. It is difficult to tell what support any given JVM has for SIMD of any kind.

What follows is some long-winded bloviating.

So, it was obvious from the first build that the JVM was going to aggressively NOOP anything and everything it could. What's interesting is that taking the fully-unrolled loop and rolling it back up prevented NOOPs, as did inclusion of division operations (but division operations stink for heating up the CPU, at least on the chips I have available for testing). And, obviously, using volatile variables prevented NOOPs perfectly well, though doing so either a). slowed the code to a crawl and/or b). prevented the JVM from using SIMD, depending on which variables were made volatile.

After several aborted attempts to work around the problem minus the volatile prefix, I've learned several interesting bits of information. The most interesting tidbit was that using arrays sized larger than 128 entries (actually, my testing was for arrays 256 entries and larger) made code run a lot slower in Oracle JDK8. This also happened if I used a very large array (or a multi-dimensional array with a lot of entries) to periodically feed different values to a 128-entry array. Why? I'm not entirely certain, and it might have been hardware-specific.

I also learned that a 5-dimensional array, while possible, is a pretty bad idea unless you want to watch java eat up ~10 gigs of free memory. OM NOM NOM yeah that didn't make it into the 01/28/2015 build. Oddly enough, doing that was faster/hotter than some of my previous "big array" attempts . . . but I digress.

What I finally settled on doing for the experimental code was keeping the outer loop structure in place, and replacing the unrolled loop with a partially-unrolled loop. I replaced the 128 entry array with a two-dimensional array with 8 and 16 entries respectively. It's all in the source code if you want to check it out.

The end result is that, on my available hardware, the new code produces slightly less heat, but the code execution time is considerably faster, leading me to believe that the JVM really is using some SIMD instructions. It does not appear to be NOOPing anything, and the temps reported with the experimental code are very close to the code from 12/30. What is interesting is that, on my Steamroller A10-7700k, the experimental code is incapable of staying at 100% CPU utilization, which is quite odd. On the E1-2500 Jaguar, the integer experimental code runs hotter than the floating-point experimental code, which is the opposite of what happens when running the code from 12/30 (and the experimental integer code is only 1C off from the 12/30 floating point code).

Not sure what to make of the Jaguar, but my guess is that the experimental code may be hitting a bottleneck on the Steamroller chip. The utilization hiccups on the Steamroller are at their worst when running the experimental floating-point code . . .

Anyway, it would be fun to see this stuff run on some other processors, as always. If you're game I'd like to see your results. Btw, some evidence of how hot Steamroller gets when using the 12/30 code (still the hottest for my chip . . . so far):

https://www.dropbox.com/s/nvjnv2ndkd4tq4a/chipabuse.png?dl=0
ChipAbuse

https://www.dropbox.com/s/z11grkn98vkp6c0/Prime95LargeFFT.png?dl=0
Prime95 Large FFTs

https://www.dropbox.com/s/85jhpbujyzl8mcf/amdlinpack.png?dl=0
AMD linpack

https://www.dropbox.com/s/wvyqrev2bsw374l/y-cruncher.png?dl=0
y-cruncher

As you can see, ChipAbuse beats them all. Bear in mind that the max reported temperatures shown by CoreTemp and CPUID hwmonitor were all set by ChipAbuse. Also, keep in mind that:

CoreTemp is reporting thermal margin as "CPU #0" (Kaveri chips use this figure to track thermal throttling; ~80C thermal margin = throttle time)

hwmonitor is reporting VRM temperatures as "package temperature"

Speedfan is reporting socket temperature as "CPU"

Some programs produce unexpected socket temperatures and thermal margins. For example, Prime95 LargeFFTs managed a socket temperature of 47C, but only a thermal margin of 33C. In contrast, y-cruncher managed a thermal margin of 36C but a socket temperature of only 44C. Strange, but true.

Those tests were all run @ 4.7 ghz, 1.5125v vcore under Windows 10 preview build 9926.

 

[Ramses]

Floating point and Integer, 9590.
They both only show 95% usage, 4.2something ghz.
Ambient at case inlet is 24C.









And this is a 10 min CPU Burn run I did for someone not long ago

 

[SPBHM]

I use Aida with FPU only selected to heat my CPU, it seems to go as high or higher than prime95.

 

[DrMrLordX]

I haven't tried Aida64 for CPU heating, but I may add that in to my pool of results.

Interesting results, Ramses! It definitely looks like ChipAbuse got you higher socket temps, though given the variable scale, it's a little hard to tell how they compared on core temperature (obviously the 12/30 floating point code was not the hottest). It certainly looks like the core temps were higher for you using the 12/30 integer code.

Did you try the experimental code at all? I saw solid 100% CPU utilization from the older code on Steamroller, but the experimental code, not so much. It's curious that the older code is failing to peg your CPU at 100%. Front-end bottleneck perhaps?

 

[Sequences]

I don't understand why you are doing this in Java. What does this bring to the table that other existing benchmarks don't already provide?

 

[Ramses]

SIMD integer pulled 99%/4.61/65ghz, 24sec to complete one loop, max temp for 5 loops was 26C over case ambient on the socket.

SIMD FP pulled 99%/4.61/65ghz as well, 27sec to complete one loop, same temps. It did drag HWinfo64 a bit so there might have been some more temp in there but I doubt much.

Not sure what front end bottleneck is, I'm a 990fx sabertooth, gskill 16gb cas7, 840 evo, yada yada all pretty good stuff. I do have all the power management stuff ON in the bios, no OC or such at all, and Win8 is set to Balanced fwiw. Just sold my vid cards to I'm not help on this box beyond this but I'll cook my i7-4510u laptop with it later if you like.

 

[DrMrLordX]

I don't understand why you are doing this in Java. What does this bring to the table that other existing benchmarks don't already provide?

Why not Java? The fact that it produces such high temperatures at all is fascinating in and of itself. Obviously, as noted above, the 12/30 code is not producing SIMD instructions, so it won't trigger the Haswell overvolt. The new code . . . well, if I had an AVX2-capable Haswell here locally, I'd know already.

Besides, it's sort of copypasta from my older Mathtester project, which was Java.

As to what it brings to the table . . . well, for Steamroller, higher temps! It looks like it cooks Piledriver pretty nicely, too. So it helps people to test their cooling setup.

SIMD integer pulled 99%/4.61/65ghz, 24sec to complete one loop, max temp for 5 loops was 26C over case ambient on the socket.

SIMD FP pulled 99%/4.61/65ghz as well, 27sec to complete one loop, same temps. It did drag HWinfo64 a bit so there might have been some more temp in there but I doubt much.

Yeah it tends to hose up Windows which causes lag on monitoring software. Probably scheduler related. Does the same thing for me under Win7 and Win10 on a 7700k. Lubuntu handles it with less hassle.

Not sure what front end bottleneck is, I'm a 990fx sabertooth, gskill 16gb cas7, 840 evo, yada yada all pretty good stuff. I do have all the power management stuff ON in the bios, no OC or such at all, and Win8 is set to Balanced fwiw.

It's not your rig, it's the Piledriver front-end I'm referring to here. It was often discussed as being a source of performance shortfall.

What's interesting about Piledriver is that it has more SIMD registers than Steamroller, I think. Steamroller is supposed to have fewer front-end bottleneck problems, but it has fewer SIMD registers, which may explain the behavior of the different code on the two architectures. Maybe!

Just sold my vid cards to I'm not help on this box beyond this but I'll cook my i7-4510u laptop with it later if you like.

That would be great, actually. Thanks!

 

[DrMrLordX]

I think I have tracked down the reason for some or all of the instances of ChipAbuse running at less than 100% CPU utilization. It boils down to my decision to re-initiate creation of the ExecutorService/Thread Pool per loop requested by the user. I have a quick fix, but it will make the program less user-friendly. I'll implement something once I have the time. Work beckons.

 

[Sequences]

Why not Java? The fact that it produces such high temperatures at all is fascinating in and of itself. Obviously, as noted above, the 12/30 code is not producing SIMD instructions, so it won't trigger the Haswell overvolt. The new code . . . well, if I had an AVX2-capable Haswell here locally, I'd know already.

I'll give you a reason why not Java - the JVM is managed and if you're benchmarking, you want to know exactly what's going on. The JVM takes some of that away from you. There are a ton of JVM flags that can drastically alter an application's behavior and figuring out how the flags work is dark magic. Now that I've entertained your counter question, can you entertain my original?

Stressing a CPU is uninteresting. You can download many programs that can bring your CPU to a crawl. High temperatures can be achieved with poor ventilation. There is also LINX which stresses the CPU quite a bit and I bet it is much more optimized than what vanilla Java can do to the CPU cache. Heck, you can write crappy Java code.

 

[Ramses]

Learning by doing is reason enough, and why I was happy to help what little I can. Lighten up.

 

[SlowSpyder]

Ran the link in the OP. 55 seconds for integer. 53 seconds for FP. Temp during integer test was 37C, FP test was 38C according to Coretemp. That was factory everything, 1.5v and 4.4GHz (didn't turbo at all). SIMD Ineger test 3 - 37C

*edit - Just for comparison I ran HyperPi to 4m just because I figured that'd run for a couple minutes so the temps should jump and settle. HyperPi, eight instances to 4m maxed out at 25C. So, yea, I think your test makes a CPU work pretty hard.

 

[DrMrLordX]

I'll give you a reason why not Java - the JVM is managed and if you're benchmarking, you want to know exactly what's going on. The JVM takes some of that away from you. There are a ton of JVM flags that can drastically alter an application's behavior and figuring out how the flags work is dark magic. Now that I've entertained your counter question, can you entertain my original?

I already answered it, really. It's a snippet from another project (Mathtester) that just happened to burn up my CPU like nobody's business. Like . . . hotter than Prime95, y-cruncher, linpack . . . everything.

Stressing a CPU is uninteresting. You can download many programs that can bring your CPU to a crawl.

Uninteresting to you, maybe! I am fascinated by programs that cause so much heat as to push CPUs into instability. Besides, ChipAbuse isn't that great as a stress-tester since it does little to nothing to test the memory subsystem or uncore/NB. It's more of a curiosity to push cooling solutions to their limits. I HAVE crashed my machine with ChipAbuse before, and the crashes are . . . weird.

High temperatures can be achieved with poor ventilation.

That is so not the point.

There is also LINX which stresses the CPU quite a bit and I bet it is much more optimized than what vanilla Java can do to the CPU cache.

I acknowledge that linpack is (to the best of my knowledge) still bringing more heat to Haswell thanks to Haswell's habit of overvolting itself when executing AVX2 code. I am hoping (fingers crossed!) that the SIMD-capable code can induce the JVM to spit out AVX2
instructions, thus causing the overvolt.

On the limited selection of non-Haswell CPUs I've seen run ChipAbuse thus far, ChipAbuse soundly beats linpack's max temps. Which is pretty awesome. I mean, who'd a thunk Java could do that? I sure didn't.

Heck, you can write crappy Java code.

Believe me, I have! You should have seen early iterations of Mathtester . . .

I will also concede that certain things, such as avoiding annoying NOOP behavior by the JVM, can be avoided by using a different language, like C++. I may explore that option in the future.

Learning by doing is reason enough, and why I was happy to help what little I can. Lighten up.

And I'm always glad that you're willing to run my insane experiments. Or, in the case of GPUPI, _mat_'s brilliant benchmark.

Ran the link in the OP. 55 seconds for integer. 53 seconds for FP. Temp during integer test was 37C, FP test was 38C according to Coretemp. That was factory everything, 1.5v and 4.4GHz (didn't turbo at all). SIMD Ineger test 3 - 37C

*edit - Just for comparison I ran HyperPi to 4m just because I figured that'd run for a couple minutes so the temps should jump and settle. HyperPi, eight instances to 4m maxed out at 25C. So, yea, I think your test makes a CPU work pretty hard.

Thanks! Yeah I expect that turbo won't engage while running this thing. I find your FP results to be . . . interesting. Hmm! No matter. ChipAbuse isn't about performance testing, it's just about heat, so the loop completion times will vanish in future versions. But the temps should go a wee bit higher.

 

[DrMrLordX]

New build of ChipAbuse (01/31/2015):

https://www.dropbox.com/s/1wbv5svebne68o2/chipabuseclasses01312015.zip?dl=0
.class files. Same method of operation, except for changes noted below.

https://www.dropbox.com/s/fn6z1p3x8yfy99h/chipabusesource01312015.zip?dl=0
source files.

I altered the way the loops are initialized via an ExecutorService. I originally borrowed this code from Mathtester which creates a new ExecutorService and spawns 48 worker threads, twice (once for warmup, then once more for actual code execution). Then it disposes of the ExecutorService (well, it's supposed to anyway). Previously, ChipAbuse used this thread execution model as well, and I just looped the method that created the ExecutorService. The end result was that I'd get a lull in temps as the code migrated away from mathematical operations and looped back through the ExecutorService creation process.

So, I just made the worker threads infinite loops and got rid of the code warmup segment. I also removed all user input regarding user choice in # of loops. The program no longer runs a timing loop, either. It was never meant to benchmark performance, anyway.

Overall, it seems to run hotter this way with fewer dips in CPU utilization. The SIMD-capable (?) code now runs a solid 100% on my 7700k unlike the 01/28/2015 build.

 

[Ramses]

Enter 1 to begin the integer abuse program.
Enter 2 to begin the floating-point abuse p
Enter 3 to begin the experimental SIMD-enab
Enter 4 to begin the experimental SIMD-enab
Enter x to exit.
1

Let's kick the tires and light the fires bi

Enter ctrl-c at the prompt to terminate the
Exception in thread "main" java.util.NoSuch
at java.util.Scanner.nextLine(Unkno
at chipabuse.ThreadHandler.runloops
at chipabuse.ChipAbuse.operator(Chi
at chipabuse.ChipAbuse.main(ChipAbu
Terminate batch job (Y/N)?

i7-4510u lappy seemed to hang on test 1, it did the first time run and I killed it at about three minutes in. UI was wigging out from processor being tied up, really shows how much more a$$ the 9590 has along with it's huge power appetite. Once the UI caught up it seems to have hit 65C or so across the board. I assume it shouldn't have stuck on the first run timed test for so long?

 

[DrMrLordX]

Enter 1 to begin the integer abuse program.
Enter 2 to begin the floating-point abuse p
Enter 3 to begin the experimental SIMD-enab
Enter 4 to begin the experimental SIMD-enab
Enter x to exit.
1

Let's kick the tires and light the fires bi

Enter ctrl-c at the prompt to terminate the
Exception in thread "main" java.util.NoSuch
at java.util.Scanner.nextLine(Unkno
at chipabuse.ThreadHandler.runloops
at chipabuse.ChipAbuse.operator(Chi
at chipabuse.ChipAbuse.main(ChipAbu
Terminate batch job (Y/N)?

i7-4510u lappy seemed to hang on test 1, it did the first time run and I killed it at about three minutes in. UI was wigging out from processor being tied up, really shows how much more a$$ the 9590 has along with it's huge power appetite. Once the UI caught up it seems to have hit 65C or so across the board. I assume it shouldn't have stuck on the first run timed test for so long?

Actually, the UI hanging up is pretty common on some machines. It really kicks the crap out of the E1-2500 running Win8.1 that I sometimes use as a guinea pig. Your best bet is to use something with temp logging which should catch up and give you a peak temperature (even lowly coretemp will work for that). Your best bet is to be patient and wait for the UI to give you enough priority to bring your temp monitor program to the foreground, where it may have a chance to update. It may take several minutes to get an accurate temperature reading. Also, sorry about the inelegant exit for the program. Cutting off an infinite loop is ugly business.

Hmm, that chippie has AVX 2.0 . . . any chance you could try options 3 or 4 to see if it overvolts? Do the laptop Haswells exhibit that behavior? Also, I wonder if that chip was throttling itself at all to stay within TDP? Or is that more of a Broadwell-Y thing . . .

 

[Ramses]

Don't know, I haven't used it long and haven't had an Intel CPU in a loooong time, but I can log all that (in theory) with hwinfo64. Might take me a few days but I'll get it done.

 

[DrMrLordX]

I use Aida with FPU only selected to heat my CPU, it seems to go as high or higher than prime95.

I finally got around to trying Aida64. The best I managed was using the FPU + GPU stress (7700k has an iGPU):

https://www.dropbox.com/s/0iig8v0bnozu0c3/aida64.png?dl=0

In contrast, the latest ChipAbuse turned in these scores (without touching the iGPU):

https://www.dropbox.com/s/nvjnv2ndkd4tq4a/chipabuse.png?dl=0

Same socket temp, but +15C thermal margin on ChipAbuse.