Seite 3 von 3

Re: LONG oder INTEGER

Verfasst: 22.10.2013 14:20
von _JON_
Habe mal mein Desktop PC gemessen

Idle: 89 Watt
Standby 13 Watt

während er bootet bis zu 137 Watt, aber das dauert ja keine 15 Sekunden mit der SSD hier.
Also in meinem Fall wäre ausschalten sinnvoller.

Re: LONG oder INTEGER

Verfasst: 22.10.2013 14:48
von Thorium
auser hat geschrieben:
Thorium hat geschrieben:Das Problem hätten wir allerdings nicht, wenn wir unsigned Integer hätten. ^^
Das Problem ist nicht + / - sondern daß man mit 4 bytes nicht unendlich lange Milliseconds zählen kann und so ein Umbruch unweigerlich ist (schlimmstenfalls machst du dir beim Umbruch mit unsigned sogar noch größere Probleme). Umgehen könnte man das Problem wenn man eine OS-Funktion verwendet die einen 8 byte Wert zurück gibt... dann sollte das Problem wirklich so weit in der Zukunft liegen daß man es ignorieren kann.
Natürlich ist ein Umbruch unweigerlich aber der wird dann in beiden Fällen auf 0 umbrechen.
Man kann es auch mit signed so programmieren das es kein Problem ist ob Long oder Quad. Man muss ja nur prüfen ob Bit 31 gesetzt ist. Ist aber mit unsigned viel einfacher, da es dort nach 32bit auf 0 umbricht egal ob unter x86 oder x64.

Re: LONG oder INTEGER

Verfasst: 22.10.2013 19:54
von auser
Thorium hat geschrieben: Natürlich ist ein Umbruch unweigerlich aber der wird dann in beiden Fällen auf 0 umbrechen.
Man kann es auch mit signed so programmieren das es kein Problem ist ob Long oder Quad. Man muss ja nur prüfen ob Bit 31 gesetzt ist. Ist aber mit unsigned viel einfacher, da es dort nach 32bit auf 0 umbricht egal ob unter x86 oder x64.
Hast du da ein Beispiel (gern auch in C/C++ wenn das mit unsigned weiter hilft)? Wie prüfst du da ohne großen Aufwand ob der Timeout wirklich erreicht ist (ohne daß er beim Setzen vom Timeout über den Umbruch hinaus sofort in Kraft tritt - was ja eigentlich auch nicht Sinn der Sache wäre)?

Re: LONG oder INTEGER

Verfasst: 22.10.2013 20:02
von auser
STARGÅTE hat geschrieben:Leider bemerke ich diese Trand auch, dass Leute ihre PC mit Ruhezustand/Standby quälen.
Ja... die konspirieren womöglich alle mit der NSA. :wink: Schließlich weiß jeder daß die Amis nach uns aufstehen. Und damit die sich beim Frühstücken nicht so stressen müssen gibt's halt jetzt als Default überall Standby und UEFI mit eingebautem Netzwerkstack der unabhängig vom Betriebsystem funzt. /:->

Re: LONG oder INTEGER

Verfasst: 23.10.2013 07:54
von Thorium
auser hat geschrieben: Hast du da ein Beispiel (gern auch in C/C++ wenn das mit unsigned weiter hilft)? Wie prüfst du da ohne großen Aufwand ob der Timeout wirklich erreicht ist (ohne daß er beim Setzen vom Timeout über den Umbruch hinaus sofort in Kraft tritt - was ja eigentlich auch nicht Sinn der Sache wäre)?
Code habe ich grad keinen aber du musst prüfen ob der neue Rückgabewert kleiner als der alte ist. Wenn ja, ist die Variable übergelaufen und du musst die Differenz entsprechend berechnen. Bei Unsigned wäre das $FFFFFFFF - AlteZeit + NeueZeit. Das ist die zeitliche Differenz zwischen neuer und alter, wenn es einen Überlauf gab berechnet mit unsigned.

Re: LONG oder INTEGER

Verfasst: 20.04.2016 17:27
von #NULL
ich hab ne frage dazu
ich hab nen alten code mit etlichen expliziten long deklarationen, also '.l' die ich gerade auf implizit integer (ohne typangabe) umstellen will. bei variablen scheint das sinnvoll. jetzt weiß ich aber nicht wie das in Strukturen ist. dort habe ich meistens .l verwendet, für einiges aber aus speichergründen .w oder .b.
ist das sinnvoll? oder sollte ich hier auch einfach alles mit .i durchdeklarieren? ich meine gelten die performance vorteile von integer auch genauso für strukturfelder?
es geht um selbstdefinierte strukturen, die nicht mit irgendwas kompatibel sein müssen.

Re: LONG oder INTEGER

Verfasst: 20.04.2016 18:42
von STARGÅTE
In der Wortgröße des Prozessors zu arbeiten ist immer schneller.
Soll heißen, es ist immer schneller Variablen und/oder Strukturfelder als Integer zu definieren wenn es möglich ist.
Auch sollte der Offset der Felder immer ein vielfaches der Wortgröße sein damit die Adresse des Feldes passend ist.

Wenn eine Struktur nicht in einem z.B. Array verwendet wird, sollte man immer Integer verwenden.
Aus Speicherplatzgründen ist es aber durchaus auch sinnvoll Word oder Byte zu verwenden, dann aber wieder folgende Sachen berücksichtigen:
- Die Strukturgröße sollte komplett trotzdem ein Vielfaches von Integer sein, damit der Offset der Arrayfelder weiterhin passend ist.
- Word und Byte felder möglichst weit am Ende der Struktur platzieren, damit der Offset der Strukturfelder möglichst wenig Einfluss auf die anderen Felder hat. Hier kann mann auch das Schlüsselwort Align verwenden, um die Felder "auszurichten", dann geht aber wieder der Speicherplatz "verloren".

Ideal wäre z.B. zwei Words hintereinander zu definieren oder 4 Bytes halt, bzw. zwei Longs wenn die Wortgröße 8 Byte beträgt.

Re: LONG oder INTEGER

Verfasst: 20.04.2016 20:14
von mk-soft
Die Diskussion über ElapsedMilliseconds() gab es schon sehr oft.

Den Prozessor ist bei einer Addition egal ob es zu eine überlauf führt. Es wird dann zusätzlich das Überlauf Bit in den Status-Register gesetzt.
Das Ergebnis ist trotzdem richtig. Um die Differenz zwischen zwei Zeiten zu berechnen sind somit die beiden Zeiten einfach zu subtrahieren und das Überlauf Bit ist zu ignorieren.
Also einfach mit Long (Bei PB immer Signed) rechnen.

Die maximale Differenz zwischen zwei Ereignissen darf aber, wenn ich mich nicht verrechnet habe, nicht über 49 Tage liegen

Code: Alles auswählen

Debug $FFFFFFFF / 1000 / 60 / 60 / 24
Der vergleich auf die Differenz muss aber Unsigned durchgeführt werden, es sei denn man kommt mit der hälfte der Zeit (Differenz bis $7FFFFFFF) aus.
:wink:

Re: LONG oder INTEGER

Verfasst: 25.04.2016 17:49
von #NULL
danke stargate für die infos!

string-felder sind dann (wie andere pointer) sowieso immer integer nehme ich an. nur bei direkt enthaltenen unterstrukturen ohne pointer muss man halt wieder hingucken..

Code: Alles auswählen

Structure S2
  b.b
EndStructure

Structure S1
  s.s       ; int
  *b1.S2    ; int
  b2.S2     ; 1
EndStructure

Debug SizeOf(S1)
Debug SizeOf(S2)