Du bist nicht angemeldet.

Stilllegung des Forums
Das Forum wurde am 05.06.2023 nach über 20 Jahren stillgelegt (weitere Informationen und ein kleiner Rückblick).
Registrierungen, Anmeldungen und Postings sind nicht mehr möglich. Öffentliche Inhalte sind weiterhin zugänglich.
Das Team von spieleprogrammierer.de bedankt sich bei der Community für die vielen schönen Jahre.
Wenn du eine deutschsprachige Spieleentwickler-Community suchst, schau doch mal im Discord und auf ZFX vorbei!

Werbeanzeige

killmichnich

unregistriert

1

16.10.2009, 14:24

Größe von Variablen festlegen?

Hiho,
wir programmieren zur Zeit an unserem Roboter rum, der Fußball spielen kann (habt ihr bestimmt schon gehört mit dem Robo Soccer und so ...).
Dabei haben wir natürlich keine so großartige Ausrüstung an Hardware wies jetzt so in nem normalen PC gibt, heißt wir haben glaub ich so 16 MHz Prozessor ... ^^
Und da ist jetzt unser Problem, dass das Ding immer langsamer wird, und wir uns überlegt haben, ob wir nich Rechenzeit einsparen können indem wir einfach Variablen verkleinern, weil wir meistens eh nur Werte bis 255 brauchen.
Und genau da liegt meine Frage: Wir kriegt man denn sowas hin, dass ne Variable z.B. nur 1 Byte groß is statt wie bei int, das ja meines Wissens nach 4 Byte hat. Ich hab schon mal gelesen, dass eine Variable vom Typ char nur 1 Byte groß ist, und mit der kann man (denk ich mal) ja auch rechnen. Die Frage wäre dann nur, wie das ganze mit Fließkommazahlen funktionieren soll, weil man da ja dann keine Kommazahl speichern kann.

Also das ganze nochmal konkret: Wie kann ich, z.B. eine Variable vom Typ float, dazu bringen, dass sie nur 1 Byte und halt dementsprechend weniger Nachkommastellen hat, ohne großartig andere Bibliotheken verwenden zu müssen?

Ich hoffe ihr versteht mein Problem und könnt dabei auch helfen ... ^^

MfG Killmichnich

Sylence

Community-Fossil

Beiträge: 1 663

Beruf: Softwareentwickler

  • Private Nachricht senden

2

16.10.2009, 14:37

Wenn ihr nur mit chars rechnet, dann könnte es unter umständen eher langsamer werden. Je nachdem wie groß ein Prozessorregister ist.

Solche low level optimierungen bringen sovie in 99% der fälle keinen nennenswerten (oder auch messbaren) verbesserungen.

Ihr müsst weiter oben ansätzen. Soll heißen algorithmen optimieren.

3

16.10.2009, 17:02

Re: Größe von Variablen festlegen?

Zitat von »"killmichnich"«

Und da ist jetzt unser Problem, dass das Ding immer langsamer wird, und wir uns überlegt haben, ob wir nich Rechenzeit einsparen können indem wir einfach Variablen verkleinern, weil wir meistens eh nur Werte bis 255 brauchen.
Wie schon angetönt solltet ihr nicht nur überlegen, sondern messen. Nehmt einen Profiler zur Hand und schaut, was die meiste Rechenzeit braucht. Einfache Zeitmessungen tuns zur Not auch. Auf jeden Fall sind Fakten besser als Vermutungen, besonders bei Mikrooptimierungen.

1-Bit-Fliesskommazahlen wären recht ungenau. Ich denke auch nicht, dass viele Prozessoren Befehle für 1-Bit-Fliesskommaarithmetik kennen.

Was heisst eigentlich "immer langsamer"? Während der Laufzeit allmählicher Performanceverlust? Oder langsamer, je mehr Features ihr hinzufügt?

4

16.10.2009, 20:22

Bei einem Byte würde ich niemals mit Fließkommazahlen Rechnen. Man kann ja auch einfach definieren, dass die ersten 3 Byte die Zahl vor dem Komma, und die hinteren 5 die nach dem Komma sind.
Ansonsten hängt es halt stark vom Prozessor ab, es ist gut möglich, dass ihr zwar mit kleinere Variablen Speicher spart, aber keine Geschwindigkeit (oder sogar welche verliert), weil der Prozessor nur mit größeren Variablen rechnen kann und alles implizit konvertiert. (Oder das trotzdem grundsätzlich 4 byte übertragen werden, davon dann aber nur 1 genutzt wird, oder oder oder, so genau hatten wir das noch nicht).
Lieber dumm fragen, als dumm bleiben!

killmichnich

unregistriert

5

17.10.2009, 09:15

hmmm ok ich glaub das is schonmal ne ganz große hilfe, thx =)

@Nexus: es wird immer langsamer je mehr wir dazu programmieren.
Wir haben mal nen Test gemacht, das Ding erst mal so gerade aus fahren zu lassen und danach mit unserem Programm dem Ball hinterher ... und da gibts schon nen kleinen Unterschied ... .

Das mit dem nachmessen wie langs braucht machen wir aufjedenfall auch noch =)

Es is halt die Sache, dass unsere Sensoren nur einen Wert bis 255 zurückgeben und die Motoren nur einen Wert bis 255 akzeptieren ... deshalb ham wir uns gedacht wär da ja 1 Byte grad gut ... ^^

Edit: Und es ging auch darum, dass ja das Dividieren anscheinend länger zum rechnen braucht, als der Rest, weswegen wirs eben iwie schaffen wollten, nur bis x stellen nach dem komma zu rechnen, damit das nicht zu genau wird und länger braucht?

FalkT

Treue Seele

Beiträge: 125

Wohnort: AC

  • Private Nachricht senden

6

17.10.2009, 14:53

Zitat von »"killmichnich"«

Edit: Und es ging auch darum, dass ja das Dividieren anscheinend länger zum rechnen braucht, als der Rest, weswegen wirs eben iwie schaffen wollten, nur bis x stellen nach dem komma zu rechnen, damit das nicht zu genau wird und länger braucht?


Naja ... wenn das der Grund ist, dann müßte ihr wohl aufs divieren verzichten !
Insbesondere wenn man durch konstante Werte teilt, lassen sich viele Sachen tricksen, z.B.:

C-/C++-Quelltext

1
2
3
int a = x / 2;  // sehr nett :D

int a = x * 0.5; // definitiv schneller

int a = x >> 1; // auch schnell


Ansonsten gibts noch ein paar andere Tricks oder sogar spezielle Math-Libs für eure Zwecke.
oder selbst-erstellte Lookup-Tables ...

Ein bißchen mehr über C lernen, könnte auch nicht schaden.
Geht damit los das manche Systeme überhaupt keine dynamische Speicherverwaltung (performant) können.

idontknow

unregistriert

7

17.10.2009, 15:11

Standardmäßig kann die CPU bestimmter Microcontroller weder multiplizieren noch dividieren, ist also keine Grundfunktion die die ALU beherrscht!

Daher würde ich dividieren mit Multiplikation umgehen sollte deutlich schneller sein!

8

17.10.2009, 15:36

Zitat von »"idontknow"«

Standardmäßig kann die CPU bestimmter Microcontroller weder multiplizieren noch dividieren, ist also keine Grundfunktion die die ALU beherrscht!

Daher würde ich dividieren mit Multiplikation umgehen sollte deutlich schneller sein!
Ah, weil Multiplikation keine Grundfunktion ist? :p

Division kann man lange nicht immer durch Multiplikation implementieren. Das geht nur in einfachen Spezialfällen mit vorher bekannten Konstanten (statt halbieren mit 1/2 multiplizieren).

killmichnich

unregistriert

9

17.10.2009, 16:00

Zitat von »"Nexus"«

(statt halbieren mit 1/2 multiplizieren).

Macht der Prozessor da wirklich nen Unterschied?
Ich bin mal davon ausgegangen, dass wenn ich was durch 2 teile das genauso lang braucht als würd ichs mit 0.5 multiplizieren? ôO

David_pb

Community-Fossil

Beiträge: 3 886

Beruf: 3D Graphics Programmer

  • Private Nachricht senden

10

17.10.2009, 16:18

Zitat von »"killmichnich"«

Zitat von »"Nexus"«

(statt halbieren mit 1/2 multiplizieren).

Macht der Prozessor da wirklich nen Unterschied?
Ich bin mal davon ausgegangen, dass wenn ich was durch 2 teile das genauso lang braucht als würd ichs mit 0.5 multiplizieren? ôO


Ja, das macht oft einen Unterschied. Du kannst häufig davon ausgehen das Divisionen (wesentlich) teurer sind als Multiplikationen (Spezialfälle wie */ 2^n mal aussen vor gelassen). Zum Beispiel wird eine skalare Division für Vektoren häufig wie folgt implementiert:

C-/C++-Quelltext

1
2
3
4
5
6
7
8
9
10
11
12
13
Vec3& operator/=( float f )
{
  // sonderfall wenn f == 0 beachten...


  float invf = 1.0f / f;
  x0 *= invf;
  x1 *= invf;
  x2 *= invf;

  // ...


  return (*this);
}


Einfach um zumindest einige der Divisionen durch Multiplikationen zu ersetzen.

Werbeanzeige