MSDN "Writing Faster Managed Code: Know What Things Cost" jest całkiem niezły, ale został napisany dla CLR v1 w 2003 roku. Czy jest tam gdzieś zaktualizowana wersja?Czy jest zaktualizowana wersja "Pisanie szybszego kodu zarządzanego: wiedzieć, ile kosztuje"?
Nie znam takiego, który zastąpiłby to, ale książka CLR via C# zapewni ci wiele głębokiej i istotnej wiedzy na temat działania CLR i pochłania dużo czasu i zasobów.
Nie sądzę, i nie sądzę, że zaktualizowana wersja byłaby o tyle inna.
Dane dotyczące czasu będą różne, ponieważ maszyna testująca byłaby prawdopodobnie nowsza i szybsza, ale relacja między testami byłaby prawie taka sama.
Artykuł dotyczy niskiego poziomu efektów typowych operacji w zarządzanym kodzie, który nie zmienił się znacznie od czasu napisania artyka. Nowe wersje frameworka dodały wiele funkcji, ale wszystkie zostały zbudowane na prymitywach, które są dostępne od wersji C# 1.0.
Nie. Nigdy go nie aktualizowałem, ale myślę, że wzięty z odpowiednimi ziarnami soli, ogólna rada i większość zasad w artykule nadal dobrze się dziś trzyma.
(Powiedział, że dobrze byłoby powtórzyć eksperyment dzisiaj zobaczyć, jak prymitywne czasy się zmieniły, jak wygenerowany kod został zmieniony, a jak mikroprocesory uległy zmianie.)
Względne koszty ogólne większości prymitywów wygrał wiele się zmieniło, ale niektóre zmieniły się dramatycznie. Na przykład, średnia wydajność niestatycznego wywołania delegata została znacznie poprawiona (w .NET 2.0, jeśli dobrze pamiętam). Nienawidziłbym myśleć, że praktykujący dzisiaj robiłby wszystko, aby uniknąć delegowania, ponieważ zgłosiłem to jako bardzo kosztowne w 2003 roku.
Od .NET 1.1, oczekiwałbym, że wiele skompilowanych sekwencji kodu ulegnie zmianie; pojawią się nowe optymalizacje kompilatora JIT (które nie są tak dobrze widoczne w mikrobachkach); różne miksy kodu JIT i NGEN (a NGEN nie był badany w moim artykule); Kluczowe podsystemy, takie jak odśmiecacz śmieci, były nieustannie dostrajane przez lata.
Podtrzymuję moją ostrożną radę dotyczącą potencjalnego wpływu efektów systemu pamięci na zagłuszanie kosztów dowolnej liczby operacji wykonywanych za pomocą pojedynczego kodu zarządzanego - i ponownie zauważ, że wiele się zmieniło. Na przykład duża część pracy wydajności CLR w 03-04 poszła na lepsze zachowanie zestawu roboczego (takie jak minimalizacja brudnych stron prywatnych) zestawów systemu NGEN.
Oczywiście temat artykułu jest konieczny, aby starannie i czujnie zmierzyć wydajność kodu, a temat jest ponadczasowy.
Nawiasem mówiąc, zawsze chciałem zrobić artykuł uzupełniający o spodziewanych/typowych kosztach czasu i przestrzeni z kilku setek najczęściej używanych metod .NET BCL i zaprezentować jako przestrogę kilku z nich. historie o horrorach, które znaleźliśmy działając na wydajności .NET. Doprowadziło to do bardzo interesującego myślenia o tym, jak scharakteryzować empiryczną wydajność biblioteki klasowej/szkieletu, tak jak faktycznie stosowali ją prawdziwi praktycy w dziczy ...
Dziękuję za przeczytanie tego i dziękuję za stałe zainteresowanie .
p.s.Widzę Vance Morrison następnie napisał wielki dwuczęściowej serii MSDN na ten temat - jeśli cieszył się mój artykuł pokochasz te:
należy dodać, że mikroprocesory również uległy zmianie. Oczywiście oferują wiele wątków i/lub rdzeni. Konstruktorzy CPU byli w stanie przećwiczyć ślady wykonawcze aplikacji OOP i JVM/CLR, aby dostroić i zmodyfikować ich mikroarchitektury. Na przykład znacznie lepsze przewidywanie rozgałęzień w kontekście wywołań metod wirtualnych i krótkich wywołań metod/zwrotów pozwala na część kodu, którego JIT nie może zoptymalizować, aby teraz wykonywać operacje poza kolejnością przy mniejszej liczbie zagrożeń, wycofywaniu zmian lub wstrzymywaniu. Niektóre koszty ogólne są całkowicie zoptymalizowane. To sprawia, że mikrobieczkowanie jest o wiele bardziej problematyczne i niebezpieczne! –
Chociaż niektóre mikroprocesory zaczęły poruszać się w przeciwnym kierunku, wracając do bycia bardziej uporządkowanym i z literalnymi rejestrami (np. PPC, Larabee), co powoduje, że wiele kar za rurociąg jest bardziej bolesnych. – Crashworks
Prawda! Wydaje mi się, że trend "efektywności energetycznej obliczeń przewyższa szybkość obliczeń" wciąż nabiera rozpędu (zakładając, że połączenie równoległego "oprogramowania przepustowości" staje się bardziej interesujące ekonomicznie), zobaczymy więcej tych prostszych mikroarchitektur, a może nawet połączenie skomplikowanych i prostych w heterogenicznych procesorach wieloprocesorowych. Co ciekawe, gdy wahadło sprzętowe odchyli się, może z czasem znaleźć odzwierciedlenie w zmianach w kodeku i organizacji VM! Oprogramowanie kształtuje sprzęt i na odwrót. –