komentarze
Promilus1984Zobacz profil
Poziom ostrzeżenia: 0%
Promilus19842011.03.11, 10:14
No to teraz to ma sens ;) Jak wszyscy znający się w temacie zapowiadali... bez 64 bitów nie ma szans.
darkmartinZobacz profil
Poziom ostrzeżenia: 0%
darkmartin2011.03.11, 10:33
-1#2
Dell ocenił, że serwery na ARM nie wcześniej niż za 2 lata.
LupierzZobacz profil
Poziom ostrzeżenia: 0%
Lupierz2011.03.11, 10:35
-12#3
Super, ale ARM i 4GB ramu? Chyba ze do tych wersji 12 rdzeniowych :D
SunTzuZobacz profil
Poziom ostrzeżenia: 0%
SunTzu2011.03.11, 10:35
-14#4
Promilus1984 @ 2011.03.11 10:14  Post: 462125
No to teraz to ma sens ;) Jak wszyscy znający się w temacie zapowiadali... bez 64 bitów nie ma szans.

Tylko po co 64bity? O ile dla PC większego znaczenia to nie ma o tyle dla ARM, ma. Tu liczy się energoefektywność.

Czemu 64? Czemu nie np 48? 42? Nawet teoretyczny 38bitowy CPU byłby wstanie obsłużyć obsłużyć aktualnie dość abstrakcyjną ilość RAMU-256GB.
Promilus1984Zobacz profil
Poziom ostrzeżenia: 0%
Promilus19842011.03.11, 10:43
20#5
@SunTzu - a po co ci procek mający 38bit szynę i muszący przeliczać adresy w 2 cyklach (w 32bit rejestrach) jak może w 1 cyklu i 64bitowym rejestrze? :> Jasne, można by zrobić 'full 48bit architecture' tylko po co skoro to nie obsłuży żadnych istniejących standardów i trzeba by robić bardziej skomplikowane narzędzia programistyczne? Czemu były proce 4, 8, 16 i 32bit a nie 4, 6, 8, 10, 12, 13, 19... widać lepiej jest dublować a nie robić dziwadła (żeby nie było parę dziwadeł WYSZŁO, ale to były bardzo specyficzne zastosowania).
SunTzuZobacz profil
Poziom ostrzeżenia: 0%
SunTzu2011.03.11, 10:57
-22#6
Dobrze zoptymalizowane-dedykowane dziwadło, zwykle działa lepiej od przerostu formy nad treścią. Bo 64bity to obsługa 17 179 869 184 GB pamięci, (a nam wystarczyłyby tylko 3 ostatatnie cyfry:) ). Zrobienie dobrej architektury przez lata, na lata z dobrymi nardzędziami programistycznymi wystarczy. Tylko tu raczej trzeba kapitału intelektualne Intela/IBM na stworzenie czegoś takiego. Bo nawet AMD nie ma dobrych narzędzi programistycznych....

Oby tylko NV nie opatentowała 64bitowego CPU ARM (haha)
Promilus1984Zobacz profil
Poziom ostrzeżenia: 0%
Promilus19842011.03.11, 11:06
@SunTzu - GPU i CPU pracują nad wspólnym problemem. GPU jedzie na 64bit float i potrzebuje 64bitowych danych z dajmy na to 36bitowego CPU. Z 36 bitowymi ALU, rejestrami i liniami danych. Bezsens. Taki CPU albo prześle 36bit młodsze, a potem 28bit starsze z 8 zerami, albo 2x32bit z 4 zerami. Jak pisałem dziwolągi są dobre w specyficznych przypadkach - to nie jest jeden z tych przypadków. Takim przypadkiem może być np. współpraca z 18 bitowymi A/D lub innymi urządzeniami (oraz softem) przystosowanym do takich właśnie liczb.
GandalfGZobacz profil
Poziom ostrzeżenia: 0%
GandalfG2011.03.11, 11:22
SunTzu @ 2011.03.11 10:57  Post: 462141
Dobrze zoptymalizowane-dedykowane dziwadło, zwykle działa lepiej od przerostu formy nad treścią. Bo 64bity to obsługa 17 179 869 184 GB pamięci, (a nam wystarczyłyby tylko 3 ostatatnie cyfry:) ). Zrobienie dobrej architektury przez lata, na lata z dobrymi nardzędziami programistycznymi wystarczy. Tylko tu raczej trzeba kapitału intelektualne Intela/IBM na stworzenie czegoś takiego. Bo nawet AMD nie ma dobrych narzędzi programistycznych....

Oby tylko NV nie opatentowała 64bitowego CPU ARM (haha)


Zacznij pisać w ASM to szybko zmienisz zdanie i zaczniesz krytykować wszelkie odstępstwa od dobrych praktyk :)

Co do narzędzi programistycznych to nie one są źródłem niskiej jakości oprogramowania. Można mieć super narzędzia i pisać kiepski soft pełen błędów. Wystarczy spojrzeć na MS :)
Co do narzędzi których używa AMD to oni akurat mają jedne z lepszych i oprócz tego tworzą własne.
http://developer.amd.com/CPU/Pages/default.aspx
http://developer.amd.com/gpu/Pages/default.aspx
SunTzuZobacz profil
Poziom ostrzeżenia: 0%
SunTzu2011.03.11, 11:51
-10#9
@up
Mają świetne, ale np. kompilator OpenCL nie jest już taki wpsaniały intel, który ma 'tyle' tu wspólnego robi lepszy


Promilus1984 @ 2011.03.11 11:06  Post: 462145
@SunTzu - GPU i CPU pracują nad wspólnym problemem. GPU jedzie na 64bit float i potrzebuje 64bitowych danych z dajmy na to 36bitowego CPU. Z 36 bitowymi ALU, rejestrami i liniami danych. Bezsens. Taki CPU albo prześle 36bit młodsze, a potem 28bit starsze z 8 zerami, albo 2x32bit z 4 zerami. Jak pisałem dziwolągi są dobre w specyficznych przypadkach - to nie jest jeden z tych przypadków. Takim przypadkiem może być np. współpraca z 18 bitowymi A/D lub innymi urządzeniami (oraz softem) przystosowanym do takich właśnie liczb.


Ale po jakiego grzyba GPU? Po co 64bitowy CPU do gier? Ja myślałem, że to raczej do rozwiązań serwerowych. Patrz na konsole i zobacz ile one mają w sumie pamięci.

Ok... zróbmy CPU 256bitowy. Po co? NV będzie się chwaliło, mamy CPU 256bitowy pierwsi na świecie i co z tego? Dla 99,999% użytkowników 64bity są i będą bezużyteczne. Tylko do serwerów.
pawełpclabZobacz profil
Poziom ostrzeżenia: 0%
pawełpclab2011.03.11, 12:00
Myślę że te 64bitwe rozszerzenia to jest właśnie sposób nvidii na stworzenie własnego standardu i zaistnienie na rynku CPU. Początkowe połączenie z 32bitowym ARM pozwoli na płynne wejście na rynek serwerów i desktopów, a gdy za jakiś czas rozwiązanie się upowszechni to nv będzie mogła albo zrezygnować z rdzenia ARM na rzecz własnego albo implementować 32bitowe instrukcje ARM na drodze emulacji kupując tylko licencję na listę instrukcji a nie na rdzeń.
Bardzo podobnie powinno wyglądać wprowadzenie 64bitowych rozszerzeń do x86. Niestety dzięki AMD mamy kolejną protezę a nie nową listę instrukcji
pawełpclabZobacz profil
Poziom ostrzeżenia: 0%
pawełpclab2011.03.11, 12:03
SunTzu @ 2011.03.11 11:51  Post: 462155
@up
Mają świetne, ale np. kompilator OpenCL nie jest już taki wpsaniały intel, który ma 'tyle' tu wspólnego robi lepszy


Promilus1984 @ 2011.03.11 11:06  Post: 462145
@SunTzu - GPU i CPU pracują nad wspólnym problemem. GPU jedzie na 64bit float i potrzebuje 64bitowych danych z dajmy na to 36bitowego CPU. Z 36 bitowymi ALU, rejestrami i liniami danych. Bezsens. Taki CPU albo prześle 36bit młodsze, a potem 28bit starsze z 8 zerami, albo 2x32bit z 4 zerami. Jak pisałem dziwolągi są dobre w specyficznych przypadkach - to nie jest jeden z tych przypadków. Takim przypadkiem może być np. współpraca z 18 bitowymi A/D lub innymi urządzeniami (oraz softem) przystosowanym do takich właśnie liczb.


Ale po jakiego grzyba GPU? Po co 64bitowy CPU do gier? Ja myślałem, że to raczej do rozwiązań serwerowych. Patrz na konsole i zobacz ile one mają w sumie pamięci.

Ok... zróbmy CPU 256bitowy. Po co? NV będzie się chwaliło, mamy CPU 256bitowy pierwsi na świecie i co z tego? Dla 99,999% użytkowników 64bity są i będą bezużyteczne. Tylko do serwerów.


Nie do gier, a po to by stworzyć przyszłościową listę instrukcji i równie przyszłościowy model programowania - taki który starczy na kilkadziesiąt lat.
mkopekZobacz profil
Poziom ostrzeżenia: 0%
mkopek2011.03.11, 12:04
Nie wiem dlaczego wszyscy stawiaja znak medzy dlugoscia rejestrow procesora i szerokoscia ALU/FPU, z iloscia adresowanej pamieci. Wiekszosc 8 bitowych procesorow bylo w stanie adresowac 64 kB pamieci, do ktorych zaadresowania potrzeba 16 bitow. Na 8 bitach mozna zaadresowac 256 bajtow. 16 bitowy x86 adrsowal 1 MB pamieci, inne 16 botowe procesory podobnie, a niektore mialy nawet 32 bitowa szyne adresowa. Przeciez mozna zrobic procesor z 32 bitowymi rejestrami, 32 bitowa szyna danych i ALU, oraz np FPU dzialajacym w trybach 32 i 64 bit oraz 64 bitowa szyna adresowa i licznikiem programu.
SunTzuZobacz profil
Poziom ostrzeżenia: 0%
SunTzu2011.03.11, 12:19
-4#13
@up
no i było takie 'dziwadło'. 32bitowy CPU zdolny adresować tylko 26bitową przestrzeń adresową.

-> dla mnie w pełni działający 64bitowy CPU w ARM to jakieś nieporozumienie. NV nie dało szczegółów. Ale aktualna Tegra 2 nie ma np. Neon-a.



pawełpclab @ 2011.03.11 12:03  Post: 462159
SunTzu @ 2011.03.11 11:51  Post: 462155
@up
Mają świetne, ale np. kompilator OpenCL nie jest już taki wpsaniały intel, który ma 'tyle' tu wspólnego robi lepszy


(...)


Ale po jakiego grzyba GPU? Po co 64bitowy CPU do gier? Ja myślałem, że to raczej do rozwiązań serwerowych. Patrz na konsole i zobacz ile one mają w sumie pamięci.

Ok... zróbmy CPU 256bitowy. Po co? NV będzie się chwaliło, mamy CPU 256bitowy pierwsi na świecie i co z tego? Dla 99,999% użytkowników 64bity są i będą bezużyteczne. Tylko do serwerów.


Nie do gier, a po to by stworzyć przyszłościową listę instrukcji i równie przyszłościowy model programowania - taki który starczy na kilkadziesiąt lat.


No i powtórzę swój argument. Konsole działają świetnie i tam 32bity w zupełności starczą i będą starczyć. Czemu tablety, komórki, które dysponują x-krotnie mniejszym wyświetlaczem miałyby potrzebować, nagle xGB pamięci?

-> PS3/Xbox ma 512MB pamięci
-> Telefony w 28nm mogą dorównać konsolom.
------ No i ile będą potrzebować pamięci? 512MB+OS
-> Zbliżamy się do granicy atomu i mamy 3-4 skoki. Załóżmy, że przy granicy atomu powstanie SoC o wydajności 4x PS3. Powinno wystarczyć 2-4GB pamięci czyli tyle ile 32bitowy CPU obsługuje.

--------------
Inna sytuacja jest w serwerach.
Promilus1984Zobacz profil
Poziom ostrzeżenia: 0%
Promilus19842011.03.11, 12:47
@SunTzu - w konsolach masz CPU 64 bitowe (Xenon oraz Cell PPE, SPE jest bodajże128bit). Denver ma być przeznaczony na poważny rynek, a nie do tabletów (tak mi się o uszy obiło) dlatego 64bit to podstawa.
rhqqZobacz profil
Poziom ostrzeżenia: 0%
rhqq2011.03.11, 12:59
SunTzu @ 2011.03.11 12:19  Post: 462163
...


zapominasz o rosnącym rynku arm dla zwykłych userów. osobiscie męczę 'laptopa' z nowym opapem, który na baterii trzyma 15godzin przy obciązeniu (wifi plus 1080p).
przy szerszej szynie i wiekszym zestawie instrukcji jest szansa, ze bedzie to działać jeszcze szybciej/energooszczędniej.
pawełpclabZobacz profil
Poziom ostrzeżenia: 0%
pawełpclab2011.03.11, 13:02
SunTzu @ 2011.03.11 12:19  Post: 462163




pawełpclab @ 2011.03.11 12:03  Post: 462159

Nie do gier, a po to by stworzyć przyszłościową listę instrukcji i równie przyszłościowy model programowania - taki który starczy na kilkadziesiąt lat.


No i powtórzę swój argument. Konsole działają świetnie i tam 32bity w zupełności starczą i będą starczyć. Czemu tablety, komórki, które dysponują x-krotnie mniejszym wyświetlaczem miałyby potrzebować, nagle xGB pamięci?




Denver nie ma być do komórek i tabletów wiec ten agrument nie ma w jego przypadku zastosowania

*Konto usunięte*2011.03.11, 13:12
Dla wszystkich myślących ludzi od początku było oczywiste, że NV zrobi 64-bitowca. Ale ile to plucia było, że to tylko 32-bity będą.

P.S. Z tego co tu czytam wynika, że niektórzy jeszcze nie załapali, iz dzieło NVidii wyląduje w PC-tach.
slukaZobacz profil
Poziom ostrzeżenia: 0%
sluka2011.03.11, 14:05
Bitowość - to pierwsza ofiara marketingu w świecie IT. Trochę historii którą sam przeżyłem.
Komputery '8 bitowe', czyli takie jak ZX Spectrum, C64, Atari XL/XE, Amstrad/Schneider i im podobne chociaż mniej znane napędzały procesory o architekturze 16-to bitowej z 8-mio bitową magistralą danych. Dlatego też mogły one adresować 64KiB pamięci. W tych 'masowo' pionierskich czasach za wyznacznik bitowości uważało się szerokość magistrali danych. Czysty 8-bitowy procesor mógł się tylko nadawać do kalkulatorów i praktycznie niczego więcej. W epoce 16-bitowców obraz całości się trochę komplikuje, a to za sprawą Intela. Komputery oparte na procesorach Motoroli były w architekturze 32/16 (MC68000, MC68010), dla przypomnienia które - seria Atari ST, Amiga 1000, 500, 2000, 500+ i 600, oraz Macintosze, modeli nie będę wymiał, ponieważ ich nie znam, egzotyczny sprzęt, za egzotyczne kwoty pieniędzy. Na procesorach intela było już więcej zamieszania. Procesory 8086 i 8088, serca IBM PC XT i kompatybilnych były nieźle nakombinbowane, co długo się wszystkim odbijało czkawką. Procesory 16/16 i 16/8 ale z 20-to bitowym adresowaniem. XTeki na 8086 można było zgodnie z ówczesnymi standardami nazewnictwa nazywać 16-to bitowymi, ale na 8088 to były rasowe ośmiobitowce ;). Spuścizna po tych procesorach to słynne 640KiB RAM, dziesięć segmentów pamięci po 64KiB i piekło programistów. Dla tych co nie wiedzą, programy pisało się w wybranym modelu pamięci, Tiny, Small, Medium, Large, Hudge. W pierwszym całość program i dane musiały się zmieścić w 64KiB pamięci. Tylko w tym modelu pamięci mogły być programy .COM. Small to już dwa segmenty pamięci jeden na program, drugi na dane. Medium i Large różniły się ilością dostępnych segmentów na program, na dane był jeden. Dopiero w ostatnim modelu dało się użyć więcej danych, ale jedna tablica musiała się dalej mieścić w jednym segmencie. Takiego piekła jak na komputerach poganianych procesorami intela nie było tam gdzie sercem były procesor motoroli. Praktycznie liniowy model pamięci. Wczesne motorole miały 24bitowe adresowanie. Jedynym drobnym zgrzytem był fizyczny brak danych 8-mio bitowych.
Epoka '32' bitów, czyli pojawienie się i386. Motorolę sobie odpuszczę, powiem tylko tyle że były komputery na MC68020, 68030, 68040, no i na tych komputerach wszytko działało już w 32bitach. W komputerach pracujących na procesorach intela dalej był dos + rozpowszechniająca się graficzna nakładka czyli windows 3.1. Programy dalej były w głównej mierze 16-to bitowe. Wyznacznikiem 'bitowości' sprzętu była dalej szerokość magistrali pamięci. I tak i386SX był uważany za procesor 16-to bitowy, a zwykły 386 jak 32-bitowy.

64 bity po raz pierwszy, czyli pierwsze Pentium. Chyba nie muszę przypominać dlaczego ten procesor był za taki uważany.

64 bity po raz drugi to Athlon 64.

O jakie 64 bity chodzi nvidii?
darkmartinZobacz profil
Poziom ostrzeżenia: 0%
darkmartin2011.03.11, 14:08
Coś ci sie ewidentnie pomyliło
Intel 4004 4 bitowy mikroprocesor
Pentium nie było 64 bitowe.
'Bitowość' procesora to wielkość (długoć w bitach) rejestrów danych, reszta jest nie istotna.
Szkoda było tyle pisania na takie bzdury.
Promilus1984Zobacz profil
Poziom ostrzeżenia: 0%
Promilus19842011.03.11, 14:25
@darkmartin - jednostka SIMD/MMX/FPU w Phenomie korzysta ze 128bitowych rejestrów ;) Jaki to jest zatem procesor? VMX w procesorach POWER/PPC także korzysta z 128bitowych rejestrów :] No, ale rejestry proca są 64bitowe w obu przypadkach. Tak samo ALU&AGU.
Zaloguj się, by móc komentować