Vb.Net 27 x schneller ?!

[mull]

Gut, hört sich dramatisch an und ich will nichts schlecht reden.

Dieser simple Sortiercode Code:

DIM A[10000]
FOR I = 0 TO 10000-1
   A = 10000 - I
NEXT

      T = GETTIMERALL()
      FOR I = 0 TO 10000 - 1
         FOR J = I TO 10000-1
            IF A > A[J]
               A[0] = A ; A = A[J] ; A[J] = A[0]
            ENDIF
         NEXT
      NEXT
     
PRINT (GETTIMERALL()- T)/1000, 10,50
SHOWSCREEN    
KEYWAIT

Dauert bei mir knapp 6 Sek., der gleiche Code mit Double Variablen in VBNet 0, 22 Sek.
Warum ist der Unterschied so gewaltig ?
Habe ich was übersehen oder wird bei so was in VB Assembler Code benutzt ?

[Schranz0r]

0,22 sec..... scheint mir eine recht otopische Zahl zu sein

[Kitty Hello]

evtl. weil 'i' und 'I' was anderes is in GLBasic?
Nein, im Ernst. Wie hast Du A definiert? Kannst Du 'A' redimensionieren? (REDIM PRESERVE), oder ist's ein statisches Feld? Die sind tatsächlich schneller.

[mull]

Hier der Orginal VbNet Code, mit Redim.
Fakt ist, dies geht bei mir knapp unter 0,2 Sek.

Dim A(1000) As Double
      ReDim A(10000)
      Dim I%, J%, T%

      For I = 0 To 10000
         A(I) = 10000 - I
      Next
      T = Environment.TickCount
      For I = 0 To 10000 - 1
         For J = I To 10000
            If A(I) > A(J) Then
               A(0) = A(I) : A(I) = A(J) : A(J) = A(0)
            End If
         Next
      Next
      Label1.Text = ((Environment.TickCount - T) / 1000).ToString + " sek. sortieren"

[mull]

Mit der neuen Version ist das Beispiel ca. 23% schneller geworden.
Brauch jetzt 4,4 Sek , statt 6 Sek.

Weiter so.

[tft]

Hi .....

Der VBNet code legt den Code als Cachable ab. Er wird nur einmal in den Processor Speicher geladen. Das bewirkt den geschwindigkeits anstieg. (Sollte es.......) Das gehört zu den internen Code Optimirungen. So wie es GFA BAsic schon zu WIN 95 Zeiten gemacht hat.

Du kannst ja mal einen Sprung in eine Funktion einfügen und schauen ob es immernoch schneller ist. Wenn ja. Ist etwas anderes daran schuld.

bei mir leuft er 2.567655

in Blitz3D mit debugger 13.0 und ohne 0.7

mach doch mal ne exe dafon und Leg es zum dounload bereit. Würde mich interesieren obs bei mir auch so ist. ... denn speed ist geil.

LIMITFPS -1
WHILE TRUE
 dtime = GETTIMER()
 fps = ((1000/dtime)+fps)/2
 delay=delay+dtime
 IF delay>500 // 1/2 sec
  delay=0
  showfps=fps
 ENDIF
 PRINT "FPS: "+showfps+" dtime:"+dtime, 0,0
 SHOWSCREEN
WEND

diese rutine macht eigentlich nichts wirklich wichtiges. Aber bringt es trotzdem nur auf 255 FPS.
Da gibt es noch einiges was Optimirungs bedürftig ist. Bei B3D komme ich auf 1455 FPS.

[D2O]

hi tft,
zum Frame ausgeben, nutzer lieber Gettimerall(), Gettimer() mist von Showscrenn zu Showscreen und die zeit wo das Flippen braucht wird nicht beachtet.
probier mal das hier:

Code (glbasic) Select Expand

LIMITFPS -1

WHILE TRUE


PRINT getfps(), 0,0
PRINT GETTIMERALL()-dtime,0,10
dtime = GETTIMERALL()
SHOWSCREEN

WEND

FUNCTION getfps:

STATIC fps_time,fps_counter,fps,fps_temp
fps_time = GETTIMERALL()
fps_counter = fps_counter + 1
IF (fps_time-fps_temp)>1000
fps_temp = fps_time
fps = fps_counter
fps_counter = 0
ENDIF

RETURN fps
ENDFUNCTIONDas sollte auch bei Dir so um die 500fps ausgeben.
Was mir aufgefallen ist, das ich nie über 500 fps komme!? (Ist das nur bei mir so?)
Aber GLB hohe Frameraten sehr gut halten kann.

Nochmals aber , wenn man Frameunabhängig programmiert, gibts oftmals etwas probleme wen die Frames über 500 liegen,
ist mir bei BB aufgefallen.
Kann vieleicht sein das sich die "Rundungen/fehler" stark bemerkbar machen.

[mull]

Hier kann das VbNet Progamm geladen werden, braucht min. Framework 2.0
http://ligapro.de\nurso\VbNetSort.exe

Habe das tauschen ( A(0) = A(I) : A(I) = A(J) : A(J) = A(0) ) in eine Function gepackt und komme trotz mehraufwand auf ca. 0.23 Sek.

[tft]

Hi ....

ja . Bei mir ist es genauso schnell.... 0.24 - 0.29

[Quentin]

hmm hört sich schon etwas seltsam an. Aber mal eine Frage: In oben gezeigtem Beispiel wird das Array ja absteigend mit den Zahlen belegt, sodaß ein Bubble-Sort ja wirklich die volle Arbeit leisten muss. Da es sich hier um konstante Werte handelt, wäre es u.U. denkbar, daß ein schlauer Optimierungsalgorhitmus des Compilers dies erkennt???

Könnte man das Beispiel mal wiederholen, indem man das Array mit Zufallszahlen zwischen 0 und 10.000 belegt? Würde mich mal interessieren, ob das einen Unterschied macht.


Zu den Werten:

der VB-Code kommt bei mir auf 0,45 sec.

der GL-Code auf 1,78

[mull]

Denke nicht das da Optimiert wird, glaube das VbNet bei Schleifen auf Assembler Code setzt.

Wenn man bei VbNet Mehrdimmensionale Felder oder Felder mit Typen hat geht die Performence etrem nach unten.
Der Code mit z.B A(1000, 0)  ist dann 5 x langsamer, obwohl die Durchläufe gleich sind.

[Quentin]

verstehe nicht ganz, was du mit Assembler-Code meinst. Letztendlich übersetzen sowohl VB als auch GL die Programme in Maschinencode, GL halt gleich beim Kompilieren und VB vor der Ausführung des Programmes, wenn ich mich recht erinnere.

könntest du es spaßeshalber mal mit Zufallszahlen versuchen? Täte mich wirklich mal interessiern. Bei GL macht es keinen großen Unterschied (1,8 Sec. statt 1,78, natürlich Mittelwert aus mehreren Durchläufen)

[Schranz0r]

Schonmal dran gedacht, das GLBasic keine --> Hochsprache <--  ist?
Und somit ist der vergleich auch wohl ein wenig Krass !

Vergleicht doch mal, PureBasic, SDLBasic, BlitzBasic, BlitzMax usw... mit GLB !
der vergleich wär gerechtfertigt.

Alleine so einen Thread zu starten, ist schon fast ne frechheit !

[trucidare]

na endlich merkt jemand das dieser thread sinnlos ist. wenn du meinst das vb.net besser ist dann bind da directx ein und schreib damit deine spiele... ich hab sämtliche sprachen durch die etwas mit open gl , directx und sdl zu tun haben und glbasic ist mit abstand einer der besten. interessant wäre ein vergleich mit einer kompilierten sprache und nicht son interpreten müll wie vb. danke fürs zuhören

[D2O]

Oops:
Aber bitte immer freundlich bleiben.