www.mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik Was benötigt weniger Takte If oder case?


Autor: John (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Wegstaben Verbuchsler (wegstabenverbuchsler)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: _Gast_ (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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).

Autor: Hans Mayer (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Hans Mayer (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wobei da genau der interessante Teil fehlt: der Binärbaum.

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Oder einfach ne Tabelle, die ist meistens die schnellste, wenn gleich 
speicherintensivste Lösung.

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Anja (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: gnuopfer (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
A. K. schrieb:
> Wobei da genau der interessante Teil fehlt: der Binärbaum.

Welcher Compiler (auf welcher Architektur) macht das tatsächlich ?
GCC ? IAR ?

Autor: MaWin (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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.

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hab nachgesehen. Es ist wie vermutet, GCC implementiert dies im 
maschinenunabhängigen Teil in diversen Varianten abhängig von 
Maschineneigenschaften und Kostenabschätzung.

Autor: Ralph (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Lehrmann Michael (ubimbo)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
John schrieb:
> Anwendung die recht Zeitkritisch ist

Dann kann es nicht in C sein ...

Autor: Ralph (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: John (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Danke an alle Antworten.

Autor: spess53 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: thomas (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Ralph (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: spess53 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: thomas (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Hannes Lux (hannes)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

...

Autor: spess53 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi

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:

    312c:  40 e0         ldi  r20, 0x00  ; 0
    312e:  50 e0         ldi  r21, 0x00  ; 0
  for(a = 0; a < 6; a++)
  {
    ....
    3162:  4f 5f         subi  r20, 0xFF  ; 255
    3164:  5f 4f         sbci  r21, 0xFF  ; 255
    ....
    3168:  46 30         cpi  r20, 0x06  ; 6
    316a:  51 05         cpc  r21, r1

    316c:  61 f7         brne  .-40       ;
    }

Bei jedem, der nicht gerade gestern mit Assembler angefangen hat, sieht 
das so aus:
      ldi r20,6

xyz:  ....
      dec r20
      brne xyz

MfG Spess

Autor: thomas (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Fairerweise muss man sagen, ein C Programmierer hätte vermutlich ++a und 
nicht a++ geschrieben :D

Autor: spess53 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Markus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
thomas schrieb:
> Fairerweise muss man sagen, ein C Programmierer hätte vermutlich ++a und
>
> nicht a++ geschrieben :D

Verstehe ich nicht.

Autor: thomas (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Preincrement ist schneller als Postincrement (wenn es der Compiler nicht 
eh schon optimiert).

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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
int main()
{
  unsigned char a;

  for( a = 0; a < 6; a++ )
    foo( );
}


void foo()
{
  PORTB = 0xFF;
}
macht.
oid foo()
{
  PORTB = 0xFF;
  38:  8f ef         ldi  r24, 0xFF  ; 255
  3a:  88 bb         out  0x18, r24  ; 24
  3c:  88 bb         out  0x18, r24  ; 24
  3e:  88 bb         out  0x18, r24  ; 24
  40:  88 bb         out  0x18, r24  ; 24
  42:  88 bb         out  0x18, r24  ; 24
  44:  88 bb         out  0x18, r24  ; 24
{
  unsigned char a;

  for( a = 0; a < 6; a++ )
    foo( );
}
  46:  80 e0         ldi  r24, 0x00  ; 0
  48:  90 e0         ldi  r25, 0x00  ; 0
  4a:  08 95         ret

0000004c <foo>:


void foo()
{
  PORTB = 0xFF;
  4c:  8f ef         ldi  r24, 0xFF  ; 255
  4e:  88 bb         out  0x18, r24  ; 24
}
  50:  08 95         ret

00000052 <_exit>:
  52:  f8 94         cli

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

Autor: Nico S. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
/OT: Mit welchem Compilerschalter kriegt man diese Mixed-ASM-C-Variante 
hin?

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
anderes Beispiel
static unsigned char a;


void foo()
{
  PORTB = a;
}

int main()
{
  for( a = 0; a < 12; a++ )
    foo( );
}

der gcc macht daraus (-Os + -fwhole_program)
  48:  80 e0         ldi  r24, 0x00  ; 0
  4a:  02 c0         rjmp  .+4        ; 0x50 <main+0x8>
  4c:  88 bb         out  0x18, r24  ; 24
  4e:  8f 5f         subi  r24, 0xFF  ; 255
  50:  8c 30         cpi  r24, 0x0C  ; 12
  52:  e0 f3         brcs  .-8        ; 0x4c <main+0x4>
  54:  80 93 60 00   sts  0x0060, r24
  58:  80 e0         ldi  r24, 0x00  ; 0
  5a:  90 e0         ldi  r25, 0x00  ; 0
  5c:  08 95         ret

Da kann man doch nicht meckern.

Besser als
  4c:  88 bb         out  0x18, r24  ; 24
  4e:  8f 5f         subi  r24, 0xFF  ; 255
  50:  8c 30         cpi  r24, 0x0C  ; 12
  52:  e0 f3         brcs  .-8        ; 0x4c <main+0x4>
kannst du die zentrale Schleife auch nicht programmieren.

Autor: spess53 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: spess53 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Ralph (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Na dann sind wir ja einer Meinung

Autor: spess53 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi

>Na dann sind wir ja einer Meinung

Wenn du deine geändert hast, ja.

MfG Spess

Autor: thomas (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Hagen Re (hagen)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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

Autor: MaWin (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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.

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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)

Autor: Hagen Re (hagen)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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

Autor: Hagen Re (hagen)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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.

Autor: Hagen Re (hagen)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Hagen Re (hagen)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Hagen

guter Rat.
Belass es dabei.
Es ist ziemlich offensichtlich, dass du keine Ahnung hast wovon du hier 
überhaupt sprichst.

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Hagen Re (hagen)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Hagen Re (hagen)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@  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, . . . ."

Autor: MaWin (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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)"

Autor: Hagen Re (hagen)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Johnny B. (johnnyb)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Hagen Re (hagen)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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

Autor: Nico22 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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.

Autor: MaWin (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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.

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@  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

Autor: Hagen Re (hagen)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@  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

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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

Autor: Hagen Re (hagen)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@  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

Autor: Hagen Re (hagen)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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

Autor: Hagen Re (hagen)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@  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

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Hagen Re (hagen)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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

Autor: Hagen Re (hagen)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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

Autor: someone (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Hagen Re (hagen)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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

Autor: Hagen Re (hagen)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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

Autor: Nico22 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@  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

Autor: someone (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Hagen Re (hagen)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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

Autor: Läubi .. (laeubi) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@  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

Autor: Läubi .. (laeubi) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Hagen Re (hagen)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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

Autor: someone (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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

Autor: MaWin (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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.

Autor: someone (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: MaWin (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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.

Autor: someone (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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!

Autor: Nico S. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: MaWin (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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.

Autor: someone (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: MaWin (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: someone (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Pozidriv (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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. :-)

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.