New Multi-Threaded Pi Program - Faster than SuperPi and PiFast

[mAJORD]

Performance improvement over Version's on K10.5 (Thuban; 6 Cores 3.9ghz DDR3 1333)


Avg of 3 runs each
25M Digits

v0447 v052 v053
9.28s 8.18s 6.99s


v0447 - v052: 13.37%
v052 - v053: 16.98%

v0447 - v0.53: 32.62%

[sRHunt3r]

Not sure how active this thread still is but I ran the 25mill on both my overclocked i7 920 @ 4.5 and my SR-2 dual X5680's @ 4.3 ... here is a screenshot of the results:



I would run the larger ones but these are both crunchers

[mAJORD]

3.8s, wow. 1# 25M

you should do just a couple of the larger ones, go on

[poke349]

Not sure how active this thread still is but I ran the 25mill on both my overclocked i7 920 @ 4.5 and my SR-2 dual X5680's @ 4.3 ... here is a screenshot of the results:



I would run the larger ones but these are both crunchers

Wow!!!

I'm in China right now and I don't 24/7 internet access. So I'll add that to the chart later.

[sRHunt3r]

I ran a few more from 50 million up to 1 billion, here are the results:







I will be upping the clocks a bit once I get the full cover board block for it

[Konokrad]

Validation Version:    1.1

Program:               y-cruncher - Gamma to the eXtReMe!!!     ( www.numberworld.org )
                       Copyright 2008-2010 Alexander J. Yee    ( a-yee@northwestern.edu )


User:                  Konokrad


Processor(s):          Intel(R) Core(TM)2 Quad CPU Q6600 @ 2.40GHz
Logical Cores:         4
Physical Memory:       4,293,357,568 bytes  ( 4.00 GB )
CPU Frequency:         3,510,065,551 Hz

Program Version:       0.5.3 Build 9134b (fix 2) (x64 SSE3 - Windows)
Constant:              Pi
Algorithm:             Chudnovsky Formula
Decimal Digits:        500,000,000
Hexadecimal Digits:    Disabled
Threading Mode:        4 threads
Computation Mode:      Ram Only
Swap Disks:            0
Working Memory:        2.42 GB

Start Time:            Wed Jul 21 12:44:48 2010
End Time:              Wed Jul 21 12:50:54 2010

Computation Time:      341.262 seconds
Total Time:            366.486 seconds

CPU Utilization:           380.15 %
Multi-core Efficiency:     95.03 %

Last Digits:
3896531789 0364496761 5664275325 5483742003 7847987772  :  499,999,950
5002477883 0364214864 5906800532 7052368734 3293261427  :  500,000,000

Timer Sanity Check:        Passed
Frequency Sanity Check:    Passed
ECC Recovered Errors:      0

----

Checksum:   48b3ee6c258c1ce81ba44fdfc5736d78a6bc806e9450622304de1a38e4c441ba

[poke349]

Nice results everyone!

I'll update the list later since I'm at the airport in Shanghai right now answering from my uncle's iPad.

p.s. v0.5.4 ETA: 2 weeks

[mAJORD]

Nice, what's it bring?

[poke349]

Nice, what's it bring?

Nothing big unfortunately. (for benchmarks at least)

I added a checkpointing feature to allow interrupted Advanced Swap Mode runs to be restarted at certain points without starting all over from the beginning.

I also beefed up the fault-tolerance in the program. So it's better able to auto-recover from errors. This doesn't make it easier to pass a run on unstable hardware since all errors will still be flagged in the validation file.

V0.5.4 has actually been ready for quite a while, but I'm still waiting for a few more "tests" to finish...

I've been really busy lately with graduation and running all over the place from SF to Seattle to Beijing...
In have big plans for v0.6.x, (AVX + maybe FMA and XOP), but it's still a long way away.
I swear I'm gonna learn mandarin before v0.6.x is ready... lol

Btw, still on my iPad...

[Alpha]

weeee!!!

[madcho]

Q9550 Yorkfield @ evrything stock 45nm
4x2Go Gskill DDR2 PC800.
Win 7 64bits up to date.

( compute time no total )
y-cruncher (x64) 1 000M : 776.465 seconds

Last Digits:
6434543524 2766553567 4357021939 6394581990 5483278746 : 999,999,950
7139868209 3196353628 2046127557 1517139511 5275045519 : 1,000,000,000

500M : 345.086 s
250M : 156.247 s
100M : 54.245 s
50M : 25.261 s
25M : 11.236 s

Runned in a a batch.
Hope this is good times.

[poke349]

@ Alpha:

Woah, since when did you get a pair of skulltrail chips?


@ madcho:

Are those really at stock? They seem a bit fast. But then... it's the first single-socket Core 2 benchmark of v0.5.4 that I've seen.

[Alpha]

Since I was allowed to bring them to test in my tempest they work btw!! Going to have to bring them back as soon as we find a working board then I get to use them at work. Vendor samples are awesome!

[poke349]

Since I was allowed to bring them to test in my tempest they work btw!! Going to have to bring them back as soon as we find a working board then I get to use them at work. Vendor samples are awesome!

Nice... I wish I got stuff like to play with at school... lolz
I dunno though. Since I'm gonna be in the parallel computing department at UIUC in about 2 weeks... who knows what I'll get to play with. (if anything)


And about v0.5.4:

ETA: 40 hours

And if all goes well, there's gonna be a little more than just v0.5.4.
It'll also explain why I'm fairly precise with the release time/date...

[Necetra]

I have say, very sexy program. Thanks!

[poke349]

Alright everyone... Get a load of this!!!

Full announcement article:
http://www.numberworld.org/misc_runs...nounce_en.html

Chinese and Japanese versions will available shortly.
EDIT: Chinese version is up. Still working on the Japanese version.




Ignore the CPU utilization %. The computation was not done in one run so the measurement got screwed up... It was hard to do this in one run anyways...
And ignore the sanity check error - probably also caused by not doing it in one run... And I think the internal timers become inaccurate after such a long time...

EDIT: I found the cause of the sanity check error. The C++ "clock_t" timer variable overflows after 24.8 days...

But the CPU utilization % does not use the "clock_t" timer nor should it be affected by breaking up the computation into multiple runs...
I know for sure it can't be that low, so it might be a OS bug or something... I dunno...
These things just aren't meant to run for such a longass time... lolz



And with that, version 0.5.4 is released.

I also release a new program called y-cruncher BBP.
As well as source code that will read the compressed .ycd digit files.

[Calmatory]

What are you using clock_t for in y-cruncher? :o At least the clock in ctime.h is useless for anything precise.

[poke349]

What are you using clock_t for in y-cruncher? :o At least the clock in ctime.h is useless for anything precise.

It uses it as part of the timer-hack detection. For all other purposes, it uses the performance counter - which is more accurate than ctime.h.

EDIT:
The Sanity Check Error is just a flag that comes out if the program thinks the clock has been tampered with. It's only purpose is in competitive benchmarking - which is irrelevant to this run.
So in the case of the overflow after 24.8 days, it wraps around - which has the same effect of setting the clock back 24.8 days (several times within a 90 day period).

[Calmatory]

Ah, thanks for clarification. Just implement a safeguard so it won't happen again. :P

It would be just SO great to have yc in HWBot or similar, with several hours long runs just to keep people pouring their LN2 overnight.

[poke349]

Ah, thanks for clarification. Just implement a safeguard so it won't happen again. :P

It would be just SO great to have yc in HWBot or similar, with several hours long runs just to keep people pouring their LN2 overnight.

Yeah, I've made that change for v0.5.4.9147. I'll probably release it soon.
So now, after 24 days, part of the timer-hack detection is simply disabled. Which is probably fine, because no competitive benchmark is gonna to run that long anyway... That'd be a LOT of LN2...


So about Linux... No matter what I do, I can't get my machine to boot reliably into Ubuntu. It would work a few times after a fresh install (even on it's own physical drive with no other partitions).
But as soon as I even touch the hardware... and boot into a drive that has Ubuntu installed...
It will hang on boot...
or it will say "No Operating System Found"


Now, no matter what I do, no matter what drive I install Ubuntu on (and I have 10 drives in that machine), I can't ever get the machine to boot into Ubuntu unless it's from the CD...


So I tried using Wubi:
First time I installed it on my D drive (not my SSD boot drive).
I get the following on boot:
"ALERT! /host/ubuntu/disks/root.disk does not exist. Dropping to a shell! "

Second time I install it on my C drive: And it seems to work.
So I boot back into Windows to uninstall some stuff and free up space on my C drive (it's and SSD). Then I uninstall and reinstall Wubi with a bigger size... and now I get the same error...
"ALERT! /host/ubuntu/disks/root.disk does not exist. Dropping to a shell! "

Help?

[Calmatory]

Hm, I haven't ever used Wubi myself, and its some time since I last used Ubuntu extensively. Have you tried unplugging all but one drive and booting straight from the disc and installing Ubuntu that way?

Just back up everything you'd ever miss if all went gone, swapping drives and installing stuff and messing with bootloaders has caused me too much lost work.

[poke349]

Hm, I haven't ever used Wubi myself, and its some time since I last used Ubuntu extensively. Have you tried unplugging all but one drive and booting straight from the disc and installing Ubuntu that way?

Just back up everything you'd ever miss if all went gone, swapping drives and installing stuff and messing with bootloaders has caused me too much lost work.

I tried that yesterday and got it work for one or two boots. And after fiddling it around for a few hours, I got it to work once with all the drives in.
But then I switched a couple drives around today, and I haven't been able to get it boot at all - even on it's only physical drive. (except from the CD itself)

So right now, it seems like the only reliable way I can boot into Ubuntu is from the CD. At least for my workstation that is...

I'll try to get Wubi to work on my laptop first. If that works (reliably), then I can do all the compiling on my laptop and do only tests/runs on my workstation.

Since the Ubuntu that Gomeler linked me seems to already have NTFS write support, I should be okay with doing tests by booting from only the CD.

[Calmatory]

I would recommend just booting off the CD and using the stand-alone installer to install the OS and bootloader. I believe it to be the most reliable way, even though I have no experience from using Wubi myself.

The Ubuntu forums are a great source of help and information, if you need some.

[poke349]

I would recommend just booting off the CD and using the stand-alone installer to install the OS and bootloader. I believe it to be the most reliable way, even though I have no experience from using Wubi myself.

The Ubuntu forums are a great source of help and information, if you need some.

That's actually the first thing I tried. After installing it from the CD, it would reboot to finish the installation. That works.

But after I login the first time, and then reboot. It says, "No Operating System Found". I've made sure that the boot order is correct.

I also had disconnected the SSD which has Windows on it - to make sure it would try to boot on the Linux drives.


When I tried it again today, I didn't even get the "No Operating System Found" error.
It would just flash the underscore "_" and hang - forever.


I've been looking at the ubuntu forums a lot today. So far, nothing helpful... I'll keep searching...

[Calmatory]

Arr, I'm not happy with the topic, but while reading through Agner Fog's recent thoughts on Intel compiler and software, it seems that the reason why the GNU compiler was slower than Intel compiler is that the GNU compiler has sub-par performance in Windows environment compared to Linux environment. Since most of the code is in C, the GCC should actually be faster than Intel C compiler, while Intel may be slightly ahead with their C++ compiler.

Here's the actual quote:

In my test of the optimizing performance of C++ compilers, the Intel compiler and the Gnu compiler for Linux shared the first place. Unfortunately, the Gnu compiler for Windows is not up to date so we still need a good replacement for the Intel compiler for Windows.

So, if there's ever going to be linux version compiled with GCC, it could potentially mean that there might be some performance gain for AMD users.