Was braucht mehr Rechenleistung,...
-
...EINE Rechenoperation mit EINER Variable in der Größe von
"4 BYTE"
o.
...ZWEI Rechenoperationen mit ZWEI Variablen in der Größe von jeweilig "2 BYTE"?
Diesmal erst die Frage dann die Begrüßung.Also dann.
Hallo liebe C++-Gemeinde!
-
Ja
-
Dieser Thread wurde von Moderator/in evilissimo aus dem Forum C++ (auch C++0x und C++11) in das Forum Rund um die Programmierung verschoben.
Im Zweifelsfall bitte auch folgende Hinweise beachten:
C/C++ Forum :: FAQ - Sonstiges :: Wohin mit meiner Frage?Dieses Posting wurde automatisch erzeugt.
-
hallo und willkommen
höchstwahrscheinlich die zwei operationen.
-
manni66 schrieb:
Ja
Ja?
Was heißt hier "ja"?
-
sC++k schrieb:
manni66 schrieb:
Ja
Ja?
Was heißt hier "ja"?Ja, eine ist schneller oder zwei sind schneller.
Das kommt doch wohl auf die Operationen, den Prozessor und den Speicherort der Daten am.
-
manni66 schrieb:
Das kommt doch wohl auf die Operationen, den Prozessor und den Speicherort der Daten am.
Du meinst also dieses Thema lässt sich auf garkeinen Fall verallgemeinern?
Und was wäre denn zu beachten um in so einer Lage auf jeden Fall Rechenaufwand
zu sparen? Anders gefragt: Welche Wahl passte am besten auf welche der von dir genannten abhängigen Umstände?
-
sC++k schrieb:
Und was wäre denn zu beachten um in so einer Lage auf jeden Fall Rechenaufwand
zu sparen?Du solltest einen Profiler nehmen oder den Assemblercode anschauen. Vorausgesetzt natürlich, du hast wirklich keine grösseren, offensichtlichen Performanceprobleme und musst dich mit derartigen Mikrooptimierungen herumschlagen.
Übrigens, das Forum kann Zeilen automatisch umbrechen
P.S. Yeah, die Vorschau geht wieder
-
Nexus schrieb:
offensichtlichen Performanceprobleme und musst dich mit derartigen Mikrooptimierungen herumschlagen.
Du meinst also der Unterschied sei kaum warnehmbar,
auch wenn man solche eine Rechenoperation ins millionen- o. milliardenfache skripted/skripten lässt?Andere Frage:
Hängt die Dauer der Berechung/Verrechnung u. der Arbeitsspeicherverbrauch zweier Variablen von der Größe der beeinhaltenden/zu berechnenden Zahlenwerte ab?
-
sC++k schrieb:
Nexus schrieb:
offensichtlichen Performanceprobleme und musst dich mit derartigen Mikrooptimierungen herumschlagen.
Du meinst also der Unterschied sei kaum warnehmbar,
auch wenn man solche eine Rechenoperation ins millionen- o. milliardenfache skripted/skripten lässt?Andere Frage:
Hängt die Dauer der Berechung/Verrechnung u. der Arbeitsspeicherverbrauch zweier Variablen von der Größe der beeinhaltenden/zu berechnenden Zahlenwerte ab?Wenn du das durch ein Skript erledigst liegt dein Performance Bottleneck an einer ganz anderen Stelle. Da brauchste dir auch keine Gedanken über die Variablengröße machen...
-
DocShoe schrieb:
Da brauchste dir auch keine Gedanken über die Variablengröße machen...
Ich will aber
-
Wenn du z.B. zwei Additionen vs. eine Division antreten lässt, dann werden wohl die zwei Additionen gewinnen.
Wenn du die selben Rechenoperationen gegeneinander antreten lässt, dann wird die Variante mit zwei Operationen maximal gleich schnell sein, oft auch langsamer.Ausgenommen vielleicht diverse sehr eigenartige Spezielfälle, die aber real keinen interessieren.
sC++k schrieb:
DocShoe schrieb:
Da brauchste dir auch keine Gedanken über die Variablengröße machen...
Ich will aber
Tu was du nicht lassen kannst.
-
Mit der modernen Prozessorarchitektur sind überhaupt rechenoperationen annähernd kostenlos. Was Zeit braucht ist die Daten in den Prozessor zu bekommen.
Vor einigen Tagen hatten wir in der Uni eine Tabelle, die die Relationen gezeigt hat:
- Plus-Operation 1 Taktzyklus - Speicherzugriff auf Level-1 Cache: 1 Taktzyklus ... - Speicherzugriff auf Level-3 Cache: ~300 Taktzyklen ...Das bedeutet, es interessiert kaum bis gar nicht in der Praxis wie schnell (oder langsam) eine Rechenoperation ausgeführt werden kann, sondern der Bottleneck liegt beim Speicher.
-
Skym0sh0 schrieb:
Mit der modernen Prozessorarchitektur sind überhaupt rechenoperationen annähernd kostenlos. Was Zeit braucht ist die Daten in den Prozessor zu bekommen.
Vor einigen Tagen hatten wir in der Uni eine Tabelle, die die Relationen gezeigt hat:
- Plus-Operation 1 Taktzyklus - Speicherzugriff auf Level-1 Cache: 1 Taktzyklus ... - Speicherzugriff auf Level-3 Cache: ~300 Taktzyklen ...Das bedeutet, es interessiert kaum bis gar nicht in der Praxis wie schnell (oder langsam) eine Rechenoperation ausgeführt werden kann, sondern der Bottleneck liegt beim Speicher.
Und sowas hinterfragst Du ehlich nicht? Ist da mit Level-3-Cache die Festplatte gemeint?
-
sC++k schrieb:
...EINE Rechenoperation mit EINER Variable in der Größe von
"4 BYTE"
o.
...ZWEI Rechenoperationen mit ZWEI Variablen in der Größe von jeweilig "2 BYTE"?
Diesmal erst die Frage dann die Begrüßung.wenn die operation eine multiplikation ist und du auf uint32_t bzw uint16_t arbeitest und der processor eine SPU ist, dann dauert eine uint32_t multiplikation 5cycle und eine uint16_t multiplikation 1cycle, zwei davon sind also 2.5mal schneller.
ich hoffe das hilft dir weiter.volkard schrieb:
Ist da mit Level-3-Cache die Festplatte gemeint?
HDD latenzen sind meistens in ms angeben. In cycles gibt man die latenz von processoren an, da diese natuerlich mit der taktung des prozessors variiert.
-
volkard schrieb:
Und sowas hinterfragst Du ehlich nicht? Ist da mit Level-3-Cache die Festplatte gemeint?
Wodrauf willst du hinaus?
Das Ding ist doch, dass, je tiefer wir in der Speicherhierarchie gehen, der Zugriff langsamer wird, umgekehrt aber der verfügbare Platz größer wird.
Woebi ich mich grad selbst verbessern muss:
- Register -> 200 ps - L1 Cache (auf der CPU) -> 1 ns - L2 Cache (auch auf der CPU) -> 10 ns - RAM -> 100 ns - HDD -> 5 ms - z.B FTP -> x s (beliebig)Meine obige Angabe war also tatsächlich etwas falsch. Wobei der Unterschied zwischen Register und RAM sich doch um den Faktor 500 unterscheiden. Und wenn ein Taktzyklus eben 200 Picosekunden braucht (-> 5GHz Prozessor), dann ist meine obige Angabe schon relativ gut stark unterschätzend.
Letztlich bleibt jedoch nur meine Aussage, dass es relativ lange braucht, Daten in den Prozessor zu schaffen, als diese Daten durch einzelne Berechnungen zu verändern. Oder siehst du das anders?
(Früher wars ja genua umgekehrt. Da hat man Daten flott in die CPU bekommen, aber die Berechnung war langsam.)
-
Skym0sh0 schrieb:
Letztlich bleibt jedoch nur meine Aussage, dass es relativ lange braucht, Daten in den Prozessor zu schaffen, als diese Daten durch einzelne Berechnungen zu verändern. Oder siehst du das anders?
Verwechsele Latenz nicht mit Rechenzeit! Es mag zwar 100 ns dauern bis der Hauptspeicher antwortet, aber dann kommen mit der Antwort auch gleich 8 Bytes und das viele Milliarden mal pro Sekunde, ohne weitere Verzögerung. Mehr als genug, um den Prozessor voll zu beschäftigen, außer bei den allertrivialsten Rechnungen. Wenn du also nicht bloß genau zwei Byte aus dem Hauptspeicher verarbeiten möchtest, die aus irgendeinem Grund nicht schon längst in einem Prozessorregister liegen, dann ist der Speicher nicht der Flaschenhals. Und das ist der Normalfall.
-
Jain, würde ich nicht unbedingt behaupten.
Arbeiten wir auf einem Array und verarbeiten sequenziell die Daten eines .B. Arrays dann geht das wahnsinnig schnell.
Aber holen wir uns mal grad von Position x ein Datum, dann von Position y und dann von z etwas, dann dauert das schon recht lange. (Klar liegt hier eine Verantwortung beim Programmierer...)
-
SeppJ schrieb:
Verwechsele Latenz nicht mit Rechenzeit! Es mag zwar 100 ns dauern bis der Hauptspeicher antwortet, aber dann kommen mit der Antwort auch gleich 8 Bytes und das viele Milliarden mal pro Sekunde, ohne weitere Verzögerung. Mehr als genug, um den Prozessor voll zu beschäftigen, außer bei den allertrivialsten Rechnungen.
Normalerweise ist ja der L1-Cache darauf ausgelegt, den Prozessor zu saturieren. RAM ist Faktor 50-100 langsamer. Also so ziemlich alle operationen unter exp stoßen damit an das Speicherbottleneck. Das merkt man sehr schnell, wenn man mal matrix-vektor produkte benchmarkt. Wenn die Matrix nicht in den Cache passt, tut das der performance richtig weh. Also so 5 floating point multiplikationen sollte man schon machen, bevor man das nächste element vom speicher nimmt.
ich wollte das schon immer mal Benchmarken, wieviele multiplikationen man da pro element braucht...
-
Etwas, das < 5 Multiplikationen benötigt würde ich unter triviale Berechnung verbuchen.
