4. var char[256] - Grundsätzliche Frage zur Speicherverwaltung

var char[256] - Grundsätzliche Frage zur Speicherverwaltung

  • C

    so lange nicht fuer uCs programmiert wird, kann man ruhig verschwenderisch sein. optimierung erst wenn alles funktioniert.

    0
  • ?

    Also feste Rahmengrößen sind doch schon eher etwas für die Geschichtsbücher. Ein gut durchdachtes Programm ist dynamisch! Empfehlenswert ist vielleicht die Arbeit mit calloc(sizeof *x)

    0
  • ?

    Hyper_gscheiter schrieb:

    Also feste Rahmengrößen sind doch schon eher etwas für die Geschichtsbücher. Ein gut durchdachtes Programm ist dynamisch! Empfehlenswert ist vielleicht die Arbeit mit calloc(sizeof *x)

    Traurig, dass hier immer vom normalen 0815-x86 ausgegangen wird...

    0
  • V

    TactX schrieb:

    Hyper_gscheiter schrieb:

    Also feste Rahmengrößen sind doch schon eher etwas für die Geschichtsbücher. Ein gut durchdachtes Programm ist dynamisch! Empfehlenswert ist vielleicht die Arbeit mit calloc(sizeof *x)

    Traurig, dass hier immer vom normalen 0815-x86 ausgegangen wird...

    ich fühle mit dir...
    🙂

    0
  • C

    traurig, dass hier immer von mikrokontrollern ausgegangen wird...

    ein bisschen schmerz kann man sich doch sparen, indem man weniger knauserig mit speicher und prozessorleistung umgeht. die zeiten von mainframes und prozessorzeit gegen geld sind vorbei.

    allerdings stimmts schon. wer programmiert denn noch C? kernelprogrammierer, embedded-leute und wer nen flaschenhals zu bewaeltigen hat. dafuer ist C doch gedacht: performance. performance fuer einen haufen code, fuer dessen erstellung man zeit braucht, die sich manche menschen noch nehmen.

    0
  • V

    c.rackwitz schrieb:

    traurig, dass hier immer von mikrokontrollern ausgegangen wird...

    das ist eins der hauptanwendungsgebiete von C...

    c.rackwitz schrieb:

    allerdings stimmts schon. wer programmiert denn noch C? kernelprogrammierer, embedded-leute und wer nen flaschenhals zu bewaeltigen hat. dafuer ist C doch gedacht: performance....

    in embedded-foren gibt es öfters mal kleinkriege zwischen C und assembler-fans, wer den meisten speed rausholt usw. (so wie hier immer C++ gegen Java).
    die assembler-fraktion hat bisher immer gewonnen 😃

    0
  • J

    Was ist '0815-x86' ?

    PS.: Ich bin noch neu in der (C) Programmierung

    0
  • R

    08/15 muss nicht erklärt werden, glaub ich.
    x86 ist eine Prozessorarchitektur. Hauptsächlich die alten 32bit-Intel und AMDs sind Exemplare dieser Architektur.

    0
  • S

    was mit 0185 gemeint ist, sollte jeder wissen 😉 die Archtitektur x86 ist die im Desktop PC (eigentlich in IBM kopatiblen) PC die Prozessorarchitktur, die im Einsatz kommt. D.h. ein normaler Rechner, den man bei Media Markt kauft, ist ein x86 Rechner.
    Siehe auch http://de.wikipedia.org/wiki/X86-Prozessor

    edit: heute bin ich zu langsam 😡

    0
  • E

    Als Verursacher dieses Threads muss ich mich doch noch mal einmischen. Das Programm, von dem ich sprach, ist überaus zeitkritisch, also kommt es stark auf gute Performance an.

    In dem Zusammenhang: Ich finde nicht, dass man so Aspekte wie Speicherbedarf und Performance ganz außer Acht lassen sollte, auch wenn die Hardware rund 1000 mal so leistungsfähig ist wie noch vor 15 Jahren. Es zeigt sich doch immer wieder, dass die Programmierer die Hardware in die Knie zwingen können. Eklatantes Beispiel: der MS Flight Simulator unter Windows.

    U.a. beschäftige ich mich zur Zeit intensiv mit dem Spielprogramm Tuxracer (C-Programm). Die alte Version 0.61 läuft auf meinem mittelmäßigen Rechner (800 MHz, Riva TNT - 3D-Grafikkarte der ersten (!) Generation) immerhin mit 50 - 90 fps. Da ist noch Spielraum vorhanden, der auch dringend gebraucht wird. Der Nachfolger ppracer, der in C++ programmiert ist, schafft gerade knapp 20 fps, ohne dass Funktionalität dazugekommen ist. Die letzte Version von ppracer, kurz bevor das Programm starb, brach mit weniger als 5 fps ein.

    Dabei gibt es in Tuxracer keine genialen Algorithmen, die für die Performance sorgen, sondern es wurde einfach auf die Performance geachtet. So werden z.B. nicht unnötig Daten herumgeschaufelt, sondern konsequent mit Zeigern übergeben. Optimale Performance lässt sich m.E. nicht nur durch großartige Algorithmen, sondern auch und vor allem durch viele Optimierungen im Kleinen erreichen.

    Ich jedenfalls ärgere mich, wenn die Programmierer vor ihren Superkisten sitzen und voraussetzen, dass bei den Anwendern ebenfalls nichts unter 3 GHz und 1 GB läuft. Und dann gibt ja noch Programmierer, die gedankenlos mit Speicher und Prozesserlast um sich werfen, bei denen sich aber die Nackenhaare sträuben, wenn mal eine Library statisch gelinkt werden soll. Manchmal habe ich Probleme, die Leute zu verstehen.

    Sorry, ich musste das mal los werden.
    Reinhard

    0
  • V

    erin schrieb:

    Optimale Performance lässt sich m.E. nicht nur durch großartige Algorithmen, sondern auch und vor allem durch viele Optimierungen im Kleinen erreichen.

    das stimmt nicht.
    du kannst dir 'nen wolf optimieren, wenn du einen schlechten algorithmus verwendest hilft das nichts.
    da muss nur mal einer kommen und den besseren (passenden) algo einsetzen und es läuft 10 mal schneller ohne optimierung.

    0
  • C

    erin:

    es gibt auch programme, da kommt es auf performance GARNICHT an. die laufen keine 100 ms und sind dann fertig.

    bei nem flight simulator oder tuxracer lohnt sich optimierung, weils da um frameraten geht. das sollte dir doch klar sein.

    dir sollte auch klar sein, dass es auch programme gibt, die keine spiele sind und auch sonst keine performance verlangen.

    es geht darum, zu wissen WANN optimierung was bringt und wann nicht.
    es geht darum, sich die arbeit nicht GRUNDLOS zu machen.

    0
  • J

    Ja, danke für die Erklärung!

    0
Anmelden zum Antworten