Interessante Sicht auf die PLO - Seite 9

Neuer Kommentar
 
Igor Makanu:

Ich bin mir zu 99% sicher, dass diese Codes mit der gleichen Geschwindigkeit bis zu einem gewissen Takt auf der Prozessorebene ausgeführt werden - der Prozessor hat Optimierung, Parallelisierung und was sonst noch auf der Mikrobefehlsebene läuft

Gibt es hier nicht einen negativen Effekt, wenn man Code beliebiger Qualität schreibt und sich darauf verlässt, dass "der Compiler ihn schon auf das Optimum bringen wird"?


Sie können sicher sein, dass der Compiler bei einem bestimmten Schreibstil das Richtige tun wird. Bei einem anderen Stil muss man einfach darauf vertrauen, dass der Compiler schlauer ist.

In Anbetracht von plattformübergreifenden, unterschiedlichen Compilern usw. möchte ich mir bewusst sein, was ich im Code tue.
 
fxsaber:

Wirkt es sich nicht negativ aus, wenn qualitativ hochwertiger Code in der Erwartung geschrieben wird, dass "der Compiler ihn auf das Optimum bringt"?

Meine Beispiele sind kaum von Qualität, sie sind typische Konstrukte - ich habe lange die Quellen auf githab verglichen, sowohl tst1 als auch tst2 Beispiele, beide werden aktiv von Programmierern genutzt

Deshalb denke ich, dass die Entwickler von Compilern die Standard-Code-Konstrukte schon vor langer Zeit gelernt haben und es kein Problem für Compiler ist.


Negative Auswirkungen - wie@TheXpert oben schrieb, gibt es Unternehmensanforderungen für die Formatierung des Codes, aber die Anforderungen sind im Allgemeinen die gleichen - der Code muss für andere Teammitglieder verständlich sein, auch für diejenigen, die gerade erst gekommen sind....


fxsaber:

Bei einem Schreibstil können Sie sicher sein, dass der Compiler das Richtige tun wird. Bei einem anderen Stil muss man einfach darauf vertrauen, dass der Compiler schlauer ist.

Es ist nicht der Compiler, der jetzt schlauer ist, sondern der Prozessor selbst, imho, wenn wir über High-Performance-Code sprechen - der Hauptleistungs-Overhead liegt nicht in Funktionsaufrufen, sondern in Speicherlesungen (Speicherzugriffen) - wenn Sie die Speicherung von Daten/Variablen durch kleine Rechenwerte ersetzen können, werden Sie (auf der Ebene der Mikrobefehlsoptimierung des Prozessors) einen kleinen Gewinn haben

... aber der ganze Rest ist imho böse ))))


SZZY: es gibt auch die Optimierung des Kodes auf dem Niveau des Compilers, ich lese ein wenig - alles auf dem Niveau der Vermutung, auf dem PC-Eisen lese ich regelmäßig, ich lese seit langem, ich habe die Meinung geschrieben




fxsaber:

In Anbetracht von plattformübergreifenden, unterschiedlichen Compilern usw. möchte ich mir bewusst sein, was ich im Code tue.

Ich habe also keine Wahl - kurz gesagt: "Ich bin ein Künstler - so sehe ich das" ))) , ich hoffe, ich habe Sie nicht beleidigt.

 

Ich habe eine Regel: Nach 5 Jahren muss der Code für den Programmierer verständlich sein, wenn er nicht verständlich ist, ist es schlechter Code.

Und wenn sie von anderen verstanden werden, sehr gut.

 
Valeriy Yastremskiy:

Ich habe eine Regel: Nach 5 Jahren muss der Code für den Programmierer verständlich sein, wenn er nicht verständlich ist, ist es schlechter Code.

Und wenn sie von anderen verstanden werden, sehr gut.

Hier (und hier) gibt es sehr guten Code. Aber ich verstehe das nicht. Mein Gehirn hat schon vor langer Zeit aufgehört zu wachsen.

 
fxsaber:

Hier (und hier) gibt es sehr guten Code. Aber ich verstehe das nicht. Mein Gehirn hat schon vor langer Zeit aufgehört zu wachsen.

Die Themen sind kompliziert und nicht jeder wird sie verstehen, ganz zu schweigen von dem Code.

 

Oh, was für ein Thema... Und ohne mich... Das ist nicht richtig... Ich muss lauter sprechen.

Was den Artikel in der Überschrift betrifft, so wird die richtige Prämisse (der Code muss so weit wie möglich deterministisch sein) in einer sehr albernen Weise verwendet, indem die Additions- und die Akkumulationsoperation als Beispiele verglichen werden. Die Schlussfolgerung ist, dass die Additionsoperation deterministisch ist, d. h. sie liefert immer dasselbe Ergebnis, während die Akkumulation nicht deterministisch ist, da das Ergebnis immer unterschiedlich ist.

Aber, entschuldigen Sie mich... Es handelt sich um unterschiedliche Operationen, und in beiden Fällen sind die Ergebnisse vollkommen korrekt und genau das, was man von der Addition bzw. der Akkumulation erwartet!

Auch das Beispiel des Zufallszahlengenerators kann nicht als "nicht-deterministisch" bezeichnet werden, wenn man bedenkt, dass es sich um eine Operation mit einer Zufallskomponente handelt.

Wie mir scheint, besteht die ganze nicht-deterministische Sache darin, dass der Autor von dem Code überhaupt nicht das erwartet, wofür der Code gedacht ist.


Und der zweite Punkt ist die Lesbarkeit des Codes - ich finde die "Fragezeichen"-Operation sehr schädlich und schwer zu verstehen. Ersetzt man die "Frage" durch einen bedingten Operator, erhält man ausführbaren Code mit absolut gleicher Effizienz. In diesem Fall wird der Quellcode zwar deutlich umfangreicher, aber auch viel übersichtlicher. Das ist meiner Meinung nach ein großes Plus.

Ich versuche immer, all diese zahlreichen logischen Ausdrücke in eine Reihe von separaten Operationen mit Zwischenergebnissen aufzuteilen. Selbst wenn ein solcher Code zu weniger effizientem ausführbarem Code führt, ist der Vorteil eines besseren Verständnisses meiner Meinung nach viel wichtiger.

 

und das ist das Reich der weihnachtsbaumorientierten Programmierung :-)

void OnStart()
  {
   if(condition)
     {
      if(other_condition)
        {
         for(loop_stmt)
           {
            if(wtf)
              {
               while(repeats)
                 {
                  if(oh_shit)
                    {
                     if(really_fck)
                       {
                        deep_nesting();
                       }
                    }
                 }
              }
           }
        }
     }
  }
 
Maxim Kuznetsov:

und das ist das Reich der weihnachtsbaumorientierten Programmierung :-)

Wenn die Bedingungen kurze Ausdrücke sind, ist das in Ordnung. Sie können sie jedoch in Funktionen aufteilen.

Und bei umgekehrten Klammern füge ich in solchen Fällen immer einen Kommentar in den Kopf der öffnenden Klammer ein, um dies zu verdeutlichen.

 
fxsaber:

Bei einem Schreibstil können Sie sicher sein, dass der Compiler das Richtige tun wird. Bei einem anderen müssen Sie nur darauf vertrauen, dass der Compiler intelligenter ist.

Es wird keinen Unterschied in der Ausführung dieser

if ( a() ) return(true);
if ( b() ) return(true);
return(false);  

und dies:

return( a() || b() );

Ich bin für einfach zu lesenden und zu debuggenden Code.

 
Andrey Khatimlianskii:

Es wird keinen Unterschied machen, dies zu tun:

und dies:

Ich bin für einfach zu lesenden und zu debuggenden Code.

Dieses Design gefällt mir überhaupt nicht, was die Lesbarkeit und die Unübersichtlichkeit angeht.

if ( a() ) return(true);
if ( b() ) return(true);
return(false);  
12345678910111213
Neuer Kommentar