Thema: Wieviele Takte benötigt ein Befehl?

[Roshl]

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.

[DDR-RAM]

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

[Roshl]

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

[DDR-RAM]

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 ^^)

Code: [Auswählen]


cmp ebx, 2
jae  defaultLabel
jmp [tableBase+ebx*4]

im Vergleich zu dem compiler-code:

Code: [Auswählen]


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

Code: [Auswählen]


switch (x)
{
case 0:
case 1:
case 3:
return false;
case 2:
return true;
default:
[...]
}

verwendet er ne jump-table.

MfG
DDR-RAM

[Roshl]

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

[n3Ro]

Aber du weist schon das jmp und call nicht wirklich das gleiche machen ?

[Roshl]

...Das PRINZIP einer Call und einer Jump Tabelle ist exakt das gleiche

[DDR-RAM]

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

MfG
DDR-RAM

[Roshl]

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...

[DDR-RAM]

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:

Code: [Auswählen]

typedef int (*FUNCTION)();

FUNCTION  pfnArray[256];

int main(int argc)
{
return pfnArray[argc]();
}


jmp table eher sowas:

Code: [Auswählen]


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

[Roshl]

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.

[DDR-RAM]

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.:

Code: [Auswählen]

void MacheEtwas2()
{
[...]
}

void MacheEtwas1()
{
[...]
MacheEtwas2();
}wird zu

Code: [Auswählen]

MacheEtwas1:
[...]
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

[Svenska]

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

[Roshl]

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.

[DDR-RAM]

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!

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"

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  

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

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

[Svenska]

Musst du die Postings zeilenweise zerlegen?

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  

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

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??

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

[DDR-RAM]

Musst du die Postings zeilenweise zerlegen?

nein, aber ich tat es (und werde es wieder tun, wenn es sein muss )

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??

Nö, Intel/AMD warens

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

[Roshl]

Leute man kanns auch ernsthaft übertreiben:P Ich schweige ab jetzt dazu einfach^^

[Svenska]

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

[Legend]

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.