*Beta* Black Hole Benchmark V5

Virssagòn

VIP Member
Introduction
Three years ago, CF.com was the testing base of my own benchmarking software. Without much knowledge of microprocessors, programming or hardware in general I was able to create a so called 'CPU Benchmark'. With loads of instability issues, bugs and a limited set of tests; it achieved something that we can almost call 'a success'. After several exposures on forums, HWBot.org, reviews and even competitions, the benchmark got known to a lot of geeks, overclockers and enthusiasts.
It wasn't the most reliable and stable benchmark ever created, but it certainly did scale well compared to other similar benchmarks.
The benchmark got more and more forgotten and after W10 came out, we even saw incompatibility issues with the new operating system.

In those three years, I've had very limited time to be active on forums, update the benchmark or even write on my own website... What kept me busy were my studies at the university, currently my third year industrial engineer.

3 weeks ago I decided to pick up where I left off three years ago and use the knowledge I gathered in the past years to rebuild from the ground up; a stable and more reliable benchmark than it was back in the days.


In the meantime, we're again 1 year later, now that I ensured compatibility for Ryzen and kaby lake, the finalizing beta can be tested.

Alpha-Phase *Closed*
An Alpha version is needed for major bug and stability checking as well as measuring the reliability of the benchmark. In this phase, we have no idea of how good or bad every aspect of the benchmark actually is. Suggestions, recommendations (also for the design), comments, theories and whatever are the key for improvement shaping the next version which will be used in a beta stage.
CF.com has been chosen for this closed alpha test-phase, only members of this forum can participate.

Beta-Phase *Running*
The alpha phase is officially over; Now only small bug testing needs to be done for things I didn't see in the development.

Features
  • The original three divisions: Quad-Threaded, Multi-Threaded and Single-Threaded for which the benchmark will test the performance rate using the stated amount of cores.
  • Each of the divisions has a Prime Number test:
This test will measure your CPUs capability to search for prime numbers. It's a number that can only be divided by itself (keeping it a round number) and of course 1. Some examples starting from 1 are: 1, 2, 3, 5, 7, 11, 13, 17, 19, ... The test will search for prime numbers between 1 and 2 million (using the formula Sieve of Atkin limited at 2 million) and repeats this several times. The score depends on how fast it can complete the test. The algorithm uses CPU operations (like modulo, multiplications, divisions, ... We use 64bit integer values) to check every number between 1 and 2 million, looping its way through. A prime numbers is marked as a 'hit' and the rest will report nothing. As our tests run Prime parallel with integer and floating point counters, we estimate that the prime test itself uses 2.5MB of memory for each core.
  • Each of the divisions has a Compression Test:
This test will measure the time needed for the CPU: to compress several looped internal Strings (which are added to a created list), decompress this list and compress the decompressed list again. Complex data-structures are compressed using the zLib data compression library by Jean-loup Gailly and Mark Adler that uses the DEFLATE data compression algorithm which is a combination of the LZ77 algorithm and Huffman coding. There's no limit of compression/decompression size and is until now one of the most used and effective data-compression algorithms with a compression rate of around 4:1 in this particular test.
  • Integer/Floating Point Performance Counters
Running through the two previous tests, there're two kinds of performance counters looping on several other threads (only used in Quad- & Multi-threaded). Those tests include floating point and integer calculations increasing a specific counter while looping through the same calculation. Numbers displayed are the amount of times each calculation (integer/floating point) has been completed during the 2 previous tests. We're using 64-bit integers and floating point numbers (numbers with a fractional part which are handled quite different by the CPU than integers). Operations in these 2 calculations are similar: it adds, subtracts, divides and multiplies these values. Both are good indicators for the raw performance of a CPU. Using much less memory as the prime number test for each running thread.
  • Stress/Stability Test (Premium Feature)
Using similar tests as the above to test the stability of your system on the selected amount of threads. As a cause of stability testing, your CPU will heat up the more threads you select.
  • Supports up to 32 Threads (will be increased to unlimited with the beta version)
  • Designed for W7 and higher
Design
The Design is a creation of Timmie from this particular forum, suggestions on this part of the benchmark are welcome as well.
preview:


Requirements:
  • 64-bit windows (recommended for W7 or higher)
  • Framework .NET 4.0
Posting formalities:
Just like before: the score, an updated CPU-z with CPU clockspeeds and memory-settings, PC-information.


Thank you for the help & participation in our testing phase.

Robbie Pyckhout (Virssagôn)


www.blackholetec.com
Like us on Facebook.
 

Attachments

  • BHBench V5 Beta.zip
    656.3 KB · Views: 18
Last edited:

Virssagòn

VIP Member
First comment on the benchmark: I found my skylake i5 6500 to be scoring very low on Floating point, while ivy bridge, sandy bridge and devil's canyon scored as expected. Scores from other skylake processors are welcome for research!

edit: the sandy, ivy bridge and devil's canyon CPUs were i7s, so I'd be interested to see how i5s with these architectures score.
 

voyagerfan99

Master of Turning Things Off and Back On Again
Staff member
Two suggestions from me:

1. Instead of clicking each time to perform the next step, just have the user click once to run the whole benchmark.
2. When you click the X to close the app you should have it end the process thread. I closed the app halfway through the multithread benchmark and it was still benchmarking in the background. I had to manually kill the process.
 

Virssagòn

VIP Member
Two suggestions from me:

1. Instead of clicking each time to perform the next step, just have the user click once to run the whole benchmark.
2. When you click the X to close the app you should have it end the process thread. I closed the app halfway through the multithread benchmark and it was still benchmarking in the background. I had to manually kill the process.

Thanks for the feedback! I'm working on the second one already.
About the first suggestion, wouldn't that make the benchmark a too long single process? Especially with slower systems? Anyway, breaks Between the 3 maintests also extends the running time, but gives the user some kind of indication that the benchmark is actually running its way through.
 

Virssagòn

VIP Member
The good old Xeon I ran my first minecraft server on years ago... Also the server that hosted BHTec during its birth.

Actually a pretty crappy machine ha
Xeon X3320 @ stock
 
Top