vb = langsam - Seite 3

Seite 3 von 3 - Forum: Coding Stuff auf overclockers.at

URL: https://www.overclockers.at/coding-stuff/vb_langsam_33660/page_3 - zur Vollversion wechseln!

Ringding schrieb am 16.05.2002 um 19:26

hab's jetzt ausprobiert, auf meinem p3 braucht man 2 takte fuer einen durchlauf, und das sollte der athlon auf jeden fall auch packen.

FMFlash schrieb am 16.05.2002 um 19:43

stimmt natürlich das die schleife sinnlos is, aber es soll auch keinen praktischen nutzen haben sondern einfach etwas testen

bei 2 takten / rechnung müsste das bei 1607 mhz satte 842 530 816 additionen / sek ergeben, also +420% leistung
wie hast dus denn compiliert?

Ringding schrieb am 16.05.2002 um 21:21

In Assembler geschrieben

FMFlash schrieb am 17.05.2002 um 15:07

:rolleyes:

LTD schrieb am 17.05.2002 um 15:31

das wärs mal - ein game in assebler coden *g* da braucht ma alle nurmehr nen p2 233 und ne tnt2 und schon würd alles flüssig laufen mit 60fps *g*

FMFlash schrieb am 17.05.2002 um 15:44

das sw-rendering der q2-ending is eh in assembler gecodet, der rest aber in c++ ... scheint also nicht immer so einen geschwindigkeitsvorteil zu bieten

that schrieb am 17.05.2002 um 23:53

Fast immer sind weniger als 10% des gesamten Codes wirklich performancekritisch.

NyoMic schrieb am 18.05.2002 um 08:17

Zitat von FMFlash
oje wie langsam muss dann erst ein in vb gecodetes 3d-game sein?

Das is ned unbedingt gesagt. VB in Verbindung mitn DirectX SDK is ned unbedingt so langsam. Natürlich wenns um aufwendigere Sachen geht als a einfachs Game mit ISO Sicht oda a einfachen FP-Shooter dann is sicher langsam. Aber für einfache Sachen is schon schnell genug.

FMFlash schrieb am 18.05.2002 um 11:55

Zitat von Ringding
hab's jetzt ausprobiert, auf meinem p3 braucht man 2 takte fuer einen durchlauf, und das sollte der athlon auf jeden fall auch packen.

mit voller optimierung geht jetzt sogar noch einiges mehr, auch ohne assembler

Zitat von that
Fast immer sind weniger als 10% des gesamten Codes wirklich performancekritisch.

jo nicht die rechungen machens aus sondern die speicherzugriffe

Ringding schrieb am 18.05.2002 um 12:13

Zitat von FMFlash
jo nicht die rechungen machens aus sondern die speicherzugriffe

Das außerdem, aber das eine hat mit dem anderen nix zu tun.

Bei heutigen Spielen wird man sich schwer tun, irgendwas nennenswert zu verbessern, wenn man Teile in Assembler schreibt. Ein paar optimierte Vektor/Matrix-Operationen zahlen sich für die meisten 3D-Spiele schon aus, aber da sollte man doch eher auf schon fertige Routinen zurückgreifen, als selber mit Assembler zu basteln anfangen. Ohne fundierte Erfahrung wird man sonst nämlich eher verschlimmbessern.

Richtig, bei Quake war der Texture Mapper in Assembler geschrieben, und ich hab leider nie ausprobiert, um wie viel langsamer die C-Version wirklich ist. Bei Doom war's allerdings ähnlich, dass die ganzen Render-Routinen in Assembler waren, und da hat das gegenüber der C-Version knappe 10% Performance gebracht. Also zwar nicht soo wenig, aber die Welt ist es auch nicht.