Vergleichoperator(==) Laufzeit abhängig vom datentyp?



  • Hi ihr Freaks 🙂

    Ich habe mal eine ganz einfache Frage an euch.
    Wenn ich einen Zahlvergleich mache, also if(i==j) dann ist doch die Laufzeit des Vergleiches nur abhängig vom datentypen oder auch von der größe der Zahlen?
    Also je mehr bits der Datentyp hat, desto länger dauert der Vergleich? Wie schaut ein Zahlenvergleich in Assembler aus? Man vergleicht doch letztendlich jede Bitstelle miteinander oder?
    würde es daher sinn machen für riesige Schleifen eine uint_32 Zahl mit dem Wert FFFF FFFF als -1 (zweierkomplement) zu interpretieren und sie mit der anderen Zahl zu vergleichen, anstatt die positive Zahl herzunehmen? Habe ich dadurch Zeit gewonnen? Ich denke nicht oder? Es sein denn, ich nehme für die -1 einen anderen datentypen...
    Eine Zusatzfrage: Wieso dauert der Vergleich von Strings so viel länger, als der vergleich von Zahlen?
    Viele Grüße
    CoraD


  • Mod

    CoraD schrieb:

    Hi ihr Freaks 🙂

    Na danke, für die freundliche Anrede.

    Ich habe mal eine ganz einfache Frage an euch.
    Wenn ich einen Zahlvergleich mache, also if(i==j) dann ist doch die Laufzeit des Vergleiches nur abhängig vom datentypen oder auch von der größe der Zahlen?
    Also je mehr bits der Datentyp hat, desto länger dauert der Vergleich? Wie schaut ein Zahlenvergleich in Assembler aus? Man vergleicht doch letztendlich jede Bitstelle miteinander oder?
    würde es daher sinn machen für riesige Schleifen eine uint_32 Zahl mit dem Wert FFFF FFFF als -1 (zweierkomplement) zu interpretieren und sie mit der anderen Zahl zu vergleichen, anstatt die positive Zahl herzunehmen? Habe ich dadurch Zeit gewonnen? Ich denke nicht oder? Es sein denn, ich nehme für die -1 einen anderen datentypen...
    Eine Zusatzfrage: Wieso dauert der Vergleich von Strings so viel länger, als der vergleich von Zahlen?
    Viele Grüße
    CoraD

    Die Geschwindigkeit des Vergleichsoperators ist abhängig vom Datentyp, ja. Also grobe Faustregel hat das auch was mit der größe des Datentyps zu tun, aber da kann man mit Leichtigkeit Ausnahmen finden. Strings sind sehr viel größere Datentypen als Zahlen, da greift die Faustregel.

    Deine Vorstellungen wie ein Computer intern funktioniert sind absoluter Blödsinn. Wenn du Mikrooptimierungen aufbauend auf diesen Vorstellungen machst, wirst du dir selber schaden.



  • Deine Vorstellungen wie ein Computer intern funktioniert sind absoluter Blödsinn. Wenn du Mikrooptimierungen aufbauend auf diesen Vorstellungen machst, wirst du dir selber schaden.

    Ich bin nur eine blöde Blondine... wie meinst Du das? Kannst Du das etwas genauer erklären? Wie funktioniert in diesem Zusammenhang ein Computer? 🙂

    Sorry für die Anrede.. war nicht böse gemeint.

    Liebe Grüße
    Cora



  • Die integralen Datentypen (char, short, int) werden immer auf Prozessorebene als ganzes (parallel) verglichen. Nur bei Datentypen, welche größer als der Datenbus sind, werden die Daten nacheinander verglichen. Und Strings werden immer zeichenweise verglichen (bzw. evtl. auch optimiert auf Datenbusbreite), da sie ja unterschiedlich lang sein können.

    Und jetzt könnte ich dir auch noch erzählen, daß ein Vergleich von einzelnen Bytes langsamer sein kann als ein ganzer Int (aber das laß ich jetzt lieber -)


  • Mod

    Das was Th69 schreibt wollte ich auch sagen. Und noch was hinzufügen: Das Bit ist auf Ebene der Prozessorlogik eine völlig irrelevante Größe. Der Prozessor rechnet mit Bytes und sogenannten Worten (die Länge eines Wortes entspricht der Datenbusbreite).

    Das Bit ist eine Größe, die eine Rolle spielt:
    a) Als Hilfsgröße beim Programmieren, weil man oft Sachen mit Zweizustandslogik programmiert.
    b) Bei der wirklichen technischen Umsetzung des Prozessors auf elektrischer Ebene. Das heißt im Schaltplan des Prozessors tauchen tatsächlich Dinge auf, die man mit Bits assoziieren kann. Für die eigentliche Funktion des Prozessors ist es aber unerheblich ob er intern mit Bits, verschränkten Quanten oder einem Rechenschieber arbeitet.



  • SeppJ, wir scheinen uns ja gut zu ergänzen 👍


Log in to reply