Hallo,
nutze ein ATmega644, finde es leider nicht im Datenblatt. Habe eine
Anwendung die recht Zeitkritisch ist, von daher ist jeder cycle wichtig.
Würdet ihr mir eher if oder switch case Anweisungen empfehlen?
Danke schön
Mfg
programmier doch mal so und mal so und compilier das ganze.
Die Programmgröße KÖNNTE einen Hinweis auf Laufzeiten geben - das
Assemblerlisting der fraglichen Passage liefert dir das genaue
Ergebniss.
Oh... Ist dir der Unterschied zw. C und ASM bekannt? Sagt dir das Wort
"Compiler" etwas?
>Würdet ihr mir eher if oder switch case Anweisungen empfehlen?
Das hängt davon ab wie der Compiler das umsetzt. Im Datenblatt bzw. im
Instruction Set findest du nur die Dauer der Assemblerbefehle
(Mnemonics).
Tipp: Ausprobieren und Simulieren oder LSS-File angucken (wenn du
AVR-ASM kannst).
Kommt drauf an wieviele Fälle abgeprüft werden müssen.
case ist manchmal eine sprungtabelle, das ist ab geschätzt 4 Fällen
schneller.
Kommt aber auch drauf an ob nicht sowieso meistens der erste Zweig
genommen wird.
Am besten Du probierst es aus.
Wenn zeitkritisch, mehr als einige wenige Abfragen und nicht zu
ungleichmässig verteilt in der Wahrscheinlichkeit, dann switch
verwenden. Wenns passt wird eine Sprungtabelle draus, andernfalls oft
ein Baum.
Yep, wenns passt nimmer er die. Brauchbare Compiler berechnen abhängig
von der Werteverteilung den Aufwand und entscheiden sich für die ihnen
am sinnvollsten erscheinende Version, evtl. noch gewichtet über
Optimierung auf Tempo oder Zeit.
Da AVRs sich im Unterschied zu x86ern vor Sprungbefehlen nicht zu
fürchten brauchen ist die Baumvariante aber auch nicht zu verachten.
John schrieb:> Würdet ihr mir eher if oder switch case Anweisungen empfehlen?
bei if hast Du die Möglichkeit je nach Aufrufhäufigkeit der einzelnen
Zweige die Anzahl der Vergleiche zu optimieren.
Wenn Du sowieso in Unterprogramme verzweigen willst hilft ein Aufruf
über eine Funktionspointertabelle.
Gruß Anja
A. K. schrieb:> Wobei da genau der interessante Teil fehlt: der Binärbaum.
Welcher Compiler (auf welcher Architektur) macht das tatsächlich ?
GCC ? IAR ?
> Würdet ihr mir eher if oder switch case Anweisungen empfehlen?
Klassischerweise baut ein Compiler ein switch zu mehrfachem if um, wenn
das kürzeren Code erlaubt, sonst nutzt er Dinge wie Sprungtabellen wenn
die kürzer sind.
Keine Ahnung, wie deiner optimieren kann, musst du in den erzeugten
Assemblercode gucken.
Man kann aber auch mit if z.B. durch Aufbau eines
Binärsentscheidungbaumes
if(a<3)
{
if(a==1)
{
}
else // a==2
{
}
}
else // a==3||a==4
{
if(a==3)
{
}
else
{
}
}
kürzeren und schnelleren Code schaffen als der Comiler, der nicht weiss,
daß a nicht 0 oder 5 sein wird.
gnuopfer schrieb:> Welcher Compiler (auf welcher Architektur) macht das tatsächlich ?> GCC ? IAR ?
GCC tut dies definitiv. Ebenfalls tat dies bereits eine leicht
modernisierte K&R-Fassung des kaum optimierenden recht simplen PCC
Anfang der 80er. Es ist im Compiler recht einfach zu implementieren -
ganz im Gegensatz zum äquivalenten Code in Form von if-statements durch
den Programmierer.
Dieses Verfahren ist grundsätzlich unabhängig von der Architektur.
Lediglich die Kosten der entstehenden Teiloperationen könnten davon
abhängig sein, insbesondere da schwer vorhersagbare Sprungbefehle bei
modernen High-Performance-Architekturen einem Binärbaum teurer zu stehen
kommen als einer Sprungtabelle, d.h. es könnte sinnvoll sein, bei
Optimierung auf Tempo die Gewichtung der Alternativen von der
Architektur abhängig zu machen. Inwieweit das geschieht weiss ich nicht.
PS: Wie beim avr-gcc allgemein üblich kann es durchaus vorkommen, dass
die Gewichtung etwas schief liegt. Weshalb es speziell im avr-gcc eine
Möglichkeit gibt, table switches auszuschliessen (-mno-tablejump).
PPS: Ich weiss nicht, ob GCC dies maschinenabhängig oder
maschinenunabhängig implementiert. Will damit nur sagen, dass das
Prinzip dieses Verfahrend weitgehend maschinenunabhängig ist.
Hab nachgesehen. Es ist wie vermutet, GCC implementiert dies im
maschinenunabhängigen Teil in diversen Varianten abhängig von
Maschineneigenschaften und Kostenabschätzung.
Also wenn du jetzt schon jeden Cycle zählen musst um das Zeitverhalten
sicher zustellen, dann hast du schlicht und einfach eine vollkommen
falsche entworfene Programmlogik, oder den falschen µC.
Aber das ist typisch wenn erst die Hardware ausgewählt wird, und danach
versucht wird die Logik in diese Vorgabe zu pressen.
Bei zeitkritischen Verhalten dürfte es sinnvoller sein in der kritischen
Sektion ( wahrscheinlich ein Interrupt) nur die Daten zu sammeln und
abzulegen.
Die Auswertung mit den If , Case ,... Anweisungen außerhalb der
kritische Sektion in der Mainloop abzuhandeln.
Lehrmann Michael schrieb:> John schrieb:>> Anwendung die recht Zeitkritisch ist>> Dann kann es nicht in C sein ...
Unsinn
Guter C Code mit einem guten Compiler erzeugt besseren ASM Code als 99%
aller ASM Programmierer.
Hi
>Unsinn>Guter C Code mit einem guten Compiler erzeugt besseren ASM Code als 99%>aller ASM Programmierer.
Träum weiter.
Das habe ich mal getestet. Ich bin in Assembler auf 1/3 der Codegröße
eines vergleichbaren C-Programms gekommen. Bei sehr korrekter
Assemblerprogrammierung ist man nach meiner Schätzung immer noch ca.
30-40% kleiner.
MfG Spess
Ralph schrieb:> Unsinn> Guter C Code mit einem guten Compiler erzeugt besseren ASM Code als 99%> aller ASM Programmierer.
Die Aussage ist Schwachsinn. Wirklich zeitkritische Programmteile die
eine genau bestimmte Anzahl von cycles benötigen dürfen bzw. müssen,
kommen an Assembler nicht vorbei.
Man kann das uU auch in C hinmurksen, wartbar ist der Code dann in der
Regel aber nicht mehr vernünftig.
spess53 schrieb:> Das habe ich mal getestet. Ich bin in Assembler auf 1/3 der Codegröße> eines vergleichbaren C-Programms gekommen. Bei sehr korrekter> Assemblerprogrammierung ist man nach meiner Schätzung immer noch ca.> 30-40% kleiner.
Dann hat der C-code oder der Compiler, oder beides nichts getaugt.
Auch C-code lässt sich so schreiben das der Compiler daraus einen ASM
Code erzeugt den du auch mit Hand nicht besser hinbekommst.
Vieleicht einige ASM Gurus, aber nicht die Masse der Programmierer.
Ich hatte auch schon ne Interruptroutine in C.
Die hatte in der ersten Version 300 ASM steps benötigt. Nach optimieren,
an Compilerverhalten anpassen ( zb auswahl des Variablebtypes, Auswahl
des Speicherbereichs ) ,....... kam ich auch 90 ASM steps.
==> guter C-Cde ergibt auch schöanken schnellen ASM Code.
Ein Compiler kann nicht aus jedem C-Code guten ASM erzeugen, da muss
schon etwas hirnschmalz in den C-Code laufen.
Hi
>Vieleicht einige ASM Gurus, aber nicht die Masse der Programmierer.>Ein Compiler kann nicht aus jedem C-Code guten ASM erzeugen, da muss>schon etwas hirnschmalz in den C-Code laufen.
Und das können auch nur ein paar C Gurus und nicht die Masse der
Programmierer.
MfG Spess
Du scheinst nicht allzuviel Assemblererfahrung zu haben. Compiler haben
es so an sich, sicherheitshalber möglichst oft Register zu sichern. Der
Pragrammierer weiß allerdings genau, was er nun sichern muss und was er
ruhig überschreiben kann. Bei kleinen Programmen behaupte ich einfach
mal, jeden Compiler ohne weiteres ausstechen zu können.
Wobei es in Echtzeitprogrammen ja garnicht unbedingt auf möglichst
schnelle Ausführung ankommt. Wichtig ist, dass ein bestimmten
Programmteil genauso lange braucht wie vorgesehen und das geht per
Assembler viel einfacher und auch eleganter als mittels C-Code.
spess53 schrieb:> Hi>>>Vieleicht einige ASM Gurus, aber nicht die Masse der Programmierer.>>>Ein Compiler kann nicht aus jedem C-Code guten ASM erzeugen, da muss>>schon etwas hirnschmalz in den C-Code laufen.>> Und das können auch nur ein paar C Gurus und nicht die Masse der> Programmierer.
Eben! Und die paar Leute, die das können, die können auch ASM, denn
sonst wären sie nicht in der Lage, ihren C-Code so zu formulieren, dass
etwas Vernünftiges bei raus kommt.
>> MfG Spess
...
Hi
>Fairerweise muss man sagen, ein C Programmierer hätte vermutlich ++a und
nicht a++ geschrieben :D
Das stammt aus dem Webserver von Uli Radig.
MfG Spess
spess53 schrieb:> Nur mal ein kleines Beispiel:>> In einer simple Schleife for(a = 0; a < 6; a++)> {> ...> }>> wird der Schleifenzähler (übrigens als unsigned char a deklariert) wie> folgt bearbeitet:
Das der gcc als gestandener C Compiler bei reinen 8-Bit Operationen so
seine Schwierigkeiten hat, ist bekannt. Aber so runtermachen musst du
ihn auch wieder nicht.
> Bei jedem, der nicht gerade gestern mit Assembler angefangen hat, sieht> das so aus:
Soo? Tut es dass
Dann schaun wir doch mal was der Optimizer aus
1
intmain()
2
{
3
unsignedchara;
4
5
for(a=0;a<6;a++)
6
foo();
7
}
8
9
10
voidfoo()
11
{
12
PORTB=0xFF;
13
}
macht.
1
oid foo()
2
{
3
PORTB = 0xFF;
4
38: 8f ef ldi r24, 0xFF ; 255
5
3a: 88 bb out 0x18, r24 ; 24
6
3c: 88 bb out 0x18, r24 ; 24
7
3e: 88 bb out 0x18, r24 ; 24
8
40: 88 bb out 0x18, r24 ; 24
9
42: 88 bb out 0x18, r24 ; 24
10
44: 88 bb out 0x18, r24 ; 24
11
{
12
unsigned char a;
13
14
for( a = 0; a < 6; a++ )
15
foo( );
16
}
17
46: 80 e0 ldi r24, 0x00 ; 0
18
48: 90 e0 ldi r25, 0x00 ; 0
19
4a: 08 95 ret
20
21
0000004c <foo>:
22
23
24
void foo()
25
{
26
PORTB = 0xFF;
27
4c: 8f ef ldi r24, 0xFF ; 255
28
4e: 88 bb out 0x18, r24 ; 24
29
}
30
50: 08 95 ret
31
32
00000052 <_exit>:
33
52: f8 94 cli
34
35
00000054 <__stop_program>:
36
54: ff cf rjmp .-2 ; 0x54 <__stop_program>
Ich würde mal sagen, er hat Loop-Unrolling betrieben.
Besser kriegst du das auch nicht hin.
Hört endlich mit diesem Schwachsinn auf! Natürlich zahlt man einen
kleinen Penalty für den Compiler und ja, wenn es auf den Taktzyklus
ankommt führt kein Weg an Assembler vorbei.
Aber: Wann ist das relevant?
Bei Neulingen sicherlich nicht. Den Penalty vom Compiler kann man in den
meisten Projekten mit links zahlen. Das tut keinem weh. Deine 30 bis 40%
von weiter oben führe ich auf C-Anfänger zurück. So hoch ist diese Zahl
niemals.
Und wenn er sagt es wäre zeitkritisch, dann wäre es auch in Assembler
zeitkritisch, da bin ich 100% sicher. Mit dem Ersetzen eines if durch
einen switch-case ist es da nicht getan. Jede Wette das er in
Wirklichkeit ganz andere Probleme hat.
Hi
>Hört endlich mit diesem Schwachsinn auf!
Hast ja Recht. Nur das:
>Guter C Code mit einem guten Compiler erzeugt besseren ASM Code als 99%>aller ASM Programmierer.
konnte ich nicht so stehen lassen.
MfG Spess
Ralph schrieb:> Dann hat der C-code oder der Compiler, oder beides nichts getaugt.
Natürlich kann man sich auf diesen Standpunkt stellen. Dummerweise muss
man dann selber in Assembler programmieren, denn dann gibt es überhaupt
keine tauglichen C Compiler. Und wer programmiert schon freiwillig mit
untauglichem Werkzeug?
Es gibt immer Code, bei dem ein Assembler-Programmierer viel rausholen
kann, auch ohne am Verfahren drehen zu müssen. Compiler sind
Kompromisse, sei es weil die Sprache das verlangt, sei es weil sich der
Aufwand nicht für jeden Kokolores lohnt.
Umgekehrt gibt es auch Code, mit denen ein Compiler sich bei der
Optimierung leichter tut als ein Assembler-Programmierer. Der schon
angesprochende binary tree switch ist so ein Fall, denn ein
Assembler-Programmierer, der mit symbolischen Namen statt lexikalischen
Konstanten operiert, programmiert sich dabei einen Wolf während der
Compiler das in mühelos hinbekommt.
> Auch C-code lässt sich so schreiben das der Compiler daraus einen ASM> Code erzeugt den du auch mit Hand nicht besser hinbekommst.
Ein prinzipielles Problem liegt darin, dass der AVR - und um den geht es
hier ja - eine 8-Bit Architektur ist, C aber von mindestens einer 16-Bit
Architektur ausgeht. Das hat diverse Konsequenzen.
Die öfter anzutreffende Rechnung in 16 Bits lässt sich unter Einsatz von
type casts ggf. noch teilweise einschränken, unter Missachtung der
Lesbarkeit. Aber ein C Compiler wird die 32 Byte-Register deshalb
tendentiell als 16 Wort-Register behandeln, ein Assembler-Programmierer
hingegen nicht.
Es gibt auch eine Reihe weiterer Aspekte, die sich in C nur mit
deutlichem Aufwand umsetzen lassen, wie beispielsweise das Aliasing, von
denen sich ein Assembler-Programmierer hingegen wenig behindert fühlt.
spess53 schrieb:> Hi>>>Hört endlich mit diesem Schwachsinn auf!>> Hast ja Recht. Nur das:>>>Guter C Code mit einem guten Compiler erzeugt besseren ASM Code als 99%>>aller ASM Programmierer.>> konnte ich nicht so stehen lassen.
Mach aus den 99% so ca 80% und du wirst in etwa bei der Wahrheit sein.
Denn eines ist unbestritten: automatisch geht gar nichts. Alles muss man
lernen. Übung macht den Meister.
Da ist es völlig egal, ob man nun von Assembler, C oder BASCOM redet.
Überall kann man schlecht arbeiten und in allen Sprachen kann man gute
Programme schreiben.
Hi
>Denn eines ist unbestritten: automatisch geht gar nichts. Alles muss man>lernen. Übung macht den Meister.>Da ist es völlig egal, ob man nun von Assembler, C oder BASCOM redet.>Überall kann man schlecht arbeiten und in allen Sprachen kann man gute>Programme schreiben.
Da brauchst du bei mir keine offenen Türen einzurennen.
MfG Spess
Um es vielleicht zusammenzufassen: Es hat niemand behauptet, dass man
mit C nicht zeitkritisch programmieren kann, dennoch gibt es Aufgaben
für die sich Assembler besser eignet als C.
ich habe nach 20 Jahren ähnliche Erfahrungen wie Spess gemacht. Ein
guter ASM und C programmierer wird einen guten Compiler immer schlagen.
Meine Erfahrungen mit GCC sind das ein Mensch in ASM bis zu 50% weniger
Code benötigt bei doppelt so schneller Ausführung des Code am Ende. Dazu
darf man aber nicht nur eine Schleife als Vergleich heranziehen sondern
zb. eine komplette Grafikbibliothek oder ähnlich größeres.
Gruß hagen
@Hagen Re (hagen)
>ich habe nach 20 Jahren ähnliche Erfahrungen wie Spess gemacht. Ein>guter ASM und C programmierer wird einen guten Compiler immer schlagen.
Das war auch kaum strittig.
>Meine Erfahrungen mit GCC sind das ein Mensch in ASM bis zu 50% weniger>Code benötigt bei doppelt so schneller Ausführung des Code am Ende.
Aber zu welchem Preis? ASM ist deutlich aufwendiger zu handhaben, von
Portabilität ganz zu schweigen.
Es gilt IMO immer noch. 90% der Rechenleistung werden in 10% des Codes
verbraucht. DIE muss man finden und optimieren. Zuerst in C, wenns doch
nicht reicht in ASM. Der Rest muss "nur" solide hingeschrieben werden.
http://en.wikipedia.org/wiki/Program_optimization#Quotes
MFG
Falk
> Es gilt IMO immer noch. 90% der Rechenleistung werden in 10%> des Codes verbraucht. DIE muss man finden und optimieren.
Ich sag mal so:
Der klassische Programmierer verwendet heute C++ oder Java,
und merkt nicht mal, welche Megabytes an Code er damit importiert
und mitbenutzt, die Dinge tun, die das Programm zur Erledigung
der Arbeit gar nicht braucht.
So schlecht kann ein C oder Assemblerprogramm gar nicht werden,
denn das sind immerhin noch Programmiersprachen, wo man was
hinschreiben muss, wenn etwas passieren soll, und nicht 'inherited'
unsichtbar Code ausgeführt wird.
Obwohl Rechner immer schneller werden, bleiben die Programme darauf
gleich langsam, weil die Programmentwickler immer schlechter werden,
sie haben zu wenig Anreiz was braucbares zu produzieren. Gerade neulich
wollte ich mir den Quelltext von einer HTML-Seite ansehen, was bisher
unter IE7 ein Klick war und plopp war er da. Bei IE8, nach 15 Minuten,
erscheint ein unbedienbar langsames Irgendwas, und bloss weil der
Quelltext 1MB statt der wohl im Test maximal benutztn 10k umfasste.
Ärmlich.
@MaWin
Auch wenn ich in vielen nicht mit dir konform gehe.
In deiner Konklusio bin ich mit dir unisono.
Die große Masse der Programmierer wird immer schlechter. Sie können ihr
Handwerk nicht mehr.
Merk ich jeden Tag hier. Die jungen Kollegen von der Uni sind ohne
Garbage Collector komplett aufgeschmissen. Datenstrukturen, was ist das?
Lineare Liste, gar doppelt verzeigert, ääääähhhhh hab ich noch nie
gemacht!
Gibts das? Ein Uni-Abgänger, der in seiner ganzen Ausbildung nie eine
Liste programmiert hat? Von einem Baum red ich erst mal gar nicht. Das
kanns doch nicht sein, dass in der Ausbildung nur noch vorgefertigte
Komponenten auf vorgefertigte Forms gezogen werden und das wars dann.
Eventuell noch 2 Werte miteinander verknüpfen, aber bitte in der Formel
nichts komplizierteres als eine Wurzel, weil sonst sind wirds zu
kompliziert.
(Alles 'leicht' übertrieben und mit einem Körnchen Salz zu geniessen.
Aber so kommts mir vor! Und wenn nicht heute dann in spätestens 5
Jahren)
@Falk: unbestritten, Compiler nehmen uns Arbeit ab. Aber sie sind eben
längst nicht so gut wie der Mensch. Aus meiner Sicht, wenn ich mal
unkonstruktiv kritisieren darf, sind fast alle Compiler deren Arbeit ich
analysieren durfte, sogar grotten schlecht. ABER! ich habe selbst noch
nie einen programmiert und möchte mich nicht anmaßen es besser
programmieren zu können. Man sieht halt das Resultat des Compilers, weiß
vorher schon intuitiv was man ungefähr erwarten kann, und ist dann
denoch häufig überrascht das der oft so gerühmte Compiler noch
schlechter sein kann als erwartet. Man denkt sich seinen Teil und weiß
das es eigentlich besser gehen könnte. Beobachtet man die
Compilerentwicklungen der letzten Jahre so sieht man dort auch keinen
Fortschritt im Sinne neuer Technologien. Obwohl es meiner Meinung nach
sehr wohl interessante Forschungsergebnisse gibt zb. selbstlernende
Systeme, clevere Optimierungsverfahren usw. Also mich hat lange Zeit
kein Compiler mehr positiv überrascht.
>Aber zu welchem Preis? ASM ist deutlich aufwendiger zu handhaben, von>Portabilität ganz zu schweigen.
Naja, ganz so dramatisch ist es auch wieder nicht. Wenn man einen
konkreten Plan hat, ganz genau sein Werkzeug kennt, dann kann man auch
in ASM ziemlich fix programmieren. Die Projektgröße, Wartbarkeit und
Austauschbarkeit der Menschen ist der limitierende Faktor.
Wenn man keine Portierbarkeit benötigt, die Wartung überschaubar ist da
es keine weiteren Änderungen geben wird, Fehler auf Grund der Qualtität
der Arbeit (eg. Erfahrungen) mit einer gewissen Wahrscheinlichkeit
ausschließen kann, dann ändern sich die Verhältnisse bei einem Vergleich
mal eben drastisch.
Ich stimme dir aber insofern zu das man Assembler wirklich nur nutzen
sollte wenn man alle anderen Optimierungsmöglichkeiten ausgeschöpft hat.
Das hat aber andere Gründe als "Compiler sind schon super gut und
erzeugen vergleichbar guten Code wie ein Mensch". In meinen Augen sind
Compiler noch weit davon entfernt, sie sind Krücken die uns so viel Zeit
sparen das es sich rentiert für uns sie zu nutzen.
Gruß Hagen
schon 1997 bauten wir Computer/Programme die einen Schach-Weltmeister
gezielt und reproduzierbar schlagen können. Ein Compiler macht in meinen
Augen nichts anders als so ein Schachprogram aus Sicht der
Optimierungsstrategieen bzw. der Suche eines Optimums als Zielsetzung.
Exakt das sollte ein Compiler ebenfalls machen. Ich denke also das der
Mensch genügend Wissen hat um Compiler zu bauen die mit Sicherheit
bessere Resultate bringen als der Mensch selber. Es gibt sie halt nur
nicht, diese Compiler.
Gruß Hagen
@Hagen
Nichts gegen dich.
Aber von Compilerbau hast du keine Ahnung.
Und nein. Schach hat nicht das geringste mit Compilerbau zu tun. Noch
nicht einmal ansatzweise. Schachprogramme haben auch mit künstlicher
Intelligenz nichts zu tun, ausser vielleicht die Techniken wie man einen
Baum vorzeitig beschneiden kann. Schachprogramme haben viel mehr mit
cleveren Suchstrategien als mit irgendwas anderen zu tun.
@Karl Heinz: wusste garnicht das du meine Vita kennst, aber wie ich's
oben schon andeutete habe ich tatsächlich noch nie einen programmiert.
Das dürfte weniger am Sachverstand gelegen haben sondern eher daran das
es keinen Reiz für mich darstellt.
Gruß Hagen
Hagen Re schrieb:> @Karl Heinz: wusste garnicht das du meine Vita kennst,
:-)
Wer Schach und Compiler in einem Satz nennt, hat sich ziemlich
offensichtlich noch nie sich mit den Problemen im Compilerbau
rumgeschlagen.
Ist keine Schande oder eine schlechte Wertung oder so.
@Karl:
>Schachprogramme haben viel mehr mit>cleveren Suchstrategien als mit irgendwas anderen zu tun.
Ah, und was ist das fertige Compilat eines Compilers ? Ein Optimum aus
einer rießigen Menge von schlechten/Untauglichen Programmcodes. Damit
sind Compiler, bzw. könnten zukünftige Compilerm, sehr wohl auch
Suchalgortihmen nach dem effizientesten Programmcode sein der die vom
menschen vorgegebenen Kritierien=Ziele erfüllt.
Ich widerspreche dir in diesem Punkt kategorisch. Es geht nicht darum
welche Techniken heutige Compiler benutzen sondern welchen Technologien
dem menschen schon längst bekannt sind die ebenfalls in den Compilerbau
Einzug hätten müssen.
Gruß Hagen
Um einen Compiler bauen zu können, der in jedem Einzelfall nicht
schlechter als ein guter Assembler-Programmierer ist, muss man erst
einmal eine Programmierprache definieren, die es möglich macht, alle
Kenntnisse des Programierers über das Programm sauber in dieser Sprache
zu formulieren. Und die alle Spezialitäten der zugrundeliegenden
Maschine abbilden kann. Beides ist bei C nicht der Fall.
Einen "Compiler" der Kategorie "Schachcomputer" gibt es bereits. Den GNU
Superoptimizer. Allerdings ist die zulässige "Programmspezifikation"
sehr überschaubar.
Ach Karl Heinz, mit welcher Begründung und welchen konkreten Argumenten
stellst du deine Behauptungen denn auf ? Bisher hast du dir nur
Aufmerksamkeit veschafft indem du die Worte eines Anderen mit
persönlichen Attacken konterst.
Letzendlich ist es mir egal was du von meinen Aussagen hälst. Ich bleibe
dabei weil ich denke das ich sie für mich logisch begründen kann.
Gruß Hagen
Hagen Re schrieb:> Ach Karl Heinz, mit welcher Begründung und welchen konkreten Argumenten> stellst du deine Behauptungen denn auf ? Bisher hast du dir nur> Aufmerksamkeit veschafft indem du die Worte eines Anderen mit> persönlichen Attacken konterst.
Das Problem
In deinen letzten Absätzen hast du eine Menge Unsinn geplappert.
Und ich will mir jetzt vor Weihnachten nicht auch noch diese ewig
gleiche Dikussion "Compiler sind Scheisse, Assembler sind so super"
antun.
Wenn du in Assembler programmieren willst dann tus. Ich werd dich nicht
daran hindern. Während du noch deine ersten 15000 Zeilen Assembler
debuggst, sitz ich dann schon lange (im Sommer) am Pool und geniesse
meinen Urlaub und pfeif auf die 3 bis 5% Laufzeitverlust, die ich mir
durch die Hauchsprache eingehandelt habe aber dafür bin ich lange
fertig, ehe du noch deine Register sortiert hast bzw die Stelle gefunden
hast, an der du das Statusregister zu pushen/popen vergessen hast
wodurch dann der Branch 15 Zeilen weiter bei einem falschen Carry
springt.
Es ist mir schlicht und ergreifend egal, ob der Compiler bei einer
komplexen Berechnung ein paar Push/Pop zuviel hat, weil er durch etwas
anderes Registerumschaufeln ein Registerpärchen frei bekommen hätte.
Das kostet ein paar Nanosekunden und die kann ich mir leisten, wenn ich
dafür 2 Tage früher mit der Funktion fertig bin.
Irgendwo weiter oben ist mal die Anmerkung gefallen, dass man doch bitte
schön nicht einzelne Schleifen in C versus Assembler vergleichen sollte.
Dem stimme ich zu. Nur ich warne gleich: Die Ahnung dass Assembler dann
immer besser abschneidet ist trügerisch. Bis zu einer gewissen
Komplexität wird der Assemblerprogrammierer davonziehen aber dann dreht
es sich um. Dann holt die Hochsprache mächtig auf und setzt zum
Überholen an. Denn irgendwann frisst dir in Assembler die Komplexität,
die du nicht mehr beherrscht die Haare vom Kopf.
@karl:
ließt du die Postings der Anderen überhaupt richtig ?
Ich habe nie behauptet das ich Assembler bevorzugen würde. Ich habe
gesagt das die Aussage "heutige Compiler wären gut" falsch ist. Die
Referenz für die Qualität eines Compilers ist der Mensch. Ein mögliches
flexibles Instrument für den Menschen bei einem Vergleich wäre der
Assembler.
Nun, meine Kernaussagen sind:
- der Compilerbau in den letzten Jahren stagniert, technologisch
- Usache ist die Ökonomie so wie du sie auch vorlebst: solange
existierende kostengünstige Copmiler schneller irgendein Ziel erreichen
als der Assemblerprogrammier sind sie ökonomisch.
- das führt dazu das dann unerfahrene Programmier sagen das sie mit dem
5-8% schlechteren Ergebnis des Compilers leben könnten. Es sind aber
nicht nur 5-8% sondern weit mehr nach meinen Erfahrungen.
Ich differenziere also. Ökonomisch sind Compiler, idealisiert sind sie
weitaus schlechter als der Mensch und die Compiler könnte durchaus viel
besser sein.
Ergo: es ist Schwachsinn alles in Assembler zu bauen. Gleichermaßen ist
es Schwachsinn zu behaupten die Compiler wären gut aus Sicht der heute
bekannten Möglichkeiten.
Gruß Hagen
Hagen Re schrieb:> - das führt dazu das dann unerfahrene Programmier sagen das sie mit dem> 5-8% schlechteren Ergebnis des Compilers leben könnten. Es sind aber> nicht nur 5-8% sondern weit mehr nach meinen Erfahrungen.
Das liegt aber nicht am Compiler sondern an der Unerfahrenheit.
Tut mir leid, aber das ist doch Bullshit. Weiter oben wurden Zahlen
genannt, die sind doch einfach nur abenteuerlich und aus den Fingern
gesogen!
Compiler sind gut, auch wenn du etwas anderes behauptest.
> nicht nur 5-8% sondern weit mehr nach meinen Erfahrungen
Wie willst du das denn vergleichen?
Ich rede hier von richtigen Programmen. 300000 Lines of C++ Code
aufwärts. Sowas ist doch in Assembler gar nicht mehr machbar! Wie willst
du wissen dass du mehr als 8% verloren hast?
@ Karl heinz Buchegger (kbuchegg) (Moderator)
>Und ich will mir jetzt vor Weihnachten nicht auch noch diese ewig>gleiche Dikussion "Compiler sind Scheisse, Assembler sind so super">antun.
"Alle Jahre wieder, . . . ."
> Compiler sind gut
Na wunderbar, Mister Superklug.
Hagen hat recht.
Globales Optimieren, um im Endresultat wirklich genau die minimal
notwendige Anzahl (Speicherplatz oder ausgeführte) Instruktionen
auszuwerfen die zur algorithmischen Lösung des in der Hcohsprache
formulierten Problems notwendig ist, macht kein Compiler, und auch
zumindest bei grösseren Projekten kein Assemblerprogrammierer.
Es gibt noch verdammt viel Optimierungsmöglichkeiten, und wie man an
notorisch langsamen Programmen sieht auch Optimierungsbedarf.
Allerdings machen es die Hochsprachenprogrammierer ja den Compilern auch
schwer, mit ihren meist "ach ich bin so herrlich flexibel und habe alles
so nichtssagend implementiert daß es auch in 10 Jahren noch flexibel
einsetzbar sein wird (weil es nichts tat was relevant war und wirklich
Arbeit weggeschafft hat muss es auch nicht gelöscht werden)"
@Karl:
>Tut mir leid, aber das ist doch Bullshit. Weiter oben wurden Zahlen>genannt, die sind doch einfach nur abenteuerlich und aus den Fingern>gesogen!
Du beziehst dich auf die 50% weniger Code bei 50% mehr Performance. ?
Nungut, da bezog ich mich konkret auf meine Nokia6100 Grafik Bibliothek.
In version 1 alles in WinAVR GCC programmiert. In Version 2, in 7 Tagen,
als Assemblerversion. Und dort stimmen diese Zahlen sehr wohl. Und
nachdem ich in C die Algorithmen einmal programmiert habe war die
Umsetzung in Assembler ebenfalls sehr schnell fertig.
Falls du es mit deinen Aussagen ernst meinst dann bin ich gerne bereit
in meinen Backups auf Suche zu gehen und dir das Projekt zu mailen um
sie deinem umfassenden Sachverstand zur Begutachtung zu überlassen. Du
könntest aber auch hier in der Codelib auf Suche gehen dort findest du
beide Versionen, Freeware in Source.
Nun, ich behaupte nicht das deine Aussage "ist doch alles Bullshit"
Bullshit wäre, sie ist einfach nur falsch nach meinen Erfahrungswerten.
Gruß Hagen
MaWin schrieb:> Globales Optimieren, um im Endresultat wirklich genau die minimal> notwendige Anzahl (Speicherplatz oder ausgeführte) Instruktionen> auszuwerfen die zur algorithmischen Lösung des in der Hcohsprache> formulierten Problems notwendig ist, macht kein Compiler, und auch> zumindest bei grösseren Projekten kein Assemblerprogrammierer.
Nein, macht er nicht.
Und, wieviel macht das in Summe aus?
Bei richtigen Programmen, nicht dem Pipifax den wir hier im Forum
tagtäglich sehen und bei dem es völlig egal ist, ob eine ISR 120 oder
130 Takte braucht?
> Es gibt noch verdammt viel Optimierungsmöglichkeiten, und wie man an> notorisch langsamen Programmen sieht auch Optimierungsbedarf.
Ja.
Und der erste Schritt ist es, seine Sprache auch in den Feinheiten zu
lernen. Wenn ich mir hier ansehe, was einem da immer wieder an C Code
vorgesetzt wird, kommt mir ehrlich gesagt manchmal das Kotzen.
Hagen Re schrieb:> Falls du es mit deinen Aussagen ernst meinst dann bin ich gerne bereit> in meinen Backups auf Suche zu gehen und dir das Projekt zu mailen um> sie deinem umfassenden Sachverstand zur Begutachtung zu überlassen. Du> könntest aber auch hier in der Codelib auf Suche gehen dort findest du> beide Versionen, Freeware in Source.
OK.
Wenn ich zwischen den Feiertagen Zeit habe, dann such ich mir das mal.
50% ist ja nicht von schlechten Eltern.
Falk Brunner schrieb:> Es gilt IMO immer noch. 90% der Rechenleistung werden in 10% des Codes> verbraucht. DIE muss man finden und optimieren.
Es ist aber auch so, dass die Auftraggeber kaum mehr an solchen
Optimierungen interessiert sind. Jedenfalls nicht bei Produkten mit
kleineren bis mittleren Stückzahlen. Sobald der Code funktional
einigermassen in Ordnung ist, wird das Zeug hergestellt und an die
Kundschaft verscherbelt.
Anstatt dann Optimierungen vorzunehmen, wird dann bereits das
Nachfolgerprodukt entwickelt.
>Compiler sind gut, auch wenn du etwas anderes behauptest.
ich behaupte Compiler sind nicht schlecht aber mit Sicherheit auch nicht
gut. Gut ist für mich ein halbwegs erfahrener Mensch. Nur aus Sicht der
Ökonomie sind Compiler gut und was ökonomisch gut ist kann oft auf allen
anderen Gebieten versagen.
Gruß Hagen
@Hagen Re:
Beschäftige dich einmal mit Compilerbau. Hier gibt es Problemstellungen,
die mit Schach wirklich überhaupt nichts zu tun haben. Führe doche
einmal aus, wie genau deiner Meinung nach dieses nicht genutzte
Potenzial aussieht.
> Und, wieviel macht das in Summe aus?
Faktor 1000.
So unsere Ergebnisse mit unserem optimierenden Compiler.
Schaltet man die Optimierung aus, steigen die Ausführungszeiten bei
grösseen (über 100kB Source, über 100 Funktionen) Programmen um den
Faktor 1000.
@ Hagen Re (hagen)
>Systeme, clevere Optimierungsverfahren usw. Also mich hat lange Zeit>kein Compiler mehr positiv überrascht.
Also ich vor ein paar Jahren mit dem AVR-GCC angefangen habe, war ich
überaus positiv überrascht. Der Code ist IMO schon recht gut. Und für
95% aller Anwendungen klein und schnell genug.
Das ist sicherlich keine sonderlich "wissenschaftlich-objektive"
Aussage, so what. Ich bin kein Softwerker und erst recht kein
Compilerbauer. Und ich nutze AVR-GCC fast nur im Hobbybereich.
> Die Referenz für die Qualität eines Compilers ist der Mensch.
Was man schon mal in Frage stellen könnte. Ziel eines Compiler ist es
IMO NICHT, eine Algorithmus von einer Hochsprache in ASM theoretisch
perfekt zu übersetzen, sondern sich in erster Linie um die Verwaltung
von Variablen, Speicher und anderem Krümelkram zu kümmern. Wenn er
"nebenbei" noch bissel Optimieren kann, ist das nett und auch ein
Verkaufsargument, aber nicht wirklich der Kern des Compilers.
>- der Compilerbau in den letzten Jahren stagniert, technologisch
Keine Ahnung.
>- Usache ist die Ökonomie so wie du sie auch vorlebst: solange>existierende kostengünstige Copmiler schneller irgendein Ziel erreichen>als der Assemblerprogrammier sind sie ökonomisch.
Damit habe ich kein Problem. Am Ende zählt das GESAMTergebnis, nicht die
super sexy technische Lösung.
>- das führt dazu das dann unerfahrene Programmier sagen das sie mit dem>5-8% schlechteren Ergebnis des Compilers leben könnten.
Das sagen auch erfahrende ;-)
> Es sind aber nicht nur 5-8% sondern weit mehr nach meinen Erfahrungen.
Hmmm. Welche sind das? Konkrete Beispiele?
>Ich differenziere also. Ökonomisch sind Compiler,
Was eines der wesentlichen Kriterien heute ist.
> idealisiert sind sie weitaus schlechter als der Mensch
Das ist das Problem mit Iealen, sie sind nicht wirklich realistisch. Die
perfekte Lösung braucht unendlich Zeit und hat demnach eine Effizienz
von Null :-0
> und die Compiler könnte durchaus viel besser sein.
Wirklich? Beispiel? Ausserdem sollte man trennen zwischen reinem
Compiler und (aufgeblasenem) Framework.
MfG
Falk
@karl:
>Wenn ich zwischen den Feiertagen Zeit habe, dann such ich mir das mal.>50% ist ja nicht von schlechten Eltern.
Schön wir ändern die Tonlage und fangen an wie Profis uns dem Thema
sachlich zu nähern.
Die hauptsächliche Einsparung am Code wurde erzielt durch die
Funktionübergreifende Optimierung der Register und damit die Elimination
von Stackframes. Ich weiß das ich damit absichtlich und bewusst eine
große Schwachstelle der heutigen Compiler ausgenutzt habe. Desweiteren
konnte auf die Prozessorflags bewusst zugegriffen werden, also Carry zb.
Das geht in C garnicht bzw. nur umständlich. Die Datentypen konnten von
32Bit auf die max. nötigen 24Bit optimiert werden was zu weniger
Registerdruck (wieder mehr Freiheiten) und eben Performance führte.
Funktionsrüpmfe konnte eliminiert werden, dh. zwei Funktion mit
unterschiedlichen Aufrufkonventionen teilen sich den gleichen Rumpf.
Auch das geht nicht mit reinem C. Es wurden also bewusst Restriktionen
der Programmiersprache um eine Abstraktionsebe zu erschaffen ausgenutzt
weil diese in Asembler nicht existent sind. Die Freiheiten des
Assemblers wurden bewusst gegen die nötigen Restriktionen einer
Hochsprache ausgespielt.
Gruß Hagen
@ Karl heinz Buchegger (kbuchegg) (Moderator)
>> Globales Optimieren, um im Endresultat wirklich genau die minimal>> notwendige Anzahl (Speicherplatz oder ausgeführte) Instruktionen>> auszuwerfen die zur algorithmischen Lösung des in der Hcohsprache>> formulierten Problems notwendig ist, macht kein Compiler, und auch>> zumindest bei grösseren Projekten kein Assemblerprogrammierer.
Tja, und was lernen wir daraus? Ich behaupte mal, das ist kein
Compilerproblem sondern eher das Framework sowie das Softwarekonzept.
Und da ist der Programmierer, pardon, Softwareentwickler gefragt.
>Bei richtigen Programmen, nicht dem Pipifax den wir hier im Forum>tagtäglich sehen und bei dem es völlig egal ist, ob eine ISR 120 oder>130 Takte braucht?
Also ich darf doch sehr bitten! Das toggeln von LEDs und die Zeitmessung
zur Garung von Eiern sind hochseriöse Applikationen des 21.
Jahrhunderts!
>> Es gibt noch verdammt viel Optimierungsmöglichkeiten, und wie man an>> notorisch langsamen Programmen sieht auch Optimierungsbedarf.>Ja.>Und der erste Schritt ist es, seine Sprache auch in den Feinheiten zu>lernen. Wenn ich mir hier ansehe, was einem da immer wieder an C Code>vorgesetzt wird, kommt mir ehrlich gesagt manchmal das Kotzen.
Sehe ich auch so. Siehe oben.
MFG
Falk
@Hagen Re (hagen)
>Die hauptsächliche Einsparung am Code wurde erzielt durch die>Funktionübergreifende Optimierung der Register und damit die Elimination>von Stackframes.
Ist ja ganz nett für AVR & CO, aber spätestens beim ARM und in höheren
"Gewichtsklassen" mit Cache und Co kannst du das vergessen.
>konnte auf die Prozessorflags bewusst zugegriffen werden, also Carry zb.>Das geht in C garnicht bzw. nur umständlich.
Ist richtig, sowas kann man aber in Inline-ASM oder Funktionen packen.
Dazu muss man nicht alles komplett in ASM schreiben. Die WIRKLICH
wichtigen 10% muss man finden und optimieren, nicht alles!
>weil diese in Asembler nicht existent sind. Die Freiheiten des>Assemblers wurden bewusst gegen die nötigen Restriktionen einer>Hochsprache ausgespielt.
Womit die Lösung sehr plattformspezifisch bleibt. Ist teilweise OK,
teilweise aber auch ein K.O. Kriterium.
MFG
Falk
@Nico:
>Beschäftige dich einmal mit Compilerbau. Hier gibt es Problemstellungen,>die mit Schach wirklich überhaupt nichts zu tun haben.
Ja wenn du es auf Detailebene betrachtest. Auf Gesamtsicht ist es aber
so das ich als Mensch die Zielsetzung vorgebe, wie zb. in VHDL. Der
Compiler oder eben die Synthesewerkzeuge (VHDL) sollten dann diese
Gesamtzielsetzung als Gesamtheit betrachten und darauf im Gesammten
Optimierungsverfahren anwenden. Es gibt nun enorm viele gültige Lösungen
für den Compiler einen gültigen Proghrammcode zu bauen. Das Ziel sollte
es aber sein eine möglichst lokal optimale Lösung zu finden. Und dort
sind wir bei Verfahren angekommen die auch im Schach eine große Rolle
spielen. Da geht es nicht nur um MinMax oder ähnlich einfache Verfahren,
sondern eher um Suchstrategien, Neuronale Netze, Genetische Algorithmen.
Und gerade auf letzeren Gebieten zeigt uns das Finanzwesen, die Robotik,
Suchmaschinen wie Google usw. usw. das es Technologien gibt die durchaus
in den Compilerbau hätten Einzug halten müssen. Und der Mensch als
Referenz für einen Maßstab benutzt exakt die gleichen Strategien wenn er
absolut kontraproduktiv zur Ökonomie in handmade Assembler arbeitet. Ich
kann mir keine bessere Referenz bei einer Analyse der Qualität eines
Compilers als den Menschen selber vorstellen.
Gruß Hagen
@ MaWin (Gast)
>Faktor 1000.>So unsere Ergebnisse mit unserem optimierenden Compiler.
Dann solltet ihr vielleicht mal einen brauchbaren Compiler anschaffen.
>Schaltet man die Optimierung aus, steigen die Ausführungszeiten bei>grösseen (über 100kB Source, über 100 Funktionen) Programmen um den>Faktor 1000.
Kann ich nicht wirklich glauben. Das ist ja wie C64 Basic gegen ASM auf
nem Pentium. Selbst Faktor 10 wäre schon viel. Aber man kann immer mit
diversen Szenarien, Tricks oder auch mangelndem Verständniss einen Fall
produzieren, wo solche astronomischen Unterschiede rauskommen. Das ist
aber nicht die Unfähigkeit des Compilers, sondern des Konzepts.
MFG
Falk
@Falk:
>>Die hauptsächliche Einsparung am Code wurde erzielt durch die>>Funktionübergreifende Optimierung der Register und damit die Elimination>>von Stackframes.>Ist ja ganz nett für AVR & CO, aber spätestens beim ARM und in höheren>"Gewichtsklassen" mit Cache und Co kannst du das vergessen.
Korrekt, meine Worte, denn das bildet die Legitimation für die
Behauptung "solange Compiler nicht gleiches können" sind sie schlechter
als der Mensch und damit nicht gut genug in meinen Augen. Einzigst die
Ökonomie, sprich der Zeitaufwand ist das Argument für heutige Compiler,
aber deswegen sind sie nicht gut in dem was sie machen.
Gruß Hagen
@Falk:
>Tja, und was lernen wir daraus? Ich behaupte mal, das ist kein>Compilerproblem sondern eher das Framework sowie das Softwarekonzept.>Und da ist der Programmierer, pardon, Softwareentwickler gefragt.
Dann führe ich deine Arguemntation mal weiter: Compiler sind Programme
durch Menschen erschaffen. Ergo gelten deine Worte auch für die
Fähigkeiten heutiger Compiler. Und schlußendlich komme ich wieder auf
den Menschen und dessen Fähigkeiten als ultimative referenz für die
Qualität eines Compilers. Und nicht nur dafür sondern auch das der
Mensch letzendlich derjenige ist der definiert was Compiler können
müssen.
Gruß Hagen
@ Hagen Re (hagen)
>Compiler oder eben die Synthesewerkzeuge (VHDL) sollten dann diese>Gesamtzielsetzung als Gesamtheit betrachten und darauf im Gesammten>Optimierungsverfahren anwenden.
Sehe ich anders. Auf der Ebene sind gute Leute mit guten Konzepten
gefragt, der Compiler kann dort wenig machen.
>sondern eher um Suchstrategien, Neuronale Netze, Genetische Algorithmen.>Und gerade auf letzeren Gebieten zeigt uns das Finanzwesen,
Das Finanzwesen? Chaostheorie? Oder einfach nur Kapitalismus? Wir
driften ab . . .
> die Robotik,>Suchmaschinen wie Google usw. usw. das es Technologien gibt die durchaus>in den Compilerbau hätten Einzug halten müssen.
Warum müssen sie das, wenn sie ausreichend ökonomisch sind?
Technologie ist Mittel zum Zweck. Wenn ich ein Ziel ohne nennenswerte
Verluste mit "alter" Technologie erreiche, wozu HighTec? Siehe
Raumstation ISS. Die wurde zum Großteil mit alten russischen Rakten
versorgt, Stand Mitte der 1960er Jahre. Und wird es in den nächsten
jahren VOLLSTÄNDIG, weil das Space Shuttle eingemottet wird. Low Tec
schlägt HighTec, auch wenn das keiner hören will. Und wohin HighTec
manchmal führt, kann man u.a. hier nachlesen. (Warum kommt mir die
Geschichte so bekannt vor? :-(
http://www.bernd-leitenberger.de/hermes.shtml> Und der Mensch als>Referenz für einen Maßstab
Was stritig ist ;-)
> benutzt exakt die gleichen Strategien wenn er>absolut kontraproduktiv zur Ökonomie in handmade Assembler arbeitet. Ich>kann mir keine bessere Referenz bei einer Analyse der Qualität eines>Compilers als den Menschen selber vorstellen.
Das liegt aber eher an deiner eingschränkten Sichtweise bzw.
vorgefassten Meinung.
MFG
Falk
Hagen Re schrieb:> Bullshit wäre, sie ist einfach nur falsch nach meinen Erfahrungswerten.
Seh ich das richtig, dass deine Erfahrungswerte auf einem Vergleich
basieren, der 2004 gemacht wurde?
@Falk:
>> idealisiert sind sie weitaus schlechter als der Mensch>Das ist das Problem mit Iealen, sie sind nicht wirklich realistisch. Die>perfekte Lösung braucht unendlich Zeit und hat demnach eine Effizienz>von Null :-0
Falsch. Der Mensch ist real existent und in jedem Fall besser als der
Compiler. Es gibt also eine realistische Referenz als Maßstab zum
Compiler. Man muß halt die ökonomischen Zwänge ausser Acht lassen. Diese
Ökonomie hat nichts mit der Qualität zu tun sondern nur Quantität zählt.
Zu behaupten Compiler wären gut würde im größten Umfang also nur diese
ökonomischen Zwänge berücksichtigen und nicht die Technologie, das
Wissen und die Qualität.
Es gibt Gebiete bei denen wir zeigen können das viel modernes Knowhow in
die Entwicklung neuer Werkzeuge geflossen ist. Ich beziehe mich konkret
auf die Synthesewerkzeuge wie VHDL/Verilog usw. Dort sieht man ein
"Ganzheitliches" Konzept bei der Betrachtung einer durch den Menschen
vorgegebenen Zielsetzung. Dort sieht man auch wie die Werkzeuge denoch
portierbaren Source ermöglichen. Und nur dort wurde ich überascht von
dem was die Synthese aus meinen Vorgaben optimales gemacht hat.
Davei geht es nicht darum das das Werkzeug eigenständig erkennt das eine
bessere Formel zu einem besseren Ergebnis führt, also das defizite des
Menschens ausgeglichen werden. Soweit wage ich garnicht zu träumen. Aber
es geht darum das das was hibnten rauskommt bei der Vorgabe die der
Mensch vorbne gemacht hat mit der manuellen Arbeit eines Mesnchens
vergleichbar sein sollte (falls dieser die Zeit dafür aufwenden möchte
:-).
Gruß Hagen
@Karl:
>Seh ich das richtig, dass deine Erfahrungswerte auf einem Vergleich>basieren, der 2004 gemacht wurde?
In diesem konkreten Fall ja. Und ich behaupte das neuere WinAVR GCCs es
nicht besser machen, auch wenn ich damit Gefahr laufe wieder in ein
Wespennest zu stechen ;) Arbeite heute noch im Hobby bevorzugt mit der
2005'er Version.
Gruß Hagen
Hagen Re schrieb:> Auf Gesamtsicht ist es aber> so das ich als Mensch die Zielsetzung vorgebe, wie zb. in VHDL. Der> Compiler oder eben die Synthesewerkzeuge (VHDL) sollten dann diese> Gesamtzielsetzung als Gesamtheit betrachten und darauf im Gesammten> Optimierungsverfahren anwenden.
Richtig.
Dazu gehören dann auch Vereinbarungen wie Calling Conventions. Das sind
die Dinge, die dir deine Stackframe-"Optimierung" möglich machten,
nachdem du sie über den Haufen geworfen hast.
In der Gesamtheit gehören die dazu.
Hagen Re schrieb:> @Karl:>>Seh ich das richtig, dass deine Erfahrungswerte auf einem Vergleich>>basieren, der 2004 gemacht wurde?>> In diesem konkreten Fall ja.
OK.
Dann wird das erste in den nächsten Tagen sein, nachzusehen, inwiefern
sich deine Zahlen in den 6 Jahren dazwischen verändert haben. Sprich:
wieviel hat gcc in der Zwischenzeit dazugelernt.
Dann seh ich mir mal genau an, was du im Assembler gemacht hast und wo
du die 50% aus dem Ärmel zauberst.
@falk:
>>sondern eher um Suchstrategien, Neuronale Netze, Genetische Algorithmen.>>Und gerade auf letzeren Gebieten zeigt uns das Finanzwesen,>Das Finanzwesen? Chaostheorie? Oder einfach nur Kapitalismus? Wir>driften ab . . .
jain ;) Es geht ja gerade darum das die "Welt" sich weiterentwickelt hat
und gerade da Wissen angesammelt hat das auch gut im Compilerbau
benutzbar wäre. Es aber aus der Ökonomie heraus nicht benutzt.
Mit Finanzwesen meinte ich folgendes: schweizer Versicherungen/Banken
benutzen genetische Algortihmen um gezielt Formeln zu suchen die das
Risiko der Versicherungen auf die zu versicherten Personen besser
berechnen können. Das wurde mit Erfolg so gemacht. Dh. Maschinen haben
nur mit Hilfe von langzeiterfassten Eingangsdaten und Ausgangsdaten
(Alter,Geschlöecht,familiäre Situation, 20 Jahre später
Wahrscheinlichkeit des Versicherungsfalles und Rückzahlungschancen)
Formeln evolutioniert die besser sind als die die der Mensch entwickeln
konnte. Das! wäre für mich die Aufgabe des Compilers. Ich gebe ihm das
Ziel vor und er findet ein Optimum das ich selber niemals finden könnte.
Erstens weil mir die Zeit zu kostbar ist und zweitens, viel wichtiger,
weil es meine Resourcen übeschreitet da ich an die Grenze meiner
Auffassunggabe komme, also weil es so komplex ist 100'ende variablen,
100'erde Funktionen als gesamtheit zu überschauen. Die Schwäche der
Menschen ist es abstrahieren zu müssen, das kann die Machine bei
komplexen Sachen weitaus besser. Also erwarte ich das die Machine also
der Compiler exakt diese Schwäche ausbügelt.
Gruß Hagen
@someone:
>Hagen Re schrieb:>> Auf Gesamtsicht ist es aber>> so das ich als Mensch die Zielsetzung vorgebe, wie zb. in VHDL. Der>> Compiler oder eben die Synthesewerkzeuge (VHDL) sollten dann diese>> Gesamtzielsetzung als Gesamtheit betrachten und darauf im Gesammten>> Optimierungsverfahren anwenden.>Richtig.>Dazu gehören dann auch Vereinbarungen wie Calling Conventions. Das sind>die Dinge, die dir deine Stackframe-"Optimierung" möglich machten,>nachdem du sie über den Haufen geworfen hast.>In der Gesamtheit gehören die dazu.
Aber eben nur für uns, damit wir das Problem abstrahieren, zerlegen und
modularisieren können. Eine Machine muß das nicht zwangsläufig tuen, sie
kann besser als der Mensch alles als Gesamtheit optimieren. Und exakt
das würde ich erwarten, sie beseitigt Defizite die ich habe.
zZ. sind Compiler immer noch dicht an Assembler angelehnt, einfache
Übersetzer. Sie lösen noch nicht unterstützend Probleme für die der
Mensch keine Zeit hat oder bei denen er Defizite hat.
Gruß hagen
Hagen Re schrieb:> zZ. sind Compiler immer noch dicht an Assembler angelehnt, einfache> Übersetzer. Sie lösen noch nicht unterstützend Probleme für die der> Mensch keine Zeit hat oder bei denen er Defizite hat.
Das wäre dann aber eher die Aufgabe eines Codegenerators als die eines
Compilers. Das würde ja den what-you-write-is-what-you-get-Ansatz
komplett zerstören.
@ Hagen Re (hagen)
>Falsch. Der Mensch ist real existent und in jedem Fall besser als der>Compiler.
Du wiederholst dich. Und drehst dich weiter im Kreis.
>Zu behaupten Compiler wären gut würde im größten Umfang also nur diese>ökonomischen Zwänge berücksichtigen und nicht die Technologie, das>Wissen und die Qualität.
Compiler sind gut, auch wenn sie noch Verbesserungspotential haben.
Dein "gut" liegt im Unendlichen.
>Es gibt Gebiete bei denen wir zeigen können das viel modernes Knowhow in>die Entwicklung neuer Werkzeuge geflossen ist. Ich beziehe mich konkret>auf die Synthesewerkzeuge wie VHDL/Verilog usw. Dort sieht man ein>"Ganzheitliches" Konzept bei der Betrachtung einer durch den Menschen>vorgegebenen Zielsetzung.
;-)
VHLD ist ähnlich wie C natürlich gewachsen, da hat man auch in
verschiedenen Stufen Funktionalität aufgebohrt. Ursprünglich war es
reine Modelierungs- und Verifikationssprache, von Synthese war am Anfang
nicht die Rede! Und VHDL ist quasi ASM, und damit so maschinennah wie
möglich. Damit liegt das Optimierungspotential vor allem wieder beim
Programmierer!
Und Verilog ist ein billiger C-Hack ;-)
> Dort sieht man auch wie die Werkzeuge denoch> portierbaren Source ermöglichen.
Weil der "Compiler" aus verschiedenen Modulen besteht. Mapping sowie
Place und Route sind herstellerabhängig.
> Und nur dort wurde ich überascht von> dem was die Synthese aus meinen Vorgaben optimales gemacht hat.
Ach, dass die Logik ohne Fehler in ein paar ROMs übersetzt wurde? Welch
technologische Leistung!
VHDL ist algorithmisch deutlich einfacher gestrickt als C. Siehe oben.
>es geht darum das das was hibnten rauskommt bei der Vorgabe die der>Mensch vorbne gemacht hat
Das macht jeder korrekte Compiler!
>mit der manuellen Arbeit eines Mesnchens>vergleichbar sein sollte (falls dieser die Zeit dafür aufwenden möchte>:-).
Du singst schon wieder ein Loblied auf den Assembler. Stimmt, es ist
eine unglaubliche Leitung einen ASM Code von ASCII in den Maschinencode
in Hex zu übersetzen. Das und nicht mehr macht ein Assembler. Ein
besserer Softwerker würde das langweilig nennen. VHDL macht nicht
sonderlich viel mehr. Dort müssen auch "nur" FlipFLops generiert und
ROMs erkannt und gefüllt werden. Die "Optimierung" besteht in der
boolschen Vereinfach der Logikterme, das ist aber mit gängigen, linearen
mathematischen Verfahren kein Riesenaufwand. Und die Gimmicks von heute,
wo automatisch Strukturen wie RAMs etc. erkannt werden, beschleunigen
die Arbeit mit VHDL nicht nennenswert.
MFG
Falk
Hagen Re schrieb:> Aber eben nur für uns, damit wir das Problem abstrahieren, zerlegen und> modularisieren können. Eine Machine muß das nicht zwangsläufig tuen, sie> kann besser als der Mensch alles als Gesamtheit optimieren. Und exakt> das würde ich erwarten, sie beseitigt Defizite die ich habe.
Nein. Die sind vorgegeben. Die kann man auch beim Selbst-übersetzen des
Compilers entfernen/abändern. Oder du arbeitest direkt mit Direktiven an
den richtigen Stellen. (Was darf der Compiler überhaupt anpacken)
Du definierst also was der Compiler machen darf. Sagst du dazu nichts,
wird der entsprechende Standard genommen und der beinhaltet die Pflicht
Register nach festem Schema zu verwenden. Schliesslich "weiss" der
Compiler nicht, ob dein Programm zur Laufzeit die Anforderung gar nicht
mehr braucht.
@Falk:
>>Falsch. Der Mensch ist real existent und in jedem Fall besser als der>>Compiler.>Du wiederholst dich. Und drehst dich weiter im Kreis.
Tja das ganze Leben ist ein Kreislauf ;) In diesem falle ist es aber ein
Hauptpunkt meiner Agrument und damit unabdingbar. Ich wiederhole mich
also aber drehe mich arguemntativ sicherlich nicht im Kreis.
>>Zu behaupten Compiler wären gut würde im größten Umfang also nur diese>>ökonomischen Zwänge berücksichtigen und nicht die Technologie, das>>Wissen und die Qualität.>Compiler sind gut, auch wenn sie noch Verbesserungspotential haben.>Dein "gut" liegt im Unendlichen.
Tja und so biegt der Eine die Arguemente leicht in seine Richtung und
der Andere wieder in die eigene Richtung. Auch da drehen wir uns im
Kreis.
Ich jedenfalls sehe den Menschen als Referenz, und definiere ja
postuliere also einen Fixpunkt um überhaupt eine Agrumentationsbasis zu
haben. Nach welchen Kriterien und Maßstäben ist den dein "gut" zu
verstehen ?
Gruß Hagen
Hagen Re schrieb:> Suchmaschinen wie Google usw.
Also was ich von Google als "Suchergebnis" erhalte ist in meinen Augen
häufig gaaaaaanz weit weg von dem was "ich" als Optimum ansehen würde ;)
Hagen Re schrieb:> Ich beziehe mich konkret> auf die Synthesewerkzeuge wie VHDL/Verilog usw
Ob du glücklicher wärst wenn dein Code jedesmal Stunden zum compilieren
benötigen würde nur um 0,001% besser zu sein ;)
Hagen Re schrieb:> Neuronale Netze, Genetische Algorithmen
Hm... ein Compiler den ich erstmal anlernen muß? Dann macht der nacher
die selben Fehler wie ich :P
@ Hagen Re (hagen)
>haben. Nach welchen Kriterien und Maßstäben ist den dein "gut" zu>verstehen ?
Wenn es um C-Compiler geht, dann ist gut für mich, wenn der Code 80% der
Geschwindigkeit und max. 150% des Speicherverbrauchs einer (sehr) guten
Assemblerversion erreicht. Extreme Spezialfälle bleiben dabei
unberücksichtigt! Der Compiler soll dabei die Ressourcen der Hardware
sinnvoll nutzen, z.B. Register und Befehle. Der AVR-GCC ist da schon
ganz OK, wenn gleich es hier und da noch Potential gibt.
Und böse Zungen haben schon vor Jahrzehten den C-Compiler als
aufgezuckerten Makroassembler bezeichnet. Ist IMO OK. C ist hardwarenah
und generisch, es hat von problembezogenen Lösungsstrategien keine
Ahnung. Das war aber auch nie gewollt.
Du erwartest vom Compiler künstliche Intelligenz sogar bis in den
Bereich der konzeptionellen, algorithmischen Ebene. Das kann in
absehbarer Zeit kein Compiler leisten. Muss er auch nicht, zumindest für
mich.
MFG
Falk
Falk Brunner schrieb:> Geschwindigkeit und max. 150% des Speicherverbrauchs> einer (sehr) guten Assemblerversion erreicht.
Wobei man hier auch immer beachten muss, was macht es wenn der Compiler
einer 7,9k Version für einen Mega8 erzeugt und da die Optimierung
abbricht?
Wozu sollte er Arbeit reinstecken um noch auf 5k zu kommen? Gibt es Geld
für nicht genutzten Speicher von Atmel zurück?
Solange er wenn ich mehr Funktion hinzufüge halt weiter optimiert das
es halt reinpasst ist doch alles ok.
@Falk:
>>haben. Nach welchen Kriterien und Maßstäben ist den dein "gut" zu>>verstehen ?>Wenn es um C-Compiler geht, dann ist gut für mich, wenn der Code 80% der>Geschwindigkeit und max. 150% des Speicherverbrauchs einer (sehr) guten>Assemblerversion erreicht. Extreme Spezialfälle bleiben dabei>unberücksichtigt! Der Compiler soll dabei die Ressourcen der Hardware>sinnvoll nutzen, z.B. Register und Befehle. Der AVR-GCC ist da schon>ganz OK, wenn gleich es hier und da noch Potential gibt.
Aha. Dann kann ich ja annehmen, wenn der Assembler das stupideste
Element in der Kette ist, das der Mensch der mit diesem Assembler den
Vergleichscode erzeugt hat, auch bei dir die ultimative Referenz
darstellt.
Dh. wenn ein C-Compiler, ca. 80% Performance und 150% Resourcen
verbraucht im Vergleich zu einem durch einen Menschen erzeugten ASM
Code, dann ist das für dich gut. Wir beide benutzen also den Menschen
als absolute Referenz zur Beurteilung der Qualität eines Compilers.
Schön denn dann stimmen wir hier überein.
Der Unterschied zwischen uns besteht also nur noch in der Frage welche
Fähigkeiten der Referenz "Mensch" wir zur Beurteilung der Qualität eines
Compilers heranziehen. Ich betrachte alle Fähigkeiten des Menschens als
Basis zur Beurteilung. Ist das nicht legitim aus deiner Sicht ?
>Du erwartest vom Compiler künstliche Intelligenz sogar bis in den>Bereich der konzeptionellen, algorithmischen Ebene.
Korrekt, das wär das Maximum meines Erwartungswertes. Warum auch nicht ?
>Das kann in absehbarer Zeit kein Compiler leisten.
Vieleicht, oder teilweise doch, denn exakt auf diesen Gebieten haben wir
eben in den letzten 15 Jahren enorme Fortschritte gemacht die eben
meiner Meinung nach keinen Einzug in den Compilerbau gemacht haben.
> Muss er auch nicht, zumindest für mich.
Das ist dein gutes Recht, ist für mich aber eben kein Indiz dafür das
Compiler gute Resultate erzielen würden.
Gruß Hagen
Hagen Re schrieb:>>Das kann in absehbarer Zeit kein Compiler leisten.>> Vieleicht, oder teilweise doch, denn exakt auf diesen Gebieten haben wir> eben in den letzten 15 Jahren enorme Fortschritte gemacht die eben> meiner Meinung nach keinen Einzug in den Compilerbau gemacht haben.
Das sehe ich nicht.
Ein Compiler hat ein paar Garantien zu leisten, dass der generierte Code
die Anforderungen des Quellcodes erfüllt. Das Compilat also "korrekt"
arbeitet. Das ist bei lernenden oder heuristischen Systemen nicht der
Fall.
Ich würd einem solchen Compiler nicht besonders weit trauen.
Es gibt eine Menge Leute die am Compilerbau interessiert sind und sich
dort einbringen. Sowohl aus der Praxis als auch aus dem
Wissenschaftlichen Umfeld. Solche Ideen Inspirieren mit Sicherheit und
kommen durch das große Umfeld aus denen Beiträge stammen auch mit
hinein, nur müssen sie Anforderungen erfüllen.
Und mal ganz davon abgesehen. Menschlische Referenz? Kann jetzt die
Turing-Maschine doch nicht das gleiche lösen, wie der denkende Mensch?
Und wenn doch. Nehmen wir einen beliebigen Menschen und einen beliebigen
Compiler? Oder doch besser das theor. Limit beider?
@Hagen Re (hagen)
>Element in der Kette ist, das der Mensch der mit diesem Assembler den>Vergleichscode erzeugt hat, auch bei dir die ultimative Referenz>darstellt.
Im Gegensatz zu dir bin ich mit dem Gebrauch von Superlativen sparsam.
>Code, dann ist das für dich gut. Wir beide benutzen also den Menschen>als absolute Referenz zur Beurteilung der Qualität eines Compilers.>Schön denn dann stimmen wir hier überein.
Jain. Für mich als Hobbyanwender reicht diese einfache Betrachtung. Für
Profis kommen nach ökonomische Dinge hinzu.
>Compilers heranziehen. Ich betrachte alle Fähigkeiten des Menschens als>Basis zur Beurteilung. Ist das nicht legitim aus deiner Sicht ?
Nein. Auch der beste Compiler hat seine Grenzen, einige auf Grund der
von vorn herein getroffenen Einschränkungen beim Entwurf und auf Grund
des nicht perfekten Umsetzens von Entwicklungszielen.
>>Du erwartest vom Compiler künstliche Intelligenz sogar bis in den>>Bereich der konzeptionellen, algorithmischen Ebene.>Korrekt, das wär das Maximum meines Erwartungswertes. Warum auch nicht ?
Weil es über das Thema "Compiler" deutlich hinaus geht. Deine Träume
hatte man schon vor 30 und mehr Jahren, als man dachte, man füttert
einen Computer mit einer Zielvorgabe und er spuckt eine fertige
Schaltung aus. Die Jungs mussten auch auf den Boden der Tatsachen
zurückkehren. Die heutigen Entwurfswerkzeuge sind sehr mächtig und
hilfreich, aber um Größenordnungen unter diesen utopischen Zielen. Der
Mensch mit Know How ist immer noch das beste Werkzeug (wenn er mit
seinen Werkzeugen umgehen kann). Und das ist auch ganz gut so.
Auch deine genetischen Algorithmen im Finanzwesen sind wahrscheinlich
deutlich schmalbandiger als du denkst. Da wird auch "nur" mit cleverer
Mathematik und viel Fire Power eine nichtlineare Regression und
Korellation betrieben, in huntertfacher Variation durchgerechnet. Was
fundantal neues kommt da nicht raus. Man korrigiere mich, wenn ich mich
irre.
>eben in den letzten 15 Jahren enorme Fortschritte gemacht die eben>meiner Meinung nach keinen Einzug in den Compilerbau gemacht haben.
Weil sie IMO
a) ökonomisch nicht gefragt sind und
b) konzeptionell am Compiler vorbei gehen.
>Das ist dein gutes Recht, ist für mich aber eben kein Indiz dafür das>Compiler gute Resultate erzielen würden.
Du drehst dich schon wieder im Kreis. Aber ich glaube wir haben da
schlicht andere Anforderungen und Sichtweisen. Ich bin da eher der
Pragmatiker, weniger Visionär. Mit allen Vor- und Nachteilen.
MFG
Falk
> Ein Compiler hat ein paar Garantien zu leisten, dass der generierte Code> die Anforderungen des Quellcodes erfüllt. Das Compilat also "korrekt"> arbeitet. Das ist bei lernenden oder heuristischen Systemen nicht der> Fall.
Auch das Schachprogramm, welches als Beispiel zuerst vorkam, muss
korrekt nach den Schachspielregeln spielen.
Er sucht nur die Optimierungen heuristisch und bewertet den Zug, so wie
ein Compiler verschiedene Möglichkeiten der Abbildung des Programms in
den Maschinencode machen kann, und die Ergebnisse bewerten sollte.
Entscheidend ist, daß heute Compiler über Funktionsgrenzen hinaus
globaler optimieren müssen, da die Funktionen (Objektmethoden) bei
modernen Sprachen immer nichtssagender und inhaltslose werden. Nur mit
Optimierung innerhalb einer Funktion ist kein Blumentopf mehr zu
gewinnen.
Naja das
MaWin schrieb:>> Ein Compiler hat ein paar Garantien zu leisten, dass der generierte Code>> die Anforderungen des Quellcodes erfüllt. Das Compilat also "korrekt">> arbeitet. Das ist bei lernenden oder heuristischen Systemen nicht der>> Fall.>> Auch das Schachprogramm, welches als Beispiel zuerst vorkam, muss> korrekt nach den Schachspielregeln spielen.
Das sind nicht vergleichbaren Garantien. Das Einhalten der Zugregeln
müsstest du mit dem Einhalten der Binärkodierung des Maschinencodes
gleichstellen. Das ist in der Tat garantierbar.
Es bedeutet jedoch lange nicht, dass das Programm korrekt arbeitet.
Korrekt im Sinne vom Schach wäre ein fehlerfreies Spiel, dass dem Gegner
nicht gewinne lässt. Das kann das Schachprogramm, nicht garantieren.
genausowenig wie ein lernender Prozess oder heuristischer Prozess bei
der Optimierung.
Solche Methoden machen nur dann Sinn, wenn Wissenslücken vorhanden sind,
oder die exakte Auswertung der Möglichkeiten nicht innerhalb der zur
Verfügung stehenden Resourcen (Zeit, Speicher, Energie, etc) geleistet
werden kann.
> Korrekt im Sinne vom Schach wäre ein fehlerfreies Spiel
Korrekt im Sinne eines Compilers ist ein Maschinenprogramm
welches 'dasselbe' wie das Hochsprachenprogramm tut.
Das sollte Schachprogramm und Compiler garantieren können.
> dass dem Gegner nicht gewinne lässt.
Das wäre OPTIMAL, und weder das Schachprogramm garantiert das,
noch garantiert der Compiler daß er den kürzestmöglichen Code
erzeugt.
Lerne die Zusammenhänge und richtige Anwendung der Begriffe,
dann klappt es auch mit dem Verständnis.
MaWin schrieb:>> Korrekt im Sinne vom Schach wäre ein fehlerfreies Spiel>> Korrekt im Sinne eines Compilers ist ein Maschinenprogramm> welches 'dasselbe' wie das Hochsprachenprogramm tut.>> Das sollte Schachprogramm und Compiler garantieren können.
Nur der Compiler. Lernende Prozesse können es nicht. Sonst bräuchten sie
nicht lernen. Dann existiert eine stete Bindung zwischen Ein und
Ausgabe. Der Nachweis liesse sich führen, dass beides das gleiche
Verhalten beschreibt.
>>> dass dem Gegner nicht gewinne lässt.>> Das wäre OPTIMAL, und weder das Schachprogramm garantiert das,> noch garantiert der Compiler daß er den kürzestmöglichen Code> erzeugt.
Nein Optimal würde (in unserem Kontext) bedeuten den kürzesten
Weg/kürzeste Spiel zu erzeugen. Aber du kannst doch noch nichtmal sagen,
ob es überhaupt eine Gewinnstrategie für das Spiel Schach gibt.
Ich lege mich nicht besonders weit aus dem Fenster, wenn ich behaupte,
dass du ein korrektes Schachspiel ncihtmal erkennen würdest.
Formal korrekt vielleicht. Das jedoch ist schon beim Idiotenmatt
gegeben. Und wie der Name es impliziert keine korrekte Lösung eines
Schachprogramms. Das würd ich in de Tonne kloppen wenn es so spielt.
> Lerne die Zusammenhänge und richtige Anwendung der Begriffe,> dann klappt es auch mit dem Verständnis.
Guter Vorsatz. Leg du dann mal los!
MaWin, irgendwie trollst du in letzter Zeit rum.
Beim Schachprogramm sage ich: Optimal, wenn der Gegner nie gewinnt.
Bei C sage ich: Mach das so und so. Der Compiler kann sich keinen
Algorithmus aussuchen, ich gebe ihn vor. Ich lasse ihm nur die Freiheit,
wie genau er das in Maschinensprache umsetzt. Das ist doch eine andere
Hausnummer.
> MaWin, irgendwie trollst du in letzter Zeit rum.
Na immerhin verwechsle ich nicht die Worte.
Schach:
Korrekt: Spielregeln eingehalten, einen Verstoss erkennt man
Optimal: Auf dem kürzesten Weg zum Sieg
Compiler:
Korrekt: Code läuft wie hochstprachentechnisch vorgesehen
Optimal: So schnell wie möglich
Ich bin sicher, daß ich mit meiner Definition vernünftig bin.
D.n. daß du und someone etwas nicht begriffen haben.
Korrekt heisst regelkonform, da gibt's keine Heuristik.
Optimal kann man heuristisch lösen, wenn man nicht weiss wie man es
sonst machen soll, und riskiert nicht optimale Ergebnisse, aber wenn es
statistsich zu guten Ergebnissen führt, ist der Weg erstmal ok bis
jemand was besseres findet.
Und nun spielt noch schön.
MaWin schrieb:>> MaWin, irgendwie trollst du in letzter Zeit rum.>> Na immerhin verwechsle ich nicht die Worte.>> Schach:> Korrekt: Spielregeln eingehalten, einen Verstoss erkennt man> Optimal: Auf dem kürzesten Weg zum Sieg>
Falsch. Ein verlorenes Spiel ist keine korrekte Lösung des
Schachproblems.
> Compiler:> Korrekt: Code läuft wie hochstprachentechnisch vorgesehen> Optimal: So schnell wie möglich
Richtig.
Und den Nachweis der Korrektheit kannst du leisten wenn du lernend
vorgehst? Deine Disswertation ist dir sicher!
> Ich bin sicher, daß ich mit meiner Definition vernünftig bin.> D.n. daß du und someone etwas nicht begriffen haben.
Und die Fachliteratur liegt auch daneben.
Du machst Korrektheit einer Übersetzung an der Syntax fest im Falle des
Schachs. Auf was es jedoch ankommt und das erkennst du beim Programm ist
die beschriebene Semantik.
> Korrekt heisst regelkonform, da gibt's keine Heuristik.
Nein. Das wäre ein Kreisschluss. Sind Regeln korrekt?
Korrektheit bedeutet, dass ein System keinen Widerspruch in sich
enthällt.
Ein Programm, dass eine Lösung finden soll aber auch nicht-Lösungen
ausgibt ist nicht korrekt. Ob Primzahl-Finder oder sonst etwas.
Eine Nicht-Lösung von Schach ist es in Schach zu verlieren.
> Optimal kann man heuristisch lösen, wenn man nicht weiss wie man es> sonst machen soll, und riskiert nicht optimale Ergebnisse, aber wenn es> statistsich zu guten Ergebnissen führt, ist der Weg erstmal ok bis> jemand was besseres findet.
Das ist über all da gut und okay wo ich mich nicht darauf verlassen
muss.
Ich will an keine Herz-Lungenmaschine, die "sehr wahrscheinlich" so
funktioniert wie sie von den Programmieren spezifiziert wurde und nicht
danach wieviel der Compiler schon vorher mal "ausprobiert" hat.
> Und nun spielt noch schön.
Werd ich nach der Arbeit. Ist empfehlenswert, wenn man keinen Unsinn
abliefern möchte.
Sag mal, liest du eigentlich auf was du antwortest ?
Verstehen tust du's jedenfalls nicht.
Du schreibst eine dermassen gequirlte Scheisse,
daß jeder Versuch es dir noch beizugringen hoffungslos ist.
> Sind Regeln korrekt?
Die Regeln des Schachs sind vorgegeben. Basta.
Herr wirf Hirn.
Tja. Dumm wenn man im Anspruch an andere selber versagt oder?
DU bestandest auf die richtige Verwendung von Begriffen. Dann halte dich
dran und lass das Quasseln. kopfschüttel
Wenn du meinen Ausführungen nicht folgen kannst und sie deshalb als
gequirlten Scheiss bezeichnest, dann such dir einen x-belibiges Paper
zur Compiler-Verifikation.
Ihr habt beide einfach unterschiedliche Ausgangspunkte.
Beim einen ist das Ziel, regelkonform Schach zu spielen (MaWin), der
andere möchte das Schachproblem lösen. Beides legitime Ziele und für
beide lassen sich unterschiedliche Definitionen für korrekt und optimal
aufstellen. Richtig/falsch oder besser gibts nicht, da letztendlich
beide Standpunkte/Ziele unterschiedlich und somit nicht vergleichbar
sind.
Auch bezogen auf das Compilerproblem geht ihr von unterschiedlichen
Voraussetzungen aus. Einmal davon, aus einer Menge von möglichen und
korrekten(!) Lösungen, die möglichst optimale herauszufinden (MaWin).
Und andererseits, die Suche nach korrekten Lösungen überhaupt (wobei
hier auch nicht-korrekte Lösungen als solche in der Lösungsmenge
angenommen werden bzw. nicht ausgeschlossen werden können - was aber
schon die Voraussetzung für MaWins Argumentation ist).
MaWin schrieb:> Ich bin sicher, daß ich mit meiner Definition vernünftig bin.
Das klingt doch schon nicht mehr so absolut.
Also, klassisches aneinander vorbeireden. :-)
Thread beobachten
Seitenaufteilung abschalten