Seite 2 von 6
Verfasst: 11.10.2006 14:39
von ts-soft
@AND51
NbDecimals funktioniert aber nicht
Verfasst: 11.10.2006 14:44
von 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
Verfasst: 11.10.2006 14:47
von 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
generell, wenn du kleine typen in eine multiplikation packst, musst du sehr vorsichtig sein, dass vor dem ergebnis kein overflow passiert.
außerdem...
And ist logisch, nicht Bitwise. Bitwise-And wird "&" geschrieben.
...irgendwie raff ich den ausdruck grad net... o_O ..vielleicht sollt ich ersma siesta machen....
Verfasst: 11.10.2006 14:50
von 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
Verfasst: 11.10.2006 14:54
von 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...
Verfasst: 11.10.2006 14:56
von AND51
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
Verfasst: 11.10.2006 15:17
von 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.
Verfasst: 11.10.2006 15:22
von Kaeru Gaman
NicTheQuick hat geschrieben: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.
Verfasst: 11.10.2006 15:29
von ts-soft
Solange keine Progressbar erforderlich ist
, spielt es wohl eher
eine untergeordnete Rolle
Verfasst: 11.10.2006 15:31
von Kaeru Gaman
hä?
was hattn jetzt Radio Eriwan mit der Chinesischen Kulturrevolution zu tun?