Ergebnis 1 bis 20 von 21

Thema: DevC++ Was sind arrays, und wozu dienen sie?

Hybrid-Darstellung

Vorheriger Beitrag Vorheriger Beitrag   Nächster Beitrag Nächster Beitrag
  1. #1
    Soweit ich das irgendwie mal mit bekommen habe sind Arrays doch einfach nur Zeiger auf einen einfachen Speicherbereich in dem sich die Elemente des Arrays hinter einander befinden. Nun wenn ich jetzt ein mehr-dimensionales Array besitze, habe ich praktisch ein Array eines Arrays ...

    Folglich komme ich zu dem Schluss, dass die Dinge nicht hintereinander sondern "willkührlich" im Speicher liegen. ( oder ist das in C/++ anders? )
    Da das eine Array die Zeiger auf den anderen Speicher enthält wo sich die eigendlichen Elemente befinden.

  2. #2
    Nein, die Elemente liegen alle nebeneinander und das wird bei allen Implementierungen statischer Arrays der Fall sein, weil die Lokalität für die Effizienz sehr wichtig ist. Das, was du meinst sind dynamische Arrays, die je nach Implementierung als Elemente auch Zeiger auf Arrays haben können, die woanders liegen. Nicht zu verwechseln mit dynamisch erzeugten statischen Arrays.

  3. #3
    Habe mich wohl unverständlich ausgedrückt. Mit Effizienz war die Unterstützung durch Hardware gemeint, die im Gegensatz zur hausgemachten 'Implementierung in Software' dennoch einen Vorteil bringen kann. Eigentlich sind es nur Additionen und Multiplikationen. Aber das kann man auch anders implementieren um somit eine bessere Effizienz erreichen.

  4. #4
    Hardwareunterstützung für den Zugriff auf mehrdimensionale Arrays? Davon lese ich zum ersten mal, wenn ich ehrlich sein soll. Was kann ich mir darunter vorstellen?

    Zitat Zitat von Brauni90 Beitrag anzeigen
    Eigentlich sind es nur Additionen und Multiplikationen. Aber das kann man auch anders implementieren um somit eine bessere Effizienz erreichen.
    Falls es rübergekommen ist, als würde ich Zugriffe auf mehrdimensionale Arrays als langsam bezeichnen, so war das nicht beabsichtigt. Das ist natürlich vollkommener Quatsch, denn Integeradditionen und selbst -multiplikationen sind heute sehr schnell, Additionen und Subtraktionen benötigen z.B. nur einen Cycle und bei Operationen auf Arrays ist die Chance groß, dass man diese vektorisieren kann, was das Ganze nochmal um ein Vielfaches schneller macht.
    Ich habe es nur so aufgefasst, als würdest du behaupten, Zugriffe auf mehrdimensionale Arrays wären schneller als auf eindimensionale.

  5. #5
    Zitat Zitat von Kyuu Beitrag anzeigen
    Hardwareunterstützung für den Zugriff auf mehrdimensionale Arrays? Davon lese ich zum ersten mal, wenn ich ehrlich sein soll. Was kann ich mir darunter vorstellen?



    Falls es rübergekommen ist, als würde ich Zugriffe auf mehrdimensionale Arrays als langsam bezeichnen, so war das nicht beabsichtigt. Das ist natürlich vollkommener Quatsch, denn Integeradditionen und selbst -multiplikationen sind heute sehr schnell, Additionen und Subtraktionen benötigen z.B. nur einen Cycle und bei Operationen auf Arrays ist die Chance groß, dass man diese vektorisieren kann, was das Ganze nochmal um ein Vielfaches schneller macht.
    Ich habe es nur so aufgefasst, als würdest du behaupten, Zugriffe auf mehrdimensionale Arrays wären schneller als auf eindimensionale.
    Boost-Mode\Heap, HW-Loops vlt?

  6. #6
    Ich bin jetzt etwas verwirrt wieso du den zweiten Teil auch zitiert hast, denn dieser hat mit dem ersten nichts zu tun. Außerdem ist mir dein Kommentar zu minimalistisch, um daraus genügend Inhalt zu gewinnen. :0

    Es ging mir übrigens nicht darum wie man sequentiellen Zugriff auf Arrays (Dimension irrelevant) hardwareseitig/softwareseitig optimieren kann, da hat man viele Möglichkeiten offen: software pipelining, loop unrolling, SIMD instructions, pointer arithmetic, etc., das ist alles eher uninteressant. Interessant ist ob die obligatorische Berechnung des Offsets bei Ausdrücken der Form 'array[a1]...[an]' hardwareseitig abgenommen werden kann.


    Edit: @Mog:

    Ah, danke für die Erklärung. :) Mit einem DSP hatte ich bisher nur sehr wenig zu tun (SSE), Hardware Looping ist für mich also Neuland.

    Geändert von Kyuu (19.08.2009 um 03:53 Uhr)

  7. #7
    Zitat Zitat von Kyuu Beitrag anzeigen
    Ich bin jetzt etwas verwirrt wieso du den zweiten Teil auch zitiert hast, denn dieser hat mit dem ersten nichts zu tun. Außerdem ist mir dein Kommentar zu minimalistisch, um daraus genügend Inhalt zu gewinnen. :0

    Es ging mir übrigens nicht darum wie man sequentiellen Zugriff auf Arrays (Dimension irrelevant) hardwareseitig/softwareseitig optimieren kann, da hat man viele Möglichkeiten offen: software pipelining, loop unrolling, SIMD instructions, pointer arithmetic, etc., das ist alles eher uninteressant. Interessant ist ob die obligatorische Berechnung des Offsets bei Ausdrücken der Form 'array[a1]...[an]' hardwareseitig abgenommen werden kann.
    Hardware-Loops. Steht doch dort. Genau dafuer sind die Dinger doch da. Jeder, der schon mal mit einem DSP gearbeitet hat, kennt diese Dinger eigentlich. Im Prinzip ist das nur ein Werk, welches for-schleifen mit einem Index optimal aufloest. Spich: Die Spruenge werden von der Hardware direkt serialisiert, und das Inkrement automatisch in einem Zug gebildet. Wohl gemerkt muss man diese per Hand verwenden - kein Compiler verwendet sie von Haus aus.

    Zumindest diese passen nicht in den Haufen, den du gelistet hast. Boost ist wahrscheinlich bereits zu abstrakt, fuer einen Programmierer.

  8. #8
    Zitat Zitat von Kyuu Beitrag anzeigen
    Hardwareunterstützung für den Zugriff auf mehrdimensionale Arrays? Davon lese ich zum ersten mal, wenn ich ehrlich sein soll. Was kann ich mir darunter vorstellen?
    Das von Mog bereits beschriebene oder den Optimierungsspielraum, den man dem Compiler damit lässt, sofern dieser das berücksichtigt. Für die meisten Nutzer wird die heutige Hardware so oder so reichen, aber darum geht es nicht. Eher um ein Hinweis auf eine Überlegung zu den damit verbundenen möglichlichen Optimierungen bei Hardware ...

  9. #9
    Ich habe durchaus nach konkreten Beispielen gefragt. ^^
    Und Optimierungsspielraum lassen impliziert noch lange nicht gewonnene Effizienz.

    BTW: Nach Michael A. Jackson lautet die erste Regel für Optimierung "Tu es nicht", die zweite "Tu es noch nicht" (im Sinne von "tu es erst, wenn Handlungsbedarf besteht"). Wenn man das befolgt, lässt man dem Compiler theoretisch sowieso den höchstmöglichen Optimierungsspielraum.

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •