nicht angemeldet
Moin Martin!
Das kann man machen, du weißt aber schon, dass es auf 32-Bit-Computern deutlich schneller ist, auf je 4-Byte zuzugreifen als auf eines.
Das ist nicht richtig. Zumindest bei x86-CPUs braucht ein BYTE-Zugriff exakt genausoviele Taktzyklen wie ein DWORD-Zugriff.
Wie denn das? Fahren da nicht bei einem Befehl immer 32 Bit Daten mit dem Bus?
Im Gegenteil: Ein DWORD-Zugriff kann sogar länger dauern, dann nämlich, wenn die Adresse nicht durch 4 teilbar ist.
Sollten „intelligente“ Compiler™ (bzw. Speicher-Allokatoren) nicht automatisch die Daten dem entsprechend zur Verfügung stellen?
Es gibt also keine Rechtfertigung, byteweise strukturierte Daten auf DWORD aufzublähen und dadurch das Vierfache an Speicher zu verschwenden wie eigentlich nötig.
In wie fern macht sich das denn bemerkbar, wer benutzt also schon genug DWORDs (in ISO C99 heißt das uint32_t) anstelle von BYTEs (aka. uint8_t)?
Zu deinem Problem an dieser Stelle: Warum nimmst du keine union:
typedef union {
BYTE b;
DWORD d;
} dword_byteweise;
dword_byteweise db;
/* Mit db.b = … kannst du nun ein BYTE speichern und mit db.d als
* DWORD wieder auslesen.
*/
Ansonsten denke ich, dass eine Geschwindigkeitsoptimierung sinnvoller ist.
ACK. Aber das, was du vorschlägst, ist keine Geschwindigkeitsoptimierung.
OK, mit DOSen kenne ich mich nicht so aus. Die Aussage, das Programme signifikant schneller wurden, als man bool in einen int der für die Plattform typische Größe zu packen (d.h. auf 32-Bittern steht irgendwo typedef int bool), stammt nicht von mir, sondern aus dem Buch von Stroustrup.
Ich weiß, wenn jeder Programmierer denkt „heutige Rechner sind schnell genug“, hat der Anwender im Endeffekt wieder nichts davon, aber die Verhältnisse müssen meiner Meinung nach stimmen.
Was für Verhältnisse?
Damit meine ich fragwürdige Optimierungen, die mir 5 Byte Hauptspeicher (siehe auch oben) und zweihundert Taktzyklen (so schnell kann man noch nicht mal blinzeln) sparen.
Das Problem, das du ansprichst, ist mir durchaus geläufig. Ich habe es bisher immer "elektronische Inflation" genannt: Die Programmierer gehen verschwenderisch mit den Ressourcen um, weil sie ja zur Verfügung stehen, und die Rechnerhersteller sehen den Bedarf für immer mehr Speicher und Rechenleistung, weil aktuelle Applikationen aufgrund der Faulheit der Programmierer die Maschinen bis an die Grenze belasten. Ich würde es begrüßen, wenn sich wieder mehr Programmierer dieses Dilemmas bewusst würden.
Wieso denn? Inflation ist doch eine praktische Sache, auch in der Volkswirtschaft, weil es dem Kunden schmackhaft gemacht wird, seine wertloser werdenden Güter/Computer durch neuere zu ersetzen, d.h. sparen ist uncool. Wenn die Programmierer verantwortlich mit den Rechnerressourcen umgingen, gäbe es nicht ca. alle drei Jahre das Bedürfnis nach einem neuen, leistungsfähigeren Computer. Und die Programmierer freuen sich darauf, dass sie wieder mehr Speicher, mehr CPU-Zeit (und mehr Farben) zum Ausfüllen haben. Das ganze ist ein toller Kreislauf für alle, die mit Computern Geld verdienen.
Viele Grüße,
Robert
Der Martin