C: Ist int oder char schneller?

Beitrag von **Airport1** » 27.04.2007, 11:41

Die Diskussion wird zunehmend schraeg bzw. OFFTOPIC:
vielleicht doch mal einen neuen Thread erstellen? .-) ?

> Es gibt ja schon Beispiele, wo ein Java-Programm genau bei einer ähnlichen Aufgabenstellung schneller war, als ein äquivalentes C Programm.

Aber zurueck zum neuem OFFTOPIC-Thema

Zumindest einen Vergleich fuer Java vs. C++ konnte ich finden:
https://www.gzg.fn.bw.schule.de/inform/ ... TIJChE.htm

Neues moegliches OFFTOPIC Thema: ich frage mich gerade wieviel schneller der Stack vs. dem normalen Heap in C ist. Hat dazu irgendjemand Messungen? Ich rate aber jetzt schon, dies loest wieder neue weitere OFFTOPIC-Diskussionen aus, dass der Stack ja nur begrenzt Platz hat, den Programmierstil etc. pp. aber darum gehts WIE IMMER in dieser Fragestellung E-I-G-E-N-T-L-I-C-H NICHT

von **Anzeige von ABAKUS** »

Beitrag von **everflux** » 27.04.2007, 12:00

Um welche Laufzeiten gehts hier denn eigentlich konkret? Wenn es sich um den Bereich Stunden handelt, diskutieren wir bald länger als man sparen könnte *G*
Ich würde das halt eher parallelisieren als zu überlegen wie man da noch das letzte bißchen aus nem mittelguten Ansatz rausholt.

Beitrag von **SloMo** » 27.04.2007, 14:32

Airport1 hat geschrieben:Neues moegliches OFFTOPIC Thema: ich frage mich gerade wieviel schneller der Stack vs. dem normalen Heap in C ist.

Stack vs. Heap, interessant, interessant!

Aus'm Bauch heraus würde ich sagen, dass nur die Allozierung einen Geschwindigkeitsunterschied ausmachen dürfte. Dann hängt der Vorteil allein davon ab, wie oft Du im Verhältnis zur Laufzeit Speicher holst und freigibst. Aber das ist auch sehr Systemabhängig. Denn nur einmal angenommen, das Betriebssystem Deines Herzenz lagert den Speicher/Code auf die Festplatte aus... dann... ja dann...... offtopic genug?

Beitrag von **Airport1** » 27.04.2007, 17:13

Dem schliesst sich doch gleich die naechste Frage an: wird denn der Stack jemals ueberhaupt ausgelagert? Beim Heap ists ja klar, da kann der Speicher sogar stark fragmentiert sein..

Der Stack aber wird fuer gewoehnlich (!) an einer festen Stelle beginnen und enden (schaetze mal an einem Stueck, alles andere ergaebe gar keinen Sinn bzgl. des "top"-Pointers), und fuer gewoehnlich wird man auch nicht dessen Groesse aendern muessen oder gar wollen. Daher nehme ich nicht an, dass es Sinn macht den Stack auszulagern, glaube auch nicht dass das jemand macht.

Beim C64 war der Stack uebrigens "riesig"

Ging von $0100 bis $01FF. Der Zugriff mittels push und pop war immer mind. 1 Taktzyklus sparsamer als wenn man den normalen Speicher adressierte.

Beitrag von **SloMo** » 27.04.2007, 21:14

Es gibt ja die virtuelle Speicherverwaltung. Die gesamte Stackgröße aller Threads ist unter Windows z.B. durch die Größe der Auslagerungsdatei + physikalischem Speicher begrenzt. Also wird der Stack auslagerbar sein. Unter Linux etc. wird es ähnlich sein.

Beitrag von **johngrinder** » 03.08.2007, 22:48

airport,

ich möchte nur mal am rande auf einen zentralen denkfehler deinerseits hinweisen:
wenn du dreistellige (!) zahlen verarbeiten willst, wird dir ein char nicht viel helfen, da ein char max. zahlen von einer grösse bis max. 255/256 aufnehmen kann.
wenn du also vor hast, "richtige" dreistellige zahlen zu verarbeiten wirst du um ein mind. small/short int nicht herum kommen, da du eine zahl wie 789 nicht in einem char abbilden kannst...

handelt es sich bei deiner applikation um eine webapplikation, dann hast du je nach platform mächtige (!) werkzeuge in form des compilers, die dir solche überlegungen automatisch abnehmen, ohne dass du dich darum kümmern musst.
niemals vergessen:
"premature optimization is the root of all evil"

das nur am rande, ich komme eigentlich aus der "stations-baiserten" entwicklung (C++ et. al.) und kann dir von solchen überlegungen, wie du sie hsat, nur erzählen, dass es in den meisten fällen verschwendete zeit ist, sich über sowas (v.a. zum frühen projekstadium!) gedanken zu machen.
erst mal die bottlenecks wirklich (!) analysieren und profilen, dann eingreifen - aber vorher schon philosophieren ist verschwendete zeit...

Beitrag von **Airport1** » 04.08.2007, 11:48

> wenn du dreistellige (!) zahlen verarbeiten willst, wird dir ein char nicht viel helfen

nein, kein denkfehler. in meinem fall wird die zahl je stelle max. 100 gross. kann also wunderbar in einen 8bit char abgebildet werden. eigentlich sogar in 7bit

> da ein char max. zahlen von einer grösse bis max. 255/256 aufnehmen kann.

unnuetz das jemand zu sagen, der aufm 64er in assembler demos schrieb. ich weiss schon bescheid, was ich dem 64er zu verdanken habe

es handelt sich nicht um eine webapplikation.

das projekt ist aber eh abgeschlossen, einfach fertig.

im nachhinein muss man natuerlich sagen, die frage ob int und char nun schneller ist, hat nun gar nicht soviel dazu beigetragen, nur minimal. aber ich fand die frage einfach zu sehr interessant

Beitrag von **johngrinder** » 04.08.2007, 14:19

aber:
heutige compiler sind eh gut genug, dass sie bestimmte optimierungen selbständig vornehmen:
kann also gut sein, dass der compiler aus der von dir als char deklarierten variable automatisch ein int macht... einfach mal in den output reingucken.