Multi Core PI @ LINPACK

[t.phase]

I developed a multithreaded CPU benchmark that calculates PI decimals using Bailey–Borwein–Plouffe formula. The benchmark is using a multithreaded algorithm written in C++ and provide excellent parallelism. Multi Core PI is written in Visual C++ using MFC and Win32API.

How it works

A slider will help you set the decimals of PI, from 10.000 to 100.000. Default is 80.000. Just hit Run benchmark button to start benching your CPU.

Submit to HWBOT

First, press Take Screenshot button. A screenshot and a XML datafile will be created. Attention! CPUZ must be running!
Second, follow the link provided on the dialog and submit your datafile to HWBOT.

Supported operating systems

Microsoft Windows XP / Server 2003
Microsoft Windows Vista / 7
Microsoft Windows 8 / Server 2012

Download link

http://www.pcgamingxtreme.ro/

[HammerON]

My results:


100% 12 thread utilization

[Aquinus]

Originally Posted by HammerON

100% 12 thread utilization

I've explained this already multiple times and people seem too ignorant to listen and you're the last person I should need to explain this to.

Disable hyper-threading and run it again, please.

[HammerON]

Wow - that was amazing
My time was increased by almost 100%.... What else would I expect when disabling HT???

[Aquinus]

Originally Posted by HammerON

http://img.techpowerup.org/130210/Capture113.jpg

Wow - that was amazing
My time was increased by almost 100%.... What else would I expect when disabling HT???

Well that confuses me even more. I disable HT on mine and my score goes from 18.5 to 19. :|

HT should never result in 100% improvement. There aren't the resources available to let it scale like that. That should be more like a 15-30% drop in performance on average.

Edit: I lied that was Multi Core PRIME not MC PI, they look exactly the same sans the formula so I didn't notice it off the bat. My skepticism from PRIME worked its way over here. Either way I disabled HT and now it runs slower by about 60%. That's a bit more normal. I'm less skeptical about this benchmark and more about the prime one (unless your storing the output in a float or a double and not a fixed point number, in that case the computer is chugging for nothing). Since floating point numbers are not exact and as you go more decimals in, the precision of further decimals decreases.

4c w/ HT:


4c w/o HT:


Once again is the output being verified? Can you do multiple runs per benchmark to make sure that every runs results are consistent and once again, I would like output so I can verify the benchmarks results so I can put my skepticism at ease. As it stands, something is happening on my rig and I don't know what it is or if it is right.

[uuuaaaaaa]

My Phenom II x6 is slow

[AphexDreamer]

Originally Posted by uuuaaaaaa

My Phenom II x6 is slow

Faster than my FX6100 apparently...

[Aquinus]

Originally Posted by AphexDreamer

Faster than my FX6100 apparently...
http://img.techpowerup.org/130209/Mu...creenShot.jpeg

It's because the FPU is getting used for this benchmark. Keep in mind that each module only has one FPU so without FMA3 optimizations you're only going to see 3-cores worth of performance out of it. However if this used fixed point instead of floating point, this could use the integer cores which are faster in general and performances significantly better on AMD's newer processors. Fixed point also offers a higher level of precision, floating point is inaccurate because of how it converts decimals to and from base 2 integers.

[AphexDreamer]

Originally Posted by Aquinus

It's because the FPU is getting used for this benchmark. Keep in mind that each module only has one FPU so without FMA3 optimizations you're only going to see 3-cores worth of performance out of it. However if this used fixed point instead of floating point, this could use the integer cores which are faster in general and performances significantly better on AMD's newer processors. Fixed point also offers a higher level of precision, floating point is inaccurate because of how it converts decimals to and from base 2 integers.

Which is why I had asked him if he would/could make a more FX optimized benchmark but he said it is FX optimized as it was coded with an FX processor. http://www.techpowerup.com/forums/sh...5&postcount=68

[uuuaaaaaa]

Originally Posted by AphexDreamer

Faster than my FX6100 apparently...
http://img.techpowerup.org/130209/Mu...creenShot.jpeg

I wasn't expecting this. You also have a much higher clock.

[Bo$$]

Maybe looks a little low here

[Melvis]

[CrackerJack]

[Arctucas]

[LAN_deRf_HA]

[lemonadesoda]

Great x86 kernel 5.x compatible!

I think a REALLY USEFUL statistic would be the time / cores / GHz so that we can see the "efficiency" of the FP core!

[t.phase]

[t.phase]

I have implemented encryption for the XML datafile! Now cheaters can't cheat anymore.

Current version is 2.101

Download link:

http://www.pcgamingxtreme.ro/

[rickss69]

[rickss69]

[cadaveca]

Originally Posted by Aquinus

It's because the FPU is getting used for this benchmark. Keep in mind that each module only has one FPU so without FMA3 optimizations you're only going to see 3-cores worth of performance out of it. However if this used fixed point instead of floating point, this could use the integer cores which are faster in general and performances significantly better on AMD's newer processors. Fixed point also offers a higher level of precision, floating point is inaccurate because of how it converts decimals to and from base 2 integers.

PD emulates x87 entirely, hence the slowdown, IMHO. FPU doesn't matter when you aren't capable of running the instruction in the first place.

[t.phase]

I removed the slider.

Default setting for benchmark is 80.000 decimals. The target is to submit to HWBOT and we have to make sure that all users are benching at the same settings [80k decimals]

Download Link:

www.pcgamingxtreme.ro

[Aquinus]

Originally Posted by cadaveca

PD emulates x87 entirely, hence the slowdown, IMHO.

Pardon me, I know what x87 is but I don't know what you mean when you say "PD", could you clarify?

Originally Posted by cadaveca

FPU doesn't matter when you aren't capable of running the instruction in the first place.

I agree but do we know that the benchmark isn't executing x87 instructions in the first place?

Also floating point emulation is worse than just using floating point numbers to begin with. You really need the exact value if you want your result of pi to be at all accurate. As that decimal place goes further out you're going to start losing precision.

[t.phase]

Originally Posted by Aquinus

Pardon me, I know what x87 is but I don't know what you mean when you say "PD", could you clarify?

I agree but do we know that the benchmark isn't executing x87 instructions in the first place?

Also floating point emulation is worse than just using floating point numbers to begin with. You really need the exact value if you want your result of pi to be at all accurate. As that decimal place goes further out you're going to start losing precision.

The application is compiled using Streaming SIMD Extensions 2 (/arch:SSE2) setting in order to replace FPU instructions with SSE code.

[Aquinus]

Originally Posted by t.phase

The application is compiled using Streaming SIMD Extensions 2 (/arch:SSE2) setting in order to replace FPU instructions with SSE code.

SSE still utilizes the FPU, but that answers part of my question. I'm still curious what Cadaveca meant by "PD" though.