float-vergleich



  • SeppJ schrieb:

    /edit:
    Und warum geben isnan von C++0x und Konsorten int und nicht bool zurück? Hat das einen tieferen Sinn?

    Vermutlich weil die C-Variante einen int zurückgibt und man Funktionen nicht anhand des Rückgabewertes überladen kann. Und die C-Variante gibt int zurück, weil selbst der C99-Bool nur eine Krücke die intern meistens ein int ist.

    Jo, das hatte ich schon vermutet. Alte Zöpfe ... 🙂


  • Mod

    berndbernd schrieb:

    Jo, das hatte ich schon vermutet. Alte Zöpfe ... 🙂

    Ich wette intern sind die C++-Bools bestimmt auch meistens ints (Außer das verstoßene Kind vector<bool> 😉 ), man merkt es bloß nicht so stark.



  • Also unter VS2010 ist jedenfalls sizeof(bool) == 1 und nicht vier. Oder meinst du auf CPU-Ebene?


  • Mod

    berndbernd schrieb:

    Also unter VS2010 ist jedenfalls sizeof(bool) == 1 und nicht vier. Oder meinst du auf CPU-Ebene?

    Nein, dann habe ich mich wohl geirrt und im Hintergrund mehr C-Kompatibilität vermutet als eigentlich da ist.



  • Wieso haben die netten Leute die den C99-Standard ausgearbeitet haben nicht char als bool genommen? Ist doch blödsinnig, einfach so Speicher zu verschenken...


  • Mod

    EOutOfResources schrieb:

    Wieso haben die netten Leute die den C99-Standard ausgearbeitet haben nicht char als bool genommen? Ist doch blödsinnig, einfach so Speicher zu verschenken...

    Strenggenommen haben sie _Bool als bool definiert 😃 . Was das intern ist, bleibt den Compilerherstellern überlassen. Aber boolsche Werte werden in C traditionell per int übergeben. Normalerweise leben solche übergebenen Werte dann nicht lange.



  • Der benötigte Speicherplatz ist vor allem dann relevant, wenn man viele Wahrheitswerte aufs Mal benötigt (z.B. in einem Array). In diesem Fall hätten die C-Programmierer wahrscheinlich weniger Hemmungen, direkt bitweise zu arbeiten. Das ist dann immer noch 8 Mal speichereffizienter als bool , hat aber auch seine Schattenseiten.



  • EOutOfResources schrieb:

    Wieso haben die netten Leute die den C99-Standard ausgearbeitet haben nicht char als bool genommen? Ist doch blödsinnig, einfach so Speicher zu verschenken...

    CPU-Zeit ist teurer als Speicher und 32bit Operationen werden auf heutigen x86(_64) CPUs deutlich schneller ausgeführt als 8bit.



  • Ethon schrieb:

    EOutOfResources schrieb:

    Wieso haben die netten Leute die den C99-Standard ausgearbeitet haben nicht char als bool genommen? Ist doch blödsinnig, einfach so Speicher zu verschenken...

    CPU-Zeit ist teurer als Speicher und 32bit Operationen werden auf heutigen x86(_64) CPUs deutlich schneller ausgeführt als 8bit.

    D.h. C89 ist schneller als C++ und C99, weil int üblicherweise 4, bool und _Bool aber nur 1 Byte hat?

    Bedenke dass der Compiler immer noch selbst optimieren kann (z.B. im Bezug auf Padding, verwendete Assemblerbefehler und Register). In C89 hat sich wahrscheinlich einfach int durchgesetzt, weil es nichts Besseres gab und int halt der Standard-Datentyp darstellte.



  • Ethon schrieb:

    CPU-Zeit ist teurer als Speicher und 32bit Operationen werden auf heutigen x86(_64) CPUs deutlich schneller ausgeführt als 8bit.

    Das glaube ich so nicht.



  • CPU-Zeit ist teurer als Speicher [...]

    Das konnte man vielleicht vor 10 Jahren so sagen. Inzwischen geht das nicht mehr so einfach. Die CPU is durchaus schonmal am idlen, weil sie auf Daten ausm Speicher warten muss. Wenn die Datentypen größer werden, passt weniger in den cache, und wenn der prefetcher das Zeug dann auch nicht rechtzeitig ausm RAM holt/holen kann...


  • Mod

    volkard schrieb:

    Ethon schrieb:

    CPU-Zeit ist teurer als Speicher und 32bit Operationen werden auf heutigen x86(_64) CPUs deutlich schneller ausgeführt als 8bit.

    Das glaube ich so nicht.

    Jedenfalls ist es leicht, diese Behauptung ebenso wie auch ihr Gegenteil zu beweisen.



  • Interessanter talk zu dem Thema: http://video.google.com/videoplay?docid=-4714369049736584770#

    CPUs in 2007 haben 210 Takte durchgearbeitet, bis eine Anfrage an den RAM ankommt.

    D.h. wenn die CPU was ausm ram braucht und darauf warten muss, wasted man 210 Takte.


Anmelden zum Antworten