Overclock.net banner

1 - 6 of 6 Posts

·
Registered
Joined
·
1,223 Posts
Discussion Starter #1
Here's a benchmark I wrote over a year ago, and I've been using it in my reviews ever since. Simply put, it is based on 3D Random Movement algorithms. There are a fair few when looking at the literature, and all use a variety of different mathematical formula to achieve the same result. Some are more trigonmetric heavy, some use random numbers generated using normal or variable distribution algorithms. When moving a single item a few spots, the speed of each algorithm is of no concern, but when you move into scientific computing and have to deal with billions, having the best algorithm for the job is on the table.

So this is the 3D Particle Movement benchmark, 3DPM for short, which uses 6 of these algorithms so find the best speeds.

The benchmark comes in two varieties:

a) 3DPM-ST: Single Thread mode, where one thread is generated
b) 3DPM-MT: MutliThread mode, where the CPU has to be able to cope with >10000 threads.





If anyone at OCN is interested, I am in the process of organising integration of this benchmark into HWBot.
Submissions to HWBot will be the usual CPU submission process - screenshot with CPU-Z of CPU and CPU-Z of Memory.
The benchmark does produce an file, which I will be writing a website for shortly.

But for now, here are the poignant links:



Still in alpha phase on HWBot, for now
wink.gif
You guys are the first to get access.

Results page for 3DPM-ST: http://hwbot.org/benchmark/3dpm-st
Results page for 3DPM-MT: http://hwbot.org/benchmark/3dpm-mt

The download page: http://www.borandi.co.uk/3DPM

Submission for 3DPM-ST: http://hwbot.org/submit/benchmark/3DPM-ST
Submission for 3DPM-MT: http://hwbot.org/submit/benchmark/3DPM-MT

Edit: For those wondering why AMD doesn't score so high... AMD architecture loves integer (whole number) operations, especially when parallel. This benchmark was written in floating point (FP) operations, which is the usual standard for scientific programming depending on the algorithm.
 

·
Premium Member
Joined
·
2,465 Posts
The AMD really takes a bath with this benchmark, my SB Celeron daily at stock can beat a FX8350. Here is a screen from the SingleThread version for you

 

·
Registered
Joined
·
1,223 Posts
Discussion Starter #3
Any issues? Can you see the submission page/link on HWBot?

Edit: From my review results, it just shows how the floating point speed on Bulldozer went down after Thuban. It's a real shame.
 

·
Premium Member
Joined
·
2,465 Posts
Couldn't find the submission in my history but found it here...

http://hwbot.org/submission/2407845

Doesn't even show up in the submission history for the benchmark, I guess because of the Alpha stage?

Have you thought of maybe adding a number of different algorithms (FP, whole number, etc) and then combining the score? Maybe something heavy RAM speed dependant (not even a clue if there is such a thing). Might make it more even with CPUs that dominate in a certain set of calculations.
 

·
Registered
Joined
·
2,718 Posts
Ran the ST and MT on a Q6600 @ 2.7ghz


Will run the same on my sig right later
thumb.gif


EDIT: Ran on sig rig
 

·
Registered
Joined
·
1,223 Posts
Discussion Starter #6
Quote:
Originally Posted by Rasparthe View Post

Couldn't find the submission in my history but found it here...

http://hwbot.org/submission/2407845

Doesn't even show up in the submission history for the benchmark, I guess because of the Alpha stage?
Yeah, that's the downside of alpha.
Quote:
Have you thought of maybe adding a number of different algorithms (FP, whole number, etc) and then combining the score? Maybe something heavy RAM speed dependant (not even a clue if there is such a thing). Might make it more even with CPUs that dominate in a certain set of calculations.
3D direction algorithms do not particularly lend themselves to INT ops - for the most part you're dealing with a sphere of radius 1 and then choosing angles/directions to fractions of degrees. Some of the random number generators are INT derived, but in the end you always divide the number by RAND_MAX (which is either the length of a SINGLE or a DOUBLE) to get a fractional value between 0 and 1.

At PJs request I attempted to make a version more memory dependant, but the nature of these algorithms is such that they are best ported to GPU. So GPU version inbound soon, using C++ AMP to make it vendor agnostic.
 
1 - 6 of 6 Posts
Top