Mam pytanie . Czy programy c# 64 bitowe szybciej działają?
. Czy ktoś to kiedyś sprawdzał , Ja wiem tylko tyle że potrzebują większej ilości pamięci bo używają 64 bitowych adresów .
0
1
tak pracują szybciej, przy małych apkach tego nie odczujesz ale im większe tym bardziej jest to odczuwalne. Z racji tego, że nasze komputery i systemy są x64, apki 32 bitowe są wirtualizowane.
4
mr_jaro napisał(a):
tak pracują szybciej, przy małych apkach tego nie odczujesz ale im większe tym bardziej jest to odczuwalne.
Masz jakieś pomiary?
Bo z tego co kiedyś widziałem (z pewnością to już naprawili) takie Math.Pow() było w wersji 64-bitowej kilkakrotnie wolniejsze.
W praktyce (nie licząc takich oczywistych wpadek) nie oczekiwałbym żadnej odczuwalnej różnicy w normalnym programie.
Z racji tego, że nasze komputery i systemy są x64,
Nasze, czyli czyje, bo piszę te słowa z 32-bitowego systemu...
apki 32 bitowe są wirtualizowane.
To mógł być argument kilkanaście lat temu - dodatkowy narzut na 32-bitowe aplikacje w 64-bitowym systemie jest raczej pomijalny.
Spodziewałbym się istotnej różnicy na korzyść 64 bitów praktycznie tylko tam, gdzie do obliczeń są wykorzystywane 64-bitowe inty, które nie będą musiały być składane z dwóch 32-bitowych liczb, co rzeczywiście jest wolniejsze.
1
Czysto teoretycznie architektura x86_64 ma więcej rejestrów, więc kod może być krótszy i przez to szybszy. W praktyce bywa różnie, przykładowo autorzy Visual Studio nie chcą robić wersji 64-bitowej, bo według ich analiz nie ma przyspieszenia — nie oceniam, jak jest w rzeczywistości, ale z pewnością bez pomiarów się nie obejdzie.
1
Ludzie mają różne zabytki. Ja mam np. na strychu kompa z 48k RAMu.
Przydatne linki:
https://docs.microsoft.com/pl-pl/dotnet/framework/64-bit-apps
https://www.codeguru.com/csharp/.net/article.php/c16921/Understanding-NET-application-options-for-32-and-64bit-systems.htm
To czym bym się głównie martwił to limit 2 GB RAM. Na dzisiejsze czasy to naprawdę osiągalny pułap (chyba że liczysz miejsca zerowe paraboli).
1
Tak, x86_64 ma więcej rejestrów, co jest dużym ułatwieniem dla… piszących w asemblerze. Hura :]
Niestety, większe wskaźniki oraz dodatkowe prefiksy instrukcji powodują że kod jest średnio dłuższy, zajmuje więcej cache procesora (jak duży by on nie był) co przynajmniej częściowo zjada zyski związane z większymi rejestrami i większą ich ilością.
Wystarczy porównać rozmiar exeka 32-bitowego i 64-bitowego tego samego programu. Zawsze jest różnica kilku-kilkunastu procent.
0
Różnicy w kodzie IL nie zauważyłem tylko wielkość obiektów na zarządzanej stercie jest większa .
Domyślnie w Visual Studio są 32 bity jeśli się nie mylę .
Zastanawiałem się co nam daje tak realnie włącznie trybu 64 bity .Chodzi mi wyłącznie o taki kod zarządzany C# .i środowisko uruchomieniowe CLR.
Czy są może jakieś publikacje w necie na ten temat
Jeszcze jedna ciekawa rzecz. Może ja się nie znam do końca . Any CPU w 64 bitowym Windowsie działa w trybie 32 bity . Według MSDN powinno być w trybie 64 bity .
Widzę po wielkości adresów .
Dzięki za wszystkie wcześniejsze odpowiedzi .
1
Zimny Krawiec napisał(a):
Jeszcze jedna ciekawa rzecz. Może ja się nie znam do końca . Any CPU w 64 bitowym Windowsie działa w trybie 32 bity . Według MSDN powinno być w trybie 64 bity .
Oprócz Any CPU jest jeszcze ustawienie "prefer 32-bit", które jest chyba domyślnie włączone.
1
AnyCPU zadziała tak, jaka jest fizyczna architektura. Any CPU + prefer 32 bit zawsze działa jako w 32 bitach, różni się od x86 tym, że działa też na ARM-ie.
0
Sprawdziłem . Jest dokładnie tak jak mówicie . Thanks !