Windows Vista - Temat ogólny

[KrzysztofMarek 9]

Dnia 16.05.2008 o 23:14, Olamagato napisał:

> Plik wymiany ustawiłem sobie na 1,5 GB. Razem, z 3,25 GB RAM daje to 4,75 GB.
Zupełnie niepotrzebnie. /.../

Nie ma to, jak fachowiec. Właśnie zlikwidowałem plik wymiany ;-D

Dnia 16.05.2008 o 23:14, Olamagato napisał:

Ale nie ma on znaczenia bo będzie tylko więcej wyświetlało na winietce systemu. Nadal
do wykorzystania będzie tylko 2 GB na aplikację.

No, to pośrednio potwierdziłeś taka możliwość i juz nie bedę szukał artykułu.
Zresztą nawet jak jakaś gra zajmie mi 2 GB, to zawsze zostanie mi jeszcze 1,25GB na system, antywirusa i co tam jeszcze...

[Olamagato 3]

Dnia 16.05.2008 o 22:15, GeoT napisał:

Możesz z niego zrezygnować całkiem (nieopłacalne choć są różne szkoły)

Opłacalne bywa, ale tylko w celu wyrzucenia usługowej części systemu (jakieś 120 MB w XP i ok. 550 MB w Vista-32) do pliku wymiany gdy masz 2 GB ram. I te wielkości determinują maksymalną potrzebną wielkość pliku wymiany (120 MB i 550 MB).

Dnia 16.05.2008 o 22:15, GeoT napisał:

Ja wybrałem prostsze rozwiązanie: przesiadłem się na system 64bitowy

Tylko pamiętaj, że ze względu na budowę kodu X86-64 wielkość kodu wzrasta statystycznie prawie dwukrotnie, co oznacza, że komputer działający w tym trybie będzie realnie potrzebował dwa razy więcej RAM niż robiący to samo system 32-bitowy z programami 32-bitowymi. Jak na razie najbardziej opłacalne pamięciowo jest odpalanie 32-bitowych programów na 64-bitowym systemie, ale kosztem jest zwiększony czas ciągłego przełączania z trybu 32 na 64 i odwrotnie przy każdej komunikacji między programem a systemem (czyli niemal cały czas, gdy program jest interaktywny - np. gra).

Tak więc, żeby uzyskać pamięciowy i wydajnościowy odpowiednik XP z 2 GB RAM (1,75 GB aplikacja + 0,25 GB na OS), to potrzeba Visty 64-bit z ok. 5,4 GB ramu (3,5 GB aplikacja + 1,9 GB). Od granicy 5,5 GB RAM Vista-64 staje się bezapelacyjnie szybsza od każdego Windows XP i podaje programom 64-bit relatywnie więcej pamięci. Zakładając oczywiście, że nie mamy żadnych zysków z obliczeń w podwójnej precyzji na 64-bitach (w stosunku do 32-bitów).
Oznacza to realnie, że jeżeli Vista 64-bit, to minimalna sensowna wielkość pamięci RAM to 8 GB bo jest to najmniejsza ilość możliwa do zamontowania, a większa od 5,5 GB.

Dnia 16.05.2008 o 22:15, GeoT napisał:

A tak tracisz ponad 700 mb ramu zupełnie za friko ...

Niewiele traci. Wykorzystanie pamięci z XP powyżej 2,3 GB ma sens tylko posiadając procesor conajmniej dwurdzeniowy i uruchamiając w tle np. program seti@home z parametrem wykorzystania maksymalnej pamięci ram (2 GB). Do granicy przydziału 1 GB dla seti@home nie ma żadnej różnicy. Ewentualnie w tle można odpalać jakieś renderowanie zdjęć na tych samych warunkach.

[Olamagato 3]

Dnia 16.05.2008 o 23:26, KrzysztofMarek napisał:

Zresztą nawet jak jakaś gra zajmie mi 2 GB, to zawsze zostanie mi jeszcze 1,25GB na system, antywirusa i co tam jeszcze...

Dokładnie. Jak napisałem do GeoT możesz jeszcze w tle zapchać jakieś 900 MB i nadal nie odczujesz żadnej różnicy na dwurdzeniowcu.
Gdyby pojawiła się gra, która robi triki i tak naprawdę składa się z dwóch aplikacji, które łącznie zabierają więcej niż 2 GB ramu (możliwe, że się taka za jakiś czas pojawi), to i tak w pełni wystarczy pamięci na tym co jest (wykopując seti itp.).

[GeoT 0]

Czyli kompletnej bzdury tam wyżej nie napisałem :)
Mam w tej chwili u siebie 4GB ramu i nawet nie wiem czy jest i jak duży plik wymiany.
W trakcie jakiejkolwiek pracy system wskazuje wykorzystanie pamięci na poziomie 33% i to bez względu na to co bym włączył i jak dużo. Jeśli chodzi i wydajność systemu moim zdaniem jest ok, więc nie wiem czy wyczułbym różnicę przy 8 GB :)

[Olamagato 3]

Dnia 17.05.2008 o 05:23, GeoT napisał:

Czyli kompletnej bzdury tam wyżej nie napisałem :)
Mam w tej chwili u siebie 4GB ramu i nawet nie wiem czy jest i jak duży plik wymiany.

Jak napisałem możesz wyłączyć. Po 1-2 uruchomieniach być może nawet zauważysz różnicę - szczególnie jeżeli nie buforujesz dysku w pamięci flash (jedna z nowych usług Visty).

Dnia 17.05.2008 o 05:23, GeoT napisał:

W trakcie jakiejkolwiek pracy system wskazuje wykorzystanie pamięci na poziomie 33%
to bez względu na to co bym włączył i jak dużo.

Prawdopodobnie do tej granicy przydzielany jest bufor dyskowej pamięci cache i prawdopodobnie relokowalne części dużych programów są wywalane do pliku wymiany (co oczywiście jest w tym wypadku bez sensu). Zamiast więc szukać sposobu na zmuszenie zarządcy do sensownego działania, prościej zabrać mu zabawkę, którą nie umie się zbyt dobrze bawić. :)
No, ale zawsze najlepiej sprawdzić i przekonać się w praktyce. Przy okazji zmniejszysz fragmentację dysku, którą Windows zwiększa trzymając tam swoje swapy i manipulując nią w trybie automatycznego idioty.

Dnia 17.05.2008 o 05:23, GeoT napisał:

Jeśli chodzi i wydajność systemu moim zdaniem jest ok, więc nie wiem czy wyczułbym różnicę przy 8 GB :)

Wyczujesz dopiero gdy zaczniesz używać programów 64-bitowych, które na dzień dobry będą potrzebować conajmniej 4 GB fizycznego ramu. Obecnie takie programy to w zasadzie jedynie programy do renderingu filmów i zdjęć w wysokiej rozdzielczości oraz bardzo rozbudowane symulacje. Icho odpowiedniki 32-bitowe już nie istnieją, albo istnieją i oferują mniejsze możliwości zarówno w szybkości jak i w wielkości przetwarzania. Co do gier, to jeszcze nie istnieją na PC takie, które żądają więcej niż 2 GB ramu lub 4 GB ramu w wersji 64-bit..

[KrzysztofMarek 9]

Dnia 16.05.2008 o 23:51, Olamagato napisał:

> /.../ Od granicy 5,5 GB RAM Vista-64 staje się bezapelacyjnie szybsza od każdego
Windows XP i podaje programom 64-bit relatywnie więcej pamięci. /.../

Mniej więcej o ile szybsza?
Bo mógłbym sobie pozwolić na Vistę i jeszcze dodatkowe 4 GB RAM - razem to dałoby 8 GB.Tylko wywalić mniej wiecej 700-800 zł na podwyższenie wydajności o 5% to juz byłoby nieopłacalne, przynajmnie dla mnie. Vista - Vistą a stary XP trzyma sie dobrze i nie robi problemów. Dlatego czekam na następcę Visty.

[ConayR 0]

Dnia 16.05.2008 o 23:51, Olamagato napisał:

Tylko pamiętaj, że ze względu na budowę kodu X86-64 wielkość kodu wzrasta statystycznie
prawie dwukrotnie, co oznacza, że komputer działający w tym trybie będzie realnie potrzebował
dwa razy więcej RAM niż robiący to samo system 32-bitowy z programami 32-bitowymi.

Z całym szacunkiem, ale powtarzasz tą bzdurę w kółko i chyba czas, żeby Cię ktoś wreszcie naprostował. Nawet zakładając, że kod jest dwukrotnie większy (a nie jest) większą część pliku wykonywalnego zajmują dane. Zarówno dane hardkodowane (np. ciągi znaków na potrzeby własnych logów) jak i zasoby (formatki okien, teksty, ikony,...).

Zbudowałem 16 binariów (10 exe, 6 dll; najmniejszy plik 30kB, największy prawie 2MB) dla x86 i x64 (wszystkie bez informacji dla debuggera, z włączoną optymalizacją pod kątem wielkości) i sumaryczny stosunek wielkości poszczególnych binariów to 1 do 1.305. Zdecydowanie 64-bitowe binaria nie są dwukrotnie większe, prawda? W końcu dwukrotnie większe w przypadku architektury x64 wartości to wskaźniki i niektóre typy wbudowane, np: size_t który zmienia się z unsigned int na unsigned __int64. Kod nie opiera się jednak wyłącznie na nich. Przez większość czasu operujesz na danych o ustalonej przez Ciebie wielkości, która nie zmienia się między x86 a x64.

Jeśli interesuje Cię minimum i maksimum z mojego zestawienia, to wynosiły dla x64/x86 odpowiednio 1.17 (aplikacja z dużą ilością okien i innych zasobów) i 1.52 (aplikacja konsolowa, bez własnej ikony - jedyny wbudowany zasób to nazwa aplikacji i wersja programu).

Warto przy tym wspomnieć, że kompilatory x64 nie są wciąż jeszcze tak dopracowane jak kompilatory x86, więc ta różnica będzie się z czasem odrobinę zmniejszała. Jasne, zawsze kod x64 będzie większy, ale nigdy dwukrotnie, jak twierdzisz błędnie od bardzo dawna, a o średnio 30%. Znacznie większy wpływ na rozmiar binariów ma na przykład to czy używasz wyjątków w aplikacji, czy nie. Użycie wyjątków lub brak anotacji throw() w kodzie zwiększa rozmiar binariów o nawet kilkanaście procent.

Ogólnie miło byłoby, gdybyś między rzeczowe odpowiedzi i pożyteczne porady nie wciskał 64-bitowego FUDu. ;-)

[GanD 0]

Osobiście polecam wyłączyć usługę indeksowania i superfetch. Jedna i druga w praktyce do niczego się nie przydaje, a można zyskać (w moim przypadku na 2GB RAM) od 5 do 10% wolnego RAM i dysk już tak nie muli jak wcześniej.

[Olamagato 3]

Dnia 17.05.2008 o 09:27, ConayR napisał:

Zbudowałem 16 binariów (10 exe, 6 dll; najmniejszy plik 30kB, największy prawie 2MB) dla x86 i x64

Pisałeś coś w assemblerze X86-64, albo jakimkolwiek innym dla procesora RISC? :)
Kompilator zawsze optymalizuje kod, a ostatnio wszystkie kompilatory 64-bit optymalizują pod względem wielkości kodu, a nie szybkości działania.

Dnia 17.05.2008 o 09:27, ConayR napisał:

Zdecydowanie 64-bitowe binaria nie są dwukrotnie większe, prawda?

Napisałem, że dwukrotnie większe w najmniej optymistycznym przypadku ("prawie"). Poza tym jeżeli pod program podciągasz również dane to mówimy o czymś zupełnie innym.
Kod musi być dwukrotnie większy nawet z rozkazami zawierającymi pojedyncze dane do ładowania bo:
1. Kody rozkazów stają się dwa razy dłuższe (aczkolwiek nie muszą - to jest cecha zależna od mikrokodu w procesorach CISC lub od kodu dla maszyny wirtualnej). Natomiast w kodzie dla procesorów RISC rozkazy zawsze są dwa razy dłuższe porównując kod 64-bit do 32-bit.
2. Wielkość podstawowej danej zasadniczo jest równa standardowej długości rejestrów ogólnego przeznaczenia. Jeżeli dane nie są równe, to procesor musi się bawić w kosztowne czasowo wydłużanie/skracanie danych (dopasowywanie ich do rejestrów).

Krótko mówiąc. Nawet jeżeli znak jest zapisany w 8 czy 16 bajtach, to procesor musi do sprawnego przetwarzania zrobić z niego daną 64-bitową. Jak to robi i czy jest to opłacalne czasowo to zupełnie inna sprawa. Można więc wrzucić po kolei ciąg 8-bitowych znaków i niech się procesor bawi w ich ładowanie i rozkładanie po rejestrach, albo wrzucić po kolei ciąg tych samych znaków wyrównanych do 64-bitowych słów, co daje nam ośmiokrotne powiększenie kodu, ale i zależnie od rodzaju pamięci czasem nawet znaczące przyspieszenie operacji (gdy cache stale pudłuje).
Np. przy szybkiej obróbce ponad 6 mld znaków w pamięci, (a taka ma miejsce przy analizie, porównaniach, kompresji) różnica między szybkością obróbki ściśniętych znaków 16-bitowych, a wyrównanych do 64-bitowych słów jest jak 1:5(!). Głupie 500% wydajności, kosztem zużycia 4 razy więcej pamięci ram. I weź pod uwagę, że wtedy cache dzisiejszych procesorów pudłuje niemal cały czas (jakieś 20% trafień). Nie jest pewne czy w przyszłości zoptymalizowane pod kątem wydajności programy nie będą zużywać znacznie więcej pamięci niż dzisiaj w kodzie 64-bitowym - szczególnie jeżeli pamięć jest relatywnie tania. Dzisiaj mamy sytuację, że programy nie potrafią w pełni wykorzystać mocy komputerów PC, ale ta sytuacja za jakiś czas może być odwrotna. A ja nie jestem prorokiem i nie wiem jak będą zoptymalizowane programy w przyszłości.

Dnia 17.05.2008 o 09:27, ConayR napisał:

W końcu dwukrotnie większe w przypadku architektury x64 wartości to wskaźniki

A to jest zasadnicza część wielkości współczesnego i bardzo skomplikowanego kodu. Wskaźnika nie zetniesz do mniejszego rozmiaru.

Dnia 17.05.2008 o 09:27, ConayR napisał:

Przez większość czasu operujesz na danych o ustalonej przez Ciebie wielkości, która nie zmienia się między x86 a x64.

Masz rację.

Dnia 17.05.2008 o 09:27, ConayR napisał:

x64/x86 odpowiednio 1.17 (aplikacja z dużą ilością okien i innych zasobów) i 1.52 (aplikacja
konsolowa, bez własnej ikony - jedyny wbudowany zasób to nazwa aplikacji i wersja programu).

W porządku. Kod AMD wygrał również m. in. dlatego, że najbardziej optymistyczne kodowanie bardzo odbiega od bardzo pesymistycznego dwukrotnego powiększenia kodu.
Prościej jest jednak użyć po prostu kodu 32-bitowego (gdy rozmiar kodu i danych nie przekracza 4 GB). Wtedy masz najmniejszy rozmiar, a procesor działa prawie równie wydajnie, tyle że na pół gwizdka.

Dnia 17.05.2008 o 09:27, ConayR napisał:

Warto przy tym wspomnieć, że kompilatory x64 nie są wciąż jeszcze tak dopracowane jak
kompilatory x86, więc ta różnica będzie się z czasem odrobinę zmniejszała.

Generatory kodu aż tak bardzo się w czasie nie zmieniają. A to jedyna zmienna rzecz w kompilatorze X86 kontra X86-64

Dnia 17.05.2008 o 09:27, ConayR napisał:

Jasne, zawsze kod x64 będzie większy, ale nigdy dwukrotnie

Maksymalnie dwukrotnie. Przy dużych programach może to być zajętość pamięci nawet więcej niż 1:1,7.
Jeżeli testuje się w małej skali, to nigdy nie będzie miarodajnych wyników.

Dnia 17.05.2008 o 09:27, ConayR napisał:

a o średnio 30%.

Pod warunkiem, że liczysz całe programy wraz z danymi, i to te specyficzne dla PC. Na przykład grafika już od dawna posługuje się danymi 64- i 128 bitów, a nawet 256-bitów, więc różnic w tej części nie będzie niemal żadnych w stosunku do kodu 32-bit. Podobnie co do tekstów (bo niemal nikt nie stosuje wyrównania 64-bit - za mało opłacalne w 99% przypadków).

Dnia 17.05.2008 o 09:27, ConayR napisał:

Ogólnie miło byłoby, gdybyś między rzeczowe odpowiedzi i pożyteczne porady nie wciskał 64-bitowego FUDu. ;-)

Fajnie gdybyś jednak zauważył, że chodziło o jednoznaczne pokazanie warunków w których Vista-64 na pewno będzie szybsza i wydajniejsza od XP-32. A wtedy należy do porównania brać przypadek najbardziej pesymistyczny.
Pozdrawiam.
ps. Mało na gramie jest ludzi, którzy coś piszą.

[Olamagato 3]

Dnia 17.05.2008 o 11:21, GanD napisał:

Osobiście polecam wyłączyć usługę indeksowania

Wyłączyłem w 2004 gdy okazało się, że z indeksowaniem czy nie pieskie wyszukiwanie plików w Windows nie potrafi znaleźć wszystkiego co powinno. :)

[ConayR 0]

> Pisałeś coś w assemblerze X86-64, albo jakimkolwiek innym dla procesora RISC? :)
Tak i tak, ale jakie to ma znaczenie i dlaczego piszesz o RISC, skoto zarówno x86 jak i x64 to CISCowe procesory?

> Kompilator zawsze optymalizuje kod, a ostatnio wszystkie kompilatory 64-bit optymalizują
> pod względem wielkości kodu, a nie szybkości działania.
Kompilator od zawsze kompiluje tak jak mu każesz. Kod kompiluje się pod kątem wielkości, żeby zapewnić aplikacji częstsze trafianie w cache (co w praktyce oznacza szybsze działanie). Rozmiary binarek podałem wyłącznie, żeby pokazać, że stosunek wielkości binarki 32- i 64-bitowej nie jest silnie zależny od rozmiaru aplikacji.

> Napisałem, że dwukrotnie większe w najmniej optymistycznym przypadku ("prawie").
Cóż, w moim słowniku ani 30% ani 50% to nie "prawie dwukrotnie więcej" (100%). Mając 9 lat nie jesteś "prawie pełnoletni".

> jeżeli pod program podciągasz również dane to mówimy o czymś zupełnie innym.

Nie, nie mówimy o czymś zupełnie innym. Wszystkie segmenty aplikacji ładowane są do pamięci przy jej starcie. Nie ma znaczenia, czy program ma 90% kodu czy 90% zasobów - jeśli exe waży 1MB to program zajmie przy starcie w pamięci 1MB (odrobinę więcej z racji fragmentacji przy podziale na segmenty). Co się dzieje po załadowaniu aplikacji, to już zupełnie inna historia, ale i ona jest niezależna od architektury (zakładając, że poruszamy się między x86 i x64).

> 1. Kody rozkazów stają się dwa razy dłuższe (aczkolwiek nie muszą - to jest cecha zależna
> od mikrokodu w procesorach CISC lub od kodu dla maszyny wirtualnej). Natomiast w kodzie
> dla procesorów RISC rozkazy zawsze są dwa razy dłuższe porównując kod 64-bit do 32-bit.
Ale ani x64 ani x86 nie są procesorami RISC. Poza tym praktyka pokazuje, że nawet procesory RISC mają zmienną wielkość słowa maszynowego (przykładowo każdy ARM od czasów ARM7 wyposażony jest w tryb Thumb). Ale znowu - to nie ma znaczenia, bo Vista nie pracuje na RISCach.

> 2. Wielkość podstawowej danej zasadniczo jest równa standardowej długości rejestrów ogólnego
> przeznaczenia. Jeżeli dane nie są równe, to procesor musi się bawić w kosztowne czasowo
> wydłużanie/skracanie danych (dopasowywanie ich do rejestrów).

Prawie każdy procesor ma operandy ładowania z konwersją wielkości, które wykonują się w jednym cyklu. Nazywanie ich kosztownymi w sytuacji, w której takie ładowanie kosztuje tyle samo, co ładowanie bez skracania, nie ma najmniejszego oparcia w rzeczywistości. Gdyby prawdą było to, co piszesz, każdy typ zmiennej w C, który nie jest równy wielkości "bitowości" maszyny, byłby wolny. Nie jest to prawdą (pod warunkiem, że dane są wyrównane w pamięci, ale zarówno w przypadku x86 jak i x64 wyrównuje się do granicy ich wielkości a nie do granicy 32 czy 64 bitów).

> Krótko mówiąc. Nawet jeżeli znak jest zapisany w 8 czy 16 bajtach, to procesor musi do
> sprawnego przetwarzania zrobić z niego daną 64-bitową. Jak to robi i czy jest to opłacalne
> czasowo to zupełnie inna sprawa.

Nie, nie jest to prawdą. Zrób sobie zrzut pamięci jakiejś struktury zawierajacej dane o różnym rozmiarze. Zrzut będzie identyczny zarówno na x86 jak i x64. Jeśli mocno nalegasz, mogę Ci wkleić logi z windbg, które to potwierdzą. Odnoszę jednak niejasne wrażenie, że Ciebie nie przekona żaden dowód.

> Można więc wrzucić po kolei ciąg 8-bitowych znaków i
> niech się procesor bawi w ich ładowanie i rozkładanie po rejestrach, albo wrzucić po
> kolei ciąg tych samych znaków wyrównanych do 64-bitowych słów, co daje nam ośmiokrotne
> powiększenie kodu, ale i zależnie od rodzaju pamięci czasem nawet znaczące przyspieszenie
> operacji (gdy cache stale pudłuje).

Nie, kod przy ładowaniu do pamięci nie jest rozrzedzany tak, żeby pasował do 32 czy 64 bitów. Masz błędne wyobrażenie na temat tego co się dzieje zarówno z pamięcią jak i z procesorem. Jeśli dwie dane 8-bitowe wymagają zsumowania, nic nie stoi na przeszkodzie, by umieścić je w dwóch bajtach jednego słowa 64-bitowego rejestru. W wyższym słowie możesz nawet umieścić jeszcze jedną zmienną.

Zresztą jest to i tak bez znaczenia skoro każdy procesor od czasów P3 dokonuje translacji na mikrokod, przemianowywania rejestrów i szeregu innych sztuczek, które sprawiają, że większość Twoich rozważań teoretycznych ma się nijak do rzeczywistości.

> Np. przy szybkiej obróbce ponad 6 mld znaków w pamięci, (a taka ma miejsce przy analizie,
> porównaniach, kompresji) różnica między szybkością obróbki ściśniętych znaków 16-bitowych,
> a wyrównanych do 64-bitowych słów jest jak 1:5(!). Głupie 500% wydajności, kosztem zużycia
> 4 razy więcej pamięci ram.
Tak, tylko że żaden 64-bitowy procesor jaki znam nie MUSI pracować na 64-bitowych danych. W ogóle większość Twoich błędnych wyobrażeń wywodzi się z przekonania, że procesor coś musi. Nie musi. Core 2 Duo na systemie 32-bitowym jak i na systemie 64-bitowym wykona tak samo szybko operację na tekście UNICODE (16 bitów na znak). Nie ma miejsca rozdymanie tekstu, bo sposób zapisania tekstu w pamięci nie jest zależny od architektury (pomijam różnice kolejności dla procesoró little/big endian).

> I weź pod uwagę, że wtedy cache dzisiejszych procesorów pudłuje
> niemal cały czas (jakieś 20% trafień).
Nie wiem skąd wziąłeś tą liczbę, ale jest błędna. Przeczy chociażby lokalności danych i kodu.

> Nie jest pewne czy w przyszłości zoptymalizowane
> pod kątem wydajności programy nie będą zużywać znacznie więcej pamięci niż dzisiaj w
> kodzie 64-bitowym - szczególnie jeżeli pamięć jest relatywnie tania.
Ale ja nie piszę tutaj na temat tego jaką deweloperkę będzie się w przyszłości praktykowało. Co to ma do rzeczy? Jasne, że większość problemów można rozwiązać algorytmami w stałym czasie lub przestrzeni (bo to jedyny powód dlaczego w przyszłości programy miałyby zajmować więcej pamięci).

> Dzisiaj mamy sytuację,
> że programy nie potrafią w pełni wykorzystać mocy komputerów PC, ale ta sytuacja za jakiś
> czas może być odwrotna. A ja nie jestem prorokiem i nie wiem jak będą zoptymalizowane
> programy w przyszłości.
No nie wiem. Czasem, kiedy Opera mi łyka 100% czasu jednego z rdzeni dochodzę do wniosku, że potrafi "wykorzystać" całą moc mojego procesora...

> > W końcu dwukrotnie większe w przypadku architektury x64 wartości to wskaźniki
> A to jest zasadnicza część wielkości współczesnego i bardzo skomplikowanego kodu. Wskaźnika
> nie zetniesz do mniejszego rozmiaru.
Wskaźniki zasadniczą wielkością współczesnego kodu? Ciekawa teoria, jakże błędna. Program operuje na danych a nie na wskaźnikach. Dane mają to do siebie, że przeważnie nie występują pojedynczo. Ile wspaźników potrzebujesz do ciągu 100 znaków? Jednego. Ile wskaźników potrzebujesz do tablicy 1000 struktur, 1kB każda? Jednego.

> W porządku. Kod AMD wygrał również m. in. dlatego, że najbardziej optymistyczne kodowanie
> bardzo odbiega od bardzo pesymistycznego dwukrotnego powiększenia kodu.
Co to jest bardzo optymistyczne kodowanie?

> Prościej jest jednak użyć po prostu kodu 32-bitowego (gdy rozmiar kodu i danych nie przekracza
> 4 GB). Wtedy masz najmniejszy rozmiar, a procesor działa prawie równie wydajnie, tyle
> że na pół gwizdka.
Nie, procesor nie działa równie wydajnie, ale na pół gwizdka. Jeśli odpalasz aplikację 32-bitową na 64-bitowym systemie, wszystko podlega translacji w WOW64. Dlatego tak ważne jest, żeby większość kodu na 64-bitowym systemie była 64-bitowa (tutaj soczyste faki dla Adobe za brak 64-bitowego flash playera).

> Generatory kodu aż tak bardzo się w czasie nie zmieniają. A to jedyna zmienna rzecz w
> kompilatorze X86 kontra X86-64
Zdziwiłbyś się jak często zmienia się kompilator i ile nowych optymalizacji powstaje w roku.

> Maksymalnie dwukrotnie. Przy dużych programach może to być zajętość pamięci nawet więcej
> niż 1:1,7.
Nigdy dwukrotnie. Nie w przypadku x86 vs x64. Jest to fizycznie niemożliwe, choćby przez to, że część Twojej binarki to loader CRT, który nie jest dwukrotnie większy dla x64 niż dla x86. Duże programy z kolei mają to do siebie, że coraz mniejszy % ich rozmiaru to kod.

> Jeżeli testuje się w małej skali, to nigdy nie będzie miarodajnych wyników.
Rozumiem, że 15MB to mała skala. Chcesz, porównam Ci binarki o łącznym romiarze powyżej 1GB. Zadowoli Cię to?

> Pod warunkiem, że liczysz całe programy wraz z danymi, i to te specyficzne dla PC. Na
> przykład grafika już od dawna posługuje się danymi 64- i 128 bitów, a nawet 256-bitów,
> więc różnic w tej części nie będzie niemal żadnych w stosunku do kodu 32-bit. Podobnie
> co do tekstów (bo niemal nikt nie stosuje wyrównania 64-bit - za mało opłacalne w 99%
> przypadków).
Po pierwsze: to temat o Viście. Udzielasz ludzio rad na temat Visty 32bit i 64bit pisząc nieprawdę na temat zużycia pamięci. Czy to specyficzne dla PC nie ma znaczenia, ten temat jest specyficzny dla PC. Po drugie uzasadnij proszę dlaczego nikt nie stosuje wyrównania do 64-bit i wyrównania czego konkretnie.

> Fajnie gdybyś jednak zauważył, że chodziło o jednoznaczne pokazanie warunków w których
> Vista-64 na pewno będzie szybsza i wydajniejsza od XP-32. A wtedy należy do porównania
> brać przypadek najbardziej pesymistyczny.
Masło maślane. Vista działa równie wydajnie zarówno na x86 jak i x64. Nie prawdą jest też, że na x64 "zużywanych niest prawie 2x więcej pamięci". Odnosiłem się wyłącznie do tego, a Ty zacząłeś dryfować w kierunku RISCów, kart graficznych i Bóg wie czego jeszcze. Cieszy mnie entuzjazm z jakim odpowiadasz na problemy ludzi, ale chyba najwyższy czas przestać wprowadzać w błąd odnośnie 64-bitowej Visty. Każdy kto ma 3GB RAMu lub więcej powinien używać 64-bitowej Visty. Sterowniki nie są już problemem a wydajność (zarówno prędkość jak i wykorzystanie pamięci) nie cierpią w porównaniu z x86.

> ps. Mało na gramie jest ludzi, którzy coś piszą.
Mało jest na GRAMie ludzi, którzy mają coś do napisania. ;-)

[exlibris 0]

Witam. Mam zainstalowanego windowsa xp proffesional, oraz zakupioną, czekającą na instalację Vistę. Jak najprościej wyczyścić całkowicie, sformatować i podzielić na partycje dysk, żeby zainstalować "na czysto"?

[KrzysztofMarek 9]

Dnia 19.05.2008 o 21:58, exlibris napisał:

Witam. Mam zainstalowanego windowsa xp proffesional, oraz zakupioną, czekającą na instalację
Vistę. Jak najprościej wyczyścić całkowicie, sformatować i podzielić na partycje dysk,
żeby zainstalować "na czysto"?

Nie będzie to dobra odpowiedź na Twoje pytanie, ale dla mnie najprościej byłoby dokupić drugi dysk twardy i na nim zainstalować Vistę. Nie niszczysz swoich danych, nie masz kłopotu z partycjami, oszczędzasz czas. Niektóre programy wprawdzie instalujesz w Viście drugi raz, ale fizycznie pozostaja one tam, gdzie sa teraz i nie musisz ich aktywizować drugi raz.

[KrzysztofMarek 9]

Dnia 17.05.2008 o 14:04, ConayR napisał:

> Każdy kto ma 3GB RAMu lub więcej
powinien używać 64-bitowej Visty. Sterowniki nie są już problemem a wydajność (zarówno
prędkość jak i wykorzystanie pamięci) nie cierpią w porównaniu z x86. /.../

Moja wiedza w porównaniu do Twojej (na tematy komputerowe oczywiście) jest żadna, ale z tym twierdzeniam się nie zgodzę.
Każda nowość kosztuje, a korzyści z poniesionych nakładów powinny być takie, żeby sie nakłady opłacały. Mnie się koszt wdrożenia Visty nie opłaca, możesz mi wskazać, takie korzyści, żeby opłacał mi sie zakup Visty i odstawienie WinXP? Mam 4GB Ram i E 8400.

[exlibris 0]

Dnia 19.05.2008 o 22:58, KrzysztofMarek napisał:

Nie będzie to dobra odpowiedź na Twoje pytanie, ale dla mnie najprościej byłoby dokupić
drugi dysk twardy i na nim zainstalować Vistę. Nie niszczysz swoich danych, nie masz
kłopotu z partycjami, oszczędzasz czas. Niektóre programy wprawdzie instalujesz w Viście
drugi raz, ale fizycznie pozostaja one tam, gdzie sa teraz i nie musisz ich aktywizować
drugi raz.

Aha. Nie mam tam żadnych danych, oprócz niepotrzebnego xp. Dysk jest nowy.

[KrzysztofMarek 9]

[ConayR 0]

>>> Każdy kto ma 3GB RAMu lub więcej powinien
>>> używać 64-bitowej Visty. Sterowniki nie są już problemem a wydajność (zarówno
>>> prędkość jak i wykorzystanie pamięci) nie cierpią w porównaniu z x86. /.../

Dnia 19.05.2008 o 23:04, KrzysztofMarek napisał:

Moja wiedza w porównaniu do Twojej (na tematy komputerowe oczywiście) jest żadna, ale
z tym twierdzeniam się nie zgodzę.

Każdy ma prawo się ze mną nie zgadzać. :-)

Dnia 19.05.2008 o 23:04, KrzysztofMarek napisał:

Każda nowość kosztuje, a korzyści z poniesionych nakładów powinny być takie, żeby sie
nakłady opłacały. Mnie się koszt wdrożenia Visty nie opłaca, możesz mi wskazać, takie
korzyści, żeby opłacał mi sie zakup Visty i odstawienie WinXP? Mam 4GB Ram i E 8400.

Jeśli używasz XP 64-bitowego i nie interesuje Cię żadne z usprawnień Visty (od lepszej hibernacji, przez WDDM i DX10, po backup czy lepsze bezpieczeństwo systemu) to pewnie nie ma powodu, byś zmieniał system. Jeśli jednak używasz 32-bitowego XP mając 4GB RAMu, to z przykrością informuję Cię, że kilkaset mega nigdy nie jest używane. Jeśli interesują Cię detale, opisałem je tutaj:
http://forum.gram.pl/forum_post.asp?tid=6741&tpage=172

W skrócie: architektura PC wymaga zmapowania urządzeń w pamięci fizycznej. W praktyce oznacza to, że im więcej własnej pamięci ma np. Twoja karta graficzna, tym więcej z obszaru adresowego zabiera. Jako że 4GB to maksimum jakie można zaadresować w 32bitach, zmapowana pamięć karty graficznej przykryje część pamięci RAM czyniąc ją niedostępną.

[KrzysztofMarek 9]

Dnia 19.05.2008 o 23:34, ConayR napisał:

>>> /.../ Jako że 4GB to maksimum jakie można zaadresować w 32bitach, zmapowana
pamięć karty graficznej przykryje część pamięci RAM czyniąc ją niedostępną.

Wiem o tym. Mój WinXP, 32 bitowy, używa jedynie 3,25 GB.
Mogę kupić Vistę i jeszcze 4 GB RAM (powiedzmy, że wydam 700 zł) co co będę z tego miał (satysfakcji nie wliczam do korzyści)P.S.
Co do wygody i bezpieczeństwa, to nie sądzę, abym się obył bez antywirusa, a z innych, to już Win2000 był satysfakcjonujacy (z SP 4, bo juz tylko taki był do kupienia).

[ConayR 0]

Dnia 19.05.2008 o 23:38, KrzysztofMarek napisał:

Wiem o tym. Mój WinXP, 32 bitowy, używa jedynie 3,25 GB.
Mogę kupić Vistę i jeszcze 4 GB RAM (powiedzmy, że wydam 700 zł) co co będę z tego miał
(satysfakcji nie wliczam do korzyści)P.S.

Vista na 2GB chodzi równie dobrze jak XP. Ty masz 4GB, więc nie rozumiem po co miałbyś dokupić kolejne 4GB. Nie, żeby to zaszkodziło w czymkolwiek. :-) Jedynie jest to IMO zbędny wydatek.

Co będziesz z tego miał? Nie wiem do czego kompa używasz. Na nowszych sterownikach zarówno DX9 jak i DX10 osiągają lepszą wydajność. Jeśli używasz akcelerowanych schematów (Aero/Aero Glass) to zużycie procesora w stanie bezczynności jest niższe niż na XP (bo rysowanie przejmuje GPU; do tej pory wszystko szło przez software''owe GDI a nawet taka prosta czynność jak maskowanie obszarów kosztuje). Jeśli składasz amatorsko wideo, nowy Movie Maker jest znacznie lepszy od tego z XP. Masz wbudowanego Windows Defendera, na 64-bitowym OSie działa Ci DEP/NX uniemożliwiający wykonanie kodu przez przepełnienie bufora. Wreszcie masz UAC, lepszą separację procesów i sesji, grupowanie w eksplorerze, wydajny desktop search, nowy Windows Mail i Windows Calendar (jeśli nie używasz Office), moduł dyktujący i rozpoznawania mowy (doskonały po angielsku czy chińsku, możesz niestety zapomnieć o polskim...). Nowy lepszy defrag, lepsze wsparcie dla dysków dynamicznych, poprzednie wersje plików z migawek, SuperFetch i ReadyBoost, poprawiony paint, gierki...

Powodów jest wiele, ale ja nie wiem do czego używasz kompa. Jeśli odpalasz go żeby sprawdzić pocztę, pobuszować po sieci i od czasu do czasu odpalasz jakąś gierkę albo oglądasz film, to nie masz silnego powodu by się przesiąść. Możesz mieć wiele malutkich, ale niczego w stylu: OMG, muszę TO mieć! :-]

Dnia 19.05.2008 o 23:38, KrzysztofMarek napisał:

Co do wygody i bezpieczeństwa, to nie sądzę, abym się obył bez antywirusa, a z innych,
to już Win2000 był satysfakcjonujacy (z SP 4, bo juz tylko taki był do kupienia).

Oczywiście, że potrzebujesz antywirusa. Póki Windows ma udział w rynku jaki ma, opłaca się eksploatować w nim luki. Każde oprogramowanie o wystarczająco silnej penetracji rynku ma znajdowane dziury. :-)

[Darkstar181 0]

Wczoraj zainstalowałem świetną, wspaniałą, nową Vistę, i oczywiście od razu są do diabła z nią problemy.
Mianowicie chciałem wyłączyć komputer, i od niechcenia (wiem,głupota boli) nie szukałem opcji wyjścia (która w XP była WIDOCZNA, a w Viście nie). W końcu kliknąłem na opcję po prawej po rozwinięciu paska z symbolem kółka z kreską w środku (czyli symbol mocy, włączenia systemu i tak dalej) Ekran się ściemnił (tak jak przy wylogowywaniu)
po czym monitor przestał cokolwiek wyświetlać, prócz napisu " tryb oszczędny ". Po czym komputer przestał na cokolwiek reagować.

Dzisiaj nie mogę uruchomić systemu, cały czas jest na monitorze pisze tryb oszczędnościowy.
Czy ktoś może mi powiedzieć jaką ja kurna opcję włączyłem !? I co ważniejsze, jak ją kurną, WYŁĄCZYĆ. Przypominam, była to opcja z symbolem tego kółka z kreską, po prawej stronie rozwiniętego paska.
Acha, sam system to Vista HOME premium, 64 bitowa. Monitor to 19 LCD (nie wiem czy ma to znaczenie, ale po podłączeniu do innego komputera monitora jest ta sama sytuacja.