Hallo miteinander
wenn ich hier
//www.sps-forum.de/simatic/72602-1500-optimierter-bausteinzugriff-sinn-unsinn.html#post504460 schon
Dazu hat der TIA Anwender Nr 1, Helle Barde schon einiges getestet und geschrieben
geadelt werde, dann muss ich wohl doch meinen Senf dazugeben, obwohl das Wichtige schon gesagt wurde.
Auf 1500 ist optimiert eindeutig schneller und mischen ist schlecht. Je teurer die CPU ist, desto größer ist der Effekt.
Man hat es zwar nicht bestätigt, aber in der 1518 vermute ich einen relativ modernen Prozessor von Intel und in den kleineren einen vom MIPS. Wenn man also einen Prozessor aus der Haswell Reihe annimmt, dann hat S mit folgenden "Problemen" zu kämpfen: 3 Cache Ebenenen, 64Byte Cachelines, Lüfterlos --> 17W TDP. (Hat mir alles mein Sohn der Herr Informatikstudent verraten). Warum macht das Probleme, wenn sich doch die PC darüber freuen. Weil "wir rückständig denkenden SPSler" (Zitat Sohn) dem Compiler in die Adressierung pfuschen wollen, denn wir glauben wir wüssten es besser. Und gleich noch ein Zitat: "Kein C-Compiler lässt so einen Blödsinn zu".
Ich habe ihm dann mittels #pragma pack(1) bewiesen dass ein C-Compiler das doch zu lässt. Und er hat mir dann bewiesen, dass deswegen genau dieses Programm um den Faktor 53 langsamer läuft. Autsch! Blöd wenn der Lauser recht hat, da geht die ganze Autorität flöten.
Woran liegt es? Die Intels lesen am liebsten 64 Byte am Stück. Und am schnellsten kann er Lesen, wenn die Daten im Level 1 Cache, d.h. nahe am EAX (wir würden da Akku zu sagen) liegen. Je weiter weg vom EAX die Daten liegen desto länger dauert es. Über die Probleme von Mehrkernsystemen wird sich S wohl gerade Gedanken machen, wir bekommen das erst mit der 1519 ;-) Also der Level1 Zugriff dauert nur wenige Nanosekunden, der Level3 schon 100 Nanosekunden und auf das RAM raus kommen wir für ein einzelnes Byte knapp an die µs. Deswegen will Intel auch nicht ein einzelnes lesen, sondern immer einen Burst von 64 Bytes, dann werden nicht so oft Adressen über die Busse gejagt und damit kann man dann 64 Byte schneller lesen als einzelne Bytes. Jetzt teilen sich wie immer Code und Daten das RAM, und der Code wird eher linear durchlaufen, da hilft das mit den 64Byte Cachelines, während die Daten wirklich RANDOM zugegriffen werden, da hilft es nix.
Wen man wissen will, was der Intel im PC so an Speicher hat, dann kann man COREINFO.EXE von SYSINTERNALS in der Eingabeaufforderung aufrufen. Mein PC auf dem ich das jetzt tippe hat 4 Kerne, jeder Kern hat 32KB für Code + 32KB für Daten Level 1 Cache, jeder Kern hat 256KB Level 2 Cache und alle Kerne zusammen haben einen Level3 Cache von 8MB.
Jetzt kommen wir daher und greifen auf DB18.DBD62 zu. Wenn Siemens irgendwas vom getrennt laden der Baustein hat, dann liegt der Anfang eines DB auf einer durch 64Byte teilbaren Adresse. Der Zugriff auf DBD62 greift jetzt genau über die Grenze --> zwei Cachelines lesen. Ok greifen wir auf DB18.DBD6 zu. Es ist ein 64bit Prozessor. Der kann 8, 16, 32, 64 Bit aus dem Level1 holen, wenn diese am Stück liegen und zwar so, dass die Adresse durch die Zugriffsbreite teilbar ist. 6/4 ist 2 rest 2. Das geht nicht. Also zwei mal 16 Bit holen und zusammen schieben. Dauert drei mal so lange wie der richtig ausgerichtete Zugriff. Und dann ist Intel ja auch immer littleendian. standard ist aber bigendian. D.h. die Bytes liegen auch noch verkehrt im Speicher. Entweder hängt man nun einen BSWAP hinterher oder man holt die BYte einzeln und schiebt sie ander herum zusammen. Dann kannste auch gleich auf DBD5 zugreifen, ist dann auch schon egal.
Ich möchte daher Thomas_v21 widersprechen
Diese "optimierte Datenablage" ist auch so eine Schnapsidee, dem Verantwortlichen bei Siemens sollte man dafür die Ohren langziehen.
Das ist sie nicht, das sieht alles so aus, also ob es auf die Haswells und was da auch immer nachkommt ausgelegt ist. So richtig wichtig ist es aber nur wenn ich die 1518 auch wirklich brauche, weil ich Zykluszeiten oder Interruptzeiten deutlich unter 1µs brauche. Wenn mir 100ms oder mehr reichen, dann ist optimiert nicht wichtig. Im Gegenteil für Kommunikationspuffer zusammenschrauben ist es störend.
Was lernen wir: Wiedermal eine grüne Banane gekauft.
"Optimiert" ist etwas, was die wenigsten von uns brauchen und die, die es brauchen, können es nicht so richtig verwenden, weil noch wichtiges fehlt. Z.B. Funktionen zum Erstellen von Kommunikationspuffern.
'n schön' Tach auch
HB
