ABAKUS

Falls es wen noch interessiert:

Habs eben nachgemessen; jeweils ne doppeltverschachtelte Schleife ueber ein char Array und ein int Array laufen lassen, gleiche Laufanzahl 10000000000, beide waren gleich schnell und brauchten 56 Sec auf einem Dual Inspiron 8600b.

Wieder ein Mythos zerstoert: int ist nicht schneller, und wenn dann nur seeehr marginal. Oder der Compiler hat mich betrogen

Laufzeiten auf nem Aldi PC Medion 8800, gleiche .exe, single cpu mode, 2.8 ghz:

*int bzw. int[]: 43 sec
*char bzw. char[]: 39 sec

Dort ist char also sogar ca. 10% schneller. Wunder.

In vielen Foren werden demnach falsche Behauptungen aufgestellt ("int ist natuerlich schneller, weil... 32bit... bla...").

So, jetzt ists wenigstens mal gemessen worden.
Alles muss man selber machen

Es kommt immer drauf an, auf welchem Rechner eine Software läuft, welche Prozessorarchitektur und welche Programmiersprache verwendet wird, und noch einige andere Kriterien.

Aber eigentlich ist eine z.B 16 Bit Zahl immer schneller als eine 32 Bit, da auch immer nur 16 Bit bei der 16 Bit Zahl vom Prozessor verarbeitet werden müssen.

Heutige Prozessoren sind in der Regel in der 32bit-Welt zu Hause, manche 64bit. Der Clou ist aber dass vielerorts behauptet wird, dass int SCHNELLER SEIN MUESSTE als ein char, da ja die Rechnerarchitektur meist auf 32bit werkelt. Dem ist offensichtlich ueberhaupt nicht so. Natuerlich gibt es Differenzen von Maschine zu Maschine. Aber mir ist bisher noch keine untergekommen die bei *int vs. *char , beide unsigned, fur int[] schneller gewesen waere. Damit sehe ich diese oftmalig geaeusserte Behauptung i.d.R. obdA als definitiv falsch an

Auch ich dachte zunaechst ein 32bit int muesste schneller sein als ein 8bit char.. gut also dass wir gemessen haben

vielleicht ist das von Sprache zu Sprache unterschiedlich? Poste doch mal deinen Testcode...

Naja, meine Messung war ja fuer C. Da wahrscheinlich fast alle Hochsprachen auf C aufbauen, bzw. C als Basis nutzen, muessten selbige ja fast zwangsweise dem selben "Lemma" unterliegen Das ueberpruefe ich aber nicht, das koennen andere machen.

Natuerlich kann das Ergebnis aber sehr compiler-abhaengig sein. Ein suboptimaler Compiler kann es durchaus fertig bringen, dass andere Ergebnisse herauskommen. Oder ein Compiler der sehr bis zu gut optimiert, wird evtl. einen Datentyp durch einen anderen ersetzen, je nachdem..

Den Testcode hab ich laengst wieder verworfen, war ne doppelt verschachtelte Schleife die jeweils auf einem *int und einem *char etwas rumgealbert ("do something") hat.. davor und danach je ein time_t ctime fuer die Zeitmessung..

Jetzt koennten eingefleischte natuerlich behaupten: du hast ja gar nicht die CPU Zeit gemessen.. aber mir gings auch gar nicht darum.. nur was schneller ist.. also nur um eine Relation zu finden..

Wenn du nen geilen Compiler hast, lagert der ggf. sogar unabhängige Berechnungen auf die FPU aus um einen höheren Parallelitätsgrad zu erreichen.
Deine Frage ist quasi nur unter Laborbedingungen auf einem sehr engen Fokus vernünftig zu beantworten.
Bei allem anderen dürfte eher die Struktur Deines Programmes eine Rolle spielen, als so synthetische Konstrukte.
Also wenn Du was beschleunigen willst finde erstmal die Stellen, die den tatsächlichen Flaschenhals darstellen - nachdem ein Prototyp der Software existiert, der ruhig mega inperformant sein darf.
Just my 2 cent

Wenn die Programmierumgebung das erlaubt, würde ich den Inline Assembler bei den Routinen verwenden, die schnell sein MÜSSEN!

Als ich damals mal einen Verschlüsselungsalgorthmis (Block Cipher) in C entwickelt hatte, war sehr sehr wohl schneller, umso weniger Bits auf einmal verarbeitet wurden.


Auf der untersten Ebene (Maschinencode) kommt es ja auch immer drauf an, wieviel Rechenschritte benötigt werden, um etwas zu machen (Addition, Subtraktion, Vergleich...etc)

> Also wenn Du was beschleunigen willst finde erstmal die Stellen, die den tatsächlichen Flaschenhals darstellen

everflux, das ist mir schon klar, dazu setze ich bei Bedarf dann versch. Profiling/Monitoring Tools ein.

In diesem speziellen Fall gehts aber um relativ viele viele (zu viele!) Rechenoperationen auf einem Array, und da fragte ich mich halt: rechtfertigt die 32Bit Architektur es int zu benutzen, was 4mal mehr Speicher verbraucht (aber angeblich schneller sein soll) als ein char. Ist char wirklich langsamer als int? Heraus kam dann eben dies.

> Auf der untersten Ebene (Maschinencode) kommt es ja auch immer drauf an, wieviel Rechenschritte benötigt werden, um etwas zu machen (Addition, Subtraktion, Vergleich...etc)

Das Assembler bzw. Maschinencode natuerlich ggf. noch schneller waere mag sein. Ich komme auch urspruenglich aus der Assembler-Ecke was z.B. dazu fuehrt dass ich immer noch versuche moeglichst viele Null-Vergleiche zu machen oder Schleifen rueckwaerts statt vorwaerts laufen zu lassen.

Auf dem C64 musste bei 1 MHz eben jeder Taktzyklus gespart werden. Solche heute natuerlich eher "Mini"-Optimierungen bekommst Du ein Leben lang nicht mehr aus dem Kopf, und das ist gut so

> Wenn die Programmierumgebung das erlaubt, würde ich den Inline Assembler bei den Routinen verwenden, die schnell sein MÜSSEN!

Inline Assembler setzte ich zuletzt bei Turbo Pascal ein. War auch ne sehr schoen strukturierte Sprache, eigentlich.

Wird jetzt aber sehr off topic. Bei Bedarf den Thread Titel lesen: es ging urspruenglich darum ob in C int oder char-Array-Operationen schneller sind

Airport1 hat geschrieben:Nun habe ich mir ueberlegt: mit char verbrauche ich weniger Speicher, aber eigentlich sind die heutigen Maschinen fuer int gebaut (32bit..), muesste dann evtl. int schneller sein als char, da die Maschine sowieso immer 4 Byte in den Speicher reinzieht?

Wieso schneller, gleich schnell wäre die richtige Schlussfolgerung, wenn man den Einzelfall betrachtet.

Deine Char-Version ist deshalb schneller, weil Du 4 Chars (4x8bit) zur Zeit bearbeiten kannst, statt nur ein 32-bit Int. Das gilt aber wahrscheinlich nur bei zusammenhängenden Speicherbereichen (...Array). C-Compiler sind in Sachen Optimierung inzwischen sehr mächtig, die werden ja auch schon seit Jahrzehnten weiterentwickelt.

Allein _wie_ unterschiedlich AMD und Intel Prozessoren intern arbeiten sollten diese Frage direkt obsolet machen.
In der Regel holst du wesentlich mehr Speed raus, wenn Du Dir einen besseren Algorithmus überlegst, oder Zwischenergebnisse (falls möglichst) irgendwo hinpackst und Speicherbedarf gegen Rechenzeit tauschst.
Auch die verschieden großen Caches/Cachearchitekturen dürften da ein paar Worte mitzureden haben.

Ich würd sagen: Machs in einer Hochsprache wie Java und laß es sich selbst zu Laufzeit da optimieren wo es auch lohnt, oder denk nochmal über den Problemansatz nach, wenn es so schäbig is.

> Ich würd sagen: Machs in einer Hochsprache wie Java

Ich weiß nicht, ob Java da wirlich so optimal ist. Wenn es schnell und Prozessorunabhängig sein soll, ist C IMHO immer die Hochsprache der Wahl. Gerade wenn man auf Puffern herumreitet. Ich würde auch gar nicht erst versuchen, das mit Inline-Assembler zu optimieren. Dazu bräuchte man schon eine Menge Erfahrung.

Ach wieso nicht?
Es gibt ja schon Beispiele, wo ein Java-Programm genau bei einer ähnlichen Aufgabenstellung schneller war, als ein äquivalentes C Programm.
Davon abgesehen habe ich in Java (oder bspw. auch .net) die Möglichkeit, sehr einfach eine multithread Anwendung zu schreiben. Wenn sich die Aufgabe gut parallelisieren läßt bringt mir das auf einer 2 oder 4 Kern Maschine einen entsprechenden Geschwindigkeitsvorteil, der selbst wenn das Javaprogramm selber etwas weniger schnell ist, als ein C Programm, diesen möglichen Nachteil mehr als aufwiegt.
Ganz davon abgesehen könnte ich die Anwendung wesentlich leichter verteilen und Teilaufgaben auf verschiedenen Maschinen rechnen.

Von Assembler würde ich aber auch wirklich Abstand nehmen.