byterechner() - Bytes in größtmögliche Einheit umrechnen

[ts-soft]

@AND51
NbDecimals funktioniert aber nicht

[AND51]

Ich arbeite dran...
Liegt daran, dass ich in einem einzeiler versuche, Dezimalstellen auszuschalten, wenn byte < 1024 ist.



Edit: So, jetzt müsste es gehen und ich kann den Titel als Spitzenreiter behalten:

Code: Alles auswählen

Procedure.s byterechner(byte.q, NbDecimals.c=0)
   Protected bytes.d=PeekQ(@byte), unit.c=1
      While unit < 6 And bytes > 1023
         bytes/1024
         unit+1
      Wend
      ProcedureReturn StrD(bytes, NbDecimals*(unit > 1 And 1))+" "+StringField("Byte,KB,MB,GB,TB,PB,EB", unit, ",")
EndProcedure

#k=4096
For n=0 To 7
	Debug byterechner(#k, n)
Next

• Nur 8 Zeilen

[Kaeru Gaman]

> indem ich >= 1024 durch > 1023 ersetze. Rein theorethisch müsste diese Ersetzung sogar einen -wenn auch minimalen- Performanceschub bringen, oder?

ich hatte die tage erst festgestellt, dass ein > anscheinend sogar langsameer ist als ein >=...

aber das war eine nebenbeobachtung, als es um etwas anderes bei ner performance-messung ging,
muss also nicht allgemeingültig sein.

grundsätzlich ist wichtig, in was für ASM-commands das übersetzt wird,
nicht wieviele zeichen im Quellcode stehen.

PS:
warum bestehst du darauf, NbDecimals und unit als CHAR zu benutzen?
du lässt es in einen ausdruck einfließen, nämlich

Code: Alles auswählen

NbDecimals*(unit > 1 And 1)

generell, wenn du kleine typen in eine multiplikation packst, musst du sehr vorsichtig sein, dass vor dem ergebnis kein overflow passiert.
außerdem...

Code: Alles auswählen

(unit > 1 And 1)

And ist logisch, nicht Bitwise. Bitwise-And wird "&" geschrieben.
...irgendwie raff ich den ausdruck grad net... o_O ..vielleicht sollt ich ersma siesta machen....

[AND51]

Aha, interessant!

Ich will's nicht abstreiten, aber logisch gedacht muss bei > 1023 nur auf eine bedingung geachtet werden, nämlich, ob die zahl größer ist.

Bei >= 1024 muss hingegen auf > 1024 und auf = 1024 geachtet werden.

Das ,üsste normalerweise langsamer sein, oder? Wie gesagt, es soll nicht daran scheitern und ich will mich auch nicht dran hochziehen

[Kaeru Gaman]

jain, das kommt drauf an, wie es umgesetzt werden kann.

das kommt allein darauf an, welche Flags von welchen Vergleichsbefehlen wie gesetzt werden.

konkret kann ich nicht sagen, wie es geht, aber ich weiß, dass in ASM dinge oft ganz anders aussehen...

[AND51]

Code: Alles auswählen

(unit > 1 And 1) 

And ist logisch, nicht Bitwise. Bitwise-And wird "&" geschrieben.
...irgendwie raff ich den ausdruck grad net... o_O ..vielleicht sollt ich ersma siesta machen....

Und ich verstehe dieses ganze "Harmose zeug" mit den Bits nicht...

ich glaube, dafür bin ich noch zu klein

[NicTheQuick]

Normalerweise ist =, <>, <=, >=, > und < in ASM jeweils ein Befehl und
wird auch in einem Rechenschritt ausgeführt, vorrausgesetzt beide
Vergleichsausdrücke sind 32 Bit groß. Ein a.b = b.l wird also wahrscheinlich
nicht so schnell sein wie ein a.l = b.l.

Wegen dem PeekQ(Parameter.q) weiß ich auch nicht so genau. In meiner
Datenbank geht es auch nur mit PeekQ(Parameter.q), aber in dem
Byterechner da oben geht es nicht anders als so.

[Kaeru Gaman]

Normalerweise ist =, <>, <=, >=, > und < in ASM jeweils ein Befehl und
wird auch in einem Rechenschritt ausgeführt.

yo, so in der richtung ging meine überlegung.

beispiel:

angenommen, in Besambler wäre >= ein einziger Befehl,
und > gäbe es nicht als eigenständigen Befehl,
dann müsste für > noch ein Increment oder ein NOT= geschaltet werden.

...darum ging es mir. man kann nichts aussagen über die performance von ausdrücken,
solange man nicht weiß, wie sie im endeffekt bei der CPU landen.

[ts-soft]

Solange keine Progressbar erforderlich ist , spielt es wohl eher
eine untergeordnete Rolle

[Kaeru Gaman]

hä?

was hattn jetzt Radio Eriwan mit der Chinesischen Kulturrevolution zu tun?