Multitasking abschalten
-
Das geht schlicht und einfach nicht, schon gar nicht mit Standard-C-Mitteln. Aber auch durch BS-Spezifische Funktionen geht das nicht wirklich - und das ist gut so. Sonst koennte ja jedes Programm einfach das Multitasking abschalten und damit das gesamte System lahmlegen. Dazu muss man sagen, dass es theoretisch moeglich waere, die System-Interrupts zu deaktivieren und so den Task-Scheudler zu unterbrechen. Das geht aber auch nur, wenn dein Code auf Ring 0, also Kernel-Level laeuft. Praktisch ist das also kaum machbar. Unter Windows kannst du einen Prozess auch auf Hoechste Prioritaet stellen und dann nochmal den Thread innerhalb des Prozesses auf eine hohe Prioritaet setzen (unter Linux wirds vermutlich aehnliche Moeglichkeiten geben, aber sicher bin ich mir, mangels Programmiererfahrung unter Linux nicht). Dann wird der Thread vom Scheudler sogar vor den System-Threads bevorzugt und bekommt am meisten Rechenzeit - kann aber jederzeit wieder vom Scheulder unterbrochen werden.
Klingt aber eher so, als suchtest du ein Real-Time OS. Bei denen kannst du nahe an das rankommen, was du willst.
Doch selbst da kann dir keiner garantieren, dass du wirklich in Echtzeit laeufst, allein schon durch die Tatsache, dass diese Betriebssysteme auch Multitasking betreiben. Inwiefern man das dort mit Funktionen abschalten kann weiss ich nicht, aber ganz deaktivieren wird man es wohl nicht koennen.
Schlussendlich gibt es auf der x86-Architektur aber gar keine Moeglichkeit mit Echtzeit zu laufen, weil der Prozessor jederzeit in den SMM schalten kann.
-
Unter Linux (und anderen POSIX-konformen Systemen) kann man den Prozess mit nice -n -20 starten (als root) und ggf. Threads mit pthread_attr_setschedparam eine hohe Priorität zuordnen.
Aber ich stimme Jonas zu; das Pferd wird da von hinten aufgezäumt. Suchst du möglicherweise nach etwas wie https://code.google.com/p/asmprofiler/ ?
-
muss mein Code ausgeführt ...
Warum?
-
Hallo,
danke schonmal für die Antworten.
Ich beschreibe mal die Aufgabenstellung genauer da das ganze doch ziemlich allg. formuliert war.Im Rahmen einer Bachelorarbeit, soll AES in Assembler nachprogrammiert werden, einmal mit und einmal ohne den neuen AES-NI Befehlssatz( der beinhaltet ein paar neue Befehle die AES beschleunigen).
Dann sollen die beiden Versionen auf Geschwindigkeit geprüft werden, um so die Effizienz herauszufinden.Das ganz soll so ablaufen dass ein C Programm geschrieben werden soll, das auf ein Signal auf einem I/O Port wartet, also USB Parallel oder Seriell, kann ich mir aussuchen. Das Signal sieht einfach so aus dass bei einem bestimmten Pin eine 1 angelegt wird.
Solange diese 1 anliegt. Soll AES laufen, und möglichst alles andere gestoppt werden, um die reine AES Laufzeit zu bestimmen, ohne dass der Scheduler dazwischenfunkt.So, mein Betreuer will das so unterbrechungsfrei wie möglich.
Ansätze waren:
-Das ganze in MSDOS zu schreiben, wo es noch kein Multitasking gibt -> gehts nicht da, da die neuen ASM Befehle anscheinend nicht untersützt werden.-Alles ausser den AES Thread auf einem anderen Prozessorkern laufen lassen. -> wäre der Betreuer nicht so begeistert von
-Dem AES Thread eine sehr hohe Priorität geben -> sind ihm immernoch zu viele Unterbrechnungen.
So, jetzt bräuchte ich ein paar Ideen von euch. OS kann ich mir aussuchen, aber es muss halt ein C Compiler und Assembler der den neuen Befehlssatz versteht, dabei sein.
Danke schonmal
-
Warum Unterbrechungsfreiheit bei Geschwindigkeitsmessungen? Da reicht doch einfach die CPU-Zeit zu messen. Das kann dir jeder Profiler schon mit hübschem Interface erledigen und selber programmieren ist auch nicht so schwer.
Die Anforderung an die Lösung und die Aufgabenstellung passen nicht zusammen. Entweder verschweigst du uns noch ein extrem wichtiges Details oder ihr solltet euch mal kundig machen, wie man die Laufzeit von Programmen/Programmteilen richtig misst.
-
Danke für die Kritik,
Gemessen werden soll die Zeit, wie lange der Algorithmus mit und ohne den neuen Befehlssatz läuft. Das ist meine Vorgabe. Beides auf dem selben Rechner. Parallelisert soll auch nichts werden.
Das soll genau der selbe Code sein, nur dass die Stellen, die den neuen Befehlen entsprechen mit Diesen ersetzt werden. Das Grundgerüst ( ob das jetzt effizient programmiert wurde oder nicht) ist egal da ja die differenz ermittelt werden soll.Der Grund warum es Unterbrechnungsfrei sein soll, ist weil die reine Laufzeit des ASM Codes bestimmt werden soll, wenn der Scheduler zwischendurch einem anderen Programm einen Zeitschlitz gibt, wird dieser Wert verfälscht oder sehe ich das falsch?
Wäre es möglich die Anzahl der verbrauchen CPU Takte die der ASM Teil braucht zu messen und anhand der Prozessorgeschwindigkeit die theoretische Echtzeitlaufzeit zu bestimmen?
Die Taktzahl lässt sich sicher leicht mit Ollydbg oder Visual Studio ermitteln nehm ich an.
-
Ich glaube, du suchst einfach den Begriff CPU-Zeit. Das ist auch die Größe, die ein Profiler in der Regel messen wird.
Es sind Nebeneffekte denkbar, durch die ein Programm durch Scheduler-Unterbrechung eventuell eine handvoll Takte langsamer läuft. Dies ist aber viel einfacher ausgleichbar als durch Umgehen des Schedulers, indem man eben einfach sehr oft misst und die schnellste(!) Zeit als Ergebnis nimmt.
-
Wenn es DOS werden soll:
Es gibt da so ein freies DOS: Free-DOS eventuell da mal testen ob du da die neuen AES-Befehle mit einem C-Compiler zum laufen bekommst. Der C-Compiler, mit dem zuletzt Free-DOS entwickelt wurde, sollte im Quelltext verfügbar sein, wenn du da etwas dran schrauben willst.
Alternative: Du nimmst MS-DOS 5.0 oder höher, schaust ob du den Assembler, der mit Q-Basic ausgeführt in den alten Zeitschriften ( DOS International oder DOS Extra ) des DMV-Verlag ca. Anfang bis Mitte der 90er veröffentlicht wurde, findest. Da kannst du, wenn du die Infos hast die fehlenden Befehle selbst nachrüsten. Ob es Kompatibilitäts-Probleme gibt
Wie weit du mit dem anderen Weg kommst? Win95, Win98 und WinME sollten ja auch noch auf DOS basieren. Vielleicht hilft dir das, wenn du da einen neueren Compiler zu laufen kriegst?
Nichts getestet - nur Denkanstösse
Viel Spass
-
Auch unter DOS gibt es übrigens Hardwareinterrupts.
-
