long vs. int



  • Hi Leute,

    ich will meinen SoftwareRenderer umschreiben, sodass die Farben nicht mehr mit fließkomma Zahlen (float's) sondern mit ganzen Zahlen (int oder long) gespeichert werden. Schließlich ist die CPU mit ganzen Zahlen deutlich schneller als mit komma Zahlen.
    Was sollte ich dafür nun nehmen bzw. was ist schneller: int oder long?
    Oder ist das beides gleich schnell?



  • Laut Standard ist die Größe von int die "natürliche Größe, wie sie von der Architektur der ausführenden Umgebung empfohlen wird". Damit sollte man annehmen können, dass int der potentiell schnellste integrale Datentyp ist.

    EDIT: Fälle, in denen sizeof long == sizeof int gilt, wurden nicht explizit betrachtet 🙂



  • Okay, danke 🙂



  • LukasBanana schrieb:

    Schließlich ist die CPU mit ganzen Zahlen deutlich schneller als mit komma Zahlen.

    Ist sie? Auch wenn dadurch die Algorithmen entsprechend geändert werden müssen? (Mal abgesehen dass es für Fließkommazahlen ne FPU gibt)

    LordJaxom schrieb:

    sollte man annehmen können, ...

    Herb Sutter & Andrei Alexandrescu schrieb:

    we programmers are notoriously bad at estimating what code will be faster or smaller

    Soll heißen: Annehmen ist nicht wissen, sondern glauben. Und dafür gibts Kirchen, Moscheen etc. Nachmessen ist wissen.

    LukasBanana schrieb:

    was ist schneller: int oder long? Oder ist das beides gleich schnell?

    Welcher Compiler? Welches OS? Welche Hardware? Speicher-, CPU- oder Netzwerkoperationen?
    Machs dir einfach: typedef int color_t; Benutze nurnoch color_t, miss dein programm einmal durch, ändere den typedef auf long, muss nochmal durch, und du weißt welcher der beiden Typen bei dir das schnellere Programm erzeugt.


  • Mod

    Und bevor jetzt jemand schreibt, dass man trotz pumuckls Einwänden annehmen könnte, dass integer normalerweise schneller als float ist, soll derjenige sich beispielsweise mal die Power 6 Prozessoren von IBM (Power 6 ist deren aktuellee Prozessorgeneration) angucken.



  • ich finde das hier ist eine recht interessante frage ob int und long einen unterschied in der geschwindigkeit zu verzeichnen haben.

    angenommen das ist so, hat dann int gegenüber unsigned int auch einen vorteil?



  • daersc schrieb:

    ich finde das hier ist eine recht interessante frage ob int und long einen unterschied in der geschwindigkeit zu verzeichnen haben.

    angenommen das ist so, hat dann int gegenüber unsigned int auch einen vorteil?

    Du machst den Vergleich vermutlich, weil du denkst, dass es hier um 4 Byte int und 4 Byte long geht, oder? Denn Unterschiede wird man wohl nur feststellen, wenn sizeof(int)!=sizeof(long). Wo sollte sonst der Unterschied sein? int und unsigned int sind in jedem Fall gleichgroß, daher würde ich einfach mal schätzen, dass hier niemals irgendein Unterschied festgestellt werden könnte.



  • Man kann auch einfach boost::int_fast16_t, boost::int_fast32_t, ... verwenden.
    boost::int_fastXX_t (bzw. boost::uint_fastXX_t) ist dabei einfach jener (unsigned) Integer Typ mit mindestens XX Bit, der am schnellsten ist. (Bzw. sein sollte, wobei ich den Boost Entwicklern recht gut vertraue was das angeht.) Sollten mehrere Typen gleich schnell sein, wird der kleinere bevorzugt.

    SeppJ schrieb:

    Und bevor jetzt jemand schreibt, dass man trotz pumuckls Einwänden annehmen könnte, dass integer normalerweise schneller als float ist, soll derjenige sich beispielsweise mal die Power 6 Prozessoren von IBM (Power 6 ist deren aktuellee Prozessorgeneration) angucken.

    Haste mal ne Benchmark?

    Davon abgesehen behaupte ich mal dass es nicht nur auf die CPU, sondern auch sehr aufs Programm drauf ankommt ob int oder float schneller ist. Schliesslich hat die FPU meist ganz andere Latenzen, da sie auf andere "Workloads" getrimmt ist.

    Und natürlich hat float auch weniger Präzision hat als ein >= 4-Byte int 🙂



  • pumuckl schrieb:

    Herb Sutter & Andrei Alexandrescu schrieb:

    we programmers are notoriously bad at estimating what code will be faster or smaller

    Soll heißen: Annehmen ist nicht wissen, sondern glauben. Und dafür gibts Kirchen, Moscheen etc. Nachmessen ist wissen.

    Schon klar, aber diese Möglichkeit habe ich nicht für beliebig viele Plattformen. Dennoch wird man diese Annahme getrost treffen können (zumindest für die integralen Typen), wenn man "natürlich" als "Datentyp, mit dem die Plattform am effizientesten arbeitet" interpretiert, was ich mangels einer besseren Definition erstmal machen würde.



  • LordJaxom schrieb:

    Schon klar, aber diese Möglichkeit habe ich nicht für beliebig viele Plattformen.

    Aber zumindest für eine Handvoll gängiger Plattformen.

    Ich finds immer faszinierend wenn die Leute hier im Forum ankommen mit einem "ich nehme mal an, dass ...". Diese Annahmen stützen sich dann oft auf irgendwelche vereinfachten Vorstellungen von Hardware und Compilern, die auf den grundlegensten Prinzipien beruhen die man im Informatikstudium oder sonstwo vermittelt bekommt, ohne daran zu denken dass die Wirklichkeit viel viel komplexer ist. Mit den Annahmen, die deshalb schon garnicht mehr stimmen müssen, geht man dann hin, steckt ein paar Tage Arbeit in einen Haufen "Optimierungen". Soweit so gut, das kann man durchaus machen - aber nur wenn man hinterher überprüft ob die Optimierung wirklich eine war oder ob man sich die Arbeit das nächstemal besser sparen sollte.

    Mal ehrlich, wie oft treffen Annahmen im Bereich Programmierung wirklich zu? Ich nehme auch immer an dass die 100 Zeilen Code die ich gerade geschrieben habe fehlerfrei compilieren und dass das Programm danach das macht was ich beabsichtigt habe. Der Compiler und die Tests belehren mich danach häufig eines besseren und häufig lerne ich aus den Fehlern die ich gemacht hab. Ihr nehmt an dass Typ X besser ist als Typ Y oder dass Algorithmus A schneller läuft als Algorithmus B. Die Chancen stehen gut dass Profiler & Co. euch da mehr oder weniger häufig eines besseren belehren können. Am Anfang eher häufiger.

    Warum immer nur auf Grund von Annahmen, groben Schätzungen und Interpretationen zig Stunden von Arbeit investieren? Kriegt ihr da kein schlechtes Gefühl wenn ihr wisst dass ihr in kurzer Zeit rausfinden könnt ob die Arbeit wirklich nötig ist?



  • pumuckl schrieb:

    Ich finds immer faszinierend wenn die Leute hier im Forum ankommen mit einem "ich nehme mal an, dass ...". Diese Annahmen stützen sich dann oft auf irgendwelche vereinfachten Vorstellungen von Hardware und Compilern, die auf den grundlegensten Prinzipien beruhen die man im Informatikstudium oder sonstwo vermittelt bekommt,

    Diese eine Annahme stützte sich auf einer Formulierung im internationalen C++ Standard 🙂

    Mit den Annahmen, die deshalb schon garnicht mehr stimmen müssen, geht man dann hin, steckt ein paar Tage Arbeit in einen Haufen "Optimierungen".

    Die Ursprungsannahme war hier "Ganzzahlen sind schneller als float". Mir ging es bei der Antwort lediglich um die Frage, welchen Ganzzahltyp man, wenn, nehmen sollte. Und da würde ich, ohne überhaupt einen Gedanken an Optimierungen zu verschwenden, int nehmen (wenn der Wertebereich ausreicht). Eben weil das der natürliche Typ ist und ich etwas gegen premature Optimization habe.


Log in to reply