Ehrgeizige Ideen !!! - Seite 5

 

Andrei01
:

Sie irren sich, weil Sie die einfachsten Dinge nicht kennen.

Die Daten eines beliebigen Arrays werden im Speicher in einer linearen Reihenfolge gespeichert. Um ein Element x[15] zu adressieren, berechnet der Compiler die Adresse des Array-Anfangs plus Shift 15, um die Adresse der Variablen zu ermitteln. Bei einem zweidimensionalen Array, z. B. x[2][5], berechnen Sie zunächst den Offset für die zweite Zeile und addieren dann den Offset für das fünfte Element hinzu, also die doppelte Anzahl von Operationen.

x[2] [5] --> x[((2-1)* ArrayRange(x[0])+5)]

x[15] --> x(+15)

dies ist alles auf Compiler-Ebene, aber ArrayRange(x[0]) für ein statisches Array ist IMMER konstant, es muss nicht ständig berechnet werden, nur einmal und zur Kompilierungszeit gespeichert

Praktizieren Sie Assembler? warum diese Probleme? wenn Sie Assembler tun, leider - ich habe keine russische Dokumentation für die RICHTIGE Belastung der Befehlspipeline auf Prozessoren älter als Pentium-I gesehen, und die RICHTIGE Belastung des Prozessors ist nicht einmal von Entwicklern von Compilern, sondern die Entwickler des Betriebssystems und der Prozessorarchitektur beschäftigt

Wenn Sie sich Sorgen machen, dass die Ausführung einer Additionsoperation in Prozessortaktzyklen länger dauert als eine Additionsoperation, dann ist das Schiff mit dem 486er-Prozessor leider abgefahren, denn das Laden von Caches und Befehlspipelines nimmt mehr Zeit in Anspruch als arithmetische und logische Operationen.

SZZY: Ich appelliere noch einmal - fangen Sie an, Primärquellen zu lesen, hier https://www.mql5.com/ru/docs/basis/types/classes beschreiben die mql5-Entwickler, wie man die Datenausrichtung richtig anordnet, die gleichen Informationen gibt es für alle Compiler, es gibt Informationen darüber, wie man den Windows-Systemfunktionsaufruf richtig verwendet usw. - Ich schreibe dies, um zu sagen, dass es nur wenig russische Dokumentation gibt, die den modernen Fähigkeiten des Betriebssystems und der Prozessoren entspricht, und das alte Zeug, das Zeug, das sie an den Hochschulen und Universitäten lehren, entspricht nicht der Realität in diesem Stadium der Entwicklung des Betriebssystems und der Hardware

 
IgorM:

x[2] [5] --> x[((2-1)* ArrayRange(x[0])+5)]

x[15] --> x(+15)

das ist alles auf Compiler-Ebene, aber ArrayRange(x[0]) für statische Arrays ist IMMER konstant, es muss nicht ständig berechnet werden, es reicht, wenn es einmal zur Kompilierungszeit berechnet und gespeichert wird

In der Kompilierungsphase wird nur die Adresse des ersten Elements berechnet. Alle anderen Elemente werden im Zählmodus über den Offset gezählt, der jedes Mal anders ist.

Bei einem zweidimensionalen Array müssen Sie zwei Offsets zählen, und zwar spaltenweise und zeilenweise, multipliziert mit der Zeilennummer, und natürlich auch beim Zählvorgang. Asembler und Compiler haben absolut nichts damit zu tun, es handelt sich lediglich um eine grundlegende Speicheradressierung für die korrekte Nutzung von Rechenressourcen in der Praxis.

Hier kann man leicht erkennen, dass die Adressierungszeit bei komplexeren Fällen, z. B. bei Objekten, deutlich langsamer ist, auch wenn es einen erheblichen Leistungsverlust zwischen ein- und zweidimensionalen Arrays gibt.

 
Andrei01:

Nur die Adresse des ersten Elements wird zur Kompilierzeit berechnet. Alle anderen Elemente werden im Zählmodus über einen Offset gezählt, der jedes Mal anders ist.

Bei einem zweidimensionalen Array müssen Sie zwei Offsets durch Spalten und Zeilen multipliziert mit der Zeilennummer und natürlich auch beim Zählvorgang berechnen. Asembler und Compiler haben absolut nichts damit zu tun, es geht nur um die grundlegende Speicheradressierung für die korrekte Nutzung der Rechenressourcen in der Praxis.

Daraus kann man leicht erkennen, dass trotz des großen Leistungsverlusts zwischen ein- und zweidimensionalen Arrays die Adressierungszeit in komplexeren Fällen, z. B. bei Objekten, noch langsamer ist.


Erfolge beim Verstehen des Geschehens und des Produktivitätsverlusts

Ich habe kein Problem damit, Compiler zu optimieren und meine eigenen Datenzugriffsentwürfe zu schreiben.

SZY: Objekte sind keine komplexen Fälle - alle Manipulationen, um Verbindungen zu schaffen - alles auf der Ebene des Compilers, leider, der Prozessor kümmert sich nicht Objekt oder nicht, es hat kein Problem mit der Berechnung von Verschiebungen relativ zu ausgerichteten Daten, auch wenn das "Wunder Programmierer" spart Speicher - schreibt Daten in Arrays wie Byte, aber nicht auf die Dokumentation an den Compiler, die Wirksamkeit dieses Codes wird nur in einer Reflexion einer selbstgefälligen Physiognomie des Programmierers im Spiegel sichtbar sein, aber in Wirklichkeit ist es ein Fake

 
IgorM:


alles auf Compiler-Ebene, leider ist es dem Prozessor egal, ob es sich um ein Objekt handelt oder nicht, er hat kein Problem mit der Berechnung von Offsets relativ zu ausgerichteten Daten

Es scheint Ihnen gerade anhand eines einfachen Beispiels erklärt worden zu sein, wie sehr ein zweidimensionales Array im Vergleich zu einem eindimensionalen Array während der Programmausführung und nicht während der Kompilierung verlangsamt wird. Ich sehe keinen Grund, mich zu wiederholen. Sie sehen also, dass Sie die Aufgabe, einen mehr oder weniger optimalen Berechnungscode zu schreiben, nicht allzu sehr in Anspruch nimmt, und vielleicht brauchen Sie sie auch gar nicht. In diesem Fall ist OOP genau das Richtige für Sie. :)

 

Sie denken in Amöben-Kategorien :) .

"Wir sollten die kleinen Effizienzgewinne vergessen, die in etwa 97 % der Fälle erzielt werden: Eine vorzeitige Optimierung ist die Wurzel allen Übels. Dennoch sollten wir unsere Chancen in diesen kritischen 3 % nicht verpassen".

Dies ist das vierte Mal, dass ich in diesem Forum zitiert werde.

 
Andrei01:

Es scheint Ihnen gerade anhand eines einfachen Beispiels erklärt worden zu sein, wie viel langsamer ein zweidimensionales Array im Vergleich zu einem eindimensionalen Array bei der Programmausführung und nicht bei der Kompilierung ist. Ich sehe keinen Grund, mich zu wiederholen. Sie sehen also, dass Sie sich nicht die Mühe machen, einen mehr oder weniger optimalen Berechnungscode zu schreiben, und vielleicht brauchen Sie ihn auch gar nicht. In diesem Fall ist OOP genau das Richtige für Sie. :)


Um welche Art von optimalem Code handelt es sich? Sie haben absolut keine Ahnung, wie Compiler und virtuelle Maschinen funktionieren

Der Programmierer braucht nicht herauszufinden, wie der Zugriff auf physische Speicherelemente und deren Adressierung in den einzelnen Compilern erfolgt (auch nicht diagonal, nicht spaltenweise - hier kann nichts getan werden) - das ist die Aufgabe der Entwickler, und wenn der Programmierer mit dem Code nicht zufrieden ist, wird er seinen Code optimieren:

- durch Vergrößerung des Codes und Verkleinerung des Datenvolumens und Verlust der Rechengeschwindigkeit

- durch Vergrößerung der Datenmenge im Code und höhere Geschwindigkeit

- alternativ verwendet er/sie einen anderen Compiler

ALLE OPTIONEN sind weg!

OOP ist ein weiterer Zweig für das Schreiben von EFFICIENT Code, die Wirksamkeit der OOP ist, dass der Programmierer ein mathematisches Modell in Form von einer Art von Architektur zu schaffen - so erreichen große Vielseitigkeit Ihres Codes, wenn Sie denken, dass die Klassen eine andere Art der Adressierung für den physischen Zugriff auf Daten haben - Sie irren sich, dass mikroskopisch zusätzliche Menge an Daten - eine verknüpfte Objekttabelle wird nicht in irgendeiner Weise die Zugriffszeit auf physische Daten im Speicher zu erhöhen und die zusätzlichen Daten werden mehr als ausgeglichen werden durch Multi

Ich bin schockiert - Sie fingen an, auf OOP zu scheißen, und gingen dann zu Argumenten über die Adressierung in mehrdimensionalen und eindimensionalen Arrays über - haben Sie das irgendwo studiert, oder nur - alle Spekulationen und Phantasien?

Die Arbeit mit mehrdimensionalen Arrays ist seit langem auf Eisen-Ebene implementiert worden - die gleiche Z-Buffer bei der Arbeit mit Grafikkarten, ach ja, "Schafe, die Eisen-Entwickler" - haben Sie nicht konsultiert und haben nicht gelernt, wie effektiv Adressierung von mehrdimensionalen Arrays ist, und nicht konsultieren Sie - alle Programmierer verwenden mehrdimensionale Arrays, ohne zu denken, und suchen nicht nach Glück bei der Erhöhung Code im Interesse der imaginären Effizienz bei der Arbeit mit eindimensionalen Arrays

 
Andrei01:
Hängt die Zuverlässigkeit von Informationen davon ab, wer sie präsentiert? Jeder vernünftige Mensch sollte verstehen, dass Informationen objektiv und nicht subjektiv sind. :)
Und jeder, der sich bemüht, das Thema zu verstehen, wird verstehen, dass Information, wie übrigens auch ihre Quantität, eine subjektive Sache ist, keine objektive:))
 
Die Effizienz moderner (vor allem 64-Bit-) Programme wird in hohem Maße durch die Entwicklungsumgebung und den Compiler bestimmt. Moderne Programme sind weniger abhängig von der Leistung der CPU und der Effizienz ihres Codes. Wer wissen möchte, warum das so ist und nicht umgekehrt, der lese bitte E. Tanenbaums monumentales Werk "Computer architecture", insbesondere Kapitel 5, Abschnitt "Intel IA-64". Jeder abgedroschene prozedurale Code in alten Compilern wird Ihnen keinen solchen Leistungsgewinn im Vergleich zu einem einfachen Übergang zu einer normalen Entwicklungsumgebung bringen. Nehmen wir zum Beispiel Assembler. Ja, das ist ein Ding. Zweifellos wird sie ewig leben. Aber ich bezweifle, dass man in Assembler IA-386-Code schreiben kann, der den üblichen IA-64-Code an Leistung übertrifft, wenn man moderne Hardware-Ressourcen wie Multicore-Prozessoren, erweiterte Befehlssätze und so weiter verwendet. Daraus ergibt sich eine Schlussfolgerung: Man sollte das reinschreiben, was man bekommt. Wenn sie uns .NET gegeben haben, müssen wir auch in diesem Format schreiben. Lassen Sie Tausende anderer Programmierer darüber nachdenken, wie man die Leistung von CIL-Code steigern kann, wie man Threads parallelisieren kann, usw. usw. Das Gleiche gilt für MQL4: Seine Zeit ist vorbei, wir haben MQL5. MetaQuotes wird dies unterstützen. Sie werden darüber nachdenken, wie sie die Leistung ihrer Sprache verbessern können.
 
IgorM:


Wenn der Programmierer mit dem Code nicht zufrieden ist, optimiert er seinen Code:

- durch Vergrößerung des Codes und Verkleinerung des Datenvolumens und Verlust der Rechengeschwindigkeit

- durch die Vergrößerung der Datenmenge im Code und die Erhöhung der Geschwindigkeit

- verwendet alternativ einen anderen Compiler

ALLE OPTIONEN sind weg!

DieCode-Optimierung setzt voraus, dass der Programmierer ein Mindestmaß an Kenntnis darüber hat, wie ressourcenintensiv ein Code-Fragment in Bezug auf die durchgeführten Elementaroperationen (Addition, Multiplikation, Speicherzugriffe, Adressberechnungen usw.) sein wird. Ohne diese ist im Prinzip keine Optimierung möglich, und selbst der beste Compiler ist gegen diesen armen Programmierer machtlos. Es scheint eine Selbstverständlichkeit zu sein, aber ich sehe, dass dies auch für viele Programmierer eine große Neuigkeit sein kann. :)

 
alsu:
Und jeder, der sich die Mühe macht, das Thema zu verstehen, wird feststellen, dass Information, ebenso wie Quantität, eine subjektive Sache ist, keine objektive:))

Nun, man muss verschiedene Dinge verwechseln und zu einer Klapperschlangenmischung zusammenfügen. :)

Der eine ist eine Informationsquelle, die objektiv ist, und der andere ist ein Empfänger, der subjektiv ist, weil er nicht immer alle Informationen wahrnehmen kann, sondern nur einen Teil davon.