H
Housechen
Gast
Nicht "die richtige". Es gibt im schlimmsten Falle Differenzen im einstelligen Bereich. Alles andere ist entweder falsche Montage, WLP falsch aufgetragen oder ausgetrocknet.
Burning CPU [BETA]
- Ersteller Sakeco
- Erstellt am
Vllt. war deine alte WLP schon angetrocknet und wirkte eher wärmeisolierend? 
stonix015
Lt. Commander
- Registriert
- Jan. 2008
- Beiträge
- 1.773
meine kriterien für ein taugliches benchmarkprogramm ist eine gute Belastung für den PC.
Am besten beschäftigt sich man mit features von modernen CPUs, wie zum Beispiel SSE, oder die ganzen neuen ALUs, es geht nicht darum die 1mio-ste Wurzel aus 1mio zu ziehen, sondern möglichst Aufgaben zu stellen, die den Prozessor gut einheizen!
Und da ist das Programm "Burning CPU" nicht gut für geeignet, seine Namengebung ist also gewiss verfehlt.
Am besten beschäftigt sich man mit features von modernen CPUs, wie zum Beispiel SSE, oder die ganzen neuen ALUs, es geht nicht darum die 1mio-ste Wurzel aus 1mio zu ziehen, sondern möglichst Aufgaben zu stellen, die den Prozessor gut einheizen!
Und da ist das Programm "Burning CPU" nicht gut für geeignet, seine Namengebung ist also gewiss verfehlt.
Pelzameise
Sachse
- Registriert
- Apr. 2008
- Beiträge
- 5.221
Deine Fragen/Aussagen wurden hier schon zur Genüge besprochen. Übrigens benutzt man ein Benchmarkprogramm nicht, um den PC möglichst gut auszulasten, sondern um die Leistung des PCs mit der anderen zu vergleichen. Und dazu wurde dieses kleine Tool auch nicht gemacht.Fakt ist aber, dass dieses Tool bei manchen schneller als andere Fehler aufgezeigt hat, und deshalb zumindest als Ergänzung zu Prime & Co dienen kann.
H
Housechen
Gast
Pelzameise schrieb:
Das eine setzt das andere aber voraus.
Und ich bezweifle, dass der Rechner bei den anderen wirklich hängen beblieben ist, sondern aufgrund der Echtzeitpriorität einfach nicht mehr aufnahmefähig war. Beim Benchmark ansich gab´s ja komischerweise nie Probleme, da wartet man dann fleißig.
Hinzu kommt noch der Sprachfaktor, und der macht das Programm von grundauf nutzlos.
Und rolleyes können wir hier nicht gebrauchen.
H
Housechen
Gast
@vander: Ach ja, da gibt es ja auch noch den "Denkfaktor"...
@sp33d: Danke für die richtige Erläuterung. Manche verstehen es halt einfach nicht, naja, wenn ein Faktor null ist...
@sp33d: Danke für die richtige Erläuterung. Manche verstehen es halt einfach nicht, naja, wenn ein Faktor null ist...
Ahh, ... Wenn man erstmal weiß was du meinst, dann werden deine Stummelsätze direkt verständlich und das mit dem Nullfaktor beziehe ich mal auf das Zitat aus meinem letzten Posting 
Bleibt noch die Frage ob Net als Programmierumgebung für Benchmark oder Stresstestprogramme ungeeignet ist. Du schreibst das dir die Sprache nicht nah genug an der Hardware ist. Das ist zweifelsfrei richtig, aber ist das für einen Benchmark/Stresstest den wirklich nötig? Letztendlich erzeugt auch der JIT bzw. NGEN Binärcode der direkt auf der CPU läuft, anders ginge es ja wohl auch nicht
Wenn der Kompiler gut ist, dann wird er versuchen die vorhandene Hardware optimal zu nutzen. Und ob ich per Assembler die entsprechenden Register von FPU, MMX usw. anspreche oder ob der Kompiler entsprechenden Programmcode erzeugt ist ziemlich Wurst. Die direkte Kontrolle über die CPU braucht man IMHO nicht wenn man der CPU lediglich einheizen will. Übrigens lassen sich in einer Hochsprache viel einfacher Techniken wie Multithreading umsetzen und hochoptimierter Assemblercode kann auch via [DllImport("myASMburner.dll")] aus VB.net aufgerufen werden.
P.S. Mich würde mal interessieren woraus deine Argumente bestehen, hast du selber schonmal was geproggt, selbst wenns nur ne Batchdatei wäre, oder bist du Theoretiker?
und das mit dem Nullfaktor beziehe ich mal auf das Zitat aus meinem letzten Posting Bleibt noch die Frage ob Net als Programmierumgebung für Benchmark oder Stresstestprogramme ungeeignet ist. Du schreibst das dir die Sprache nicht nah genug an der Hardware ist. Das ist zweifelsfrei richtig, aber ist das für einen Benchmark/Stresstest den wirklich nötig? Letztendlich erzeugt auch der JIT bzw. NGEN Binärcode der direkt auf der CPU läuft, anders ginge es ja wohl auch nicht
Wenn der Kompiler gut ist, dann wird er versuchen die vorhandene Hardware optimal zu nutzen. Und ob ich per Assembler die entsprechenden Register von FPU, MMX usw. anspreche oder ob der Kompiler entsprechenden Programmcode erzeugt ist ziemlich Wurst. Die direkte Kontrolle über die CPU braucht man IMHO nicht wenn man der CPU lediglich einheizen will. Übrigens lassen sich in einer Hochsprache viel einfacher Techniken wie Multithreading umsetzen und hochoptimierter Assemblercode kann auch via [DllImport("myASMburner.dll")] aus VB.net aufgerufen werden.P.S. Mich würde mal interessieren woraus deine Argumente bestehen, hast du selber schonmal was geproggt, selbst wenns nur ne Batchdatei wäre, oder bist du Theoretiker?
stonix015
Lt. Commander
- Registriert
- Jan. 2008
- Beiträge
- 1.773
bleibt mal ganz ruhig
ich wurde gefragt was für mich kriterien für ein benchmarkprogramm sind, das habe ich beantwortet!
aber nun, um einen pc gut zu testen muss der prozessor sehr gleichmäßig ausgelastet sein, damit jeder sektor überprüft wird
und das ist hier nicht der fall!
ich wurde gefragt was für mich kriterien für ein benchmarkprogramm sind, das habe ich beantwortet!
aber nun, um einen pc gut zu testen muss der prozessor sehr gleichmäßig ausgelastet sein, damit jeder sektor überprüft wird
und das ist hier nicht der fall!
Pelzameise
Sachse
- Registriert
- Apr. 2008
- Beiträge
- 5.221
Wenn man hier im Thread etwas zurück geht, dann kann man in etwa die selbe Diskussion nochmal lesen.
Grantig
Captain
- Registriert
- Okt. 2008
- Beiträge
- 3.552
Das man mit .NET nicht Hardwarenah programmieren kann, halte ich für ein Gerücht.
Ansonsten muss ich aber Cyba_Mephisto zustimmen, er hat vollkommen richtig erkannt, dass Burning CPU wohl keinen Rechner zum Absturz gebracht hat, sondern nur soviele Threads mit Echzeitproirität erzeugt hat, dass für andere Prozesse nur noch sehr wenig Prozessorzeit übrig bleibt, weswegen das System nur noch extrem langsam reagiert.
Ich hab mir mal den Code von Burning CPU im Reflector angeschaut und die Berechnungen die durchgeführt werden sind wirklich nicht sehr anspruchsvoll.
Das sieht man auch daran, dass bei so gut wie allen, die das Tool getestet haben, die CPU Temp. relativ niedrig bleibt, woraus klar wird, dass nicht alle Ausführungseinheiten der CPU voll ausgelastet sind.
Leider taugt dieses Tool deshalb weder als Stresstest, noch als Benchmark.
Ansonsten muss ich aber Cyba_Mephisto zustimmen, er hat vollkommen richtig erkannt, dass Burning CPU wohl keinen Rechner zum Absturz gebracht hat, sondern nur soviele Threads mit Echzeitproirität erzeugt hat, dass für andere Prozesse nur noch sehr wenig Prozessorzeit übrig bleibt, weswegen das System nur noch extrem langsam reagiert.
Ich hab mir mal den Code von Burning CPU im Reflector angeschaut und die Berechnungen die durchgeführt werden sind wirklich nicht sehr anspruchsvoll.
Das sieht man auch daran, dass bei so gut wie allen, die das Tool getestet haben, die CPU Temp. relativ niedrig bleibt, woraus klar wird, dass nicht alle Ausführungseinheiten der CPU voll ausgelastet sind.
Leider taugt dieses Tool deshalb weder als Stresstest, noch als Benchmark.
H
Housechen
Gast
Danke Grantig für die hoffentlich ausreichenden Beweise.
Zum Gerücht:
Nunja, dazu gibt es jetzt 2 Arten zu diskutieren:
1. In .Net (zumindest in VB.Net) hat man keine Möglichkeit, Zeiger zu benutzen. Es gibt außerdem andere Dienste wie den Garbagecollector, die im Hintergrund laufen und über die der Programmierer für diese Anforderungen, die ein solches Programm stellt, nicht die nötige Kontrolle hat.
2. Mal andersherum herangegangen. Gibt es irgendeinen Benchmark/Stabilitätstest usw. dessen Berechnungskern in .Net geschrieben wurde und trotzdem aussagekräftig ist? Oder mal übergreifend, auf Java? Oder eine andere vergleichbare Sprache?
Zum Berechnungskern passend vanders Zitat:
Zum persönlichen Hintergrund:
Ich programmiere selber in C#, VB.net und Java, wobei mein Fokus momentan auf der Entwicklung von "Engines" zur vereinfachten Entwicklung von 2D-Spielen liegt (Menüs bzw. selbst nachgeschriebene "Form"-Klone", die Verwaltung und Bereitstellung von Ressourcen für die einzelnen Spielkomponenten, Kontrolle des Spielablaufes bzw. das Abwechseln von Gameszenes, sowohl untereinander, als auch mit den GUI-Parts), basierend auf C# und XNA.
Dazu muss ich aber auch eingestehen, dass .Net-Code zuerst in eine Zwischensprache übersetzt und dann zur Laufzeit in Maschinencode compiliert wird. Somit ist theoretisch und auch praktisch .Net-Code genauso effizient wie C/++ Code oder irgendwas "hardwarenäheres". Nicht außer Acht zu lassen ist allerdings der 1. Aspekt, der für die Kontrolle, die man über sämtliche Operationen und ihre Arten und Weisen in diesem Anwendungsgebiet haben muss, unumgänglich ist.
Evtl. melden sich ja hier noch einige Programmierer zu Wort, die da tiefer in dieser Hintergrundtechnik stecken, um die Probleme dieser Thematik herauszukristallisieren und zu unterstreichen.
Zum Gerücht:
Nunja, dazu gibt es jetzt 2 Arten zu diskutieren:
1. In .Net (zumindest in VB.Net) hat man keine Möglichkeit, Zeiger zu benutzen. Es gibt außerdem andere Dienste wie den Garbagecollector, die im Hintergrund laufen und über die der Programmierer für diese Anforderungen, die ein solches Programm stellt, nicht die nötige Kontrolle hat.
2. Mal andersherum herangegangen. Gibt es irgendeinen Benchmark/Stabilitätstest usw. dessen Berechnungskern in .Net geschrieben wurde und trotzdem aussagekräftig ist? Oder mal übergreifend, auf Java? Oder eine andere vergleichbare Sprache?
Zum Berechnungskern passend vanders Zitat:
Zum persönlichen Hintergrund:
Ich programmiere selber in C#, VB.net und Java, wobei mein Fokus momentan auf der Entwicklung von "Engines" zur vereinfachten Entwicklung von 2D-Spielen liegt (Menüs bzw. selbst nachgeschriebene "Form"-Klone", die Verwaltung und Bereitstellung von Ressourcen für die einzelnen Spielkomponenten, Kontrolle des Spielablaufes bzw. das Abwechseln von Gameszenes, sowohl untereinander, als auch mit den GUI-Parts), basierend auf C# und XNA.
Dazu muss ich aber auch eingestehen, dass .Net-Code zuerst in eine Zwischensprache übersetzt und dann zur Laufzeit in Maschinencode compiliert wird. Somit ist theoretisch und auch praktisch .Net-Code genauso effizient wie C/++ Code oder irgendwas "hardwarenäheres". Nicht außer Acht zu lassen ist allerdings der 1. Aspekt, der für die Kontrolle, die man über sämtliche Operationen und ihre Arten und Weisen in diesem Anwendungsgebiet haben muss, unumgänglich ist.
Evtl. melden sich ja hier noch einige Programmierer zu Wort, die da tiefer in dieser Hintergrundtechnik stecken, um die Probleme dieser Thematik herauszukristallisieren und zu unterstreichen.
Zuletzt bearbeitet:
Grantig
Captain
- Registriert
- Okt. 2008
- Beiträge
- 3.552
zu 1)
Sowohl in VC++, als auch in C# lassen sich Zeiger benutzen.
Per GC.Collect() lässt sich eine Garbage Collection auch manuell erzwingen (was aber in 99% der Fälle unnötig ist). Objekte lassen sich pinnen, damit sie nicht vom GC verschoben werden.
Mir fällt kein Fall ein, in dem der GC ein Problem darstellt.
Außerdem kann man ja auch Methoden einer C++ Bibliothek importieren.
Zudem kann man in VC++ auch ASM Code inlinen, in C# über Umwege (klick) auch.
zu 2)
Mir fällt nix ein, was aber auch daran liegen kann, dass schon etliche gute Benchmarks und Stresstests existieren und einfach kein Bedarf nach weiteren Programmen dieser Art besteht.
Falls da noch weiterer Diskussionsbedarf besteht, würde ich vorschlagen, dass du vllt. nen extra Thread dazu aufmachst.
Zum einen wird sonst dieser Thread hier unnötig aufgebläht und zum anderen werden dann vllt. mehr Leute auf diese Diskussion aufmerksam, die tiefer in dieser Hintergrundtechnik stecken.
Sowohl in VC++, als auch in C# lassen sich Zeiger benutzen.
Per GC.Collect() lässt sich eine Garbage Collection auch manuell erzwingen (was aber in 99% der Fälle unnötig ist). Objekte lassen sich pinnen, damit sie nicht vom GC verschoben werden.
Mir fällt kein Fall ein, in dem der GC ein Problem darstellt.
Außerdem kann man ja auch Methoden einer C++ Bibliothek importieren.
Zudem kann man in VC++ auch ASM Code inlinen, in C# über Umwege (klick) auch.
zu 2)
Mir fällt nix ein, was aber auch daran liegen kann, dass schon etliche gute Benchmarks und Stresstests existieren und einfach kein Bedarf nach weiteren Programmen dieser Art besteht.
Falls da noch weiterer Diskussionsbedarf besteht, würde ich vorschlagen, dass du vllt. nen extra Thread dazu aufmachst.
Zum einen wird sonst dieser Thread hier unnötig aufgebläht und zum anderen werden dann vllt. mehr Leute auf diese Diskussion aufmerksam, die tiefer in dieser Hintergrundtechnik stecken.
H
Housechen
Gast
Grantig schrieb:
Sagte ich doch.
Mit Kern meinte ich, dass keine Importe aus anderssprachigen Bibliotheken erfolgen. Evtl. habe ich mich falsch ausgedrückt, sorry.
Jetzt zurück zum Programm:
Alle von dir vorgeschlagenen "Kompromissfälle" treten nicht ein. Und selbst die Berechnungen an sich, Sprache hin oder her, konntest du schon als "unvorteilhaft" belegen. Dazu nochmal der Hinweis, dass die allererste Version einfach nur eine Schleife ohne jegliche Berechnung durchlief (pro Thread).
Was mir jedoch Sorgen macht, ist, dass sich die ganzen Nutzer an diesem Programm orientieren und es zum "schnellen und zuverlässigen" Testen der CPU-Stabilität hier empfohlen wird.
Zuletzt bearbeitet:
Maddin1604
Cadet 3rd Year
- Registriert
- Mai 2008
- Beiträge
- 59
Gute Arbeit! Werde das gute Stück bei Gelegenheit und Bedarf auch mal testen. Nehme es auch gleich mal in meine Signatur auf. 
MfG
MfG
