Nachdem sich Microsoft über das erste Service Pack für Visual Studio 2010 sehr bedeckt gehalten hat, steht seit gestern – vorerst nur für MSDN Subscribers – die Beta zur Verfügung.
Eine vollständige Liste der Verbesserungen ist noch nicht im Umlauf, aber unter den größten Neuerungen findet man:
Einen Help Viewer, mit dem man durch die Hilfe surfen kann, ohne den Browser zu benutzen
Über 80 Bugfixes im Team Foundation Server
Die Möglichkeit für Unit-Testing mit .NET 3.5
Einen Performance Wizard für Silverlight, mit dem sich Code profilieren lässt
Öffentliche Downloads folgen Donnerstag. Die Lizenz ist die der VS2010-Beta; man darf sie bis Juni 2011 im Produktivbetrieb einsetzen.
Intellitrace is the revolutionary new debugging technology in VS 2010 that allows you to move forward and backwards through a debug session. With it being a V1 offering at RTM, we just didn't have time to make it work in all scenarios. In SP1, we've rounded it out with a couple of important ones - 64-bit and Sharepoint. We still don't have Silverlight or unmanaged C++ support but we'll continue to make progress on important scenarios.
Naja, die Hoffnung stirbt ja bekanntlich zuletzt ...
Nachtrag:
IntelliTrace is not supported for native C++ applications. We hope to fix this limitation in the future.
Das war im Oktober letzten Jahres. Und ich dachte, C++ wäre für Microsoft keine Sprache zweiter Klasse. :?
Die haben wohl schon genug damit zu tun, meine Bug-Reports abzuarbeiten ... ;)
Ich warte auf das fertige Service Pack und hoffe, dass ich dann endlich wieder globale Optimierungen benutzen kann ... der Debugger und die Entwicklungsumgebungen sind mir persönlich zweitrangig. Und ich bin faul wie Hund.
Krishty hat geschrieben:Einen Help Viewer, mit dem man durch die Hilfe surfen kann, ohne den Browser zu benutzen
Hm, ich mache das schon seit Ewigkeiten mit VS05. Was ist daran neu?
Da ich auch seit einigen Versionen den integrierten Help Viewer überhaupt gar nicht mehr benutze, hätte ich mir eigentlich einfach nur gewünscht, dass bei einem Druck auf F1 einfach der selektierte Text im Standardbrowser mit der Standardsuchmaschine gesucht wird. Mehr Ansprüche habe ich eigentlich nicht mehr, und ich denke, das könnte ich mir auch mal als Makro zusammenbasteln ...
Nachtrag: Damit man meine Aussagen einordnen kann -- ich benutze noch Visual Studio 2005, habe aber bei ein paar Kollegen schon ins 2010er reingeschnuppert.
Habe es nun doch installiert, um der Bug-Reports Willen —
Kann jemand bestätigen, dass das Kompilieren schneller geht? Ein komplett-Rebuild meiner Engine samt LTCG unter x86 dauert nur noch 14 statt 45 Sekunden :shock: 20 Sekunden für Assimp x64 Release … das geht ja ab wie ohne Sattel …
Ich habe zweimal manuell alle Dateien gelöscht weil ich einfach nicht glauben konnte, dass der tatsächlich alles neu kompiliert – so lange hat vorher schon allein ein inkrementeller Build/Link gedauert …
Ich habe gestern die Splitterwelten auf VC10 umgezogen, bislang allerdings noch ohne SP1. Meine Erfahrungen bisher:
- Projekte größtenteils sauber umgesetzt. Gott sei Dank haben wir vorher schon alle Dependencies relativ zum Hauptprojekt verpackt. Boost, FMod, PhysX, DirectX, TBB, Qt - einmal auschecken und alles steht. Hätt ich viel früher drauf kommen müssen.
- einige Einstellungen verhunzt - aus einem Custom Build Step ist plötzlich ein C++-Compile geworden, das geht bei nem Header natürlich nicht.
- Übersetzungszeit anscheinend nahezu genauso schnell wie VC9, die GUI ist drastisch langsamer und von sekundenlangen Aussetzern durchsetzt. Evtl. wirkt da Krishtys SP1-Bericht noch förderlich.
- Release-Build mit LTCG baut jetzt ewig, produziert aber bald doppelt so schnellen Code! 108 fps anstatt 55 fps auf dem Händlerschiff - Danke, VC10!
- Debug-Build ist abartig langsam. 6 fps im Debug, 15 im OptimDebug - ich hab's wohl mit den Runtime-Checks übertrieben.
- 2 Millionen Warnungen! Woher kommen die alle? Beispiele:
.... "Enum-Wert BlaBlubb nicht explizit in switch behandelt" - dazu ist der default: Zweig!
.... "Folgende Funktion für Inlining ausgewählt" - ach? Erzähl's der Parkuhr.
.... "Konnte Funktion nicht inlinen" - Dein Problem, nicht meins.
.... "Abweichende Ausnahmenspezifikation" - bei new[]! Was soll ich da machen bitte?
Ich hab jetzt etwa 15 Warnungen auf der Totmachliste, weil sonst allein die Textausgabe im Buildfenster ne halbe Minute zusätzliche Zeit beanspruche würde. Und der Großteil der Warnungen kam eh in den System Includes, da kann ich gar nix machen. Mach ich da irgendwas falsch? Oder ist das am Ende schlicht eine Folge der 5 aufeinandergestapelten Konvertierungen: VC6 -> 2003 -> 2005 -> 2008 -> 2010
Wird Zeit, dass das Projekt fertig wird. Aber zumindest kann ich ab jetzt die neuen C++0x-Features einsetzen. Das hab ich im Team durchgesetzt :-)
Du hast das Warnungs-Level auf all statt auf 4 ;) Diese Warnungen sind zu 99 % unnötig und zu 0,5 % buggy … ich mache das nur einmal im Monat bei einem komplett-Review.
Schrompf hat geschrieben:.... "Abweichende Ausnahmenspezifikation" - bei new[]! Was soll ich da machen bitte?
Garnichts. Ist imo ein Compiler-Bug, weil die Meldung auf bei perfekt qualifiziertem Operator kommt.
Der LTCG-Speedup ist ja super. Falls ihr mal bei einer Compiler-Einstellung unsicher seid, fragt mich – ich habe die meisten schon von vorn bis hinten analyisiert.
Ne, ich hatte eigentlich alles auf Warning Level 3 eingestellt :-) Daher auch meine Verwunderung. Evtl. hab ich aber wirklich irgendwo in einem der generierten, vererbten und konvertierten Property Sheets noch ein -Wall drin. Örg. Aber Danke für das Hilfsangebot. Ich werde bei Gegelegenheit darauf zurückkommen.
Gut, eine Frage hätte ich gleich: welcher der Runtime Checks verursacht so einen massiven Performance-Einbruch? Wir haben ja extra eine "Relug" genannte Build-Konfig, bei der alle Optimierungen außer LTGC an sind, gleichzeitig aber Debug-Symbole, _DEBUG, Assertions und sowas auch an sind. Die lief früher mit etwa halber Release-Geschwindigkeit, ist aber nach meiner Konvertierung und all den Anpassungen nur noch bei einem Zehntel der Release-Performance. Die ist damit mehr oder minder unbrauchbar.
Gute Frage. Von 2008 auf 2010 wurde nur /GS (Buffer Security Check) bedeutend überarbeitet – das hat aber keinen nennenswerten Overhead. Könnten Änderungen an der STL (strengere Iteratoren) oder an der CRT sein, aber die benutze ich nicht mehr … versuch mal, /RTC (Smaller Type Check und Basic Runtime Check) abzuschalten. Falls du irgendwo in einer inneren Schleife Typen konvertierst, könnte das was ausmachen.
Du kannst Debug-Informationen übrigens auch in Release-Builds aktivieren und damit akzeptabel (eben den Optimierungen entsprechend) debuggen – der einzige Overhead in der Exe ist ein zusätzlicher String mit dem Pfad der PDB-Datei, sonst bleibt alles so schnell wie vorher.
Gut, eine Frage hätte ich gleich: welcher der Runtime Checks verursacht so einen massiven Performance-Einbruch?
Was sagt denn der Profiler? Der sollte doch am zuverlässigsten sehen wo es am schlimmsten hakt. Wahrscheinlich lassen die betroffenen Codestellen einen Rückschluss auf die ausschlaggebenden Debug-Features und damit auch auf die entsprechenden Compiler-Optionen zu.
Das ist eine gute Frage. Ich stelle gerade fest, dass in der Visual Studio Ultimate aus der MSDNAA ein Profiler eingebaut ist. DAS ist mal ne gute Nachricht! Alle Profiler, die ich sonst so kannte, haben unter Win7 64Bit nicht funktioniert.
AMD CodeAnalyst for Windows supports the following platforms: Microsoft® Windows XP®, Windows® 2003, Windows® Server 2003, Windows® Server 2008, and Vista®, and Windows 7® distribution on x86 and AMD64 architectures.
. Und als ich ihn das letzte mal verwendet hab war er auch ganz brauchbar.
Ne, gerade VerySleepy wollte hier gar nicht. AMDs Code Catalyst hab ich früher mal ausprobiert und bin nicht damit klargekommen. Vielleicht sollte ich das bei Gelegenheit mal erneut probieren.
Ich muss nochmal nerven, sorry: Ich habe grade festgestellt, dass die "range-based loop" aus dem C++0x-Draft es gar nicht in VC10 geschafft hat. Kommt die mit dem Service Pack 1? Oder bin ich bis mindestens 2012 gezwingen, Iterator Loops zu schreiben und die einzige Freude daran ist das neue auto?
Randbemerkung: der Projektschalter, der den Relug-Build zum Kriechen brachte, war /GS - Puffersicherheitsüberprüfung. Jetzt ist auch ReleaseDebug-Frankenbuild wieder auf dem gewünschten Performance-Level - ~50fps, was etwa das Vierfache von vorher ist. Die "Überprüfung von kleineren Typen", die mir sagen soll, wenn bei einem impliziten Cast Daten verloren gehen, kann ich gar nicht anschalten, weil es sonst schon beim Start 500 mal tief in boost::format klingelt. Die "Vollständigen Laufzeitüberprüfungen" sind dagegen 'ne nützliche Sache - anscheinend kaum Performance-Auswirkungen (~20%, soweit ich das hier sagen kann) und findet aller Jubeljahre doch mal eine lokale Var, die man zu initialisieren vergessen hat. Leider gibt's die nicht für Klassenmember.
Leider hat meine Projektstruktur inzwischen eine Komplexität erreicht, die ich anscheinend nicht mehr vollständig beherrsche. Irgendwo in den Projektsettings ist _SECURE_SCL=0 definiert... das merke ich daran, das es keinen messbaren Unterschied ergibt, wenn ich es solutionweit nochmal definiere. Aber frag mich mal, wo... Ich hab's noch nicht gefunden. Sonst hätte ich es in obige Auflistung noch mit aufgenommen.
Schrompf hat geschrieben:der Projektschalter, der den Relug-Build zum Kriechen brachte, war /GS - Puffersicherheitsüberprüfung. Jetzt ist auch ReleaseDebug-Frankenbuild wieder auf dem gewünschten Performance-Level - ~50fps, was etwa das Vierfache von vorher ist.
Uff! In der Theorie sollte das ein Speichern, ein Laden und ein Vergleichen eines DWORDs sein – und das auch nur in Funktionen, die mit lokalen char-Arrays arbeiten, die länger als vier Buchstaben sind. Krass, wie weit Theorie und Praxis manchmal auseinander gehen.
Ob Deines entsetzten Ausrufs habe ich jetzt nochmal /GS zurückgedreht. Und ich habe immernoch ~50fps im Relug Build. Was geht hier ab? Jetzt geht die Forscherei wieder los, nur damit ich hier keinen Unsinn stehen habe...
Re: Beta von Visual Studio 2010 SP1 verfügbar
