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.Have you tried clearing CMOS and remove the battery for 15min or so?
hmm... You have a point here. I'll see during the weekend.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.
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.




Reply With Quote

Bookmarks