Intel zapowiada nową architekturę x86s

1. Prościej byłoby Intelowi (autor: Xeno | data: 22/05/23 | godz.: 21:23)
   przejście na RISC-V...
   
   
2. @xeno (autor: henrix343 | data: 22/05/23 | godz.: 21:48)
   dokladnie, no ale wiadomo ze wtedy nie napychali by sobie kabzy prosta kasa od amatorow sprzetu komputerowego.
   
   
3. Nie rozumiem (autor: pandy | data: 23/05/23 | godz.: 00:30)
   tego postulatu - skoro mają prawa do x86 to po co mieliby z nich rezygnować i przechodzić na ciągle gorszą ISA?
   
   
4. x86s (autor: Conan Barbarian | data: 23/05/23 | godz.: 00:42)
   Mam rozumieć, że od tego momentu każdy, szczególnie Chiny, mogą sobie strugać swoje post-x86.
   Dlaczego Intel nie nazwie tego x64? - to proste, gdyż x86-64 opracowało AMD.
   
   
5. W ten sposób uwalą uproszczoną emulację. (autor: Kenjiro | data: 23/05/23 | godz.: 07:20)
   Bo będzie wymagana pełna emulacja, co znacząco zmniejszy wydajność kodu 32-bit. A tego jest jeszcze większość na świecie.
   
   Mi to wygląda na próbę ominięcia części patentów AMD.
   
   Z drugiej strony Itanium już było...
   
   
6. Sensacja i dezinformacja (autor: GLI | data: 23/05/23 | godz.: 09:05)
   Intel chce zrezygnować z możliwości uruchamiania systemów operacyjnych innych niż 64-bitowe: "Startup legacy modes removed". W ramach systemu 64-bitowego możliwe będzie uruchamianie starszych aplikacji 32-bitowych (np. SysWOW64 dla Windows będzie dostępny).
   
   
7. Czyli jak będę chciał zagrać w pierwotnego Doma, Descenta, UFO, Cywilizacje (autor: ekspert_IT | data: 23/05/23 | godz.: 09:11)
   Mogą być problemy...
   Jak po emulacji będzie chodzić jak na 386 to dziękuję bardzo...
   
   
8. @7. (autor: Gakudini | data: 23/05/23 | godz.: 09:37)
   A jak teraz je uruchamiasz? Z menu rozruchowego wybierasz MS DOS 4.0?
   
   
9. Czyli Intel tak na prawdę chce pozostawić w swoich procach (autor: Qjanusz | data: 23/05/23 | godz.: 10:17)
   wyłącznie licencjonowaną architekturę AMD64
   
   Własne IA64 padło lata temu, a innych możliwości na horyzoncie brak
   
   
10. Odważna decyzja (autor: P.J._ | data: 23/05/23 | godz.: 13:54)
    Odważna decyzja, docelowo słuszna, chociaż początki notabene będę trudne. Myślę, że Intel po straceniu Apple'a i porównywaniu wydajności M2, docelowo M3 i tak dalej czuje oddech konkurencji.
    
    
11. No I dobrze (autor: mirek190 | data: 23/05/23 | godz.: 15:01)
    A ci co placza ze 32 bit trzeba emulowac ...to dawno jest emulowane.
    Nawet pelna emulacja aplikacji 32 bit nie widze problemu ... ne ma aplikacji 32 bit / 16 bit ktore by nie poszly na full wyfdajnosci na prockach wspolczesnuch x64 a co dopiero na przyszlych ...
    
    
12. @1 Defakto są już RISC od czasów Pentium (autor: Master/Pentium | data: 23/05/23 | godz.: 15:30)
    masz interpretację CISC na poziomie mikrokodu.
    
    
13. Interesujący pomysł (autor: Master/Pentium | data: 23/05/23 | godz.: 15:32)
    Nie widziałem nowej instancji OS (Windows/Linux) x86_32 od ładnych kilku lat. Tym bardziej nie widziałem 16bitowego systemu od ładnych +15 lat.
    
    
14. szkoda (autor: Markizy | data: 23/05/23 | godz.: 15:51)
    że tak późno się zdecydowali. Już jak by od adler lake porzucili pełne wsparcie to nic specjalnego by się nie stało. Teraz to MS i ludzie od linuxa będą musieli popracować aby bezproblemowo działy programy 32bitowe ale wszystko do ogarnięcia.
    
    
15. Markizy (autor: PCCPU | data: 23/05/23 | godz.: 18:03)
    Jestem niemal pewny że aplikacje 32 bitowe w systemie 64 bitowym będą działały bez problemu. To nie emulacja 32b x86 na całkiem innej arch np ARM cz Itanium. Także bez paniki :)
    
    
16. Kiedy nowa architektura? (autor: maximus1 | data: 23/05/23 | godz.: 18:12)
    1. Czy mam rozumieć, że czysty 64-bitowy CPU bez 16 i 32-bitowego balastu będzie mieć lepszą wydajność od aktualnych CPU (zakładam, tę samą ilość rdzeni, taktowanie itd.)?
    2. Czy coś wiadomo o 128-bitowych procesorach, czyli takich, które będą mieć 128-bitowe rejestry i szynę adresową (pewnie przycięta jak w AMD i intelu) 128-bit?
    3. Obecny procesory x86(64) są na zewnątrz CISC a w środku RISC - możliwe, że ma to jakiś związek z zachowywaniem wstecznej kompatybilności z 32, 16-bitowymi systemami, czy są prowadzone prace nad zupełnie nową architekturą dla komputerów domowych? Wiem, że są ARM-y, że Apple ma swój procesor, ale co z następcą x86?
    Wiadomo, że w przypadku domowych komputerów (zamknięty kod źródłowy windowsa, gier i reszty programów) nowa architektura wiązałaby się z grubą linią = żegnamy się ze starymi programami, bo wątpię by chociaż 30% programów (także gier) z ostatnich 20 lat, ba! 10 lat została na nową skompilowana pod nowe procesory.
    
    
17. AMD (autor: Conan Barbarian | data: 23/05/23 | godz.: 18:28)
    Jeśli Intel to wdroży, to przynajmniej na początku AMD na tym zyska oferując kombajn x86-64 a nie jakieś emulacje.
    
    
18. @maximus1 (autor: PCCPU | data: 23/05/23 | godz.: 21:45)
    1 i 3.
    Z tego co mi wiadomo 16b i 32b są wykonywane na nowoczesnych 64 bitowych rejestrach ogólnego przeznaczenia. Już po opublikowaniu specyfikacji x86-64(AMD64) krążyły opinie że można było to zrobić lepiej czyli przy okazji wprowadzenia x64 pozbyć się starych i powolnych trybów m.in adresowania. 16 i 32 bitowe tryby zajmują tranzystory m.in w mikrokodzie i dekoderach a każda rozbudowa i przebudowa rdzenia do nowszej generacji musi uwzględniać te wszystkie już przrstarzałe tryby związane z 16 i 32 bitami. Pozbycie się tych trybów pozwoli zredukować opóźnienia i wykorzystać zwolnione zasoby tranzystorów na na naprawdę potrzebne ulepszenia z myślą o x64. To właśnie jest głównym motywem x86S. Ale spokojnie bo o ile systemu 32 bitowego nie uruchomimy na x86S to dla odmiany aplikacje 32 bitowe pod przewodnictwem systemu 64 bitowego już tak. W związku z tym częścią x86S nadal obecne będą instrukcje wektorowe MMX-SSE które i tak są wykonywane na nowoczesnych rejestrach wektorowych.
    
    Jeśli miałbym obstawiać która mikroarchitektóra wprowadzi x86S to myślę że będzie nią "Royal Core". Do "Royal Core" pasuje NovaLake na rdzeniach PantherCove. Chociaż Intel twierdzi że to LunarLake jest projektem od podstaw całkowicie nowym co kolwiek to znaczy lecz bazuje dalej tak jak ArrowLake na rdzeniach LionCove. Może nazwy kodowe potrafią być mylące to jak dla mnie PantherCove bardziej pasuje do x86S niż LionCove ;)
    
    2.
    Przejście na 64b podyktowane było głównie przez możliwość adresowania ponad 4GB pamięci RAM bo samo poszerzenie rejestrów ogólnego przeznaczenia(GPR) do 64b i dwukrotnego zwiększenia do 16 z 8 dało jakieś +15% a czasami nawet mniej.
    Granicą adresowania dla 64 bitów jest 16 Exabajtów!!! By lepiej uświadomić sobie jak jest to ogromna wielkość pamięci:
    1 Exabajt = 1024 Petabajty
    1 Petabajt = 1024 Terabajty
    1 Terabajt = 1024 Gigabajty - jakby ktoś nie wiedział ;)
    Teraz pytanie kiedy i czy w ogóle dotrzemy do granic możliwości adresowania 64 bitowego ;)
    Samo poszerzenie rejestrów ogólnego przeznaczenia(GPR) do 128 bitów pociągnęło by za sobą wiele zmian w rdzeniu i może dało by korzyści w jakiś bardzo niszowych zastosowaniach. Ten budżet tranzystorów lepiej wykorzystać do ulepszeń i rozbudowy rdzenia obliczeniowego 64 bitowego co da ogólnie więcej korzyści niż 128 bit.
    
    
19. Edit2 (autor: PCCPU | data: 23/05/23 | godz.: 22:07)
    Hipotetycznie x86S stwarza możliwość m.in dołożenia rejestrów 64 bitowych z 16 do np 32-128 zachowując kompatybilność z x86-64. Pytanie ile by to dało i czy w ogóle by to coś dało. Jeśli by coś dało to czy zyski były by tego warte.
    
    
20. Ciekawostka (autor: PCCPU | data: 24/05/23 | godz.: 00:12)
    Nie wiem jakim cudem to przegapiłem ale cóż:
    EmeraldRapids(Xeon)który jest dalej na Intel 7(E10nmSF) ma fizycznie 66 rdzeni z czego aktywnych będzie do 64 rdzeni. Każdy rdzeń w SapphireRapids miał do dyspozycji cache L3 1.875MB a w EmeraldRapids każdy rdzeń ma do dyspozycji 5MB L3! Czyli nowy 64 rdzeniowy Xeon będzie miał L2 128MB i L3 320MB. Łącznie daje to 448MB!
    
    Co jeszcze ciekawsze EmeraldRapids składa się z 2 zamiast 4 chipów, które zajmują mniejszą powierzchnię dając o 10% więcej rdzeni!
    
    SapphireRapids (Intel 7)
    Fizycznie 60 rdzeni GoldenCove
    Rdzeń L2 2MB + L3 1.875MB
    L2 120MB i L3 112.5MB
    L2+L3 232.5 MB
    4 kafelki po 15 rdzeni 393.88 mm2
    60 rdzeni 1575.52 mm2
    
    EmeraldRapids (Intel 7)
    66 rdzeni RaptorCove (aktywnych do 64 rdzeni)
    Rdzeń L2 2MB + L3 5MB
    L2 132MB (aktywne 128MB) + L3 330MB (aktywne 320MB)
    L2+L3 462MB (Aktywne 448MB)
    2 kafelki po 33 rdzenie 763.03 mm2
    66 rdzeni 1526.05 mm2
    
    EmeraldRapids jest o 3.14% mniejszy mając przy tym o 10% więcej rdzeni i 2.84x więcej L3!
    
    
21. Edit: (autor: PCCPU | data: 24/05/23 | godz.: 05:55)
    EmeraldRapids jest o 3.14% mniejszy mając przy tym o 10% więcej rdzeni i 2.93x więcej L3!
    
    
22. @PCCPU (autor: Promilus | data: 24/05/23 | godz.: 18:16)
    Dużo literek, mało treści. Zdolności adresowania nie są zależne od "bitowości" GPR. 32bitowe x86 obsługiwały poprzez PAE 36bit pamięci fizycznej, a 64bitowe CPU obsługują aktualnie tylko 40-48bit fizycznej pamięci. No może w porywach 52. 64bit wprowadzono dlatego, że I TAK operowano już od dawna na DANYCH 64bit, a przy okazji można było ogarnąć liniową przestrzeń adresową 64bit (przy czym nadal fizycznie adresowane jest zdecydowanie mniej). Samo poszerzenie rejestrów i większa pamięć nie dały ZUPEŁNIE NIC. Jeśli aplikacja nie potrzebowała więcej niż 2GB RAM to większa przestrzeń adresowa nie mogła nic dać. Jeśli aplikacja głównie korzystała z float, double, int (a nie long long) to też nie z bardzo można się było spodziewać jakiegokolwiek wzrostu bo niby z jakiej paki? Wzrost był tym większy im większy udział był szerszych danych w programie. Bardzo duży w np. programach szachowych, żaden albo prawie żaden w grach. GPR spokojnie można poszerzyć do 128bit, przecież masz choćby YMM które mają już 2-4x więcej i jakoś to nikogo nie boli. Tylko jaki jest sens? GPRy nie obsługują packed, a używanie typu szerszego niż 64b to bardzo niszowe zastosowania. Wywalenie starych trybów i rozkazów to jest coś co intel prędzej czy później musiał zrobić. Dobrze byłoby gdyby to zrobił z dekadę wcześniej. Teraz to już jest "po ptokach".
    
    
    
23. @22. (autor: Mariosti | data: 24/05/23 | godz.: 20:34)
    " Teraz to już jest "po ptokach"."
    
    No chyba jednak nie jest bo 64bitowe procesory będą wystarczające przez najbliższe 50-100 lat nawet na rynku serwerów (pełne adresowanie 64bit pozwoli na wykorzystanie do 16 777 216 TB ramu - a więc naprawdę duuuużo).
    
    Wszelkie zalety ze sprzętowej obsługi większych zmiennych (jak sam wspomniałeś nie stosowanych powszechnie w oprogramowaniu) lepiej jest implementować jako sprzętowe rozszerzenia co zresztą już nastąpiło (jak chociażby avx obsługujący 128 a nawet 256bitowe zmienne (te drugie weszły z AVX-512L), albo sprzętowe rozszerzenia mocno optymalizujące procesy wyszukiwania wielkich liczb pierwszych itp.).
    
    Także definitywnie jest dobry czas na uproszczenie zestawu instrukcji i zarazem znaczne uproszczenie frontendu rdzeni co pozwoli w efekcie na znacznie większe ich skomplikowanie ale pod kątem wzrostu wydajności zamiast zachowywania wstecznej kompatybilności.
    
    
24. czas najwyzszy (autor: pawel1207 | data: 24/05/23 | godz.: 20:44)
    to uprosci procesory i pozbedzie sie kilku archaizmow nadal bedzie to lata za isa bo wielu rzeczy w x86 sie nie przeskoczy ale krok w dobra strone w sumie podyktowane to jest tym ze x86 p/w energetycznie jest slabe w porownaniu do isa czy arma. procki grzeja sie jak poryte i zra ogromne ilosci pradu pozbycie sie dziadostwa czyli najgorszej i najglupszej listy rozkazow ever czyli x86 :D im szybciej tym lepiej...
    
    
25. @Mariosti (autor: Promilus | data: 24/05/23 | godz.: 20:53)
    Chodzi o odchudzanie x86. ARM a jak się Apple postara nawet RISC-V zapewni kompatybilność ze starszymi aplikacjami x86 na podobnym poziomie wydajności, a z nowymi z pewną stratą ale może akceptowalną. Bo jeśli odetniemy z x86 sprzętową kompatybilność wsteczną to co ta architektura oferuje? Energooszczędność? No nie. Bogactwo oprogramowania? Już też nie. To może bezkompromisową wydajność? Mhmmmm.... właśnie. 10 lat temu to by zrobiło robotę, bo ARM w desktopie zwyczajnie nie istniał. A teraz jest poważną konkurencją. x86 ma jedną poważną zaletę, ale ona też topnieje (bo jest coraz mniej tego typu użytkowników). Kupisz go w "sklepie za rogiem" ... Jeśli chodzi o komputery przemysłowe, htpc, thin client, serwery, laptopy - wszędzie ARM ma się już znakomicie. Odchudzenie x86 nie zmieni tu wiele, co najwyżej pozwoli się utrzymać nieco dłużej w wyścigu.
    
    
26. @25. (autor: Mariosti | data: 24/05/23 | godz.: 21:03)
    Podejrzewam że cały soft kompilowany na x64 będzie działał bez przebudowy na x86s - to będzie jego mega zaleta, a jednocześnie poprawi to albo energooszczędność, albo wydajność - gdzie wydajność w ogólnym przetwarzaniu jest wciąż nieporównywalnie wyższa od najlepszego nawet ARM (sukcesy M1 to wszystko akceleratory sprzętowe i soft optymalizowany pod konkretny procesor, a nie wydajność ALU i FPU, zresztą im bardziej ARM zbliża się do x86 tym bardziej ginie jego efektywność energetyczna także można zadać pytanie po co ARM pcha się poza urządzenia mobilne skoro nie ma tam zalet?).
    
    
27. @Promilus (autor: PCCPU | data: 24/05/23 | godz.: 21:43)
    Nigdzie nie napisałem że szerokość rejestrów ogólnego przeznaczenia (GPR) ma ścisły związek z obsługą ilości pamięci ale prawdą jest że decyduje o bitowości procesora i linowym dostępie do pamięci. Co z tego że niektóre 32 bitowe procesory miały adresowanie 36 bitowe co pozwalało zadresować do 64GB skoro nie była to pamięć jednocześnie liniowo dostępna a soft jak i system tym bardziej konsumencki nie był wstanie z tego skorzystać a nawet jeśli to bywało z tym różnie. Procesor 64bitowy którego rejestry mają szerokość 64bitów są wstanie adresować liniowo 16 Exabajtów pamięci RAM z tym że 64 bitowego adresowania nie stosuje się ze względu że tak gigantyczna ilość pamięci obecnie nie jest i szybko nie będzie osiągalna. 40 i więcej bitowe adresowanie w procesorze 64 bitowym pozwala na jednocześnie liniowy dostęp do całej dostępnej przestrzeni adresowej.
    Można śmiało napisać że np K8-A64 wewnętrznie był 64 bitowy ale zewnętrznie 40-48 bitowy.
    Z tego co pamiętam SunnyCove wprowadził 52-bitowe adresowanie aczkolwiek do PC to wciąż sporo za dużo jak na potrzeby softu.
    
    Procesor 16 bitowy ma GPR o szerokości 16 bitów
    Procesor 32 bitowy ma GPR o szerokości 32 bitów
    Procesor 64 bitowy ma GPR o szerokości 64 bitów
    Co innego ilość GPR gdzie przy x86 16 i 32 bitach było 8(GPR)
    x86-64 wprowadziło 16xGPR 64 bitowych.
    
    
    
    
    
28. Edit: (autor: PCCPU | data: 24/05/23 | godz.: 22:00)
    Wiadomo że 32 bitowa aplikacja jeśli działa na procesorze 64 bitowym ma dostęp tylko do połowy rejestrów(GPR) czyli do 8 z 16 i w takim przypadku zapene nic nie da jeśli o szybkość przetwarzania chodzi. 5-15% wyższa wydajność była z przejścia na 64bity. Przynajmniej takie info można znaleźć w sieci.
    
    
29. Bardzo ciekawy komentarz (autor: pandy | data: 24/05/23 | godz.: 23:18)
    na Phoronix który pokazuje dlaczego 64 bity raczej wystarczą na bardzo długo jeśli chodzi o pamięć i pokazujący pewne wielkości w kontekście fizycznym. https://www.phoronix.com/...?p=1388527#post1388527
    
    W skrócie nie da się fizycznie zbudować pamięci z adresem 128 bitów.
    
    
30. @pandy (autor: PCCPU | data: 25/05/23 | godz.: 00:12)
    Procesory 64 bitowe mimo że dysponują wektorami 128, 256 i 512 bitowymi to i tak skalary są 64 bitowe. Jeśli kiedykolwiek powstanie procesor 128 bitowe to będzie ostatnim ponieważ powyżej 128 bitowych skalarów nigdy nie zobaczymy.
    
    
31. Edit: (autor: PCCPU | data: 25/05/23 | godz.: 00:14)
    Oczywiście jeśli kiedykolwiek powstanie procesor 128 bitowy to nigdy nie będzie dostępny z adresowaniem 128 bitowym.
    
    
    
32. @PCCPU (autor: Promilus | data: 25/05/23 | godz.: 06:30)
    Ograniczenie PAE nie wynikało z procesora tylko systemu. 32bitowe linux z PAE (tam to się PSE zdaje nazywało) działał ok i nie miał limitu 2GB na proces (czyli POŁOWY z max dostępnej pamięci 32b), aczkolwiek tak - 64bit GPR są związane z tym jak OS obsługuje taką pamięć, bo wali w końcu 64b wskaźnikami. Tylko znów - wcale nie oznacza to, że NIE dałoby się obsłużyć większej pamięci liniowej na 32b procesorach :) Zwyczajnie nie było sensu robić takiej chimery. A przykładem procesorów które adresowały zdecydowanie więcej niż szerokość ALU i rejestrów ogólnych to każdy 8 bitowiec i większość 16 bitowców (które z kolei miały odpowiednio 16 i 24bity do adresowania). Więc to nie chodziło nigdy o możliwości adresowania a spójność i wygodę.
    "5-15% wyższa wydajność była z przejścia na 64bity. Przynajmniej takie info można znaleźć w sieci." - ale nikt nie potrafił pokazać na czym bazuje. A testy oczywiście były. I typowo użytkownik w takim 2003r z 64b nie miał praktycznie nic ;) Baaa, i w 2006 trudno było o cokolwiek (oprócz w/w programów szachowych, które i z ilością rdzeni, i z bitowością skalowały się bardzo ładnie).
    
    @Mariosti - rzecz w tym, że nawet M2 pobiera mniej energii a w Cinebenchu prześciga swoich poprzedników/konkurentów spod szyldu intel. To tylko wskazuje, że x86 nie jest niedościgniony. Może w desktopie jeszcze (bo nie ma tak wyżyłowanych ARM), ale i w HPC (Fugaku) i w laptopach to x86 oferuje niewiele, a ARM coraz więcej. Tak, EPYC z akceleratorami obliczeniowymi (GPU de facto) odzyskuje rynek HPC, ale ARM już pierwszy krok zrobił i łatwo tego nie odda.
    
    
33. @32. (autor: Mariosti | data: 25/05/23 | godz.: 11:47)
    Zauważ że porównywane do M1 i M2 procesory intela to jednak trochę paździerze i jeśli chodzi o wydajność architektury, efektywność energetyczną, a także proces produkcji.
    
    Dodatkowo trzeba pamiętać że M1 i M2 mają RAM zintegrowany z CPU, a to daje bardzo duży zysk efektywności energetycznej i przepustowości pamięci i nie ma żadnego związku z możliwościami samych rdzeni CPU.
    
    
    Apple specjalnie tak to dobrało aby wypadało jak zbawca świata.
    
    
34. Co do M1-2 (autor: PCCPU | data: 25/05/23 | godz.: 13:32)
    Zobaczymy co przyniesie LionCove i Zen5 a także kolejne generacje x86.
    
    
35. Benchmark programu szachowego ShashChess 32 (autor: maximus1 | data: 25/05/23 | godz.: 15:26)
    Jako ciekawostkę wrzucam benchmark programu szachowego ShashChess - wersję numer 32 dla różnych procesorów można pobrać z
    https://github.com/amchess/ShashChess
    Wydajność (ilość węzłów na sekundę) prezentuje się poniżej:
    417748 general-32
    743590 general-64
    825613 x86-32
    1326275 x86-64
    1712241 avx2
    1239978 bmi2
    1540309 modern
    1380376 sse3-popcnt
    1512766 sse41-popcnt
    1496548 ssse3
    
    Test wykonano na AMD Ryzen 5 3600 - test jednowątkowy (po uruchomieniu programu wpisujemy po prostu polecenie bench)
    Jak widać najwydajniejsza jest wersja avx2, ponad 1,7 miliona pozycji na sekundę. Nie przetestowałem tylko wersji avx512, bo procesor jest nie obsługuje, prośba, jest tutaj ktoś kto ma procesor z obsługą avx512? Jeśli tak, to poproszę o test dwóch wersji avx2 i avx512. Dzięki!
    
    
    
36. @maximus1 (autor: Promilus | data: 25/05/23 | godz.: 17:10)
    No i test tylko potwierdza co pisałem ;) Wydajność silników szachowych silnie jest uzależniona od ilości wątków, bitowości procesora i szerokości SIMD. Aczkolwiek po AVX2 spodziewałem się więcej.
    
    
37. ... (autor: pwil2 | data: 26/05/23 | godz.: 02:57)
    Ilość rejestrów została rozszerzona z 8 do 16, ale pod spodem jest ich wielokrotnie więcej. Są dynamicznie przemapowywane.
    
    
38. @PCCPU#30 (autor: pandy | data: 26/05/23 | godz.: 22:36)
    Tak, komentarz który podlinkowałem dotyczy dwóch kwestii - szerokości rejestrów skalarnych i tu 128 wydaje się być czymś maksymalnym choć niekoniecznie tak zyskownym jak przejście z 32 na 64 bity jeśli chodzi o prędkość obliczeniowa.
    W drugiej zaś części tego komentarza jest poruszona kwestia adresu fizycznego i ewentualnej próby implementacji takiej fizycznej pamięci w zestawieniu z granicami materialnego wszechświata.
    
    
39. @pandy (autor: PCCPU | data: 27/05/23 | godz.: 22:01)
    Tak. Czytałem już wcześniej ten komentarz.
    Według tego co napisał osiągnięcie granicy 128 bitowego adresowania przyjmując że 1 bit jest z atomu wodoru i pomijając w jaki sposób dane byłyby odczytywane i zapisywane to taka pamięć zajmowała by absurdalnie gigantyczną przestrzeń i masę że jest to nierealne. 128 bitowa przestrzeń adresowa oznacza pamięć której masia przekroczyła by masę wszystkich flot na świecie o 10 milionów razy.
    
    Co do rejestrów skalarnych to poruszył temat 1024 bitów twierdząc że nigdy nie da takiego impetu jak przejście z 32 do 64 bitów dodatkowo przytaczając ile jest atomów na ziemi i we wszechświecie. 1024 bitowy procesor nigdy nie zostanie skonstruowany a jeśli nawet 128 bitowy kiedykolwiek powstanie to nie będzie to szybko i będzie ostatnim rozszerzeniem rejestrów skalarnych.
    
    
40. Edit: (autor: PCCPU | data: 27/05/23 | godz.: 22:10)
    Myślę że zanim powstanie o ile powstanie procesor 128 bitowy mogą być procesory np 72, 80 czy 96 bitowe.
    
    
41. @PCCPU (autor: Promilus | data: 28/05/23 | godz.: 07:13)
    Zapominasz waćpan o tym, że obok technologii krzemowej rozwijane są procesory kwantowe ;) I tutaj już od dłuższego czasu są procesory o więcej niż 64 kubitach. Krzemowy flash trzyma w jednej komórce nawet 4 bity (QML), różne nowe rodzaje pamięci - także operacyjnej - też mogą. Albo i więcej. Dlatego "nigdy" i "zawsze" to bardzo niefortunne wyrazy jeśli chodzi o technologię. I - co kolejny raz podkreślam - proszę nie łączyć adresowalnej pamięci z szerokością rejestrów i jednostki arytmetycznej, bo powiązanie jest dość luźne. Co do procesorów 72, 80 czy 96bit - jeśli rzeczywiście wyjdziemy z potrzebami poza to co daje 64b to nikt o te dodatkowe 8b się nie będzie szczypał tylko jeśli już to będzie te 80 albo 96. Zresztą 80bit jest formatem rozszerzonej precyzji FPU od lat 80-tych, a 96b to precyzja niektórych obliczeń wewnątrz samego FPU w tym formacie. Ale FPU to zupełnie inna bajka i jego szerokość ma się nijak to szerokości CPU.
    
    
42. @PCCPU (autor: pandy | data: 28/05/23 | godz.: 14:39)
    Ale procesory 80 czy 96 bitowe już istnieją - 80 bitowe są wszystkie koprocesory numeryczne wspierające tzw extended precision a niektóre DSP czy ASP miały powyżej 80 bitów - trylko że to zastosowania niszowe.
    
    
43. @Promilus (autor: pandy | data: 28/05/23 | godz.: 14:40)
    Poniewczasie przeczytałem twój komentarz
    
    
44. PAE itd. (autor: Master/Pentium | data: 31/05/23 | godz.: 13:24)
    obsługa PAE jest trochę bardziej współczesnym odpowiednikiem EMS czyli sięganie do pamięci wyżej przez okno w dostępnej pamięci niżej. Czyli skomplikowane, wolniejsze i podatne na problemy. Praktycznie nic z normalnego softu tego nie obsługiwało bo to poprostu nieopłacalny badziew.
    Tak więc x86_64 powstał właśnie z powodu niemożności obsłużenie pamięci powyżej 4GB w normalny sposób nie powodujący straty wydajności i stada dziwnych problemów. No i przerabiania wszystkich programów aby dodać obsługę PAE (nietrywialne).
    
    
    
45. @Master/Pentium (autor: Promilus | data: 2/06/23 | godz.: 05:38)
    Panie, po pierwsze to mało wiesz. EMS to była normalna fizyczna pamięć w 24 i 32b przestrzeni (16 i 32bitowe x86) tylko by ją zwyczajowo wciągnąć trzeba by wejść w protected mode, a DOS tego nie miał stąd zainstalowano taką protezę NA DOS!!
    
    PAE pozwalało zaadresować 64GB fizycznej pamięci. Robiło to względnie sprytnie i z niskim narzutem. Nie PAE samo w sobie było problemem, ani ilość pamięci którą oferował. Problemem było to co wyraźnie pisałem - 2GB limit pamięci na proces w 32b systemie windows. I dla niektórych użytkowników - niestabilność określonych sterowników w tym trybie (ale to akurat wina producentów sprzętu) - głównie dotyczyło to XP więc MS PAE zablokował do 4GB w tej wersji (tak jakby PAE nie było).
    Na linuksie PAE było od końcówki lat 90 dość często stosowane i nie było z tym większego problemu. Ale jeszcze raz podkreślę - 64bit to było rozwiązanie problemu nie ilości pamięci ogółem, a ilości pamięci dostępnej przez proces.
    
    
    
    
46. @Promilus (autor: Master/Pentium | data: 2/06/23 | godz.: 08:03)
    A ile programów pod Linux potrafiło użyć PAE?
    Próbowałem używać Oracle 32bit, ustawianie tego do >4GB to była jazda, nie polecam. Oczywiście masz rację że limit 2GB per proces też był problemem i to dużym.
    Co do EMS to chyba mylisz z XMS. EMS można było używać z real mode przez okno 64kB w konwencjonalnej pamięci. To XMS wymagał trybu chronionego i był dostępny bez sporej straty wydajności.
    
    
47. @46. (autor: Mariosti | data: 2/06/23 | godz.: 13:12)
    Czyli dalej nie zrozumiałeś poprzedniego komentarza.
    PAE nie zwiększa ilości pamięci dostępnej do alokacji przez proces, max teoretyczny z PAE to 4GB.
    Różnica z PAE jest taka że system operacyjny będzie w stanie dysponować większą ilością pamięci operacyjnej, czyli np może odpalić 16 procesów i każdemu przydzielić po 4GB ramu, wykorzystując w sumie 64GB ramu.
    
    Jeśli jednak chcesz aby jeden proces dostał 64GB ramu to musi być to już aplikacja 64 bitowa na systemie 64 bitowym.
    
    
48. rozumiemy się raczej dobrze (autor: Master/Pentium | data: 2/06/23 | godz.: 14:45)
    nie wiem jak ty ale ja używam oprogramowania użytkowego, system to środowisko do niego. Co z tego że system widzi powyżej 4TB skoro programy mogły użyć max 2GB a programy z obsługą PAE (to pozwalało obejść limit 2GB dla procesu) można policzyć na palcach dewala alkoholika. Ja znam dosłownie jeden - Oracle Database a i tak implementacja tego była tam dosyć ułomna. Ogólnie jak EMS to była tymczasowa proteza a nie rozwiązanie.
    
    
49. @Master/Pentium (autor: Promilus | data: 2/06/23 | godz.: 17:48)
    Nie to TY mylisz EMS ;) EMS to była łata na DOS, który wtedy NIE potrafił inaczej dostać się do pamięci powyżej 640KB. Nie miało to nic wspólnego z procesorem, który w trybie protected oczywiście adresował zdecydowanie więcej. I dość normalnie. I wszystko co uruchamiało się w tym trybie normalnie korzystało z tej pamięci. A stary DOS MUSIAŁ używać EMS. Czyli kwestia stricte programowa.
    "Oczywiście masz rację że limit 2GB per proces też był problemem i to dużym" właśnie to był ten główny problem, a nie ilość adresowalnej pamięci fizycznej. Bo 64GB jakie dawało 36bitów nawet dzisiaj nie jest dla szerszej rzeszy odbiorców indywidualnych ważnym ograniczeniem. Ale 2GB na proces już zdecydowanie byłoby i jest od ponad dekady. Więc zupełnym nieporozumieniem jest twierdzenie, że 64bit weszły by móc mieć więcej pamięci RAM. Nie. 64 bit weszło by móc wykorzystać więcej RAM dla aplikacji bez skomplikowanych sztuczek oraz by wyrzucić obszar pamięci peryferiów daleko poza obszar pamięci fizycznej - bo tak się złożyło, że przy 32bit i mocarnych kartach grafiki już się to komplikowało.
    "Co z tego że system widzi powyżej 4TB skoro programy mogły użyć max 2GB a programy z obsługą PAE (to pozwalało obejść limit 2GB dla procesu)" - 2GB na proces to ograniczenie windowsa, zresztą jeśli appka była skompilowana z largeadressaware to mogła wykorzystać więcej, wszystkie appki 64b są kompilowane domyślnie z tą flagą, appki 32b z tą flagą w systemach 64bit korzystają z większej ilości pamięci (w identyczny sposób jak w systemach z PAE tylko w przypadku 32bit systemu z PAE ta wielkość to efektywnie ok 3GB, a dla 64bitowych - które PAE oczywiście mają, DOMYŚLNIE - jest to 4GB). I tak, jest to różnica bo w takim serwerze jest mnóstwo różnych procesów zjadających pojedynczo tylko setki MB, a naraz dziesiątki GB. I tutaj PAE w 32bit rozwiązywało wiele problemów. Zresztą było w procesorach już od intel pentium pro!
    
    
    
    
    
50. @Promilus, tutaj chyba wychodzą na wierz nasze specjalizacje (autor: Master/Pentium | data: 3/06/23 | godz.: 19:50)
    Do domowego użytku lub do uruchamiania mnóstwa drobnicy (webserwisy?) PAE było wystarczająco dobre. Owszem miało pewien narzut na wydajności ale akceptowalny do tych zastosowań.
    Problem w tym że ja wtedy (jak i teraz) siedziałem głównie w bazach danych czyli oprogramowaniu które baaardzo lubi alokować dużooo pamięci. I tutaj limity architektualne wnoszone przez x86 były dużo bardziej upierdliwe. Na szczeście jak już ceny konfiguracji serwerowych >4GB RAM spadły do rozsądnego poziomu to miałem dostęp do systemów i oprogramowania x64. Z czego skorzystałem jak tylko miałem możliwość, boost 10-20% wynikający z porzucenia PAE jak i samego użycia x86_64 był miłym bonusem.
    
    
51. Technicznie to 32 bitowy Windows ma limit 3GB (autor: pandy | data: 4/06/23 | godz.: 01:50)
    https://learn.microsoft.com/...bb124810(v=exchg.65)?redirectedfrom=MSDN
    
    
52. @51 to nie jest limit Windows (autor: Master/Pentium | data: 4/06/23 | godz.: 10:10)
    W linux jest identyczny limit, to limit związany z architekturą x86.
    https://stackoverflow.com/...ace-and-kernel-space.
    UWAGA: Użycie tego przełącznika miało swój zestaw problemów, nie warto było uruchamiać tego bezmyślnie na serwerach.
    
    
53. @52 (autor: pandy | data: 4/06/23 | godz.: 15:45)
    To limit na maszynach 32bit której mapują I/O w przestrzeni programu i danych. Linux dziedziczy pewne cechy typowe dla maszyn opartych na Intelu ale już inne architektury nie mają takich ograniczeń.
    
    
54. @53. Owszem (autor: Master/Pentium | data: 4/06/23 | godz.: 17:09)
    Dlatego napisałem o ograniczeniach x86.