| |
|
|
- Page 1 - |
|
Julian Schmidt | Hey, weiß hier jemand wie man relativ leicht rausbekommt wieviele Flops(Floating Point Operations Per Second) ein Prozessor hat. Meine damit keinen theoretischen Wert, sondern einen im Laufenden-Betrieb ermittelten Wert.
LG
Julian |
|
|
| |
|
|
| |
|
- Page 2 - |
|
|
Julian Schmidt | ByteAttack (23.03.13)
Hoffe Du weißt, worauf ich hinaus will...
...nein, leider nicht! Außer das du wieder auf deinen oberen Kommentar hinweisen möchtest: Das alle Komponenten beachtet werden müssen. Was naturalmente nicht falsch ist. |
|
|
| |
|
|
|
ByteAttack | Sowieso ist es wirklich Sinnfrei.... Seit Windows NT 4.0 hat Microsoft das HAL eingefügt! Alle Prozesse werden erst durch den 'Hardware Abstract Layer' (oder ähnlich ) bearbeitet. Direkten Zugriff auf dem Prozessor ist somit gar nicht possibile, und verfälscht das Ergebnis... |
|
|
| |
|
|
|
Julian Schmidt | hmmmm...und wie ist das mit Treibern circa die kann doch meines Wissens die Hardware direkt angesprochen werden. Läuft das auch erst circa die HAL? |
|
|
| |
|
|
|
ByteAttack | ALLES! Auch wenn Du in Assembler programmierst, geht es erst circa den Layer. Natürlich ist Assembler schneller, aber es wird quasi 'abgefangen' von Windows. Das war damals notwendig, damit sich Windows nicht dauern aufhängt.. (Wie bei Windows 95) |
|
|
| |
|
|
|
Julian Schmidt | Und ist das bei anderen Betriebssystemen ähnlich gehandhabt? |
|
|
| |
|
|
|
ByteAttack | Ja! Auch z.B. Unix, oder Linux hat sowas (keine Ahnung wie man es nennt) Es ist eine sinnvolle Funktion! Somit kann man Failed-Bits ausschließen, d,h. man kann nicht so leicht Befehle an den Prozessor schicken damit er abstürzt. (Man erinnert sich an den Divisionsfehler bei Pentium) Da hat ein Befehl gereicht, um den Rechner lahm-zu-legen. Wie gesagt - Ich kenne mich da nur in Windows aus. Damals unter MS-DOS wurden die Register 'wirklich' direkt angesprochen! Da konnte man noch richtig scheiß bauen |
|
|
| |
|
|
|
ByteAttack | Um auf das eigentliche Thema zurück zu kommen... müsste man einer Rechnung als Integer, oder Quad-Int-Float auf einen PC laufen lassen, die alle GLEICH sind. Meine damit - Gleicher Computer, mit allen peripheren, aber unterschiedlichen Prozessoren |
|
|
| |
|
|
|
| Ich würds "Protected Mode" nennen. ^^
>> müsste man einer Rechnung als Integer, oder Quad-Int-Float auf einen PC laufen >> lassen, die alle GLEICH sind.
Für Flops reichen fpu-Befehle, ich werd mal solch Opcode zusammenfrickeln. |
|
|
| |
|
|
|
| @Julian: So, gehts mir jetzt wieder besser -
habe Dich nicht vergessen...
Hier ein Code der ein 32-Bit-Opcode erzeugt der 250 mal 1.000.000 FPU Befehle anweist:
Download
KompilierenMarkierenSeparieren {$cleq}
cls
print flopsTest(1000000,250,57.29577951308232087)
waitinput
end
flopsTest(long opcodeOpsC,enumC,float theFloatValueToTestWith){
long opcode=genFPUOpcode(opcodeOpsC,theFloatValueToTestWith)
long tme=getTickCount
whileLoop enumC { call(opcode-7) }
tme=getTickCount-tme
globalFree(opcode)
return tme
}
nProc genFPUOpcode(long opcodeOpsC,float theFloatValueToTestWith){
mul opcodeOpsC,2
long floatVal=dim(8)
setFloat(floatVal,0,theFloatValueToTestWith)
long opcode=dim(8+opcodeOpsC)
setByte(opcode,0,$B8)//mov eax
setLong(opcode,1,floatVal)
setByte(opcode,5,$DD)//fld ptr eax
setByte(opcode,7+opcodeOpsC,$C3)//ret0
add opcode,7
whileLoop 0,opcodeOpsC-1,2 {
setByte(opcode,loop,$DC)
if rnd(2) {
setByte(opcode+1,loop,$30)
} else {
setByte(opcode+1,loop,$08)
}
}
return opcode
}
Mein Computer rechnet danach 250.000.000 Gleitkommawerte in 538ms.
Den ersten Parameter bei flopsTest nicht höher als 1mio setzen da die Funktion sonst zu grande würde. |
|
|
| |
|
|
|
Julian Schmidt | Stürzt bei mir ab, wenn ich es selber mit XPSE kompiliere oder ausführe. Dein Anhang oben corre aber.
|
|
|
| |
|
|
|
| Teste mal ob die hiermit ( [...] ) kompilierte Exe bei Dir corre. |
|
|
| |
|
|
|
Julian Schmidt | Ja, klappt. Warum nicht mit meinen normalen X2? |
|
|
| |
|
|