Softpicks.Net Deutsch

[Michael Zimmermann]

Hallo!

Anton Huber:
> Kommt davon wenn man C Programme ...erzeugt
> ... Es sei mir bitte verziehen ...

Ego te absolvo.

Programmiere drei Basicunser und sündige fortan nicht mehr.
;-)

> > Sic. Egal, ob ich jetzt a=a+1; oder a++; schreibe -
> > wieso laßt Ihr eigentlich alle die ;;; weg? Verwöhnt
> > von VB? - , muß ja letztlich die gleiche Aktion
> > durchgeführt werden, also gleichviele Bytes bewegt
> > werden.
> >
> > Auch bei a++ wird ein um eins erhöhter Wert berechnet
> > und a erneut zugewiesen.
>
> Ich hab jetzt noch mal nachgelesen, da mir da so was im
> Hinterkopf herumschwirrte. Selbst der Erfinder der
> Sprache C++ (Bjarne Stroustrup) schreibt in seinem Buch
> 'The C++ Programming Language' Das die
> Ausführungsgeschwindigkeit von ++a höher als a++ ist.

Wieviel Prozent? Daran hängt es, wieviel praktische
Relevanz einer solchen Aussage zukommt.

> ...
> Also, überdenke Deine Aussage(n) besser noch mal ...

Da gibt's nicht viel zu überdenken. Es ist etwa 25 Jahre
her, daß ich das Zeugs habe lernen müssen und ich verwende
es so selten als möglich. Wenn ich irgendwas mit C(++),
mit Java, mit Abscheu programmieren /muß/, ist für mich
die oberste Prämisse, den Code möglichst basic aussehen
zu lassen. Ich weigere mich einfach, diese krausen,
jeglicher Ästhetik hohnsprechenden Kürzelkonstrukte zu
verwenden.

Gruß aus Mainz
Michael

.

Hallo, Anton,

Anton Huber:

> Selbst der Erfinder der Sprache C++ (Bjarne Stroustrup)
> schreibt in seinem Buch 'The C++ Programming Language'
> Das die Ausführungsgeschwindigkeit von ++a höher als a++ ist.

Wer auch immer das geschrieben hat, Du musst es mir jetzt erklaeren!
;-)

Das ist fuer einen Kompiler imvho doch absoluter Unsinn. Es wird ein
Wert geladen, erhoeht und gespeichert - so oder so. Warum soll es da
Zeitunterschiede /bei der Ausfuehrung/ geben? Fuer die
Kompiliergeschwindigkeit mag das gelten oder wenn es ein Interpreter
waere. Aber bei Kompilat?

Gruss - Mark

--
Informationen fuer Neulinge in den Access-Newsgroups unter
http://www.doerbandt.de/Access/Newbie.htm

Bitte keine eMails auf Newsgroup-Beiträge senden.
.

"Michael Zimmermann" threw this exception:

Hi,

>Anton Huber:
>> Kommt davon wenn man C Programme ...erzeugt
>> ... Es sei mir bitte verziehen ...
>
>Ego te absolvo.
>
>Programmiere drei Basicunser und sündige fortan nicht mehr.
>;-)

Danke für die Absolution !


>Da gibt's nicht viel zu überdenken. Es ist etwa 25 Jahre
>her, daß ich das Zeugs habe lernen müssen und ich verwende
>es so selten als möglich. Wenn ich irgendwas mit C(++),
>mit Java, mit Abscheu programmieren /muß/, ist für mich
>die oberste Prämisse, den Code möglichst basic aussehen
>zu lassen. Ich weigere mich einfach, diese krausen,
>jeglicher Ästhetik hohnsprechenden Kürzelkonstrukte zu
>verwenden.

Und ich sag gleich noch dazu immer vorher alles selber
probieren . Ich nehme alles zurück ..., kleiner einfacher
versuchsaufbau in C:

Um überhaupt ein Ergebnis zu bekommen auf einem
PIII 733 MHz . Optimiert -> nur Compilereinstellung
"Geschwindigkeit"

int main(int argc, char* argv[])
{
short sbt = 1;
ULONGLONG a = 0;
DWORD mseconds1 = GetTickCount();

switch (sbt) {

case 1:
for (a = 0 ; a < 400000000; a++) {

/* zischen 1682 und 1993 msecs */
}
break;
case 2:
for (a = 0; a < 400000000; ) {

a = a + 1;
/* zischen 1682 und 1993 msecs */
}
break;
case 3:
for (a = 0; a < 40000000; ++a) {
/* zischen 120 und 133 msecs !!! */
}
break;
}
printf("%d \r\n", (GetTickCount() - mseconds1) );
return 0;
}

In einer while-Schleife sieht das ganze komplett
anderes aus da ist ++a das absolute Schlusslicht ...


Vielleicht komm ich mal dazu diese Angelegenheit in
VB zu probieren ...


Gruss
Anton

--
Aber wieso? Gestern ging's doch noch!
.

Mark Doerbandt threw this exception:

>Hallo, Anton,
>
>Anton Huber:
>
>> Selbst der Erfinder der Sprache C++ (Bjarne Stroustrup)
>> schreibt in seinem Buch 'The C++ Programming Language'
>> Das die Ausführungsgeschwindigkeit von ++a höher als a++ ist.
>
>Wer auch immer das geschrieben hat, Du musst es mir jetzt erklaeren!
>;-)

Dazu müsste ich es selber ja mal verstehen ).


>Das ist fuer einen Kompiler imvho doch absoluter Unsinn. Es wird ein
>Wert geladen, erhoeht und gespeichert - so oder so. Warum soll es da
>Zeitunterschiede /bei der Ausfuehrung/ geben? Fuer die
>Kompiliergeschwindigkeit mag das gelten oder wenn es ein Interpreter
>waere. Aber bei Kompilat?

Naja schon, da ein Wert geholt - Wert erhöht - Wert gespeichert
viel mehr Aufwand bedeutet als ein Wert im Register inkrementiert.
Da ein inkrement ja ein eingebauter Befehl im Prozessor ist.
Und ich denke schneller als der kanns niemand machen .

Aber egal schau Dir mal mein anderes Posting an,
es gibt zumindest gewaltige Unterschiede in jeder
Richtung ... also wir reden für die Katz es kommt immer
auf die Situation an wie man wo was verwendet. Ich
dachte mir diese (amateurhaften) Ergebnisse selbst 'so' nicht ...


Gruss
Anton

--
Aber wieso? Gestern ging's doch noch!
.

Gerald Aichholzer threw this exception:

Hi,

>> Mark Doerbandt threw this exception:
>>
>>>Anton Huber:
>>>
>>>
>>>>Aber IMHO ist ein
>>>> a = a +1
>>>> b = b+1
>>>> x = a+ b
>>>>im Gegensatz zu einem
>>>> x = ++a + ++b
>>>>langsamer.
>
>es ist so wie Mark und Michael es sagen. Zu Erkennen, dass obige
>Schreibweisen äquivalent sind, gehört wohl zu den Basisoptimierungen
>eines Compilers.
>
>Grob kann man sagen, dass der Compiler den Code in einen internen,
>Assembler-ähnlichen Code umwandelt, der dann optimiert wird. Dieser
>interne Code dürfte bei den obigen Anweisungen ziemlich ident sein.
>Das Schlagwort heisst hier auch 'Peephole-Optimizer' (AFAIR - Com-
>pilerbau ist schon lange her *nirg*).

Ähm, hallo? Ist da wer? Die Variante ++a ist um längen schneller. Ich
weiss ned warum Ihr da so eingefahren seit. Der Compiler *kann*
hier auch gar nichts optimieren. Ist mir aber erst heute Nacht
eingefallen . (Siehe anderes Posting von mir)

Wo ist der Unterschied? Ganz einfach es_ist_so[Punkt]

Bei a = a + 1 muss eine temporäre Kopie angelegt werden. Und ist auch
ganz klar. Weil da eine Zuweisung stattfinden. Und nein : der Compiler
(zumindest bscmake V6) optimiert da rein gar nichts. Auch bei a++ muss
ich eine temp. Kopie in Kauf nehmen. Und selbst wenn die temp. Kopie
nicht irgendwem zugewiesen werden würde kann der Compiler diese
Unterscheidung nicht treffen. Das wäre ja Schwachsinn wenn ein
Compiler anfangen würde, anzunehmen was Du vor hast und nach
'seinem' gutdünken zu übersetzen.
Mach Dir eine Konsolenanwendung und teste die Varianten!

a = a +1; a++; ++a am Besten gleich mit unterschiedlichen
loop-Varianten (for; while) und Du wirst einen gewaltigen
Unterschied merken!!!

Ist da etwas Wunschdenken mit dabei?!? Glaubt Ihr echt der Compiler
kann 'langsam' geschrieben Programme zu schnellen Compilieren,
hihi ...

Und um auch VB nicht zu kurz kommen zu lassen. Da ist es eigentlich
noch krasser. Da bei VB Typen hin und her 'gewiesen' werden können
und VB die Umwandlung übernimmt. Kann ich nun hoffen dass wenn
ich definierte Variablen gleichen Typs verwende der VB-Compiler
des so akzeptiert. Es könnte aber auch sein das er jedesmal und immer
einen dynamischen Cast für jede Zuweisung/Berechnung durchführt.
Und da kann der Compiler nix optimieren weil der Linker vorher so
viel Code mit rein schreibt das es einfach mehr ist.

Und ich zitiere jetzt mal frei heraus was ich umlängst gelesen
habe >> Ich bin manchmal verblüfft, wie Umfangreich und wie
viel unütze Teile sich in dem compilat eines simplen,
kleinen und einfachen Programm befinden<<

Und diese Aussage kommt nicht von irgendwo. Nochmal der:
Der Compiler nimmt Dir Deine Arbeit nicht ab, und wie gesagt
probiers einfach mal aus es_ist_ein_Unterschied!!!


Gruss
Anton

--
Aber wieso? Gestern ging's doch noch!
.

Gerald Aichholzer threw this exception:

Hi,

>Anton Huber wrote:
>> Mark Doerbandt threw this exception:
>>
>>>Anton Huber:
>>>
>>>
>>>>Aber IMHO ist ein
>>>> a = a +1
>>>> b = b+1
>>>> x = a+ b
>>>>im Gegensatz zu einem
>>>> x = ++a + ++b
>>>>langsamer.
>>>
>>>Nein, das kannst Du nicht wissen. Es kommt darauf an, wie gut der
>>>Kompilier ist. Nur weil die drei Aktionen einmal in einer und einmal
>>>in drei Zeilen stehen, heisst das ja noch lange nicht, dass der
>>>Kompiler nicht intelligent genug ist, die eben inkrementierten Werte
>>>noch "zufaellig" in zwei Registern zu haben und dann diese zu
>>>addieren. Wenn er das nicht tut, verschenkt er Optimierungspotential.
>
>es ist so wie Mark und Michael es sagen. Zu Erkennen, dass obige
>Schreibweisen äquivalent sind, gehört wohl zu den Basisoptimierungen
>eines Compilers.

So und um die Diskusion auch mal zu einem Ende zu bringen:

A) Wenn selbst Beweise , die leicht selbst durchgeführt
werden können, nichts 'bringen' dann hilfts eh nix .

B) Was könnte den bei diesen Varianten vorgehen:

register int a;
(Wobei ja register nur eine Empfehlung an den
Compiler ist, aber gehen wir mal davon aus er
legt es in einem Register ab).

1) a = a + 1; (Fakt: Es gibt keine Heuristik in Compiler)
Möglche Implementierung:

- Hole Wert von a aus dem Register
- Erhöhe den Wert von a um eins
-Schreibe a in das Register zurück
-Gib die Adresse von a zurück

oder:
- Hole Wert von a aus dem Register
- Erhöhe den Wert von a um eins
- Speichere den Wert von a in einer temp. Kopie
- Schreibe a in das Register zurück
- Gib die temp. Kopie von a zurück
(Sehr verschwenderisch, aber nicht unmöglich)

oder:
- Inkrementiere a im Register
- Gib die Adresse von a zurück
Diese Variante wäre möglich macht der
Compiler aber nicht (zumindest bcmake)

a++:
- Hole Wert aus dem Register
- Speichere den Wert in einer temp. Kopie
- Inkrementiere a im Register
- Gib die temp. Kopie zurück.

++a: - Inkrementiere a im Register
- Gib die Adresse von a zurück.
(Definitiv so)

Deswegen wurde die sehr hardwarenahe Notation ++a/a++ ja auch
eingeführt, und aus diesem Grunde ist die ++a ja auch um längen
schneller. Natürlich könnte der Compiler bei a = a + 1 den Code
optimieren. Aber da sind halt zwei Unsicherheitsfaktoren da
1. er muss wissen es handelt sich um ein und dieselbe Variable
2. er muss wissen Du willst den Wert nur um eins erhöhen.
Und mit verlaub, diese Entscheidung nimmt Dir IMHO kein Compiler ab.
Auch wenns hier noch einfach aussieht ist die Anwendung solcher
Strategien ja mit einem deutlichen Mehraufwand in der Compiler-
programmierung verbunden.

Und ich kanns 'besweisen' (Du Dir selber auch ).


Gruss
Anton

--
Aber wieso? Gestern ging's doch noch!
.

Hallo, Anton,

Anton Huber:

> A) Wenn selbst Beweise , die leicht selbst durchgeführt
> werden können, nichts 'bringen' dann hilfts eh nix .

Es geht nicht um Beweise. Es geht nicht um konkrete Kompiler. (Die
sind eh schlecht.) Es geht um Moeglichkeiten der Optimierung. Dass
jede Realisierung Schwaechen hat, ist klar. Aber die Entwicklung geht
weiter. Und sie geht eben imho hin zu besser lesbarem Code und weniger
kryptischen Sprachen und zu Kompilern, die Dir die Arbeit fuer solche
einfachen (!) Optimierungen abnehmen. Oder willst Du mir ernsthaft
erklären, ich solle mir /merken/, dass a++ langsamer (schneller, wie
war das gleich noch) als ++a ist? Das ist absolut ueberfluessiges
Zeug, mit dem ich mein Gehirn nun wirklich nicht belasten moechte und
wo ich *erwarte*, dass die Kompilerbauer ihre Arbeit gemacht haben
oder noch machen werden.

Gruss - Mark

--
Informationen fuer Neulinge in den Access-Newsgroups unter
http://www.doerbandt.de/Access/Newbie.htm

Bitte keine eMails auf Newsgroup-Beiträge senden.
.

Gerald Aichholzer threw this exception:

Hi Gerald,

>Anton Huber wrote:
>> Gerald Aichholzer threw this exception:
>>
>> Ähm, hallo? Ist da wer? Die Variante ++a ist um längen schneller. Ich
>> weiss ned warum Ihr da so eingefahren seit. Der Compiler *kann*
>> hier auch gar nichts optimieren. Ist mir aber erst heute Nacht
>> eingefallen . (Siehe anderes Posting von mir)
>>
>
>dein Beweis gilt genau für deine Compiler-Version und deine Prozessor-
>Architektur. Was real rauskommt hängt u.a. genau von diesen Parametern
>ab. Weiters hängt es von der "Umgebung" des Befehls ab. Probier mal
>
> b = ++a;
> b = a++;
>
>Ich habe es nicht getestet - aber logisch gibt es keinen Grund, warum
>eines der beiden Statements schneller sein soll ausser durch Eigenhei-
>ten der speziellen Prozessorarchitektur.

Hm, meinst? Dann frag mal Leute die sich damit auskennen . Ich
wiederhole mich ständig, aber der logische Grund ist, dass bei der
Variante b = a++; eine temporäre Kopie von a angefertigt werden
*muss* um überhaupt den alten Wert noch zurück geben zu können.
Das ist doch logisch!?! Bei der Variante ++a; genügts a hochzuzählen
und einen Zeiger auf a zurückzugeben. Da ist keine Optimierbarkeit
drinnen, logisch unmöglich.
Und welche Variante wird wohl schneller sein ... des überlasse
ich dann Deiner Phantasie ... ).

Jetzt mit allen möglichen und unmöglich Varianten her zu kommen,
ist wie 'aber ich hab doch recht'. Denn es geht ja mal um den Gross.
Es wird schon Compiler geben die auf solche Optimierungen
spezialisiert sind aber bscmake, pgcc und gcc kommen zu ähnlichen
Ergebnissen zwar nicht zueinander vergleichbar aber die Differenzen
sind ähnlich. Mir geht es ja nicht einen absolut gültigen Beweis an zu
tretten sondern kurz zu überprüfen ob die einschlägige Literatur mit
dem recht hat. Und wenns in jedem vernünftigen Buch über C so steht
und ich auch zu diesem Ergebnis komme wird schon was wahres
dran sein ...

And wenn ich VB heranziehe kannst schon 3 x nicht so argumentieren.
Da die tatsächliche Implementierung des a = a + 1 wahrscheinlich
aufwendiger gestaltet ist als in C, wenn ich allein an die
'Typenfreiheit' denke. Da wird schon noch viel anderes während dieser
Zuweisung/Berechnung vorgehen.

Das wir uns hier prinzipiell in einem Bereich befinden der für den
Normaluser 'zeitlich' ja überhaupt nicht mehr zu fassen ist, steht
auf einem anderen Papier .
Aber wenn ich bsplsw. einen Parser oder Kodierer/Dekodierer
schreibe wäre VB für mich die letzte Wahl ...


Gruss
Anton

--
Aber wieso? Gestern ging's doch noch!
.

stefan hoffmann threw this exception:

Hi Stefan,

>tach Gerald,
>
>Gerald Aichholzer schrieb:
>> Ich hätte deinen Test auch so geschrieben:
>> for( b = 0; b < KONSTANTE; b++)
>> a = a + 1;
>> for( b = 0; b < KONSTANTE; b++)
>> a++;
>>
>> usw. um Seiteneffekte durch die Verwendung von a als Laufvariable zu
>> verhindern.
>Gefährlich. Wenn du vergisst die Optimierung auszuschalten, macht er dir
> unter Umständen eine Konstantenzuweisung daraus.
>
>Aber ohne euch zu ärgern: Hat von euch beiden schon mal einer beide
>Varianten im Assemblat verglichen - gerne mehrer Architekturen? imho ist
>das am aussagekräftigsten.

Nein (noch) nicht. Aber es bleibt das Gesagte bestehen. Die eine
Variante a++; (und da denke ich spielt a = a + 1 im ähnlichen Feld)
ist langsamer als ++a; eben wegen der temporären Kopie, die egal
wie die tatsächlichen Implementierungsdetails sind, unumgänglich
ist!


Gruss
Anton

--
Aber wieso? Gestern ging's doch noch!
.

Hallo, Anton,

Anton Huber:

> Hm, meinst? Dann frag mal Leute die sich damit auskennen . Ich
> wiederhole mich ständig, aber der logische Grund ist, dass bei der
> Variante b = a++; eine temporäre Kopie von a angefertigt werden
> *muss* um überhaupt den alten Wert noch zurück geben zu können.
> Das ist doch logisch!?! Bei der Variante ++a; genügts a hochzuzählen
> und einen Zeiger auf a zurückzugeben. Da ist keine Optimierbarkeit
> drinnen, logisch unmöglich.

Mal ganz naiv gefragt: hast Du denn mal Assembler programmiert? Bei
mir ist es zugegeben auch eine Weile her. Also mal von Anfang an: es
gibt eine Variable a, die steht irgendwo im Speicher. Es ist ja nicht
so, dass diese Speicherzelle einfach inkrementiert wird. Der Prozessor
lädt die Variable in eines seiner Register, inkrementiert sie und
schreibt sie wieder zurueck. Ob er jetzt die andere Variable b im
Speicher vor oder nach dem Inkrementieren mit dem Registerwert
beschreibt, ist eben ganz genau /egal/. Logisch?

Gruss - Mark
.

Peter Dreisiebner threw this exception:

Hi,

>Anton Huber wrote:
>
>Hallo Anton,
>
>> case 1:
>> for (a = 0 ; a < 400000000; a++) {
>> case 2:
>> for (a = 0; a < 400000000; ) {
>> case 3:
>> for (a = 0; a < 40000000; ++a) {
>
>bei 'case 3' fehlt aber eine Null.

Man sieht dass man nichts sieht ... )
und man beweist sich selber immer das man im
Recht ist ;-)

Der Unterschied ist nicht so gewaltig wie wenn
eine 0 fehlt aber es sind um die 200 msecs ...

Danke!!!


Gruss
Anton

--
Aber wieso? Gestern ging's doch noch!
.

Hallo, Anton,

Anton Huber:

> Peter Dreisiebner threw this exception:
>> bei 'case 3' fehlt aber eine Null.

> --
> Aber wieso? Gestern ging's doch noch!

LOL! ;-)

Gruss - Mark
.

Mark Doerbandt threw this exception:

Hi,

>Anton Huber:
>
>> Hm, meinst? Dann frag mal Leute die sich damit auskennen . Ich
>> wiederhole mich ständig, aber der logische Grund ist, dass bei der
>> Variante b = a++; eine temporäre Kopie von a angefertigt werden
>> *muss* um überhaupt den alten Wert noch zurück geben zu können.
>> Das ist doch logisch!?! Bei der Variante ++a; genügts a hochzuzählen
>> und einen Zeiger auf a zurückzugeben. Da ist keine Optimierbarkeit
>> drinnen, logisch unmöglich.
>
>Mal ganz naiv gefragt: hast Du denn mal Assembler programmiert? Bei
>mir ist es zugegeben auch eine Weile her.

Eine Weile ist gar kein Ausdruck, ich denke es war als der
Borland C++-Compiler 1.X aktuell war ... .
Und da warens aber auch nur Experimente, hab nie wirklich
was gscheites in Assembler gmacht ...


>Also mal von Anfang an: es
>gibt eine Variable a, die steht irgendwo im Speicher. Es ist ja nicht
>so, dass diese Speicherzelle einfach inkrementiert wird. Der Prozessor
>lädt die Variable in eines seiner Register, inkrementiert sie und
>schreibt sie wieder zurueck. Ob er jetzt die andere Variable b im
>Speicher vor oder nach dem Inkrementieren mit dem Registerwert
>beschreibt, ist eben ganz genau /egal/. Logisch?

Na, es geht ja ned um des (und ausserdem haben wir angenommen
der Compiler entspricht der Empfehlung 'register', wie
unwahrscheinlich es auch immer sein mag.) was der Prozessor dazu
sagt, sondern darum das bei ++a; direkt eine Refrenz zurück-
gegeben werden kann, was heisst es ist keine Kopie nötig. Sobald
der Prozessor die Variable um eins erhöht hat ist der alte Wert für
die Applikation ja nicht mehr da. Die Application kann dem Prozessor
ja nicht sagen "Inkrementiere a in deinem Register aber warte bis
ich den alten Wert der noch im Speicher steht verwendet habe", des
geht ja ned, also muss_eine_Kopie_erstellt_werden. Und dieser
Umstand braucht eben seit. Das die Inkrementierung gleich schnell
verläuft ist für die Sache an sich ja unerheblich.


Gruss
Anton

--
Aber wieso? Gestern ging's doch noch!
.

Hallo, Anton,

Anton Huber:

> Na, es geht ja ned um des

Doch. Lies mal Geralds Pseudocode.
Die Kopie ist /immer/ erforderlich und befindet sich im Register des
Prozessors.

Gruss - Mark

--
Informationen fuer Neulinge in den Access-Newsgroups unter
http://www.doerbandt.de/Access/Newbie.htm

Bitte keine eMails auf Newsgroup-Beiträge senden.
.

Gerald Aichholzer threw this exception:

Hi Gerald,

>in allgemeinem Pseudeassembler:
>
> Variante 1: load a into R1
> inc R1
> store R1 into a
> store R1 into b
>
> Variante 2: load a into R1
> store R1 into b
> inc R1
> store R1 into a
>
>Wo siehst du da eine temporäre Kopie?

Wo siehst Du eine? Ich sehe keine ). Es gab da mal einen schönen
Thread in irgend einer *.c/c++ Gruppe mit dem Namen '(Völlig) verwirrt
durch Zeiger' ich denke den lese ich mir jetzt noch mal gründlich
durch ...

Oh mann, die ganze Diskussion um sonst. Wieso schreiben
namhafte Autoren sowas in Bücher ... naja hoffentlich lesen
die hier mit ...


Gruss und Dank
Anton

--
Aber wieso? Gestern ging's doch noch!
.