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

[Tiltevros]

i dont know if im good in this test but here is my results

[tet5uo]

IT'S ALIVE!

Let er dry up and now It's all good.

Except my Radiators aren't going to be enough to cool these ridiculous 480s I think I'll have to add another 120x2 to get it under control.

BTW the last runs I gave oyu I forgot the memory speed. It's 2000mHz cas 10

[skycrane]

hey poke, ive got a 50b run in the making, but im having problems with it. it got to 54% and shut down and restarted the comp. restarted the comp, and it picked up from the restore point in ycruncher and finished the run, but now its done with the computation, and now is having problems with writing the hex digites to it gets to about 5.3b written, and stops, ycruncher says press any key to continue, i press the any key and it says it again. so i press another key, and it just closes out. and if i start it over again, it pick up from the beginning of trying to write all the hex digits over again and the same thing happens....


btw, i got a few 1tb drives and im going to see how what the speed difference is between my runs and his.

have you seen this in the news section? a 960gb flash drive??
reads/writes upto 1400/1500 MB i bet a few of those would be killers on a run

[poke349]

Is it showing any sort of error message? The only thing that could stop the computation while it's writing digits would be if there isn't enough space on the disk, or if the disk is FAT and the there is a limit on the filesize.

Other than that, I'm not sure.


Flash drive? I see one about the pci SSD...
lolz... wish I had that kind of money...

[pleskinen]

Alex, I have a couple runs for you...
50 million: 12.83 seconds
100 million: 28.49 seconds
Those might be near the top for 4-core machines. Run on a Core i7 at 4.36 GHz, 6GB triple channel at 1600MHz.

50 million:

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:                  None Specified - You can edit this in "Username.txt".


Processor(s):          Intel(R) Core(TM) i7 CPU 920 @ 2.67GHz
Logical Cores:         8
Physical Memory:       6,433,198,080 bytes  ( 6.00 GB )
CPU Frequency:         4,149,712,511 Hz

Program Version:       0.5.4 Build 9148 (fix 1) (x64 SSE4.1 - Windows ~ Ushio)
Constant:              Pi
Algorithm:             Chudnovsky Formula
Decimal Digits:        50,000,000
Hexadecimal Digits:    Disabled
Threading Mode:        8 threads
Computation Mode:      Ram Only
Swap Disks:            0
Working Memory:        317 MB

Start Date:            Thu Nov 11 12:59:23 2010
End Date:              Thu Nov 11 12:59:39 2010

Computation Time:      12.831 seconds
Total Time:            15.364 seconds

CPU Utilization:           705.23 %
Multi-core Efficiency:     88.15 %

Last Digits:
4127897300 0153683630 8346732220 0943329365 1632962502  :  49,999,950
5130045796 0464561703 2424263071 4554183801 7945652654  :  50,000,000

Timer Sanity Check:        Passed
Frequency Sanity Check:    Passed
ECC Recovered Errors:      0
Checkpoint From:           None

----

Checksum:   99d6660827942ace0a36328b6f0918423e869d6d09c88b071496382d5e95c67a

100 million:

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:                  None Specified - You can edit this in "Username.txt".


Processor(s):          Intel(R) Core(TM) i7 CPU 920 @ 2.67GHz
Logical Cores:         8
Physical Memory:       6,433,198,080 bytes  ( 6.00 GB )
CPU Frequency:         4,149,713,791 Hz

Program Version:       0.5.4 Build 9148 (fix 1) (x64 SSE4.1 - Windows ~ Ushio)
Constant:              Pi
Algorithm:             Chudnovsky Formula
Decimal Digits:        100,000,000
Hexadecimal Digits:    Disabled
Threading Mode:        8 threads
Computation Mode:      Ram Only
Swap Disks:            0
Working Memory:        536 MB

Start Date:            Thu Nov 11 12:55:45 2010
End Date:              Thu Nov 11 12:56:17 2010

Computation Time:      28.493 seconds
Total Time:            32.017 seconds

CPU Utilization:           717.55 %
Multi-core Efficiency:     89.69 %

Last Digits:
9948682556 3967530560 3352869667 7734610718 4471868529  :  99,999,950
7572203175 2074898161 1683139375 1497058112 0187751592  :  100,000,000

Timer Sanity Check:        Passed
Frequency Sanity Check:    Passed
ECC Recovered Errors:      0
Checkpoint From:           None

----

Checksum:   3cc2d6e19c87546100b73dc188df9fa42587b362ca1355b404e6682d9e9a0fce

EDIT: Thanks for helping get my account authenticated or validated or whatever.

[NEOAethyr]

This program is bad@ss.
With it I was able to find out that my cpu-nb was way to low for 3ghz.
I was surprised on how much it really needed, it's no wonder I had probs figuering out the prob before.

I run it for about an hour, I let thread 1 test 5 finish and that seems to be good enough, at least for now.
To point it simply, there is no other hardware testing program out there that can test your system like this one in a short time.

The only thing that comes close is running pcsx2 with soft rendering.
And this is alot more reliable for testing.
A good program to figure out those odd probs on your system.
Defently one of my fav testing tools along side s&m now.

It would be nice if test0 was trashed out though because that test doesn't seem to stress anything much.

[pleskinen]

NEO, I agree 100%--any CPU or memory (especially memory) instabilities show up very quickly in y-cruncher. Plus, it's perhaps the most heat-generating program for Intel chips out there, and it's a very good way to compare multi-core processors. The math is way over my head though!

[tet5uo]

Definately a good stress tester. Actually gets my cores slightly hotter than LinX.

[poke349]

This program is bad@ss.
With it I was able to find out that my cpu-nb was way to low for 3ghz.
I was surprised on how much it really needed, it's no wonder I had probs figuering out the prob before.

I run it for about an hour, I let thread 1 test 5 finish and that seems to be good enough, at least for now.
To point it simply, there is no other hardware testing program out there that can test your system like this one in a short time.

The only thing that comes close is running pcsx2 with soft rendering.
And this is alot more reliable for testing.
A good program to figure out those odd probs on your system.
Defently one of my fav testing tools along side s&m now.

It would be nice if test0 was trashed out though because that test doesn't seem to stress anything much.

Glad you like it.

I intentionally made test0 short so that it will immediately catch "very unstable" machines. Just in case someone messed up something, it will fail the first test. Most errors will probably be caught before a test is over, but some won't be caught until the test finishes and fails the global check.

NEO, I agree 100%--any CPU or memory (especially memory) instabilities show up very quickly in y-cruncher. Plus, it's perhaps the most heat-generating program for Intel chips out there, and it's a very good way to compare multi-core processors. The math is way over my head though!

Memory for sure. For CPU, prime95 is slightly better. There are number of other "very synthetic" benchmarks that are more intensive, but they don't really do anything "meaningful". CoreDamage is one I can think of.

It's one thing to make a program that is intensive, but it's another thing to make it do anything useful. (I can make something synthetic that's more intensive than y-cruncher, but it's kinda pointless and unrealistic... I probably can't do it as well as CoreDamage, but you get the idea...)
prime95 tests if a number is prime, LinX/Linpack does linear algebra, y-cruncher computes digits, wprime computes square roots, but CoreDamage doesn't do anything but damage your hardware.

Definately a good stress tester. Actually gets my cores slightly hotter than LinX.

I'm inclined to think that v0.6.x will be more intensive. But I'm not entirely sure. It will faster, but that's because I'm reducing the amount of work, not because I'm better optimizing it to keep the execution units busy...



Basically, the amount of heat and stress a program will produce is pretty much how much of the chip it can keep utilized at all times. I can say for sure that y-cruncher does NOT do a good job of that.

Here's something that might be interesting for the hardware folks:
y-cruncher v0.5.4...

1. uses very little integer multiplication. There's usually a dedicated execution unit just for this. So it's mostly idle...
2. rarely ever uses integer SSE. There's also a dedicated execution unit for this... So it never gets used...
3. does not use the x87 FPU. (except in the non-SSE version) There's a dedicated unit for this... though it probably shares resources with the Floating-point SSE unit.
4. does not saturate the Floating-point SSE Multiply unit. Intel chips starting from Core 2 have a dedicated unit for this that can handle one SSE multiply every single cycle... y-cruncher doesn't even come close to issuing that many SSE multiplies...
5. has very little branching. So the branch predictor is mostly idle... (I think this is a huge portion of the chip.)
6. uses about half of the instruction decoder bandwidth. Both Intel and AMD chips right now can decode and issue about 4 instructions/cycle. y-cruncher only averages 2 instructions per cycle... (according to my profiler...)
7. never does integer and floating-point at the same time. So one of those execution units is always idle... (except during hyperthreading... )
8. has a lot of cache misses. Each cache miss means all execution units go idle for a while. (except during hyperthreading...)

The only thing it makes heavy use of is the memory subsystem.
(which is why everyone says y-cruncher is good for stressing memory )


So there's plenty of room for producing more heat. But that isn't really the point of the program.

v0.5.5 will use floating-point AVX. (maybe FMA as well)
v0.6.x will start making heavy use of integer SSE

I have (on paper) a very aggressive algorithm that will simultaneously utilize integer multiplication, floating-point SSE/AVX, and integer SSE...
How this translates to heat... I have no idea...

[zalbard]

I have (on paper) a very aggressive algorithm that will simultaneously utilize integer multiplication, floating-point SSE/AVX, and integer SSE...
How this translates to heat... I have no idea...

I have a bad feeling about this.
...

Bring it on!

[poke349]

I have a bad feeling about this.
...

Bring it on!

I actually have some code (in a different project) that implements the same overall sub-routine. It generates as much heat as y-cruncher v0.5.4 without any memory access.
So the higher level caches (L2 and up), prefetchers, memory controllers... are all completely idle.
How much heat it will produce with full memory access is up to anyone's guess...

However, "aggressive" doesn't necessarily mean fast. Just from counting up cycles, the algorithm already needs 80% of the run-time of the current algorithm (in v0.5.4) to perform its task. (and that's assuming perfect memory access - no cache misses)
So it doesn't look that great right now. It's gonna need more tuning before it becomes worthwhile to implement.

Also AVX will only double the data-width of floating-point. Integer will stay the same. That's gonna cause problems...
On current machines, mixing floating-point and integer SSE seems to work very well. But since AVX will (eventually*) double-up floating-point, I have a feeling that getting rid of the integer SSE and emulating them with floating-point AVX might end up being faster - in which case all the vector work will be done in the FP-AVX unit and none in the integer SSE.

*I say "eventually", because neither Intel nor AMD will be implementing a full 256-bit wide execution unit for each core on their next gen chips. (according to what I know - and I may be wrong)
It's gonna take another (or more) generations before they actually give each a core a full AVX unit that actually has the same instruction throughput as the current SSE units.
(They did this with SSE back in the Pentium days. SSE didn't get a full 128-bit execution unit until Core 2.)

Anyway... Don't expect to see this algorithm for a while (if at all). It's completely experimental, and will probably be after v0.7.x if it does turn out to be useful. The code-size will be massive (~30,000 - 60,000 lines) and I haven't started it yet.

[zads]

Can anyone help me to run y-cruncher on Linux?
I have only a little experience with Linux OS, I don't even know how to get the program running.
I have Ubuntu installed as dual boot with Windows currently.
I found out after installing Windows that it only supports 2 physical processors.. doh.
I have a basic little system I want to test...

[poke349]

Can anyone help me to run y-cruncher on Linux?
I have only a little experience with Linux OS, I don't even know how to get the program running.
I have Ubuntu installed as dual boot with Windows currently.
I found out after installing Windows that it only supports 2 physical processors.. doh.
I have a basic little system I want to test...

Woah! Nice machine you've got there!

EDIT:
Although that's a very nice system, y-cruncher isn't going to be able to fully utilize it properly since y-cruncher isn't written using MPI. (Message Passing Interface)
MPI (or something equivalent to it) is one of the programming models that are scalable to multi-socket. y-cruncher doesn't use it yet, and it will be a while before it does. (the whole program needs to be redesigned)
But nevertheless, it'll be interesting to see how it runs.


You'll need to launch a terminal window to run y-cruncher. It isn't double-click like in Windows.
The terminal can be found in one of the drop-down menus on top. (It's either "Applications" or the ubuntu icon left of it.)

Once you're got the terminal window open, you need to enter the path of the program. If you're familiar with Windows cmdline, it should be pretty easy to figure out.
(You'll probably want to rename the file to something without spaces.)

If the binary is on the desktop, here's one way to run it:
1. Rename the file from "y-cruncher v0.5.4.9157 (fix 1) (x64 SSE3 - Linux).out" to "ycruncher.out"

2. Open up the terminal and run the following commands:

cd Desktop
./ycrunch.out

If any of the other Linux users here can give a better explanation, it'd be helpful

[amrgb]

Hi poke. Congrats for your efforts on this program.

I don't know if you still bother updating the top 10, but I have a few top 10 benchs.

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:                  None Specified - You can edit this in "Username.txt".


Processor(s):          Intel(R) Core(TM) i7 CPU 950 @ 3.07GHz
Logical Cores:         8
Physical Memory:       25,768,148,992 bytes  ( 24.0 GB )
CPU Frequency:         4,117,589,584 Hz

Program Version:       0.5.4 Build 9148 (fix 1) (x64 SSE4.1 - Windows ~ Ushio)
Constant:              Pi
Algorithm:             Chudnovsky Formula
Decimal Digits:        1,000,000,000
Hexadecimal Digits:    Disabled
Threading Mode:        8 threads
Computation Mode:      Ram Only
Swap Disks:            0
Working Memory:        4.75 GB

Start Date:            Sat Dec 04 13:01:30 2010
End Date:              Sat Dec 04 13:09:11 2010

Computation Time:      435.798 seconds
Total Time:            460.493 seconds

CPU Utilization:           673.59 %
Multi-core Efficiency:     84.19 %

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

Timer Sanity Check:        Passed
Frequency Sanity Check:    Passed
ECC Recovered Errors:      0
Checkpoint From:           None

----

Checksum:   f6bf2a028fe5ef0f0b33e87ff2d07e4ca978640e8f48678a1ee3c40e4f7c7093

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:                  None Specified - You can edit this in "Username.txt".


Processor(s):          Intel(R) Core(TM) i7 CPU 950 @ 3.07GHz
Logical Cores:         8
Physical Memory:       25,768,148,992 bytes  ( 24.0 GB )
CPU Frequency:         4,117,600,815 Hz

Program Version:       0.5.4 Build 9148 (fix 1) (x64 SSE4.1 - Windows ~ Ushio)
Constant:              Pi
Algorithm:             Chudnovsky Formula
Decimal Digits:        2,500,000,000
Hexadecimal Digits:    Disabled
Threading Mode:        8 threads
Computation Mode:      Ram Only
Swap Disks:            0
Working Memory:        11.2 GB

Start Date:            Sat Dec 04 13:09:11 2010
End Date:              Sat Dec 04 13:30:09 2010

Computation Time:      1,195.711 seconds
Total Time:            1,258.296 seconds

CPU Utilization:           683.48 %
Multi-core Efficiency:     85.43 %

Last Digits:
0917027898 3554136437 7123165188 3528593128 0032489094  :  2,499,999,950
9228502005 4677489552 2459688725 5242233502 7255998083  :  2,500,000,000

Timer Sanity Check:        Passed
Frequency Sanity Check:    Passed
ECC Recovered Errors:      0
Checkpoint From:           None

----

Checksum:   c5d0a141ef759c0008c5157a65e28dfaf91c13c1f0ad680e1246bc8be0272c78

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:                  None Specified - You can edit this in "Username.txt".


Processor(s):          Intel(R) Core(TM) i7 CPU 950 @ 3.07GHz
Logical Cores:         8
Physical Memory:       25,768,148,992 bytes  ( 24.0 GB )
CPU Frequency:         4,117,612,391 Hz

Program Version:       0.5.4 Build 9148 (fix 1) (x64 SSE4.1 - Windows ~ Ushio)
Constant:              Pi
Algorithm:             Chudnovsky Formula
Decimal Digits:        5,000,000,000
Hexadecimal Digits:    Disabled
Threading Mode:        8 threads
Computation Mode:      Ram Only
Swap Disks:            0
Working Memory:        22.5 GB

Start Date:            Sat Dec 04 13:35:21 2010
End Date:              Sat Dec 04 14:20:35 2010

Computation Time:      2,583.178 seconds
Total Time:            2,713.828 seconds

CPU Utilization:           710.20 %
Multi-core Efficiency:     88.77 %

Last Digits:
4384678622 1397184596 0181195416 0748430457 5386741865  :  4,999,999,950
0914971996 1298184401 9216126684 9425834935 5440797257  :  5,000,000,000

Timer Sanity Check:        Passed
Frequency Sanity Check:    Passed
ECC Recovered Errors:      0
Checkpoint From:           None

----

Checksum:   b3ab74c20b5e166617949e6c1a95ab9242d054534bf97de5083c12cdfde4dce5

Finally, a screenshot of my system

[poke349]

Wow! 24 GB on a single i7!

I'll update that when I get back to campus.

[Boogerlad]

coredamage stresses the cpu the most, but does y-cruncher stress the ram the most?

[poke349]

coredamage stresses the cpu the most, but does y-cruncher stress the ram the most?

I would think something like memtest would be better. But memtest doesn't put much load on the cores so the less heat might actually make it less stressful than y-cruncher.


@amrgb

Updated Looks like you've got the fastest single-socket time for 5b. Nobody else has enough memory to run it all in ram.

[amrgb]

Lol, I always liked systems will loads of ram.

I have some top ten results for 25M to 250M range at 4.4Ghz too.

But I'll wait a bit to see if I can squeeze anything more out of it before bothering you. You have better things to do. Good luck for your grad studies.

[alpha754293]

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:                  None Specified - You can edit this in "Username.txt".


Processor(s):          Intel(R) Core(TM) i7 CPU X 980 @ 3.33GHz
Logical Cores:         6
Physical Memory:       25,767,911,424 bytes  ( 24.0 GB )
CPU Frequency:         3,373,004,655 Hz

Program Version:       0.5.4 Build 9148 (fix 1) (x64 SSE4.1 - Windows ~ Ushio)
Constant:              Pi
Algorithm:             Chudnovsky Formula
Decimal Digits:        5,000,000,000
Hexadecimal Digits:    Disabled
Threading Mode:        8 threads
Computation Mode:      Ram Only
Swap Disks:            0
Working Memory:        22.5 GB

Start Date:            Tue Dec 07 14:30:25 2010
End Date:              Tue Dec 07 15:12:15 2010

Computation Time:      2,332.598 seconds
Total Time:            2,510.880 seconds

CPU Utilization:           568.25 %
Multi-core Efficiency:     94.70 %

Last Digits:
4384678622 1397184596 0181195416 0748430457 5386741865  :  4,999,999,950
0914971996 1298184401 9216126684 9425834935 5440797257  :  5,000,000,000

Timer Sanity Check:        Passed
Frequency Sanity Check:    Passed
ECC Recovered Errors:      0
Checkpoint From:           None

----

Checksum:   e2fa05997341d0d81549027f063ae681a5b7f80ca8ae578019e97c6ed2dd0367

Corsair XMS DDR3-1333 6x 4 GB
Peak temperature: 62 C.
IntelBurnTest peak temperature: 66 C.

IBT is more intensive still.

*edit*
TurboBoost to 3.46 GHz (3508 MHz according to Core Temp).

[alpha754293]

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:                  None Specified - You can edit this in "Username.txt".


Processor(s):          Intel(R) Core(TM) i7 CPU X 980 @ 3.33GHz
Logical Cores:         6
Physical Memory:       25,767,911,424 bytes  ( 24.0 GB )
CPU Frequency:         3,374,004,047 Hz

Program Version:       0.5.4 Build 9148 (fix 1) (x64 SSE4.1 - Windows ~ Ushio)
Constant:              Pi
Algorithm:             Chudnovsky Formula
Decimal Digits:        5,000,000,000
Hexadecimal Digits:    Disabled
Threading Mode:        8 threads
Computation Mode:      Ram Only
Swap Disks:            0
Working Memory:        22.5 GB

Start Date:            Wed Dec 08 09:22:47 2010
End Date:              Wed Dec 08 10:00:16 2010

Computation Time:      2,145.752 seconds
Total Time:            2,262.404 seconds

CPU Utilization:           564.07 %
Multi-core Efficiency:     94.01 %

Last Digits:
4384678622 1397184596 0181195416 0748430457 5386741865  :  4,999,999,950
0914971996 1298184401 9216126684 9425834935 5440797257  :  5,000,000,000

Timer Sanity Check:        Passed
Frequency Sanity Check:    Passed
ECC Recovered Errors:      0
Checkpoint From:           None

----

Checksum:   febecffde2eddf82192fc62ce8a6e57c61c604cad360bfd20cf0bec5fa8cbbec

OC'd to 4 GHz on air (@1.3875 V I think). (TurboBoost disabled).

Peak temperature: 78 C
IntelBurnTest peak temperature: 85 C

IBT still wins.

*edit*
P.S. Both of my runs are single socket ONLY.

*edit*
Original run at stock with TurboBoost was on an OCZ 240 GB Agility 2 SATA2 SSD.

Original run at 4 GHz was also on the same drive.

This new run was done on a Fusion-io ioXtreme 80 GB SSD PCIe x4 card.

Because of the nature of Windows, it is never truly swap-less by default, so swap was on the Agility while the "working directory" was on the Fusion-io.

Running Windows XP Pro x64.

[poke349]

Nice result!

Interesting, from what I've y-cruncher runs hotter than IBT/Linpack on i7s when HT is enabled. I guess they must have a new version of Linpack that runs better on i7.

I'll update it over the weekend.

Speaking of multi-socket rigs... My workstation managed to kill itself without even running...

I haven't turned it on for 3 weeks. I turn it on today, and it hangs on POST during DRAM testing...
Pulled out all but 1 stick - same result.
Tried with different sticks... same result...

It's already on it's 3rd mobo... I don't think I can trust Tyan boards anymore...

I'm gonna test the two CPUs over the weekend to make sure it's the mobo... Then I have to carry the mobo home during winter break for RMA. (The Tyan RMA lab is a 20 min. drive from my house.)

[amrgb]

alpha754293 is right. This version of y-cruncher runs considerably colder compared to LinX. From the top of my head some 5c.

Have you tried clearing CMOS and remove the battery for 15min or so?

My DFI NF4 did the same every time I went on vacation and let it off for a month. The first time was really scary. Somehow, something was getting corrupted when relying on the battery to keep settings for so long.

[poke349]

alpha754293 is right. This version of y-cruncher runs considerably colder compared to LinX. From the top of my head some 5c.

The current y-cruncher release uses the same arithmetic module as it did a year ago. Since y-cruncher didn't change, then LinX must have.

EDIT:
y-cruncher's arithmetic module is gonna get overhauled between v0.5.5 - 0.7.x.

v0.5.5 - v0.5.?
AVX for sure. Maybe FMA.
y-cruncher will be mostly integer-bound by this point. So don't expect it to be any hotter than v0.5.4.


v0.6.x
The internal 32-bit library will be replaced with a 64-bit version. (which I'm "slowly" working on right now)
A lot more code will be vectorized.
Expect this version to produce more heat.

I'm also gonna try to implement several mathematical improvements. These will make the program faster, but it won't have any effect on how hot it runs.

At around this time, I'll probably be releasing the arithmetic module as a pre-compiled dynamic library for others to use.


v0.7.x
This is still pretty open-ended, but I plan on introducing two new multiplication algorithms. One of which will (on paper), use nearly every single execution unit simultaneously...
How this translates to heat? I have no idea. I talked a little about this a few posts back.


At some point, I'm gonna start experimenting with CUDA 2.0. But that will be later.

Have you tried clearing CMOS and remove the battery for 15min or so?

Not for that long, but it was enough to set the BIOS back to factory settings. Same error.

My DFI NF4 did the same every time I went on vacation and let it off for a month. The first time was really scary. Somehow, something was getting corrupted when relying on the battery to keep settings for so long.

hmm... You have a point here. I'll see during the weekend.

One thing good about these dual-socket machines is that you can debug everything without a second machine with compatible parts...

With sockets and 2 CPUs, I can switch them around (or run them alone). I was able to identify a dead socket (during my 2nd RMA) as opposed to a dead CPU.
Same with all the ram modules.

[alpha754293]

Nice result!

Interesting, from what I've y-cruncher runs hotter than IBT/Linpack on i7s when HT is enabled. I guess they must have a new version of Linpack that runs better on i7.

I'll update it over the weekend.

Speaking of multi-socket rigs... My workstation managed to kill itself without even running...

I haven't turned it on for 3 weeks. I turn it on today, and it hangs on POST during DRAM testing...
Pulled out all but 1 stick - same result.
Tried with different sticks... same result...

It's already on it's 3rd mobo... I don't think I can trust Tyan boards anymore...

I'm gonna test the two CPUs over the weekend to make sure it's the mobo... Then I have to carry the mobo home during winter break for RMA. (The Tyan RMA lab is a 20 min. drive from my house.)

I've only use Tyan boards. I've had more luck with them than Supermicro boards. Although if they were to interchange positions, I wouldn't really be surprised.

Afterall, Supermicro did come out with the quad Socket G34 board long before Tyan got theirs out. (It was an annoying nearly-a-year-long delay....*grumbles*).

The thing with these boards is a) don't OC them. Ever. b) make sure that you have sufficient cooling. The systems typically might cost more than what you would like to spend, but you build it right, there's no reason why you can't run that thing into the ground and it'd be as robust as the Toyota Hilux that Top Gear keep beating on.

alpha754293 is right. This version of y-cruncher runs considerably colder compared to LinX. From the top of my head some 5c.

Have you tried clearing CMOS and remove the battery for 15min or so?

My DFI NF4 did the same every time I went on vacation and let it off for a month. The first time was really scary. Somehow, something was getting corrupted when relying on the battery to keep settings for so long.

The only time my system does something funky like that is with my dual Socket F Opteron workstation. It really hates cold starts. Warm starts, it has no problems with it.

The current y-cruncher release uses the same arithmetic module as it did a year ago. Since y-cruncher didn't change, then LinX must have.

EDIT:
y-cruncher's arithmetic module is gonna get overhauled between v0.5.5 - 0.7.x.

v0.5.5 - v0.5.?
AVX for sure. Maybe FMA.
y-cruncher will be mostly integer-bound by this point. So don't expect it to be any hotter than v0.5.4.


v0.6.x
The internal 32-bit library will be replaced with a 64-bit version. (which I'm "slowly" working on right now)
A lot more code will be vectorized.
Expect this version to produce more heat.

I'm also gonna try to implement several mathematical improvements. These will make the program faster, but it won't have any effect on how hot it runs.

At around this time, I'll probably be releasing the arithmetic module as a pre-compiled dynamic library for others to use.


v0.7.x
This is still pretty open-ended, but I plan on introducing two new multiplication algorithms. One of which will (on paper), use nearly every single execution unit simultaneously...
How this translates to heat? I have no idea. I talked a little about this a few posts back.


At some point, I'm gonna start experimenting with CUDA 2.0. But that will be later.




Not for that long, but it was enough to set the BIOS back to factory settings. Same error.



hmm... You have a point here. I'll see during the weekend.

One thing good about these dual-socket machines is that you can debug everything without a second machine with compatible parts...

With sockets and 2 CPUs, I can switch them around (or run them alone). I was able to identify a dead socket (during my 2nd RMA) as opposed to a dead CPU.
Same with all the ram modules.

I haven't really ran some of the other number of digits yet. I plan on doing so, but not quite yet. Things have been a bit busy at work. The only reason why I'm on here right now is cuz I'm running a FEA in the background, so that'll give me design direction. (But there's another internal issue that we're chasing down...)

Haha...you haven't updated the charts yet.

I'll probably give the 10B and 25B runs a go. On the 25B, I might be the only single processor record up there.

[poke349]

Confirmed, it's the mobo. I took the whole thing apart and did a ton of open air tests on the floor with a static mat.

This time, I don't think it died because of overheating. First of all, it was off. And secondly, the cooling I have on it is more than overkill (out of paranoia).

Tried all combinations of the two processors. (switched, ran each alone in each socket)... all the same result.
If either processor was dead, it wouldn't be seeing the same results for all combinations.

Tried different memory modules - same
Different power supply - same
No video card - same

I got it to work only once, but never again - even under the same settings. So it's going to RMA.

I've had it with this mobo. It was designed for the Clovertowns - never meant for the 150 watt, 1600 FSB Harpertowns...
I'll be ordering SuperMicro's version shortly before getting back from winter break:
http://www.newegg.com/Product/Produc...-155-_-Product

(It's big, so I've made sure it fits in my case.)

It lacks a pcie x16, but I don't game on it anymore (my i7 rig is better for games). I'll just grab the best pcie x8 card I can find to get full resolution, Aero (Windows), and Emerald (Linux).

*God... I'll have two extra video cards sitting around... (GTX 9800+, GTS 250)
One of them will go into my future Sandy Bridge/Bulldozer rig, as well as the extra 1000W power supply I have sitting around.


I'll update the charts tomorrow. lol


I wonder what to do when I get the Tyan board back from RMA.
I might just get a couple of low-end 1333 FSB Harpertowns to fill it. But I can't really justify it because whatever I put in it will be outclassed by my current setup (2 x X5482 + 64GB).

It'll also won't be very useful for my code-development and tuning because it will be identical in architecture to my current setup. (and I want something different)