Lowlevel
Lowlevel => Lowlevel-Coding => Thema gestartet von: Argone am 26. May 2005, 12:49
-
Hat irgendjemand zufällig eine Liste, oder weiß wo es eine solche gibt, in der aufgeführt ist, wieviele Takte ein Befehl braucht?
-
Da das von Prozessortyp zu Prozessortyp unterschiedlich ist kann es schwer sein eine komplette Liste mit allen Werten zu bekommen.
-
Variiert das so stark bei den verschiedenen Intelprozessoren?
-
Ja, weil sich z.B. das Kern Design vom Pentium zum Pentium 2/3 und auch vom Pentium 2/3 zum Pentium 4 massiv geändert hat.
-
Kannst aber mal hier versuchen etwas brauchbares für dich zu finden:
http://cr.yp.to/hardware/x86.html
-
Vielen Dank
-
in der ASM86FAQ (http://www.pbhq.de/asm86faq.html) stehen auch noch die zyklen für cpus von 8086 bis zum pentium 1.
-
ausserdem ist es blödsinn einfach die taktzahlen zu addieren also meinetwegen sowas: add=5takte mov=2 takte dann sind ein mov und ein add=7, das haut nicht hin,
Grund: Out-of-Order Execution, Ausführungspipelines, die Verschiedenen Ausführungseinheiten, eventuell auftretende AGI-Stalls, und vieles mehr.
Durch entsprechende Code-Anordnung kann man erreichen das jeder befehl nur einen takt braucht (aber nur wenn keine jumps drin sind, sonst muss neu prefetched werden) man kann aber auch so dämlich anordnen, dass jeder 10 braucht oder sonstwas, selber code aber unterschiedliche taktzyklen. Also mit ner eifnachen Liste wird da nichts.
-
Die Liste funktioniert bei allem, was ohne Pipelines läuft, also bis zum 286er auf jeden Fall, bei 386er und 486er bin ich mir nicht sicher.
Aber ich bezweifle, dass du fuer diese Prozessoren im speziellen programmierst...
Bei den Intel-Dokus steht's fuer jeden Prozessor auch dabei, jedenfalls bei meiner 286er Doku *danke nochmal*. Ausserdem haben sich die Ausfuehrungszeiten von Befehlen mit jedem Prozessor geändert.
Svenska
-
Dann ist das mit Codeperformance unter Assembler aber eine ziemlich schwierige Sache, oder?
-
Theoretisch muesstest du fuer jeden Prozessortyp (teilweise sogar
verschiedene Untertypen) gewisse Teile anders codieren.
Ich glaube nicht, dass das ein Hobbyprogrammierer hinkriegt...
Zumal es bei den neueren Prozessorn extrem viel Wissen erfordert, wenn
es um Pipelining, Registerueberschreibungen, Befehlspaarungen,
Speicherzugriffe und vieles mehr geht. Codeoptimierung ist ein extremes
Thema, stelle ich persönlich noch ne Stufe höher von der Komplexität als
OS-Programmierung. Da ist dann schon genaueste Kenntnis der
Hardware erforderlich.
Und schliesslich bewegst du dich damit auch wieder von Portabilität weg -
wobei alleine Assemblernutzung schon schlimm genug ist :)
Svenska
-
Nur gut das GCC hochoptimierten Code ausspuckt und man so beruhigt in C/C++ coden kann ohne sich über die Performance sorgen zu machen ;-)
-
Dann werde ich wohl doch noch C/C++ lernen müssen...
-
:D:D:D!
1. Wird NIE ein Kompiler richtig optimierten Code ausspucken, wie er schreibbar ist in ASM, weil der nie den Hintergrund dahinter erkennt und dadurch gewisse Kniffe anwenden kann.
2. Ist ASM an sich sowas von schnell und auf jeden Fall schneller als C-Code, egal, ob er optimiert ist oder nicht.
3. Mag ASM zwar nicht portabel sein, was einige sagen, dass der C-Code so viel währe. Bringt dir aber nix, weil grade auf Lowlevel-Ebene futschelste viel im Speicher rum und stellst zum Beispiel Pagingtabellen auf. Da bringt dir ein portabler Code nix, weil der eh nie auf nem anderen Prozessor laufen wird, schon alleine wegen dem Aufbau des Prozessors.
Bleibt als einziger Grund für C der Syntax und diese Strukturen, wie IF und so weiter, wodurch man wesentlich schneller coden kann.
-
Also, wenn du dir so sicher bist, das hingefrickelter asm-code besser ist als compiler-optimierter code, würde ich dich gerne vom Gegenteil überzeugen.
Man muss nur den richtigen wählen, keinen aus der Steinzeit.
Und ich würde das glatte Gegenteil deiner 1. Aussage behaupten.
In Zukunft wird es auf jeden Fall Compiler geben, die immer den bestmöglichen Code ausspucken, wenn man nur der Compiler richtig eingestellt ist.
Deine 2. Aussage ist strange, der C-Code wird zuerst in asm-code übersetzt vom compiler. Warum soll er deshalb generell langsamer sein?
Und zu 3. kann man sich drüber streiten, klar werden einige Sachen, auf anderen Architekturen anders sein. Aber wenn du z.B. von x86 nach amd64 portierst, dann wird dir der C-Code mehr nützten, als dein asm geschreibsel, weil der Compiler für amd64 optimieren kann, der asm-code fast komplett neu geschrieben werden muss, wenn du z.B. die neuen Register nutzen willst. Auf dem alleruntersten Lowlevel-niveau kommt man zwar nicht umhin asm zu verwenden, aber ich würde möglichst viel drauf Verzichten.
Ich würde nur asm verwenden, für bottle necks (ja, die heutigen Compiler sind noch nicht das Optimum) und lowest level.
MfG
DDR-RAM
-
1. Du willst mir allen Ernstes erklären, ein Computer wird einmal verstehen, was ein Mensch mit einer Aktion bezwecken will? Wird er nicht. Damit das ginge müsste der Mensch sich erstmal selber verstehen, was er heute in großen Bereichen noch nicht tut. Wie soll man da einen PC zu bringen, das zu verstehen? Ein PC kann zwar überlegen, was man damit meinen KÃNNTE, aber an sich verarbeitet er nur Ausdrücke und nicht, was dahinter steckt. Man könnte fast sagen, er weiß nicht, was er verarbeitet. Er verarbeitet einfach.
2. Eben aus dem Grund der "Verschrottung" durch den C-Compiler, der sicher nicht so feinen Code schreibt, den man mit ASM so oder so schreibt. Der Anwender weiß, was er verarbeitet und kann damit spielen, der PC nicht. Mach mal ne If-Konstruktion und schau, was der Compiler draus baut...
3. Es geht um "portierbar", was meines Erachtens nach eher das von Win auf Linux und Mac und umgekehrt ist. Und diese Portablilität ist bei C im Lowlevelbereich nicht gegeben, außer bei Rechnern selber Architektur. Und bei C wirste wohl auch nen Teil umschreiben dürfen, weil PM64 anderst ist als PM32. Nur im Bereich, wo man mit Standartlibs fuchtelt, da kann man portieren, ach wie toll.
-
1. Wird NIE ein Kompiler richtig optimierten Code ausspucken, wie er schreibbar ist in ASM, weil der nie den Hintergrund dahinter erkennt und dadurch gewisse Kniffe anwenden kann.
ein normalsterblicher kann vielleicht einige dutzend oder hundert zeilen assembler bis zum äußersten optimieren, aber bei einem richtigen projekt (computer spiel, betriebssystem, audio-/videocodec), wo hunderttausend zeilen code optimiert werden müssen, möchte ich das nicht von hand machen. vielleicht holt der compiler nicht aus jeder einzelnen zeile das maximum raus, aber über den ganzen code gesehen, schafft er im schnitt deutlich bessere optimierungen, als ein mensch.
spätestens wenn es darum geht multithreading programme zu optimieren, wird es viel zu kompliziert für einen menschen. da werden im c-code ein paar "hints" (bei OpenMP z.b. irgendein #pragma) gesetzt und dann legt der c-compiler eine for-schleife so außeinander, dass der code in zum beispiel 8 threads aufgeteilt wird. da muss sich der mensch keine gedanken machen, wie man die synchronisiert und ob es so praktisch überhaupt funktionieren kann, und so weiter, weil der compiler es einfach tut. (oder eine fehlermeldung ausgibt, wenn es doch nicht gehen sollte.)
-
Also ich weiss nicht ob die Leute die sagen Compiler code sei dem ASM code vom Menschen ebenbürtig sich einmal vom Compiler den Code als Assemblat haben geben lassen. Ich krieg manchmal total das kotzten was gcc abliefert und das bei Optimierung -O3.
Bei OS-Programmierung kommt man aber eh nicht drum rum manchmal mit ASM arbeiten zu müssen, also ist man immer irgendwo Plattform gebunden und muss für jede Plattform anderen Code schreiben, auch dem Compiler muss man sagen, auf welche Plattform er ausgerichtet sein soll.
Für AMD64 muss man auch seinen C-Code neu schreiben, da ja vieles wegfällt, z.b. muss man zwangsläufig Softwaretaskswitching verwenden. Wenn man bisher TSS benutzt hat, muss man auch den C-Code ändern.
PS: Alle Aussagen gelten nur, wenn der, der Asm codet das auch wirklich(!) beherrscht. Komplett in Asm geschriebenes OS muss nicht schneller sein, wenn der Code schrott ist. Aber man kann genauso in C totalen scheiss zusammencoden und der Compiler kann da auch nix optimieren.
-
Also als erstes zählen, die Algorithmen.
Basic QuickSort ist schneller als asm bubble sort, wenn man 20k Elemente sortieren will.
Bei asm kann man viel falsch machen, bei C dagegen fast nichts.
Hm, also ich bringe nochmal ein Beispiel für C-Code und den asm-code dazu:
bool IsPrime(unsigned int x)
{
switch (x)
{
case 0:
case 1:
return false;
case 2:
return true;
default:
if (x % 2 == 0)
return false;
for (unsigned int i = 3; i < fastIntSqrt(x); i++)
{
if (x % i == 0)
return false;
}
return true;
}
}
(ja, ist C++, wegen bool)
und jetzt der asm-code (mit dem C-Code dazwischen)
bool IsPrime(unsigned int x)
{
push ebx
mov ebx,eax
switch (x)
cmp ebx,1
jbe IsPrime+11h (4010B1h)
cmp ebx,2
jne IsPrime+15h (4010B5h)
case 2:
return true;
mov al,1
pop ebx
}
}
ret
{
case 0:
case 1:
return false;
xor al,al
pop ebx
}
}
ret
default:
if (x % 2 == 0)
test bl,1
return false;
je IsPrime+11h (4010B1h)
push esi
for (unsigned int i = 3; i < fastIntSqrt(x); i++)
mov esi,3
call fastIntSqrt (401000h)
mov ecx,eax
cmp ecx,esi
jbe IsPrime+41h (4010E1h)
jmp IsPrime+30h (4010D0h)
lea ecx,[ecx]
{
if (x % i == 0)
xor edx,edx
mov eax,ebx
div eax,esi
test edx,edx
je IsPrime+46h (4010E6h)
add esi,1
cmp esi,ecx
jb IsPrime+30h (4010D0h)
pop esi
}
return true;
mov al,1
pop ebx
}
}
ret
pop esi
return false;
xor al,al
pop ebx
}
}
ret
Was kann man da noch großartig optimieren?
Achso, der Compiler hat nicht c-aufrufkonvention genommen, sondern einfach x per eax übergeben! Ist übrigens MS VC++, weiß nich, ob gcc das auch machen kann.
Die stellen, wo der Compiler scheiße ausspuckt sind imo sehr selten und ich guck mir eigentlich immer den asm-code an, damit ich sehe, das er net nur scheiße macht.
Also, ohne Optimierung ist klar, das des net gut ist, aber mit -O3?
gebe mal Beispiel :D
Ok, teilweise sind einige stellen redundant, aber sowas zu erkennen, noch ein, zwei Jahre und Handoptimierungen kann man sich gänzlich sparen (vor allem auch weil für verschiedene CPU's unterschiedlich optimiert werden muss, beim Compiler einfach switch für ne andere Cpu angeben, aber asm muss neucoden)
Ich bin zuversichtlich!
MfG
DDR-RAM
-
1. In ASM nehme man eine Call-Table bei den Switches, spart alle CMPs und alle JMPs.
2. Da sind noch nicht die Strukturen mit drinnen.
Lass es mal komplett auskompilieren. ;)
-
Bei mir hat der Compiler manchmal einfach falschen Code erzeugt, der den Rechner zum Absturz bringt. Manche Funktionen funktionierten nur richtig wenn ich ein paar Funktionsaufrufe einbaue die mit der Funktion nichts zu tun haben usw.
Bei dem Code den du da geliefert hast könnte man an einigen (wenigen) Stellen noch den Code anders anordnen zwecks Pipelining und Pairing (ja ich kenne mich mit dem Mist recht gut aus) aber da die Funktion ja auch relativ kurz ist machts nicht viel. Bei längeren Funktionen summieren sich die unzulänglichkeiten.
GCC kann diese Übergabe auch, nennt sich FastCall.
Ich kenne keinen C-Compiler der MMX/SSE/3Dnow! Code erzeugen kann, da wäre noch sehr viel Optimierung möglich. Das kann man momentan nur direkt in ASM.
-
Die Sprungtabelle, lohnt sich aber in diesem Fall noch nicht ;-)
Bei größeren switches, würde der Compiler das auch machen, aber er müsste ja sowieso erstmal testen, ob es in diesem Fall kleiner gleich 2 ist um die Sprungtabelle zu nehmen.
Außerdem muss für die Sprungtabelle noch eine zusätzliche Leseoperation durchgeführt werden, du siehst es ist gar nicht so einfach.
Ich hätte aber erst überprüft, ob ebx größer 2 ist und wäre dann weggesprungen, da für den Großteil aller zahlen, ebx größer als 2 ist und somit ein weiterer Vergleich gespart wird.
Welche Strukturen?
[edit]
@roshl:
hm, wo kann man denn da noch was machen?
Also eigentlich sollte es für P4 optimiert sein.
Das mit MMX/SSE/SSE2/3d Now ist allerdings war, liegt aber auch vor allem daran, dass bei AMD und Intel jeder sein eigenes Süppchen gekocht hat und das es wirklich schwer abzuschätzen ist, wann man es verwenden soll, aber intern wird es ja teilweise verwendet, z.B. bei Fließkommaoperationen
[/edit]
MfG
DDR-RAM
-
Was für eine Zusätzliche Leseoperation?
mov eax,param
shl eax,2
add eax,tabellenbasis
call [eax]
das reicht für eine Sprungtabelle aus
-
Was für eine Zusätzliche Leseoperation?
mov eax,param
call [eax*4]
das reicht für eine Sprungtabelle aus
also die Tabelle sieht eher so aus (kein call ^^)
cmp ebx, 2
jae defaultLabel
jmp [tableBase+ebx*4]
im Vergleich zu dem compiler-code:
cmp ebx,1
jbe KleinerGleich1
cmp ebx,2
jne Groesser2
Gleich2:
[...]
KleinerGleich1:
[...]
Groesser2:
Vorteil bei der Compiler variante, größe 10 Byte (gegen 12 Byte),
außerdem ist bei ebx = 2 kein sprung nötig, keine leseoperation nötig (der Sprungtabelleneintrag muss gelesen werden ;-)), auch wenn es nur ein cache-read ist.
Übrigens, wenn man das switch-case teil verändert, dahin
switch (x)
{
case 0:
case 1:
case 3:
return false;
case 2:
return true;
default:
[...]
}
verwendet er ne jump-table.
MfG
DDR-RAM
-
hatte schon nen kleines edit gemacht;) aber ob jump oder call table ist erstmal egal, das prinzip ist das gleiche
Meine Variante prüft hingegen ja nicht ob es grösser 2 ist oder so;) sondern ruft einfach auf was auch immer da steht
-
Aber du weist schon das jmp und call nicht wirklich das gleiche machen ;-) ?
-
...Das PRINZIP einer Call und einer Jump Tabelle ist exakt das gleiche
-
ja, aber in dem Beispiel waren alle natürlichen Zahlen kleiner 2^32 zugelassen, soviel virtuellen Speicher hast du gar nicht für die jump table, du musst es also vorher überprüfen ;-)
und call-table, wäre ja nen bisschen was anderes, wir wollen ja keine Funktion aufrufen, aus der zurück gesprungen werden soll.
Wie gesagt, in diesem Beispiel bringt die jmptable keine punkte.
Und deine editiertes, braucht mit der überprüfung auch kleiner 2 sogar 15 Bytes :D
MfG
DDR-RAM
-
Man sollte die Tables ja auch nur einsetzen wo es Sinn macht. Aber ich glaube ihr versteht mich nich. Man kann in C genauso wie in Asm mieserablen Code schreiben, auch der Compiler kann da nicht immer alles abfangen. Letztlich ist es egal welche Sprache ich nehme so lange ich das Programmieren an sich nicht beherrsche.
Mit dem Prinzip einer Call/Jump Table meine ich folgendes: nicht für jeden Wert eine Unterscheidung, sondern ein Call/Jump der die Unterscheidung automatisch macht. Das Prinzip ist bei beiden gleich.
Ausserdem ists es unwichtig ob es nun 10 oder 15 Byte braucht. Weniger Code heisst nicht immer, dass er auch schneller ist. Manchmal kann sogar ein nop den Code beschleunigen...
-
Die Code größe spielt in sofern eine Rolle, das es bei größerem Code wahrscheinlicher ist, das dieser geswappt wird ;-)
Das z.B. Funktionen 16-Byte aligend sein sollten und auch schleifen labels, ist mir klar, auch das weniger größe nicht automatisch heißt schneller. Nur wenn man kleineren Code macht, der nicht langsamer ist, als größer, der das gleich macht, ist der kleinere zu bevorzugen!
hm, ne call table ist eher sowas:
typedef int (*FUNCTION)();
FUNCTION pfnArray[256];
int main(int argc)
{
return pfnArray[argc]();
}
jmp table eher sowas:
switch (x % 4)
{
case 0:
[...] break;
case 1:
[...] break;
case 2:
[...] break;
case 3:
[...] break;
default: __assume(0); // MS syntax damit default label net generiert wird
}
MfG
DDR-RAM
-
Wo ist der Unterschied? Adressen werden in einem Array angelegt und aufgerufen. Das liegt nur an C dass es anders aussieht in Asm ist es das gleiche. Ich kann jede Adresse die ich Calle auch anjumpen, dass das Ziel mit dem ret dann nicht hinhaut ist ne andere Sache, aber an sich besteht aus Asm Sicht kein Unterschied.
C versaut bei vielen das Denken was eigentlich genau programmiert wird. Die CPU weiss nicht ob das nun eine Funktion ist oder ne Variable oder sonstwas, sie kennt nur Addressen.
-
naja, und da ist es dann eben doch wichtig,
bei jmp gibt es keine Rücksprungmöglichkeit, bei call aber schon.
Das sie ähnlich sind bestreitet ja keiner. Das die CPU nur nach einem festgelegten schema interpretiert, ist mir klar.
außerdem wird der jmp Befehl teilweise auch für Funktionsaufrufe verwendet, z.B.:
void MacheEtwas2()
{
[...]
}
void MacheEtwas1()
{
[...]
MacheEtwas2();
}wird zuMacheEtwas1:
[...]
jmp MacheEtwas2
oder es wird gleich geinlined, aber der Compiler hat führt da ja schön analysen durch, der wird schon wissen, ob inlining besser ist oder nicht und wenn ich es doch entscheiden will, dann gibt es noinline.
Gibt es auch sowas wie __forceinline bei gcc?
MfG
DDR-RAM
MfG
DDR-RAM
-
Wer Low Level programmieren will, muss die Architektur, auf der er arbeitet, wie seine Westentasche (auswendig) kennen. Sonst bringt das ueberhaupt nichts. Auch wird ein x86-Spezi niemals eine m68k-Arch gut beproggen.
Ein Compiler ist niemals in der Lage, den menschlichen Hintergedanken zu entdecken; ein nichtoptimierter Alghorithmus in Assembler kann langsamer sein als ein hochoptimierter in Basic (nicht kompiliert!).
Gewisse Teile kann ein Compiler beschleunigen und mit der Masse an Anweisungen nimmt auch die Effizienz zu (ein Mensch kann keine 10 Mio Asm-Lines optimieren) - aber das Grundprinzip muss stimmen. Ein Microkernel wird immer langsamer sein, als ein Monolithischer - wenn beide gut designed sind. Ein schrottiger Monolithischer ist langsamer als ein guter Microkernel. Und so geht es weiter.
Streitet euch ueber x verschiedene Sprungmöglichkeiten; bringen tut es doch nix. Wie Roshl schon sagte, man muss Programmieren können - und zwar nicht nur technisch, sondern auch vom Grundgedanken her.
Die Frage Asm oder Nicht-Asm ist eine Designfrage; gewisse Teile kann man so wesentlich beschleunigen. Der Grossteil eines OS' muss aber nicht extremoptimiert werden.
Svenska
-
Du bist mir sympathisch^^
Ich halte nichts davon wenn man sonstwelche Programmiersprachen kann, wenn man das programmieren selbst nicht kann. Die Sprache sollte nur das Mittel zum Zweck sein.
Die Performancegrenzen liegen letztlich in der Assemblersprache, schneller kann es nicht werden, man kann schliesslich keine neuen Opcodes erfinden (noch nicht). Ein Compiler kann zwar optimieren bis zum was-weiss-ich-was, erreicht letztlich aber nur eine unendliche Annäherung an die Assemblersprache.
Achja beachtet jemand, dass ein Compiler auch von Menschen programmiert wurde? Also wird die Optimierungsroutine von denen versaut kann der Compiler nix^^ und die meisten würden es hier nichtmal merken, da sie einfach blind als gut annehmen was der Compiler ausgibt.
-
Hallo,
Wer Low Level programmieren will, muss die Architektur, auf der er arbeitet, wie seine Westentasche (auswendig) kennen.
muss nicht, das kommt mit der Zeit, am Anfang reicht sich die specs sehr oft durchzulesen.
Sonst bringt das ueberhaupt nichts.
Ja klar, wenn man das Konzept nicht versteht, dann sollte man vielleicht besser aufgeben.
Auch wird ein x86-Spezi niemals eine m68k-Arch gut beproggen.
Hab selber keine Erfahrung mit anderen CPU's als x86-reihe, aber von-neumann-ähnlich sind sie doch (fast?) alle. Man wird sich auch in mehrere Architekturen einarbeiten können.
Ein Compiler ist niemals in der Lage, den menschlichen Hintergedanken zu entdecken;
Wozu sollte er den genauen Hintergedanken erkennen?
Und wieso sollte er nicht in der Lage sein, das zu können?
Das Stichwort heißt AI! :D
ein nichtoptimierter Alghorithmus in Assembler kann langsamer sein als ein hochoptimierter in Basic (nicht kompiliert!).
ja, das stimmt ;-)
Gewisse Teile kann ein Compiler beschleunigen und mit der Masse an Anweisungen nimmt auch die Effizienz zu (ein Mensch kann keine 10 Mio Asm-Lines optimieren)
Ein Compiler beschleunigt nicht, er übersetzt eine Hochsprache in asm-code. Dieser kann attribute von langsam bis maximal optimiert bekommen ;-)
- aber das Grundprinzip muss stimmen.
Du meinst die Algorithmen und das framework. ja ;-)
Ein Microkernel wird immer langsamer sein, als ein Monolithischer - wenn beide gut designed sind.
kommt auf die Definitionen an.
Ein schrottiger Monolithischer ist langsamer als ein guter Microkernel. Und so geht es weiter.
jupp
Streitet euch ueber x verschiedene Sprungmöglichkeiten;
ne haben wir nicht gemacht ;-)
bringen tut es doch nix.
in dem sinne, "bringen täte es doch nichts" :D
Wie Roshl schon sagte, man muss Programmieren können - und zwar nicht nur technisch, sondern auch vom Grundgedanken her.
Was ist technisch programmieren können? meinst du theorethisch?
Und müssen tut man es nicht, sehr viele Menschen kommen auch ohne aus, auch wenn ich sie bedauere :lol:
Die Frage Asm oder Nicht-Asm ist eine Designfrage; gewisse Teile kann man so wesentlich beschleunigen.
genauso gut, kann man so gewisse Teile verlangsamen.
Ich würde nicht von mir behaupten, das ich zu den allerbesten asm-codern gehöre, das wäre selbstüberschätzung, aber die meisten Techniken kenne ich. Trotzdem würde ich nicht behaupten, das ich mit gleichem Aufwand, gleich guten, gleich viel machenden c, wie asm-code produzieren kann. Wenn ihr so gozu seid, dann bitte :D
Der Grossteil eines OS' muss aber nicht extremoptimiert werden.
müssen tut auch nix, aber hast schon recht ;-)
Du bist mir sympathisch^^
Ich halte nichts davon wenn man sonstwelche Programmiersprachen kann, wenn man das programmieren selbst nicht kann.
ja, stimmt schon, aber wer kann sowas und kann nicht programmieren? kann er dann die Programmiersprachen überhaupt? Er kennt dann nur die Syntax ;-)
Die Sprache sollte nur das Mittel zum Zweck sein.
Ja, aber C und asm haben zwei verschiedene Zwecke,
c teilt den Programmablauf mit,
asm teilt die Befehlsfolge für die endgültige binary mit.
Die Performancegrenzen liegen letztlich in der Assemblersprache, schneller kann es nicht werden, man kann schliesslich keine neuen Opcodes erfinden (noch nicht).
Naja, also eigentlich wurden ja mit mmx/3d now/sse/sse2/sse3 usw. neue opcodes erfunden ;-)
Aber so reduziert ist das thema nicht, es geht ja nicht darum irgendwelche befehle wild aneinander zubringen, aber das weißt du ja ;-)
Ein Compiler kann zwar optimieren bis zum was-weiss-ich-was, erreicht letztlich aber nur eine unendliche Annäherung an die
Assemblersprache.
Assemblersprache ist einfach nur die abstraktion der binärcodierten Maschinenbefehle in menschen verständlicherer Sprache.
Der Compiler übersetzt C-Code in diese Sprache, das macht er gut oder schlecht. Wenn eine maximal optimierte Übersetzung für eine bestimmte Zielplattform existiert und diese Zielplattform deterministisch arbeitet, dann ist diese maximale optimierte Übersetzung auch auffindbar, nicht nur assoziativ durch Menschen, sondern auch algorithmisch.
Und assoziatives denken (!) werden irgendwann auch Computer können.
Achja beachtet jemand, dass ein Compiler auch von Menschen programmiert wurde? Also wird die Optimierungsroutine von denen versaut kann der Compiler nix^^ und die meisten würden es hier nichtmal merken, da sie einfach blind als gut annehmen was der Compiler ausgibt.
Wie gesagt, ich guck mir meinen Code oft im disassembler an.
Mir fallen eigentlich nur selten redundanzen auf, der Rest ist fast immer sehr gut übersetzt.
Und meist wird der Compiler nicht nur von einem Menschen programmiert. Beim gcc, kann man auch selber nachbessern, wenn man es denn sogut kann.
MfG
DDR-RAM
-
Musst du die Postings zeilenweise zerlegen? :D
Auch wird ein x86-Spezi niemals eine m68k-Arch gut beproggen.
Hab selber keine Erfahrung mit anderen CPU's als x86-reihe, aber von-neumann-ähnlich sind sie doch (fast?) alle. Man wird sich auch in mehrere Architekturen einarbeiten können.
Sicherlich, aber wer den x86er mit allen seinen Eigenheiten perfekt kann, wird mit den Kenntnissen auf ner völlig anderen Architektur nicht unbedingt gleich gut abschneiden. Wobei man, wenn man x86 kann, genug Hintergrundwissen hat...
Gewisse Teile kann ein Compiler beschleunigen und mit der Masse an Anweisungen nimmt auch die Effizienz zu (ein Mensch kann keine 10 Mio Asm-Lines optimieren)
Ein Compiler beschleunigt nicht, er übersetzt eine Hochsprache in asm-code. Dieser kann attribute von langsam bis maximal optimiert bekommen ;-)
Ein Compiler nimmt den vom Menschen vorgegeben Algorithmus nach dem Prinzip des "sicheren". Je mehr man diesen Algorithmus an die Erfordernisse anpasst, desto effektiver und damit schneller kann er ausgefuehrt werden. Ein Compiler weiss nicht, was wichtig und was nicht-wichtig ist und geht darum (meist) den sichersten Weg; das Geschwindigkeitsmaximum liegt im direkten, handgecodeten ASM. Wenn man es kann.
Ein Microkernel wird immer langsamer sein, als ein Monolithischer - wenn beide gut designed sind.
kommt auf die Definitionen an.
Ein reiner Mikrokernel muss langsamer sein, da du ja - laut Definition "Mikrokernel" - ständig Ringwechsel und Taskwechsel hast. Was beim monolithischen im Kerneltask mitläuft (z.B. Hardwaretreiber) muss als Extratask gewertet werden, was sich bei wirklich "mikro" dann in einem Geschwindigkeitsminus niederschlägt.
Wie Roshl schon sagte, man muss Programmieren können - und zwar nicht nur technisch, sondern auch vom Grundgedanken her.
Was ist technisch programmieren können? meinst du theorethisch?
Mit technisch meinte ich das praktische (Syntax-Kenntnis usw) und mit dem Grundgedanken das Design dahinter. Nur wenn letzteres stimmt, schafft man auch ein Ergebnis - und je besser es ist, desto optimierter kann man programmieren.
Und müssen tut man es nicht, sehr viele Menschen kommen auch ohne aus, auch wenn ich sie bedauere :lol:
Da hat wohl einer meine Frage wörtlich genommen :(
Die Frage Asm oder Nicht-Asm ist eine Designfrage; gewisse Teile kann man so wesentlich beschleunigen.
genauso gut, kann man so gewisse Teile verlangsamen.
Stimmt. Aber je mehr man sich mit dem Grundgedanken, der darunterliegenden Technik auskennt, desto eher kann man mit Asm beschleunigen, was ein Compiler nicht mehr kann. Je mehr durchdacht alles ist, desto besser.
Trotzdem würde ich nicht behaupten, das ich mit gleichem Aufwand, gleich guten, gleich viel machenden c, wie asm-code produzieren kann. Wenn ihr so gozu seid, dann bitte :D
Das meine ich mit Designfrage. C/C++ ist schon eine gute Wahl, auch wenn ich es nicht mag :-) Nur mit Assembler hält man somit den Schluessel zur "Kammer des Schreckens" in der Hand. Man kann zerstören und perfektionieren. Wenn man es kann.
Die Sprache sollte nur das Mittel zum Zweck sein.
Ja, aber C und asm haben zwei verschiedene Zwecke,
c teilt den Programmablauf mit,
asm teilt die Befehlsfolge für die endgültige binary mit.
Jein. Assembler ist die Sprache des Prozessors und die letzte Grenze, wenn es um Optimierungen geht (ging es darum nicht in diesem Faden?). C ist eine Hochsprache, geschaffen, um die Programmierung zu vereinfachen. Damit gehen immer Einschränkungen einher, denn je mehr die Sprache vorgibt, desto weniger kann man alleine tun. Wobei C schon sehr freigiebig ist. Das Mittel zum Zweck (der Lösung) ist die Sprache. Und diese kann je nach Wahl Assembler, C oder ein x-beliebiger Basicdialekt sein. Man muss halt Vor- und Nachteile abwägen.
Die Performancegrenzen liegen letztlich in der Assemblersprache, schneller kann es nicht werden, man kann schliesslich keine neuen Opcodes erfinden (noch nicht).
Naja, also eigentlich wurden ja mit mmx/3d now/sse/sse2/sse3 usw. neue opcodes erfunden ;-)
Hast du die erfunden und mit deinem OS in den Prozessor geschrieben?? :D
Ein Compiler kann zwar optimieren bis zum was-weiss-ich-was, erreicht letztlich aber nur eine unendliche Annäherung an die
Assemblersprache.
Assemblersprache ist einfach nur die abstraktion der binärcodierten Maschinenbefehle in menschen verständlicherer Sprache.[...]
Ja, und ein Compiler wird nicht in den nächsten 50-100 Jahren einen Algorithmus durch einen besseren ersetzen, weil er es selbst mitkriegt. Das muss der Mensch noch lange lange allein machen.
Und assoziatives denken (!) werden irgendwann auch Computer können.
Aber nicht mehr in unserer Lebensspanne, vermute ich mal. Und wenn wir an diesem Punkt sind, dann brauchen wir nicht mehr programmieren, da die Computer dem menschlichen Hirn sowieso ueberlegen sind(, die Weltherrschaft uebernehmen), und sich selbst programmieren. Und soweit soll es in meiner Zeit nicht kommen :-)
und die meisten würden es hier nichtmal merken, da sie einfach blind als gut annehmen was der Compiler ausgibt.
Ich zum Beispiel, aber da ich die Sprachen nicht kann... :-)
MfG Svenska
-
Musst du die Postings zeilenweise zerlegen? :D
nein, aber ich tat es :D (und werde es wieder tun, wenn es sein muss :D :D )
Gewisse Teile kann ein Compiler beschleunigen und mit der Masse an Anweisungen nimmt auch die Effizienz zu (ein Mensch kann keine 10 Mio Asm-Lines optimieren)
Ein Compiler beschleunigt nicht, er übersetzt eine Hochsprache in asm-code. Dieser kann attribute von langsam bis maximal optimiert bekommen ;-)
Ein Compiler nimmt den vom Menschen vorgegeben Algorithmus nach dem Prinzip des "sicheren". Je mehr man diesen Algorithmus an die Erfordernisse anpasst, desto effektiver und damit schneller kann er ausgefuehrt werden. Ein Compiler weiss nicht, was wichtig und was nicht-wichtig ist und geht darum (meist) den sichersten Weg; das Geschwindigkeitsmaximum liegt im direkten, handgecodeten ASM. Wenn man es kann.
also, wenn man es in c hinschreibt, dann wird es wohl wichtig sein, code der keinen effekt hat, wird von einem guten compiler einfach rausgeschnitten, lokale variablen werden möglichst in registern gehalten (außer mit volatile schlüsselwort). Das Wort Sicherheit bringe ich wie gesagt nur mit dem c-volatile-schlüsselwort in Verbindung. Der Compiler darf nach dem Standard nach gutdünken optimieren, wenn das resultat das gleiche ist. Das ist die ganze Sicherheit. Und wenn man möchte, das Speicherzugriffe nicht wegoptimiert werden, dann nutzt man halt das volatile schlüsselwort.
Die Frage Asm oder Nicht-Asm ist eine Designfrage; gewisse Teile kann man so wesentlich beschleunigen.
genauso gut, kann man so gewisse Teile verlangsamen.
Stimmt. Aber je mehr man sich mit dem Grundgedanken, der darunterliegenden Technik auskennt, desto eher kann man mit Asm beschleunigen, was ein Compiler nicht mehr kann.
Es heißt nicht "nicht mehr kann", sonder "noch nicht kann". ;-)
Was die eine Version eines Compilers noch nicht so gut optimierte, kann eine neuere schon sehr viel besser optimieren können.
Die Sprache sollte nur das Mittel zum Zweck sein.
Ja, aber C und asm haben zwei verschiedene Zwecke,
c teilt den Programmablauf mit,
asm teilt die Befehlsfolge für die endgültige binary mit.
Jein. Assembler ist die Sprache des Prozessors und die letzte Grenze, wenn es um Optimierungen geht (ging es darum nicht in diesem Faden?).
Assembler selber hat noch nichts mit optimierung zu tun.
Um in asm zu coden, sollte man wissen, in welcher Reihenfolge welche Befehle gut sind usw. Asm-sprachen ist die einzigen Sprachen, in denen der Programmierer selber optimieren muss/kann.
In C u.a. übernimmt diese Aufgabe der Compiler.
Es geht also darum, wer kann besser optimierten asm-code erzeugen, der Mensch oder der Compiler. Und langsam aber sicher geht das immer weiter in Richtung Compiler. So das der Programmierer nur bei Flaschenhälsen eingreifen sollte oder er sehr viel Spaß am hand-asm-coden hat. Da über sehr weite Strecken, die Sache auch schnell entarten kann in asm.
C ist eine Hochsprache, geschaffen, um die Programmierung zu vereinfachen.
auch, aber z.B. auch um die Portablität zwischen verschieden Architekturen zu verbessern.
Damit gehen immer Einschränkungen einher, denn je mehr die Sprache vorgibt, desto weniger kann man alleine tun.
also C/C++ schränken uneingeschränkt nicht ein.
Es ist viel mehr so, das asm-code meist nur für bestimmte Zielplattformen gut ist oder nur bestimmte prozessorversionen, z.B. pIII oder athlon. Dem Compilat des Compilers ergeht es natürlich genauso, aber man kann einfach den Code für ne andere Zielplattform kompilieren bzw. zielversion der CPU kompilieren. Im äußersten lowlevel Bereich ist asm natürlich ein muss, um prozessorspezifische Sachen zu machen (wie IDT laden, paging aktivieren, etc.), ja in sofern ist C beschränkt.
Wobei C schon sehr freigiebig ist. Das Mittel zum Zweck (der Lösung) ist die Sprache. Und diese kann je nach Wahl Assembler, C oder ein x-beliebiger Basicdialekt sein. Man muss halt Vor- und Nachteile abwägen.
Ja, es gibt os-projekte in diversesten programmiersprachen.
Die Performancegrenzen liegen letztlich in der Assemblersprache, schneller kann es nicht werden, man kann schliesslich keine neuen Opcodes erfinden (noch nicht).
Naja, also eigentlich wurden ja mit mmx/3d now/sse/sse2/sse3 usw. neue opcodes erfunden ;-)
Hast du die erfunden und mit deinem OS in den Prozessor geschrieben?? :D
Nö, Intel/AMD warens 8)
Ein Compiler kann zwar optimieren bis zum was-weiss-ich-was, erreicht letztlich aber nur eine unendliche Annäherung an die
Assemblersprache.
Assemblersprache ist einfach nur die abstraktion der binärcodierten Maschinenbefehle in menschen verständlicherer Sprache.[...]
Ja, und ein Compiler wird nicht in den nächsten 50-100 Jahren einen Algorithmus durch einen besseren ersetzen, weil er es selbst mitkriegt. Das muss der Mensch noch lange lange allein machen.
Naja, so weit würde ich das nicht wegpacken, in 20 Jahren könnte es vielleicht schon soweit sein, bedenke wie rasant die Entwicklung vorangeht und bald gibt es Quanten-PC's und wir brauchen neue Cryptoalgorithmen. ;-)
Ein möglicher Algorithmus wäre, das Ergebnis vorherberechnen, wie es sein soll und auf dessen basis, einen effektiveren Algo vorzuschlagen, falls er einen kennt. Aber das ist eigentlich gar nicht das Ziel.
Wenn ich etwas in C/C++ mache, dann habe ich eine Erwartung, wie der übersetzte asm-code aussieht. Und dieser Erwartung wird der Compiler im großen und ganzen gerecht. Weil es da meistens auch nichts zu deuten gibt, wie es von dir dargestellt wird. Ein in C gebautes quicksort, wird (mit gleichen gimmicks) einem relativ gut gecodetem asm-quicksort in nichts nachstehen. (ok, bei asm kann man direkt den stack benutzten und muss sich nicht selber einen bauen)
Und assoziatives denken (!) werden irgendwann auch Computer können.
Aber nicht mehr in unserer Lebensspanne, vermute ich mal. Und wenn wir an diesem Punkt sind, dann brauchen wir nicht mehr programmieren, da die Computer dem menschlichen Hirn sowieso ueberlegen sind(, die Weltherrschaft uebernehmen), und sich selbst programmieren. Und soweit soll es in meiner Zeit nicht kommen :-)
Ja, ich habe vor solchen Visionen auch immer wieder Angst.
Aber als erstes gehen die ganzen Arbeiterjobs drauf, das mit den Jobs in Forschung/Entwicklung, wird sich noch bisschen länger hinziehen, aber irgendwann, bräuchenen wir wahrscheinlich alle nicht mehr zu arbeiten, allerdings sollte bis dahin die Menschheit ihre inneren Konflikte lösen, sonst gehts zurück in die Steinzeit.
MfG
DDR-RAM
-
Leute man kanns auch ernsthaft übertreiben:P Ich schweige ab jetzt dazu einfach^^
-
der Programmierer nur bei Flaschenhälsen eingreifen
Ging es nicht darum?
C ist eine Hochsprache, geschaffen, um die Programmierung zu vereinfachen.
auch, aber z.B. auch um die Portablität zwischen verschieden Architekturen zu verbessern.
Auch.
Damit gehen immer Einschränkungen einher, denn je mehr die Sprache vorgibt, desto weniger kann man alleine tun.
also C/C++ schränken uneingeschränkt nicht ein.
Dann bräuchte man kein Asm mehr. Da man es aber braucht......
Im äußersten lowlevel Bereich ist asm natürlich ein muss, um prozessorspezifische Sachen zu machen (wie IDT laden, paging aktivieren, etc.), ja in sofern ist C beschränkt.
[...]
Ein möglicher Algorithmus wäre, das Ergebnis vorherberechnen, wie es sein soll und auf dessen basis, einen effektiveren Algo vorzuschlagen, falls er einen kennt.
Falls er einen kennt. Dat ersetzt aber den Menschen, der ihn sich ausdachte nicht...
Ein in C gebautes quicksort, wird (mit gleichen gimmicks) einem relativ gut gecodetem asm-quicksort in nichts nachstehen. (ok, bei asm kann man direkt den stack benutzten und muss sich nicht selber einen bauen)
Wie war das mit dem beschränkt? :)
allerdings sollte bis dahin die Menschheit ihre inneren Konflikte lösen, sonst gehts zurück in die Steinzeit.
Soweit waren wir schonmal mit dem kalten Krieg. Ich glaube nicht, dass die Menschheit jemals ihre innersten Probleme lösen wird, leider.
Ist mir auch relativ egal, solange es mich nicht betrifft.
________________
Was ich sagen will - ein Compiler einer Hochsprache ist effektiv, insbesondere die neusten Generationen. Aber eine Hochsprache hat _immer_ Nachteile gegenueber der reinen Prozessorsprache, was gewisse Sachen angeht. Perfekte Optimierung und 100%ige Flaschenhalsentfernung ist mit einer Hochsprache - besonders im Lowlevelbereich - nicht möglich. Die Vorteile sind nicht von der Hand zu weisen, denn wenn man einen 100000 Zeilen-Asm-Code mal schnell als Mensch durchgehen soll und dabei noch strukturelle Fehler finden soll... ne danke. Und dafuer wurden Hochsprachen geschaffen - um dem Menschen den Ueberblick zu gewähren. Portierung kam später dazu, urspruenglich war eh keine Portabilität geplant; sie hat auch den Nachteil, dass ein Fehler im Programm xy auf z verschiedenen Plattformen funktionieren kann... aber das ist ne andere Sache.
Optimierung bis zum äussersten geht nur mit Assembler, Programmierung in Massen ist Domäne der Hochsprachen.
Was man allerdings machen kann, ist ein Programm in einer Hochsprache zu schreiben und dann auf Maschinensprache von Hand zu uebersetzen; damit umgeht man die Unuebersichtlichkeit. Ist aber auch Ansichtssache, wie so vieles...
Svenska
-
Boah leute, die 20-30% die ne gute(!) ASM Implementierung wohl gegenüber ner guten(!) Hochsprachenimplementation bringen wird (ausser wohl im Bereich von SIMD, da die Compiler wohl noch nicht so toll sind ;) ) sind wenig im Vergleich von einem guten zu einem schlechten Algorithmus.
Implementiert erstmal einen ordentlichen Algorithmus, wenn ihr das habt, dann guckt mal ob sich ASM überhaupt lohnt.
-
[...]
Ein möglicher Algorithmus wäre, das Ergebnis vorherberechnen, wie es sein soll und auf dessen basis, einen effektiveren Algo vorzuschlagen, falls er einen kennt.
Falls er einen kennt. Dat ersetzt aber den Menschen, der ihn sich ausdachte nicht...
Wenn der Compiler einen auswählt, den er kennt, dann hast du recht, ja,
wenn er aber z.B. einen genetischen Algorithmus arbeitet, der einen Algorithmus verändert, dann muss der Coder des Compilers _nur_ diesen bauen, der Rest ergibt sich sozusagen von selbst.
(mir ist klar, das genetische Algorithmen im allgemeinen recht langsam zum Ziel kommen, aber die PC's werden auch schneller)
Und wie gesagt, das ist auch nicht Aufgabe des Compilers.
Ein in C gebautes quicksort, wird (mit gleichen gimmicks) einem relativ gut gecodetem asm-quicksort in nichts nachstehen. (ok, bei asm kann man direkt den stack benutzten und muss sich nicht selber einen bauen)
Wie war das mit dem beschränkt? :)
:D
allerdings sollte bis dahin die Menschheit ihre inneren Konflikte lösen, sonst gehts zurück in die Steinzeit.
Soweit waren wir schonmal mit dem kalten Krieg. Ich glaube nicht, dass die Menschheit jemals ihre innersten Probleme lösen wird, leider.
Ist mir auch relativ egal, solange es mich nicht betrifft.
immer dieser Egoismus. :shock: Aber eine Hochsprache hat _immer_ Nachteile gegenueber der reinen Prozessorsprache, was gewisse Sachen angeht. Perfekte Optimierung und 100%ige Flaschenhalsentfernung ist mit einer Hochsprache - besonders im Lowlevelbereich - nicht möglich.
Die Nachteile, sind doch nicht zwanghaft, sie sind vorhanden, bei wahrscheinlich allen aktuellen Compilern.
Alles was zum Programmablauf zu wissen ist, steht im Quellcode.
Ein gut "ausgebildeter" asm-coder könnte diesen maximal optimiert übersetzten. Diese maximale Optimierung, geschieht doch aber nicht irgendwie wirr, sondern nachvollziehbar, ja wahrscheinlich sogar nach einem bestimmten Schema/Algorithmus und das ist genau das, was ein Computer sehr gut kann. Das es recht gut geht, sieht man an den heutigen Compilern. Das es aber noch besser ginge, sieht man daran, das an einigen stellen, handoptimierung sinnvoll wird.
Optimierung bis zum äussersten geht nur mit Assembler
In asm kann man als einiziges für einen speziellen Prozessor hinoptimieren, ja. Algorithmen kann man aber auch in allen anderen Sprachen optimieren. (ja, das meintest du wahrscheinlich nicht ;-) ).
Bei Hochsprachen optimiert der Compiler, bei asm ist einem das selber überlassen (ja, wieder sind die algorithmen nicht gemeint).
Das, was uns wahrscheinlich trennt, ist, dass ich glaube das Compiler (vielleicht in 20 Jahren, vielleicht eher) maximale Optimierung erreichen können.
Boah leute, die 20-30% die ne gute(!) ASM Implementierung wohl gegenüber ner guten(!) Hochsprachenimplementation bringen wird
Die Zahl ist aber reichlich aus der Luft gegriffen, 20-30% schneller ist Handoptimierter Code wahrscheinlich nicht, kleiner erst recht nicht.
Ich würde maximal von 10%, im Durchschnitt aber _deutlich_ unter 5%.
(ausser wohl im Bereich von SIMD, da die Compiler wohl noch nicht so toll sind ;) )
ja, hoffentlich _noch_ :roll:
sind wenig im Vergleich von einem guten zu einem schlechten Algorithmus.
Ja, das will keiner abstreiten ;-)
Implementiert erstmal einen ordentlichen Algorithmus, wenn ihr das habt, dann guckt mal ob sich ASM überhaupt lohnt.
willst du an _uns_ Zweifeln? ;-)
MfG
DDR-RAM
-
Also,
allerdings sollte bis dahin die Menschheit ihre inneren Konflikte lösen, sonst gehts zurück in die Steinzeit.
Soweit waren wir schonmal mit dem kalten Krieg. Ich glaube nicht, dass die Menschheit jemals ihre innersten Probleme lösen wird, leider.
Ist mir auch relativ egal, solange es mich nicht betrifft.
immer dieser Egoismus. :shock:
Ich als kleiner Durschnitts-Otto-Normalverbraucher habe nichts an der Welt zu verändern, mein Einfluss ist zu gering. Und ich will nicht Politiker sein, denn alles, was man macht, ist falsch.
Ausserdem bezweifle ich, dass gewisse Menschen es jemals schaffen, die Welt zu erobern - genug Versuche gab es ja. Und erst, wenn die Welt ein Staat ist und auch geeint ist, wird es ueberhaupt gewisse Probleme nicht geben. Es gab genug Versuche, der Welt eine gemeinsame Sprache aufzubrummen - Interlingua, Esperanto - alles schiefgelaufen.
Wenn die Menschen sich umbringen - oder die Computer die Menschen fuer Ueberfluessig erachten - will ich schon lange eines natuerlichen Todes gestorben sein. Der Rest ist mir egal und das hat nix mit Egoismus zu tun.
Das, was uns wahrscheinlich trennt, ist, dass ich glaube das Compiler (vielleicht in 20 Jahren, vielleicht eher) maximale Optimierung erreichen können.
Damit wären in vielleicht 20 Jahren die Computer den menschlichen Hirnen gleichgestellt, wenn nicht noch schlimmer. Das nennt man dann Singularität und die will ich nicht erleben :shock:
Boah leute, die 20-30% die ne gute(!) ASM Implementierung wohl gegenüber ner guten(!) Hochsprachenimplementation bringen wird
Wenn du alles von der Hochsprache implementieren lässt und demgegenueber das gleiche optimiert in Hand schreibst... das sind vielleicht 3-4%, im Extremfall (da lohnt es sich dann) dann auch mal 5 oder gar 6%.
sind wenig im Vergleich von einem guten zu einem schlechten Algorithmus.
Ja, der entscheidet ueberall um mehrfache 100% Unterschied.
Implementiert erstmal einen ordentlichen Algorithmus, wenn ihr das habt, dann guckt mal ob sich ASM überhaupt lohnt.
Lohnt sich in der Mehrzahl aller Fälle nicht wegen der Masse an Code. Es sei denn, man hat Spass dran :)
Svenska
-
sind wenig im Vergleich von einem guten zu einem schlechten Algorithmus.
Ja, das will keiner abstreiten ;-)
Ja warum streitet ihr euch dann hier überhaupt? Ja, 20-30% waren schon aus der Luft gegriffen, aber zumindestens früher war das durchaus noch möglich (und da hab ich auch schon programmiert, falls jemand auf die idee kommen sollte sich zu fragen warum mich das interressiert ;) )
GCC 3.4 und die aktuellen Intel Compiler usw. machen es einem da schon viel schwerer ;)
Aber wenn dann lohnt es sich auch mehr die Compiler zu optimieren als alles in Assembler zu optimieren - wenige (zwar grosse) Programme die verbessert werden, und dadurch laufen alle Programme schneller, als wenn man alle(!) Programme auf dieser Ebene optimieren wollte.
Ãhnlich sieht es wohl auch innerhalb eines einzigen Programmes aus - in der Art das man dafür sorgen sollte auch nen aktuellen Compiler zu haben (der dann hoffentlich besser optimiert).