Windows XP64 przesunięty na 2005

1. Hmm... (autor: DJopek | data: 28/07/04 | godz.: 13:30)
   Szkoda, bo gdyby MS wprowadził 64-bitowy system wreszcie AMD64 rozwinął by skrzydła...
   
   
2. a co Intelowi się procek (autor: Chrisu | data: 28/07/04 | godz.: 13:48)
   chrzani i M$ czeka??
   
   
3. Intel , AMD64 , M$ (autor: RusH | data: 28/07/04 | godz.: 14:06)
   Po pierwsze NIGDZIE sieci nie ma ANI JEDNEGO testu EM64T, a _przecieki_ od ludzi majacych okazje go testowac testowac (tylko BETA XP64 opatrzona klauzula non disclosure dziala na EM64T) sa raczej niezbyt zachwycajace, cos w rodzaju "nie wierzylismy w wyniki, to nie mozne tak tragicznie wygladac" :)
   
   AMD64 radzi sobei bardzo doberze, jest 64Bitowy Linux, na dniach praktycznie wyjdzie 64Bitowy Solaris. M$ ma chyba jakas cicha umowe z Intelem i BARDZO na niej straci. Ludzie CHCA 64bity .. a M$ ich olewa. Ludzie dostana swoje 64Bity od IBMa (Linux) albo od SUNa (Solaris) i obsikaja M$
   
   
4. Rush (autor: ixxos | data: 28/07/04 | godz.: 18:17)
   nie zgadzam się -Intel Z m$ ;) niestety ale dokopią tym AMD-całe szczęście że są bardzo wydajne w aplikacjach 32 bitowych
   Dla Linuxa a tym bardziej SUNa nikt nie będzie kupował 64bitowych drogich proców do zastosowań domowych -desktopowych
   -nie ta branża -mają zastowanie w serwerach, czy maszynach obliczeniowych ale wciąż mówimy tutaj o czym innym -o zwykłych aplikacjach dla przeciętnego i jednocześnie bardzo wymagającego użytkownika... AMD się pośpieszył i teraz będzie tracił, może obniży ceny??
   bo sprzedaż spadnie
   zresztą wymieńcie aplikacje -programy, gry, multimedia które są przygotowane i wykorzystują te 64bit na razie o tym ciszaaa
   
   
5. dokładnie tak (autor: h-doc | data: 28/07/04 | godz.: 18:30)
   na co komu dzisiaj 64 bity? Czego nie da się zrobić na 32 bitach jeśli chodzi o zastosowania konsumenckie (nie-profesjonalne)?
   Też jestem zdania, że na 64 bity jeszcze nie przyszła pora. Także opóźnienie nowego Windowsa ani mnie ziębi ani parzy.
   
   
6. dokładnie o tym samym pomyślałem (autor: beef | data: 28/07/04 | godz.: 21:51)
   zauważcie, że rynek profesjonalny (mam na myśli tzw "biznesowy"), wyłączając wąskie specjalizacje (super wydajne serwery itp), jest przeważnie jeszcze bardziej konserwatywny jeśli chodzi o wszelkie nowinki. Już widzę te masy firm masowo przechodzące na linuxa by mieć system informatyczny, który będzie działał dokładnie tak samo jak poprzedni, ale na 64 BITACH (wytłumaczcie to pani Joli z księgowości :)) Z kolei na rynku konsumenckim głównym motorem napędowym technologicznych nowości są GRY, z tym że to raczej one sterują rozwojem sprzętu, nie na odwrót. Przejście na 64 bity jest pewnie nieuniknione (tak jak kiedyś z 8 a potem z 16), z tym że wtedy wyraźnie było widać kres możliwości ówczesnych technologii, a teraz... chyba tylko kres możliwości speców od marketingu :)
   
   
7. przy okazji (autor: beef | data: 28/07/04 | godz.: 22:25)
   4GB (koniec przestrzeni adresowej przy 32 bitach, przynajmniej dla jednej aplikacji) to 8x więcej niż obecny standard 512MB. 8x mniej niż 512 to 64MB. Pamiętacie, kiedy był to standard? Bo tyle mniej więcej nas czeka :) W sumie tylko to może zmusić do zmiany. Nowe zestawy instrukcji to miły gadżet, ale IHMO dla 99% programistów (nie mówiąc o użytkownikach) bez znaczenia. Nikt już nie pisze w assemblerze, a kompilatory są na full wypasie. Poza tym całkowite liczby większe niż 32-bitowe były mi potrzebne może 2 razy, i to bynajmniej nie w krytyczbych wydajnościowo miejscach, a piszę naprawdę najprzeróżniejsze rzeczy. Nawet w dużych bazach danych rzadko stosuje się indeksy>32bit i bynajmniej nie procesor jest tu wąskim gardłem. Co więcej, jest wyraźna tendencja (Java+.NET) do porzucenia kodu natywnego na rzecz VM i kompilacji JIT itd...
   
   
8. niee (autor: RusH | data: 29/07/04 | godz.: 01:11)
   powoli,
   po pierwsze przestrzen adresowa, obecnie jest to 4GB w teorii, z czego na prawde mozna zaadresowac 3.5GB (reszta idzie na smiecie systemowe)
   obecnie UT2004 ma 2GB stuffu do wyswietlania na HDD, nowy Engine Unreala ma miec 2GB stuffu w RAMIE do wyswietlania :) i wtedy juz TRZEBA miec platforme 64bit
   
   po drugie 64bit nie wymaga specjalnego pisania aplikacji - zyskuje sie glownie na wiekszej liczbie rejestrow, same bity daja naprawde niewiele
   
   po trzecie Linuks - firmy MASOWO na niego przechodza, Hiundaj, Samsung, Nowell
   
   64bioty to nie jakies mitycznie 2x 32bity, to tylko wieksza przestrzen adresowa ramu + 2x wiecej rejestrow (nie trzeba niczego pchac na stos) + kilka dodatkowych "duzych" instrukcji. Nie potrzeba do tego pisania programow od nowa - na tym polega poteka AMD64 , wystarczy rekompilacja z parametem/64bit i JUZ , program zaczyna chodzic szybciej !
   
   
9. no tak (autor: beef | data: 29/07/04 | godz.: 11:27)
   w sumie pisząc "bez znaczenia" miałem na myśli dokładnie to, że programy będzie się pisać dokładnie tak samo :) Innymi słowy gdyby nie zbliżająca się powoli do końca przestrzeń adresowa nikt by za 64-bitami nie tęsknił, chociaż oczywiście to, że nie trzeba nic przepisywać od nowa można uznać za zaletę (+wzrost wydajności ofkors). Natomiast z tym RAM-em, to nadal podtrzymuję, że przejście od 512MB do 4GB zajmie prawdopodobnie tyle czasu co od 64MB do 512MB, ja wiem - ze 3 lata. Czyli intel ma jeszcze z rok rezerwy zanim zacznie się masowe zainteresowanie 64Bitami. Tak myślę. Tak czy inaczej konkurencja dobra rzecz.
   
   
10. beef (autor: RusH | data: 29/07/04 | godz.: 15:53)
    servery - tam minimum to 4GB , w serverze na Xeonach trzeba kombinoac z PAE (stronicowanie) i jest to SYF a nie rozwiazanie, w AMD64 masz liniowo tyle ramu ile chcesz i upchasz na plycie
    lepiej nie mozna sobei nawet wymarzyc
    
    
11. Ci ktorzy twierdzą, że AMD64 to zbytek (autor: dabia | data: 29/07/04 | godz.: 23:31)
    to samo najczęściej mówią o najnowszych kartach graficznych. A ja uważam, że 64 bity przydają się (ze względu na wydajność oczywiście, a nie naklejkę MAD64 na obudowie) naprawdę w wielu zastosowaniach. W przetwarzaniu grafiki 2D czy podczas renderingu 3D i w kodekach (na razie słabo z tego korzystają, ale skoro system i podstawowe oprogramowanie już działa na 64 bitach, to inne dodatki też zaczną być optymalizowane). Fakt, że na 64 bity trzeba wydać jakieś 100$ więcej (u krajowych dystrybutorów nie opłaca się kupować, bo platforma kosztuje 2x więcej niż w USA), ale choć trochę cieszy, że aby zwiększyć wydajność systemu wystarczy potem przez rok-dwa wymieniać tylko jądro lub aplikację na bardziej zoptymalizowaną pod AMD64 bez wydawania centa na szybszy procesor ;-)
    
    
12. dabia (autor: beef | data: 30/07/04 | godz.: 01:52)
    "Ci ktorzy twierdzą, że AMD64 to zbytek to samo najczęściej mówią o najnowszych kartach graficznych"
    
    To uproszczenie sprawy
    
    "W przetwarzaniu grafiki 2D czy podczas renderingu 3D i w kodekach(...)"
    
    W większości przypadków stosuje się teraz koprocesor, gdzie 64bity były "od zawsze" + SSE itp, ew MMX (128-bitowe rejestry od wielu, wielu lat). To nie w tym rzecz. 64 bity = większa przestrzeń adresowa. Więc to nie sam proc, tylko ew. proc + mnóstwo ramu, z którego aplikacje będą mogły skorzystać. Ale to nie stanie się z dnia na dzień. Niewielki przyrost szybkości może być w związku z optymalizacją pod wiekszą liczbę rejestrów, ale jak mówię, niewielki.
    
    Rush - jeśli chodzi o serwery, to mnie przekonałeś. Jeśli chodzi o aplikacje biznesowe i "zwykłych" klientów nadal uważam, że wszyscy będą mieli to w nosie przynajmniej jeszcze przez rok.
    
    
13. errrrr (autor: beef | data: 30/07/04 | godz.: 01:53)
    "aplikacje biznesowe" = klienckie, bo tu się da i serwery podpiąć :)
    
    
14. mocne workstacje (autor: RusH | data: 30/07/04 | godz.: 13:23)
    mocne workstacje wrecz blagaja o AMD64
    Xeony sie chowaja
    Mam wrazenie ze ty piszes o paniach Krysiach z ksiegowosci .. im ZAWSZE wystarczy najslabszy komputer z supermarketu, albo jescze lepiej sam Xterminal.
    
    
15. a ja bym wolał (autor: h-doc | data: 30/07/04 | godz.: 21:44)
    zamiast 64 bitów lepsze instrukcje multimedialne. W SSE czy SSE2 mogę przerobić na raz 4 liczby float. A czemu by nie wydłużyć rejestrów SSE i przerabiać od razu 8 lub 16 liczb? Do tego operacje z nasyceniem dla stałego przecinka, sprzętowe pętle... To by się naprawdę przydało, a tak cała para idzie w gwizdek (procek 2.4 GHz przy przetwarzaniu sygnału jest wolniejszy od DSP z zegarem o rząd mniejszym)