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.
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.
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...
- uses very little integer multiplication. There's usually a dedicated execution unit just for this. So it's mostly idle...
- rarely ever uses integer SSE. There's also a dedicated execution unit for this... So it never gets used...
- 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.
- 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...
- has very little branching. So the branch predictor is mostly idle... (I think this is a huge portion of the chip.)
- 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...)
- never does integer and floating-point at the same time. So one of those execution units is always idle... (except during hyperthreading...
)
- 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...![]()






)
)
Reply With Quote


Bookmarks