Falls jemand einen Stresstest sucht, der ausschließlich Integer Einheiten abdeckt, hier bitteschön. Einfach mit Doppelklick starten und die Anzahl der Tasks/Threads festlegen, dann mit Enter bestätigen.

Zum selber Kompilieren:

Code:

using System;
using System.Linq;
using System.Threading.Tasks;
 
namespace IntMark
{
    class Program
    {
        static void Main(string[] args)
        {
            Console.WriteLine("Number of tasks:");
 
            // Be careful, no input validation
            int numOfTasks = Convert.ToInt32(Console.ReadLine());
 
            // Generates about 64kb test data
            const long length = 8000;
            long[] array = Enumerable.Range(1, (int)length).Select(x => (long)x).ToArray();
 
            for (int i = 0; i < numOfTasks; i++)
            {
                Console.WriteLine("{0}. Task started...", i + 1);
 
                Task.Factory.StartNew(() =>
                {
                    try
                    {
                        while (true)
                        {
                            long dotProduct = array.Sum(x => x * x);
 
                            // https://www.wolframalpha.com/input/?i=sum(i%5E2,i%3D1..n)
                            if (dotProduct != (length * (length + 1) * (2 * length + 1)) / 6)
                            {
                                throw new InvalidOperationException();
                            }
                        }
                    }
                    catch (Exception ex)
                    {
                        Console.WriteLine("Task aborted with exception {0}", ex.Message);
                    }
                });
            }
 
            Console.ReadKey();
        }
    }
}

Version mit dynamischen Lastwechsel hier: Stresstest für die Integer Einheiten der CPU

Der Test verursacht mit 16 Threads eine Package Power von 180 Watt auf meinem Threadripper, obwohl nur 8 Kerne + SMT aktiviert sind.

Bei welchem Takt?

Zitat von lutari

Bei welchem Takt?

Achso, ich vergaß. 4GHz bei 1.35V.

Hast du mal einen Vergleich mit 8 Threads auf 8 Kernen ohne SMT?

Würde mich interessieren, wie stark sich SMT bei Zen auf den Stromverbrauch auswirkt.
Welchen Threadripper hast du eigentlich?

Kann ich morgen gerne mal testen. Ich habe den 1950X. Der Game Mode ist zur Zeit aktiviert.

Disassemblier mal den Mist. Der Code macht zu viel Pause in .NET. Gib der CPU richtig Zunder mit wenigstens K&R C übersetzt mit gcc oder nimm wenn Du es kannst direkt Notepad++ und übersetze mit masm.

Den Code kann man nicht wirklich disassemblieren, decompilieren mit .NET Reflector. Ist ein .NET Assembly. Aber der Code nimmt auf jeden Fall nicht Teil auf der Assembly mit 24 KByte Intros. Das ist mal sicher


Nicht das .NET schlecht ist, ich mag das auch in C#. Aber um eine CPU zu stressen, ein bischen Hardware näher bitte. DIe Pipelines nutzen. Die sollen ackern, für die Integer. Reihenweise. Und nicht wie im Stau, ersma Schleifenbildung, die Stack Pointer zugange, die Integers nix zu tun, wenn alle vom Autobahnkreuz nicht Sternförmig abreisen. Die werden im Stau nicht heiss, wie Autos, eher kalt Die for int Schleife macht Autobahn gesperrt, nicht mehr und nicht weniger. Das macht die gehörig oft. Dann noch die while kaskadiert und dann auch noch Exception Handling, sicher ist sicher. Wenn man sowas Kleines programmiert für den Zweck, dann braucht man kein Exception Handling.
Für normale Anwendergesicht (Lamer) Programmierung ist das Lehrbuchmäßig, aber ja, für den Zweck zwar ungeeignet der Code. Programmieren macht Spaß, deswegen gebe ich mir die Mühe, meinen Senf dazu zu geben.


Bei Pinball Dreams war ich in Aalborg Denmark der Taktzyklenoptimierer 1991. Für scrollfreies Ruckeln strebt man Schleifenbildung an. Straight down Code lässt die Pipelines brennen, auch wenn die RAM Preise teuer sind. Fleissarbeit, Schleifenbildung zu vermeiden. Das kostet so dermaßen Zyklen, jedesmal über Stack Pointer Alles zu sichern im RAM. Mehr mit den Registern arbeiten. Ausm RAM so viel es eben geht sequentiell lesen, nicht so viel schreiben.

Ich habe gerade nochmal drüber nachgedacht. Es wird kein Maximum Heat Test, aber weil die meisten Rehner, während Lastwechsel abstürzen, wenn die VCORE auf den Kernen steiler abfällt als die Eiger Nordwand, bevor die SPAWAS nachregeln, ist der Code doch gut, Bau Floating Point Arithmetics mit ein. Du weisst, ein Vorzeichenbit, 7 Bit Exponent und 24 Bit Mantisse. Nimm nicht den Datentyp double, nimm float. Wir haben es mit 32/64 bit Prozessoren zu tun und nicht mit 32/16 Bit Prozessoren. Ich habe mal für 10MB Speicher 1100 Mark bezahlt.

Speicher haben wir genug. Bau ruhig mal ein paar Waitstates ein in den Tasks. Ich teste das dann gerne

Sorry, jetzt habe ich Multihreaded erst gesehen in der for int. Sorry. Ja , wegen den Lastwechseln kann das so einige Computer zum Abstürzen bringen. Ich habe damals in Lattice C Assembler Mnemonics mit eingebaut. Compilercode ist erfahrungsgemäß nicht so dolle.

Klar ist das high Level Code, aber man weiß halt nicht, was der Jitter so zaubert im Hintergrund. Wenn ich den Code mit 16 Tasks laufen lassen bei mir, habe ich eine CPU Auslastung von 97-98% und eine TDP von 180 Watt auf 8 Kernen, was schon ziemlich hoch ist.

Ja mach gaussmath App, Integer und Fast Floating Point in.NET. Schön Lastwechsel einbauen. Viele, ganz viele User leben mit BSOD mit instabilen Kisten. Ich kenne keinen Stresstest, der Lastwechsel mit eingebaut hat. Prime 95 kann das bisher am Besten. Da schmieren die Computer ab, wenn einmal kurz die Spawas die abreissende Flanke haben in der Stromversorgung zur CPU.

Das ist mit Lastwechseln ist natürlich eine gute Idee. Wie würdest du das machen? Sleeps oder Cache-RAM Wechsel über die Größe des Arrays?