Vb.Net 27 x schneller ?!

Previous topic - Next topic

tft

Hi ...

bleibt mal alle schön locker. Jede der Basic Dialekte hat seine Stärken und schwächen. Ich kenne sie eigentlich alle. Und Geschwindigkeits vergleiche gab es schon immer. Damit muss man leben.
Ich habe einige Test durchleufe gemacht. Und GLBasic ist insgesamt gesehen im Mittelfeld. Trotzdem habe ich eine Licence gekauft. Weil ich denke das da noch einiges an Potenziel drinn ist. Wenn Gernot den Step aus der Forschleife nimmt. Den man ja auch anders lösen kann wenn man es braucht. Dann solten die Schleifen auch schneller gehen. Abes es bedarf da noch etliches an Optimirungs arbeit. Auch auf seiten den Assembler Parts gibt es etliche Feinheiten, die man erst nach einigen versuchen richtig hinbekommt. Denn oft wird vergessen das sich bei solchen Schleifen konstruckten jede Microsecunde und jede Tackt ersparniss auszahlt. Den es handlet sich im Beispeil ja um 10000*10000 durchleufe. Und der sortier Algo ist ja nun alles andere als Optimal angelegt. Zudem ist ja noch entscheidend ob zur Schleifen Bildung Register oder Speicher adressen herangezogen werden. Da sich das mit den registern von Processor zu processor ja unterscheidet. Geht es fieleicht unter diesem Aspect keine schnellere Lösung. Das zu beurteilen sind nur wenige in der Lage. Und ich selber kann es Aczeptieren , da mein Hauptaugenmerk auf Windows Mobil liegt.

Fiel Spass noch

mull

@Quentin
Mit Zufallzahlen das gleiche, mall etwas lansamer, mal schneller.

Es ist immer wieder Erstaunlich zu sehen wie andere sich aus dem Nichts angemacht fühlen.
Niemand hat behaupet das etwas schlecht oder etwas anderes besser ist.

Geht's mal locker an und seht mehr den Informativen Hintergrund und den Spaß, als wie "Kräftemessen von Programmiersprachen"
AMD Phenom II x4 955 Proc. 3.2 GHZ,  4GB Ram
Windows 7 64bit Ultima
NVIDIA GeForce GTX 460
Leistungsindex 5,7

trucidare

mir gehts nur gegen den strich dass einer daher kommt der noch null komma nix gemacht hat und es mit einer interpretierten *'!+! vergleicht die zudem noch nichtmal directx eingebunden hat.
noch schlimmer ist es zu behaupten das man alle basic dialekte kennt und weiß wo die stärken und schwächen sind. nichts für ungut tft aber du bist sehr egozentrisch.
allein einen terz draus zu machen ob ein programm nun ein wenig länger brauch als in einer anderen sprache finde ich zum "brechen"... nehmt es so hin wie es ist oder lasst es... mir macht keiner glbasic madig.. nur damit das klar ist!!!

und gernot falls du das hier liest bitte mal melden geht noch um den cross compiler für den mac... habe ein patch gefunden mit dem man gcc für universal darwin bins patchen kann. jedoch weiß ich nicht für welche version.
MacBook Pro 2,2 GHz Core 2 Duo, 4 GB RAM, 160 GB HDD, 8600M GT
Core i3 - 3,07 GHz, 8 GB Ram, 2.5 TB HDD, Geforce GTX 260+ OC

D2O

Nun mal langsam!
Keiner macht hier was madig!
Ich muss mich mull anschliesen, bleibt locker.

Und was tft angeht, der programiert schon etwas länger als manch anderer hier der windel enstiegen ist.

Ich mach mal nen anderen Thread auf.
I7 2600K; 8 GB RAM ; Win10 Pro x64 | NVidia GTX 750 TI 2048MB ; Realtec OnBoard Sound;
Lenovo ThinkPad T400: XP Pro
GLB Premium-immer Aktuell

Quentin

muuuuuuuuuhhaarrrr

fangen jetzt schon Glaubenskriege hier an? Die sind wirklich fehl am Platze.

Die Unterschiede sind definitiv da und es wäre interessant dafür den Grunde zu erfahren. Daß jeder Compiler anders optimiert und somit auch jeder seine Stärken und Schwächen hat, ist nichts Neues, das ist so alt wie der Compilerbau selbst. Ich beurteile GL auch nicht danach, ob es FOR-Schleifen schneller  oder SPRITES schneller bearbeitet als andere Sprachen. GL gefällt mir wegen seiner Einfachheit und was man damit anfangen kann.

Aber zu eurer Erbauung:
Auch wenn ich ich Sortieralgorhitmus etwas anderes formulieren würde, hier mal ein Beispiel mit INLINE-C++. Diese Version arbeitet doch schon um einiges schneller als die reine Basic-Variante. (1,35 sec stat 1,78 sec im langjährigen Mittel :) )

Code (glbasic) Select
DIM A[10000]
FOR I = 0 TO 10000-1
   A[i] = RND(10000)
NEXT

      T = GETTIMERALL()
     
      LOCAL i, j
      INLINE
        for(i=0; i<9999; i++)
        {
          for(j=i; j<9999; j++)
          {
            if(A(i) > A(j))
            {
              A(0) = A(i); A(i) = A(j); A(j) = A(0);
            };
          };
        };      
      ENDINLINE
     
//      FOR I = 0 TO 10000 - 1
//         FOR J = I TO 10000-1
//            IF A[i] > A[J]
//               A[0] = A[i] ; A[i] = A[J] ; A[J] = A[0]
//            ENDIF
//         NEXT
//      NEXT

PRINT (GETTIMERALL()- T)/1000, 10,50
SHOWSCREEN
KEYWAIT
@mull
danke für die Info. War nur mal so eine Idee.

Schranz0r

Quote from: mull...
Dauert bei mir knapp 6 Sek., der gleiche Code mit Double Variablen in VBNet 0, 22 Sek.
Warum ist der Unterschied so gewaltig ?
Ums nochmal zu sagen:

GLBasic ist keine Hochsprache, denn er muss den Code erst Interpretieren.

Frage beantwortet, und Thread kann geclosed werden !

Das geflame hier ist ja wie im Kindergarten..


Ist schon schlimm genug, das manche Leute anfangen mit GLB zu arbeiten, ums dann auf anhieb zu kritisieren. Diesen Leuten empfehle ich, Klappe zu, sich seinen Teil denken, oder ne andere Sprache suchen!

Wenn VB so toll ist, dann macht eure sachen in VB, aber wie trucidare  schon sagte, macht mal DX rein und schreibt mal ein Spiel!

1. erheblich mehr aufwand
2. dadurch demotivierend, da ergebnisse erst nach massig Code sichbar werden.

Also nochmal zum Mitschreiben:

Mir ist es egal das leute hier reinglotzt werden, die schon(VOLL ERFAHRUNG HABEN,  sogar da, wo ich noch in die Windel gepupst hab) erfahrung haben mit Programmieren.

Wenn die so toll drauf sind, sollen sie mal selber eine Sprache entwickeln, die den Comfort von GLBasic hat, und eine For-Schleife  like" C++ Speed"  hat!


Ist einfach nur lächerlich.....
I <3 DGArray's :D

PC:
AMD Ryzen 7 3800X 16@4.5GHz, 16GB Corsair Vengeance LPX DDR4-3200 RAM, ASUS Dual GeForce RTX™ 3060 OC Edition 12GB GDDR6, Windows 11 Pro 64Bit, MSi Tomahawk B350 Mainboard

Quentin

Quote from: Schranz0rGLBasic ist keine Hochsprache, denn er muss den Code erst Interpretieren.
ähhh Schranzor, was verstehst du jetzt unter Hochsprache? Natürlich ist GL eine. Und interpretiert werden muss hier auch nix, schließlich erzeugt GL standalone EXE-Dateien. Verstehe auch wirklich nicht, warum man sich aufgrund diese Vergleiche auf den Schlips getreten fühlen muss.

Aber noch mal back to topic:

@tft
mit dem Hinweis auf STEP bei der FOR-Schleife könntest du durchaus recht haben. Möglich daß VB da Optimierungen vornimmt, wenn der Zusatz fehlt. In GL-Basic gibt es jedoch noch eine Variante der FOR-NEXT-Schleife. Sieh mal in der Hilfe nach FOREACH. Diese Variante sollte deutlich schneller arbeiten. Mal sehen, daß müsste man eigentlich hinbekommen, aber nicht mehr heute ;)

Schranz0r

@ Quentin:
Mal frei aus kopf raus:


Hochsprache ist eine Grundsprache, aus dene andere Dialekte erzeugt werden.


Hochsprache VB:

BlitzBasic
GLBasic
SDLBasic
FreeBasic
....


Verstehst du nun was ich meine?

Kann ja nicht so schnell gehen wie die "Muttersprache".....
Und sich wegen 1 Sec dermassen auf zu plustern ist schon der hammer !

Kanns nur nochmal sagen, Thread schleissen , bzw. Löschen!
Weil das nimmt sonst noch überhand hier !
I <3 DGArray's :D

PC:
AMD Ryzen 7 3800X 16@4.5GHz, 16GB Corsair Vengeance LPX DDR4-3200 RAM, ASUS Dual GeForce RTX™ 3060 OC Edition 12GB GDDR6, Windows 11 Pro 64Bit, MSi Tomahawk B350 Mainboard

tft

Hi

@Schranzür ... das was ich jetzt sage mache ich nicht gerne. Aber eine Hochsprache im sinne der Computertechnik, ist nicht zu verwechseln mit einer Hochsprache in der Sprachwissenschaft. Alle Basic Dialekte sind Hochsprachen, Da diese den eigentlichen grundwortschatz. Nämlich ASM befehle nicht... oder kaum unterstützen. Eine Hochsprache ist der grund Programmier Sprache übergeordnet, weil sie in ihren Befehlen und Struckturen dem Menschlichen unvermögen mit abstrackten befehlsfolgen klarzukommen entgegenwirkt.

Ein Processor kann zwischen 10-156 grundbefehle zum abarbeiten von informationen verfügen. (Mehr oder Weniger.) Die fürsich genommen nicht wirklich zusammenhängende dinge machen. Die Hochsprache erzeugt Befehlsmuster die einen Sprachlichen sinn ergeben. Und erst dieser sinn ermöglicht es den nicht ASM begabten programme zu schreiben. Es gibt nur noch wenige die ASM so beherschen das sie keine Hochsprache benötigen.

Und VB ist auf jeden fall nicht die Grundsprache der anderen Basic Dialekte. Eine der ersten Basic Varianten gab es bereits zu Zeiten des ZX80 und C64. Da hat man an VB noch nicht mal ansatzweise gedacht. Und C gab es auch noch nicht. Höchsten experimentel auf universitäts Rechnern. Grossrechner wurden in ASM Programiert.

Ich weis ... das gehört jetzt nicht hierher. Aber das muste ich noch loswerden. :) SORRY

Kitty Hello

So. Jetzt die echte Erklärung:
Das VBnet macht das Feld statisch. So wie in C++ double feld[10000]; Das ist ganz was anderes, als ein dynamisches Feld, das intern 4 dimensionen haben muss (feld[100000][1][1][1]) - geht nicht anders.
Darum ist das schneller. Ob das jetzt bei einem Spiel wirklich zu Buche schlägt, ist fraglich, da i.d.R. die Grafik- und Soundfunktionen den größten Leistungsanteil bringen.
Wer tatsächlich so zeitkritische Berechnungen in Echtzeit benötigt, hat in GLBasic aber trotzdem den Vorteil INLINE C++ oder ASM zu schreiben - schneller geht's nicht.
Insofern sehe ich hier kein echtes Problem. Sicher ist das ein Test, bei dem GLBasic langsamer abschneidet als VB, aber so einen Test finde ich in jeder Sprache. Frage ist nur - ist dieser Test für ein Spiel relevant?

Sorry für die teilweise sehr emotionalen Antworten. Das sollte so nicht sein.

mull

Jetzt ist für mich die Sache aufgelöst und geklärt.
AMD Phenom II x4 955 Proc. 3.2 GHZ,  4GB Ram
Windows 7 64bit Ultima
NVIDIA GeForce GTX 460
Leistungsindex 5,7

Schranz0r

Jow, jetzt ist es von Tisch und gut ist :D
Sorry wenn ich ruppig war   ... ;)
I <3 DGArray's :D

PC:
AMD Ryzen 7 3800X 16@4.5GHz, 16GB Corsair Vengeance LPX DDR4-3200 RAM, ASUS Dual GeForce RTX™ 3060 OC Edition 12GB GDDR6, Windows 11 Pro 64Bit, MSi Tomahawk B350 Mainboard

tft

Hallo Gernot

Wäre es für dich schwer die Directive Statisch einzufügen Die sache mit den Redimensionierbaren Dim Feldern ist zwar recht pracktisch. Aber ich selber bin mer Geschwindigkeits bezogen. Und For Next Schleifen gibt es in einem Spiel zu hauf. Selbst bei B3D nerft mich die geschwindigkeits verluste durch Schleifen. Obwohl man bei inteligenter vorgehensweise fiele Schleifen Konstruckte minimieren kann. Das der zugriff auf Felder langsamer ist wenn sie Dynamisch verwaltet werden ist klar.Aber sind den die Types nicht für Dynamische felder besser geeigent? Habe ich nach INLINE volle Register kontrolle. Oder muss ich vorher alle Register retten und selber restaurieren?

Kitty Hello

Ein Tipp: Wenn Du dynamische Felder von TYPEs machst, kann FOREACH unglaublich schnell durchlaufen.
I.d.R reicht das für ein Spiel.

Sebe

Das ist bei weitem nicht der einzige Grund. Ich hab bereits ziemlich viele Speedtests gemacht und und die .Net Sprachen hängen die "Hobbysprachen" dabei immer ab. Für PureBasic gibt es demnächst einen .Net Compiler (eine Art Addon von einem PureBasic User), der hat das originale PB schon bei den Betatests speedmäßig weit hinter sich gelassen. Der Hauptgrund dafür liegt in der JIT Compilierung von .Net. Beim ersten Ausführen einer Codestelle wird diese in Maschinensprache übersetzt wobei sie gleichzeitig auf die jeweilige Plattform optimiert wird. Mit anderen Worten: beim ersten Ausführen einer .Net exe wird diese langsamer laden und anfangs auch etwas langsamer laufen als eine normal-kompilierte exe. Dannach geht es aber ab.