3. visualstudio05 ist larm...

visualstudio05 ist larm...

  • R

    hab es mir gestern installiert und die damit gebauten programme sind ca 25% langsammer als die mit dem 03er gebauten. sollte das ding nicht supertoll optimieren? das einzige was besser ist, ist dass es schneller kompiliert.

    vielleicht hab ich noch irgendein verstecktes flag nicht gefunden dass die wunderoptimierungen enabled.

    bisher bin ich jedenfalls derbe enttäuscht. mich wundert auch dass ich nur sse und sse2, aber kein sse3 wählen kann, dabei ist doch mit sse3 z.b. der truncate befehl in die fpu gekommen?

    rapso->greets();

    0
  • K

    hm, bei den Programmen selber hab ich noch keinen Unterschied festgestellt (aber auch nicht gemessen). Mein Eindruck ist aber eher, dass er beim Compilieren lahmer ist ... 😞 😉

    0
  • G

    rapso schrieb:

    hab es mir gestern installiert und die damit gebauten programme sind ca 25% langsammer als die mit dem 03er gebauten. sollte das ding nicht supertoll optimieren? das einzige was besser ist, ist dass es schneller kompiliert.

    Dass der Compiler beim Übersetzen etwas schneller ist, den Eindruck habe ich ebenfalls. Dass die Anwendungen allerdings langsamer laufen, kann ich nicht nachvollziehen. Ich habe allerdings keine konkreten Benchmarks zum Vergleichen. Wenn ich den VC++ 2003 Compiler hier noch irgendwo finde, kann ich ja bei meinem Space Game mal messen.

    rapso schrieb:

    bisher bin ich jedenfalls derbe enttäuscht. mich wundert auch dass ich nur sse und sse2, aber kein sse3 wählen kann, dabei ist doch mit sse3 z.b. der truncate befehl in die fpu gekommen?

    SSE3 ist zwar noch nicht dabei. Was nicht ist, kann ja aber noch kommen. Und momentan stellt sich doch sowieso noch die Frage des effektiven Nutzens von SSE3 (imo). Ich denke, viele Leute sind halt noch mit 32 Bit Bartons & Co unterwegs (wie zB meiner einer) und die haben ja noch nicht mal SSE2.

    0
  • R

    groovemaster schrieb:

    SSE3 ist zwar noch nicht dabei. Was nicht ist, kann ja aber noch kommen. Und momentan stellt sich doch sowieso noch die Frage des effektiven Nutzens von SSE3 (imo). Ich denke, viele Leute sind halt noch mit 32 Bit Bartons & Co unterwegs (wie zB meiner einer) und die haben ja noch nicht mal SSE2.

    afai ist SSE3 wohl mit dem masm direkt nutzbar, hab ich noch nicht probiert, aber was mit SSE3 zusammen kam, ist eine funktion zum abrunden beim float2int, sonst mußte immer die fpu umgestellt werden meines wissens nach. das dürfte einiges an speed bringen eigentlich, aber mitlerweile macht der compiler sowas wohl eh mit sse, weshalb man die fpu da wohl vergessen kann.

    performanceeinbrüche hab ich stark gemerkt, mein raytracer ist in der benchmarkscene von 85-90ms/frame auf 110-115ms/frame rauf. was schon derbe viel ist wenn ich mir überlege wie lange ich optimiert habe um den von 120ms auf 90ms runter zu bekommen... wenn ich dafür kein workaround finde, werde ich vs03 wohl parallel drauf lassen müssen :(. naja, vielleicht frag ich bei gelegenheit bei ms an was der scheiss soll 😉 :xmas2:

    rapso->greets();

    0
  • G

    rapso schrieb:

    performanceeinbrüche hab ich stark gemerkt, mein raytracer ist in der benchmarkscene von 85-90ms/frame auf 110-115ms/frame rauf. was schon derbe viel ist wenn ich mir überlege wie lange ich optimiert habe um den von 120ms auf 90ms runter zu bekommen...

    Hast du mal etwas mit den Projekteinstellungen gespielt? Da gibts ja einiges an Optimierungen. Und es sind auch Sachen hinzugekommen, wie zB das Handling für Gleitkommazahlen (/fp:...). Auch werden beim Release Build per default Einstellungen gesetzt, die sich imo eher negativ auf die Performance auswirken. Ansonsten würde es mich sehr wundern, wenn der Compiler bzgl. der Performance der Kompilate schlechter geworden sein soll. AFAIK sind ja die hauptsächlichen Änderungen vom MSC 7.1 zu 8.0 im Bereich C++/CLI angesiedelt.

    0
  • ?

    was heißt larm? 😕

    0
  • R

    deutsch1 schrieb:

    was heißt larm? 😕

    das etwas so langsam ist, dass das h in lahm zu einem r wird.

    0
  • R

    ich hab jetzt ein wenig mit den compilerflags rumgespielt aber es hat nichts an performance gebracht, das fp flag hab ich auf fast, die beiden anderen machen das ganze derbe langsam.

    ich hab mir mal das assemblat einer performancekritischen stelle angesehen und finde es ein wenig seltsam.

    vs03:

    00404AA0  sub         esp,0A8h 
00404AA6  push        ebx  
00404AA7  push        ebp  
00404AA8  push        esi  
	if(m_pChilds)
00404AA9  mov         esi,dword ptr [esp+0B8h] 
00404AB0  mov         ebx,ecx 
00404AB2  push        edi  
00404AB3  mov         edi,dword ptr [ebx+10h] 
00404AB6  test        edi,edi 
00404AB8  je          004054DE 
00404ABE  lea         ebp,[esi+0Ch] 
	{
		DBOOL	SS	=	m_SplitPlane.RightSide(rRay.StartPos());
00404AC1  movss       xmm0,dword ptr [esi+4] 
00404AC6  mulss       xmm0,dword ptr [ebx+4] 
00404ACB  movss       xmm1,dword ptr [esi] 
00404ACF  mulss       xmm1,dword ptr [ebx] 
00404AD3  addss       xmm0,xmm1 
00404AD7  movss       xmm1,dword ptr [esi+8] 
00404ADC  mulss       xmm1,dword ptr [ebx+8] 
00404AE1  addss       xmm0,xmm1 
00404AE5  comiss      xmm0,dword ptr [ebx+0Ch] 
00404AE9  jbe         CBSPNode::Trace+52h (40

    vs05

    00404980  sub         esp,20h 
00404983  push        ebx  
00404984  push        ebp  
00404985  push        esi  
	if(m_pChilds)
00404986  mov         esi,dword ptr [esp+30h] 
0040498A  push        edi  
0040498B  mov         edi,ecx 
0040498D  mov         eax,dword ptr [edi+10h] 
00404990  test        eax,eax 
00404992  je          CBSPNode::Trace+25Ah (404BDAh) 
00404998  jmp         CBSPNode::Trace+20h (4049A0h)  //<--WTF 
0040499A  lea         ebx,[ebx] 
	{
		DBOOL	SS	=	m_SplitPlane.RightSide(rRay.StartPos());
004049A0  movss       xmm3,dword ptr [edi+4] 
004049A5  movss       xmm1,dword ptr [edi] 
004049A9  movss       xmm4,dword ptr [esi] 
004049AD  movss       xmm5,dword ptr [esi+4] 
004049B2  movss       xmm2,dword ptr [edi+8] 
004049B7  movss       xmm0,dword ptr [edi+0Ch] 
004049BC  mulss       xmm5,xmm3 
004049C0  mulss       xmm4,xmm1 
004049C4  addss       xmm4,xmm5 
004049C8  movaps      xmm5,xmm2 
004049CB  mulss       xmm5,dword ptr [esi+8] 
004049D0  addss       xmm4,xmm5 
004049D4  comiss      xmm4,xmm0 
004049D7  jbe         CBSPNode::Trace+60h (4049E0h)

    mir entzieht sich da der tiefere sinn, hat jemand ne leuchte für mich?
    ich hab an 0040499A auch nen breakpoint gesetzt für den fall dass ich etwas übersehe, der wird aber nie angesprungen *hmmm*

    rapso->greets();

    0
  • ?

    beschwer dich doch bei Microsoft

    0
  • A

    Also ich kenne mich mit Intel-Assembler garnicht aus, nur mit 6510 und ARM. 😉 Egal...

    Könnte es sein, das die Secure-C-Runtime eingeschaltet ist? Die würde Performance fressen.

    CBSPNode, ist daswas von dir?

    0
  • R

    Artchi schrieb:

    Könnte es sein, das die Secure-C-Runtime eingeschaltet ist? Die würde Performance fressen.

    meinst du buffer-security-check, Run-time-checks usw? nein, die sind nicht an. wäre aber aus dem vs03 projekt übernommen worden.

    Artchi schrieb:

    CBSPNode, ist daswas von dir?

    ja, eine klasse eines BSP-Trees die eine Node darin darstellt, in dem sniple wird geprüft ob weitere childs vorhanden sind bzw. ob der pointer !NULL ist.

    rapso->greets();

    0
  • G

    Warum die SSE Befehle bei der 05er Version mehr sind, kann ich momentan nicht nachvollziehen. Wahrscheinlich soll dort erst alles in Register geschoben werden, bevor gerechnet wird. Ob das jetzt günstiger ist, als direkt den Speicher für den rechten Operand zu verwenden, kann ich momentan nicht sagen.
    Merkwürdig ist aber auch folgendes:

    00404990  test        eax,eax 
00404992  je          CBSPNode::Trace+25Ah (404BDAh) 
00404998  jmp         CBSPNode::Trace+20h (4049A0h)  //<--WTF 
0040499A  lea         ebx,[ebx]

    Sieht so aus, als würde jmp hier wegen Alignment gemacht werden. Ob das vorteilhaft ist, weiss ich nicht. Auswirkungen auf die Laufzeit kann das aber durchaus haben (vllt. auch negative).

    0
  • R

    hab ich auch vermutet, aber das hätte eigentlich nur vorteile wenn es in nem loop wäre, so ist es einfach nur ein jump und das manuelle allignment zieht wohl mehr als wenn man den penalty direkt der cpu überlassen würde... hmhmhm... ms hat noch nicht geantwortet.

    0
  • S

    Reines Interesse: Welche Version des 2005er?

    MfG SideWinder

    0
  • R

    gibt es mehrere? also ich hab die version mitte dezember gezogen... proffesional, dvd, english.

    0
  • S

    rapso schrieb:

    gibt es mehrere? also ich hab die version mitte dezember gezogen... proffesional, dvd, english.

    Professional. Ich wollte nur überprüfen ob das eventuell an der Express Edition liegt 🙂

    MfG SideWinder

    0
  • A

    An der Express könnte es auch nicht ganz liegen, da die Express den 32bit Professional-Compiler drin hat, nur ohne WPO. Ansonst sind alle Optimierungen in der Express drin.

    0
  • R

    hah, die antwort wird euch gefallen

    Microsoft schrieb:

    I tried to reproduce this bug on my machine. I installed both vs2003 and vs2005. My vs2005 version is 8.0.50727.42.
    My vs2003 version is 7.1.3088. I found that vs2005 release build is almost 10 times faster than vs2003 release build.
    I can not find the redundant jmp in vs2005 assembly code. Please give more detail information about how to build for
    further investigation.

    also, um mal festzuhalten, mein wochenlang optimierter raytracer, der es am ende auf 20fps bei 512*512 brachte und wirklich das letzte aus meiner kiste kratzt, läuft bei denen mit 200fps 😮 ... dank neuem compiler 😮 ... sehr sehr schön. 😮

    rapso->greets();

    0
  • P

    Artchi schrieb:

    An der Express könnte es auch nicht ganz liegen, da die Express den 32bit Professional-Compiler drin hat, nur ohne WPO. Ansonst sind alle Optimierungen in der Express drin.

    Die Optimierung in der Express funzt doch net. Wenn man die einstellt, gibts nen Compile-Fehler(oder Linker, weis net mehr^^).

    0
Anmelden zum Antworten