komentarze
h63619Zobacz profil
Poziom ostrzeżenia: 0%
h636192016.08.07, 13:28
-1#61
komisarz @ 2016.08.06 23:47  Post: 995930
SunTzu @ 2016.08.06 22:11  Post: 995917

Mam taki dongle działa to całkiem ok. Net nawet na tym działa dobrze ale przecież urzędnik ma pracować, a nie na fejsie siedzieć.


Naprawde nie wiesz jak wyglada praca. I jak ciezkie bywaja fronetndy. Byle system raportowania ktory siedzi na serwerze ale przsyla tysiace rekordow ktore musza byc sformatowene czy to w IE czy to w excelu potrafi zamulic najnowsze core i5 na kilkanscie sekund, czasami dluzej. A to przyklad nei chalupniczej roboty tylko SAPa. Armem mozeszw takim wypadku napalic w piecu. Albo wyszukiwanie slow w wiekszym dokumnecie. A byle Vlookup w excelu? Bardzo czesto uzywana funkcjac ktora zazyna kazdgo kompa. A57 to moze nadawac sie do wysweitlania terminala, a nie pracy. Pracuje w korporacjach od wielu lat, wiem co robia ludzie. Sadze, ze ty jednak nie i stad twoje dziwne wyborazenia. Aha, dodajmy jeszcze antywirusa, zgon sprzetu na minuty murowany.


Bo niestety bardzo często używane są błędne technologie zamówione przez głupich managerów.
Obecnie wszyscy chcą mieć frontend w HTML i Javascript a później zdziwienie, że muli. Wcześniej robili w Excellu i VBA i również muliło. A wystarczyło zrobić w WPF a obecnie w UWP i C# i F# i by nie muliło na Atomie/ARMie.
Jacek1991Zobacz profil
Poziom ostrzeżenia: 0%
Jacek19912016.08.07, 15:06
vas quander @ 2016.08.06 21:24  Post: 995911
Generalnie chciałbym zobaczyć jak odnosi się wydajność aktualnych AMR'ów do wydajności procesorów desktopowych sprzed paru lat :D Np starcie snapdragona 650 z takim Dualkiem E6500 :D

nie wiem na ile to jest miarodajne ale proc z S5 według moich testow wyszlo ze jest 7,5x wolniejszy od xeona 1230v2
StanleyZobacz profil
Poziom ostrzeżenia: 0%
Stanley2016.08.07, 17:49
mICh@eL @ 2016.08.06 21:45  Post: 995914
Obecnie z punktu widzenia programisty to tylko mała liczba rejestrów jest przeszkodą w CISC jak x86 (choć x64 dubluje ilość i jest już lepiej). A właśnie, jak CISC powstawały to rejestry i tranzystory były drogie, a pamięć nie była o rzędy wielkości wolniejsza niż procek, dlatego postawiono na model obliczeń pamięć-pamięć z minimalnym zestawem rejestrów. To teoretycznie największa kula u nogi CISC, ale zredukowana poprzez szybkie pamięci podręczne i inne techniki ;)


Już 10 lat temu to o czym piszesz zaczeło tracić racje bytu. W 2016r można je nazwać bajdurzeniem bo jest wręcz na odwrót. Poza tym jak się głębiej zastanowisz zwiększanie ilośći rejestrów nie ma sensu i jest mocno zależne od zdolności ludzkiego mózgu oraz ilości ALU, AGU procesora ;) W ARM potrzeba ich o 33% więcej więc np. z 12 robi się realne 8. Nie istnieje przecież ADD EAX, EBX ale np. ADD R0,R1,R2. Ponadto brak koprocesora/MMX - kolejne 8 'rejestrów' mniej. (era Pentium lata 90). Więc nawet dawniej ta przewaga była iluzoryczna.

Optymalna ilość rejstrów powinna pokrywać się z ilością zmiennych temporalnych w ciele funkcji np. do punktu wywołania kolejnej lub jej zakończenia. To względnie stała dla programistów. Ilość rejestrów w x86 podąża za rozbudowaniem ilości jednostek wykonawczych, górny limit stanowi jednak nadal ludzki mózg więc dalsza rozbudowa nie ma sensu. Ponadto doszło SSE które przejeło role ESI, EDI (pośrednika dla operacji na tablicach) Więc x86-64 już dekadę temu całkowicie zniwelował potencjalną słabość. Minimum 16 rejestrów 64bit do tego minimum 16x 128b SSE dla kompilatora w ramach tgz. wektoryzacji. Maksimum 32x 512b - masa rejestrów.. masa

Kluczem dla czegoś więcej (rozbudowanego programu obiektowego) jest ilość i asocjacja cache(dopasowana do zastosowań tj. ilości i rozmiaru wątków). Sięganie do RAM to jak sięganie po dyskietkę. L3 służy do przełączania kontekstów dla procesów/synchronizacji wątków im więcej kontekstu tym bardziej zmarnowana. Dlatego pojawiła się wraz z rozwojem multicore i wciąż zwiększa. L2 należy traktować praktycznie rzecz biorąc jako ilosć pamięci RAM dla wątku dla multicore może generować wieczne opóźnienia 'invalidate' Jej rozmiar pozostaje raczej bez zmian bo programista też. L1 to pamięć dla szeregu wywołań funkcji wątku np. rekurencja do której kluczowe jest redukowanie ilości zmiennych. Względnie stała od lat. Nawet jeśli coś trafi do rejestru, po wywołaniu funkcji rejestr trafia na stos.. więc ilość rejestrów ma pewien limit ponad to ilość jest bez znaczenia skoro i tak trafia do RAM. Cała reszta tablic i struktur trafia do cache/ram, nawet jeśli trafi jeden bajt trafia tam cała linijka 64 bajtów. Że jest to aż nadto pokazał przypadek pierwszego Pentium 4 z szerszą linijką cache - najwyraźniej 12x64bit nie podążało to za ilością zmiennych lokalnych stąd sporo pamięci się marnowało, sporo linijek.. czego brakowało Celeronom D. Że warto zmniejszać opóźnienia do L1/L2 pokazał K7 ale wtedy faktycznie brakowało rejestrów (32bit).

ARMv8 ma obecnie w teorii 31(jeden z 32 trwale zero) ale większość z nich jest zarezerwowana i do dyspozycji pozostaje zaledwie 12-14 rejestrów! Dawniej ARMv7 było 16 ale były też dodatkowe na wzór z Intelowskim EBP, ESP to robiło wrażenie przy 4 rejestrach EAX-EDX (ALU, AGU) oraz dwóch EDI, ESI(głównie AGU np adresacja tablic). Dla ARM ich ilość się wręcz zmniejszyła ale trzeba brać pod uwagę że jeden 64-bit zajmuje 8 bajtów. Zachowaj 16 a stracisz 2 linijki cache więc ARM poszedł na ustępstwa. Dawniej z uwagi na zastosowania chodziło raczej o odciążenie operacji LOAD-STORE, skrócenie operacji zmuszało do przechowania wyników pośrednich. Stąd ich duża ilość dziś to bardziej balast niż przewaga..

Duża ilosć rejestrów jest przeszkodą dla OS w przerzucaniu kontekstu zadań. Obecnie to raczej problem dla x86 a nie wada, że ma ich za dużo nie za mało. Dawniej FSAVE potrzebowało zaledwie 120-200 bajtów do zachowania stanu procesora, z SSE potrzeba aż 512 natomiast XSAVE z AVX potrzeba ok 8kB pamięci zachować.. przy większej liczbie procesów nawet jeśli na tym samym procesorze dasz np. 8MB cache to zachowa się jak dawniej 1MB i cała para pójdzie w gwizdek. Skoro więcej niż 16 zmiennych czyni funkcje trudną do zrozumienia. Umysł człowieka jest w stanie zrozumieć do 5 zdań 'rekurencyjnych więc nie ma co się prześcigać na ilość rejestrów, rozszerzeń i zmuszania OS do zachowania ' niepotrzebnego śmiecia' podczas przełączania kontekstu. Podejrzewam ze dla zachowania stanu procka x86 (bez FPU) wystarczył zaledwie 64B - jedna linijka cache, stąd taka ilość w 86? Moim zdaniem zwiększanie ilości rejestrów dawniej byłoby wręcz szkodliwe dla x86 był to plus dodatni. Dla ARM było konieczne(wyniki pośrednie) ale miało też plusy ujemne dla bardziej rozbudowanego OS. Obecnie Intel 'króluje' w prześciganiu się na ich ilość i to wcale nie jest dobrze. 32x 512bit AVX jisas krajst. Zauważcie dla Windows 10: konieczne CMPXCHG16 bo:

Promilus1984Zobacz profil
Poziom ostrzeżenia: 0%
Promilus19842016.08.07, 19:46
@Stanley - dokładnie, tylko michael zapomniał, że w miarę nowoczesne x86 (od pentium II bodajże) mają więcej fizycznych rejestrów niż zakłada ich model programowy, a to przez out of order execution i register renaming ;) Tak właśnie intel łamał ograniczenia CISC i ciągle mu to dobrze wychodzi.
mICh@eLZobacz profil
Poziom ostrzeżenia: 0%
mICh@eL2016.08.07, 21:12
Promilus1984 @ 2016.08.07 07:35  Post: 995943
Z czasem oczywiście RISC były rozbudowywane, a CISC od Pentiuma były wewnętrznie RISC i tylko tłumaczyły instrukcje na wewnętrzny kod mikrooperacji.

Następny mitoman ;) Nie ma i nie było żadnego wewnętrznego RISC w Pentium. Mikrokod x86 miały i 386 i nikt nie twierdzi, że w środku siedzi RISC! Skąd mit? Ano bierze się z tego, że dla RISC dekoder jest prosty bo w znaczącej większości 1 rozkaz RISC = 1 mikroinstrukcja. Dlatego mikroinstrukcje Z ZASADY są RISC-like. Teraz skoro x86 czyli procesor CISC też wewnetrznie operuje na mikroinstrukcjach to dla wielu mitomanów 'to jest przefarbowany RISC'. A to jest zwyczajna bujda. Taką drogę obrało AMD w przypadku K5 (rdzeń z Am2900) i o ile znacząco zwiększyło to wydajność całkowitoliczbową to zmiennoprzeciwnkowa leżała i kwiczała. Nx5x86 cechował ten sam problem (przy czym ten procesor nie miał dedykowanego FPU wewnątrz, a zewnętrzny i tak był cienki). Na bazie kolejnego pomysłu NexGena powstał K6 i ... a jakże, nadal były dokładnie te same wady! Pentium to był CISC tylko wspomagany 2 potokiem wykonawczym (potok U dla złożonych instrukcji i potok V dla prostych instrukcji). I Intel nadal rozwija tą samą technologię (od Core 2 - 1 potok dla złożonych instrukcji do 4uops, 3 do prostych instrukcji 1uop). AMD przez moment wybiło się z K7 i jego kontynuacją K8 dzięki napływowi inżynierów z Alphy (kolejny RISCowy procesor) - dzięki nim dopracowali co nie działało we wcześniejszych modelach, przede wszystkim mocno poprawiono FPU i magistrale danych. Nie zmienia to faktu, że w czasach G3, G4 i PIII, P4 nadal była to wojna RISC vs CISC i od tamtego czasu nic się nie zmieniło. Czy zupełnie CISCowe ALU 8051 różni się bardzo od RISCowego z AVR? Pomijając to, że 8051 bazuje na akumulatorze do przechowywania wyniku, a w AVR można sobie wybrać rejestr docelowy? Nie, działa tak samo. Dostaje dane na wejście, linie sterujące się zmieniają... cykl lub kilka później jest wynik. Cała CISCowość kończy się za logiką sterującą. I zawsze kończyła.

Chyba nie do końca rozumiesz jak działa procesor myląc potokowość z superskalarnością. 8086 miał już potokową realizację - dwie fazy, bo najpierw dekodowanie, potem wykonanie. 486 miał już bardziej klasycznej 5 stopni. Ale bez uOps nie zrobisz głębokiego potoku na 14 stopni czystymi CISCowymi instrukcjami, a taki 486 z typowymi CISCowymi instrukcjami jak wielomiany utknie po prostu w fazie wykonania wstrzymując napełnianie potoku.

Czysty CISC bezpotokowy jak dostaje skomplikowaną instrukcje, to po prostu ją wykonuje, czyli z każdym taktem przełącza linie sterujące, dane wędrują po magistralach, do ALU który wykonuje operacje, do rejestrów, na stos itd. (np. operacje na kolejkach w VAX-ie). Potem leci ostatni cykl i ładowanie kolejnego rozkazu.

Samo wykonywanie skomplikowanego rozkazu może trwać np. 200 taktów, gdzie inkrementacja akumulatora to jest myk, więc nie zrobisz w taki sposób realizacji potokowej. Musisz do tego mieć zestaw instrukcji podstawowych, które się wykonują w jednakowym czasie, żeby to miało sens (a nie potok wstrzymany co chwile bo leci długa instrukcja).

W pierwszych RISCach wybrano drogę opracowania takiego ISA i procesor dostawał już od razu takie instrukcje, a cała zabawa w zamienianie konstrukcji typu a += b spoczywało na kompilatorze, który musiał wygenerować rozkazy ładowania do rejestrów, sumowania, zapisu, itd. (w x86 to zrobisz jedną instrukcją bo pamięć-pamięć). Intel nie mógł tak oderwać się, bo windowsy i inne programy, więc poszli drogą tłumaczenia instrukcji - robili to co kompilator, czyli rozbijali na te podstawowe instrukcje, które dopiero były wykonywane przez procesor i jego jednostkę sterującą sygnałami. Tu nie ma żadnej bujdy czy mitu, choć może nie dosłownie tam jest wewnętrzny RISC i tylko w locie tłumaczy instrukcje, natomiast sama zasada działania jest właśnie riscowa z tymi mikro-operacjami :P
mICh@eLZobacz profil
Poziom ostrzeżenia: 0%
mICh@eL2016.08.07, 21:39
Promilus1984 @ 2016.08.07 19:46  Post: 996002
@Stanley - dokładnie, tylko michael zapomniał, że w miarę nowoczesne x86 (od pentium II bodajże) mają więcej fizycznych rejestrów niż zakłada ich model programowy, a to przez out of order execution i register renaming ;) Tak właśnie intel łamał ograniczenia CISC i ciągle mu to dobrze wychodzi.

Ja to doskonale pamiętam, bo nawet miesiąc temu z tego egzamin pisałem. A byłem chyba jedną z niewielu osób które chodziły na wszystkie wykłady, bo mnie tematyka bardzo interesowała :P Po prostu wczoraj nie miałem czasu, by cały semestr studiów streścić w komentarzu w 15 minut :D

Stanley @ 2016.08.07 17:49  Post: 995985
mICh@eL @ 2016.08.06 21:45  Post: 995914
Obecnie z punktu widzenia programisty to tylko mała liczba rejestrów jest przeszkodą w CISC jak x86 (choć x64 dubluje ilość i jest już lepiej). A właśnie, jak CISC powstawały to rejestry i tranzystory były drogie, a pamięć nie była o rzędy wielkości wolniejsza niż procek, dlatego postawiono na model obliczeń pamięć-pamięć z minimalnym zestawem rejestrów. To teoretycznie największa kula u nogi CISC, ale zredukowana poprzez szybkie pamięci podręczne i inne techniki ;)


Już 10 lat temu to o czym piszesz zaczeło tracić racje bytu. W 2016r można je nazwać bajdurzeniem bo jest wręcz na odwrót. Poza tym jak się głębiej zastanowisz zwiększanie ilośći rejestrów nie ma sensu i jest mocno zależne od zdolności ludzkiego mózgu oraz ilości ALU, AGU procesora ;) W ARM potrzeba ich o 33% więcej więc np. z 12 robi się realne 8. Nie istnieje przecież ADD EAX, EBX ale np. ADD R0,R1,R2. Ponadto brak koprocesora/MMX - kolejne 8 'rejestrów' mniej. (era Pentium lata 90). Więc nawet dawniej ta przewaga była iluzoryczna.

Optymalna ilość rejstrów powinna pokrywać się z ilością zmiennych temporalnych w ciele funkcji np. do punktu wywołania kolejnej lub jej zakończenia. To względnie stała dla programistów. Ilość rejestrów w x86 podąża za rozbudowaniem ilości jednostek wykonawczych, górny limit stanowi jednak nadal ludzki mózg więc dalsza rozbudowa nie ma sensu. Ponadto doszło SSE które przejeło role ESI, EDI (pośrednika dla operacji na tablicach) Więc x86-64 już dekadę temu całkowicie zniwelował potencjalną słabość. Minimum 16 rejestrów 64bit do tego minimum 16x 128b SSE dla kompilatora w ramach tgz. wektoryzacji. Maksimum 32x 512b - masa rejestrów.. masa

Kluczem dla czegoś więcej (rozbudowanego programu obiektowego) jest ilość i asocjacja cache(dopasowana do zastosowań tj. ilości i rozmiaru wątków). Sięganie do RAM to jak sięganie po dyskietkę. L3 służy do przełączania kontekstów dla procesów/synchronizacji wątków im więcej kontekstu tym bardziej zmarnowana. Dlatego pojawiła się wraz z rozwojem multicore i wciąż zwiększa. L2 należy traktować praktycznie rzecz biorąc jako ilosć pamięci RAM dla wątku dla multicore może generować wieczne opóźnienia 'invalidate' Jej rozmiar pozostaje raczej bez zmian bo programista też. L1 to pamięć dla szeregu wywołań funkcji wątku np. rekurencja do której kluczowe jest redukowanie ilości zmiennych. Względnie stała od lat. Nawet jeśli coś trafi do rejestru, po wywołaniu funkcji rejestr trafia na stos.. więc ilość rejestrów ma pewien limit ponad to ilość jest bez znaczenia skoro i tak trafia do RAM. Cała reszta tablic i struktur trafia do cache/ram, nawet jeśli trafi jeden bajt trafia tam cała linijka 64 bajtów. Że jest to aż nadto pokazał przypadek pierwszego Pentium 4 z szerszą linijką cache - najwyraźniej 12x64bit nie podążało to za ilością zmiennych lokalnych stąd sporo pamięci się marnowało, sporo linijek.. czego brakowało Celeronom D. Że warto zmniejszać opóźnienia do L1/L2 pokazał K7 ale wtedy faktycznie brakowało rejestrów (32bit).

ARMv8 ma obecnie w teorii 31(jeden z 32 trwale zero) ale większość z nich jest zarezerwowana i do dyspozycji pozostaje zaledwie 12-14 rejestrów! Dawniej ARMv7 było 16 ale były też dodatkowe na wzór z Intelowskim EBP, ESP to robiło wrażenie przy 4 rejestrach EAX-EDX (ALU, AGU) oraz dwóch EDI, ESI(głównie AGU np adresacja tablic). Dla ARM ich ilość się wręcz zmniejszyła ale trzeba brać pod uwagę że jeden 64-bit zajmuje 8 bajtów. Zachowaj 16 a stracisz 2 linijki cache więc ARM poszedł na ustępstwa. Dawniej z uwagi na zastosowania chodziło raczej o odciążenie operacji LOAD-STORE, skrócenie operacji zmuszało do przechowania wyników pośrednich. Stąd ich duża ilość dziś to bardziej balast niż przewaga..

Duża ilosć rejestrów jest przeszkodą dla OS w przerzucaniu kontekstu zadań. Obecnie to raczej problem dla x86 a nie wada, że ma ich za dużo nie za mało. Dawniej FSAVE potrzebowało zaledwie 120-200 bajtów do zachowania stanu procesora, z SSE potrzeba aż 512 natomiast XSAVE z AVX potrzeba ok 8kB pamięci zachować.. przy większej liczbie procesów nawet jeśli na tym samym procesorze dasz np. 8MB cache to zachowa się jak dawniej 1MB i cała para pójdzie w gwizdek. Skoro więcej niż 16 zmiennych czyni funkcje trudną do zrozumienia. Umysł człowieka jest w stanie zrozumieć do 5 zdań 'rekurencyjnych więc nie ma co się prześcigać na ilość rejestrów, rozszerzeń i zmuszania OS do zachowania ' niepotrzebnego śmiecia' podczas przełączania kontekstu. Podejrzewam ze dla zachowania stanu procka x86 (bez FPU) wystarczył zaledwie 64B - jedna linijka cache, stąd taka ilość w 86? Moim zdaniem zwiększanie ilości rejestrów dawniej byłoby wręcz szkodliwe dla x86 był to plus dodatni. Dla ARM było konieczne(wyniki pośrednie) ale miało też plusy ujemne dla bardziej rozbudowanego OS. Obecnie Intel 'króluje' w prześciganiu się na ich ilość i to wcale nie jest dobrze. 32x 512bit AVX jisas krajst. Zauważcie dla Windows 10: konieczne CMPXCHG16 bo:]

Nie mam czasu się tak rozpisywać, więc krótka piłka: pisałeś kiedyś coś większego w czystym asemblerze x86? Bo ja tak, robiłem projekt z wykrywania krawędzi z użyciem instrukcji wektorowych, tak samo pisałem mały programik w asemblerze AVR. Chciałem już przestać czytać po tym fragmencie:
> 'W ARM potrzeba ich o 33% więcej więc np. z 12 robi się realne 8. Nie istnieje przecież ADD EAX, EBX ale np. ADD R0,R1,R2.'
Nawet nie wiesz, że to tylko format instrukcji (ba, w AVX intel wprowadził VEX i wszystkie instrukcje, nawet stare SSE też są w formacie trójargumentowym) i możesz najzwyczajniej w świecie napisać ADD R0, R0, R0? Właśnie niedestruktywny format rozkazów to kolejny wielki bonus riscowy, bo unikasz dodatkowych instrukcji robiących kopię aktualnej wartości rejestru. A że w x86 rejestrów mało to przeważnie wszystko leciało na stos ;)

Ale potem napisałeś jeszcze to:
> 'Minimum 16 rejestrów 64bit do tego minimum 16x 128b SSE dla kompilatora w ramach tgz. wektoryzacji. Maksimum 32x 512b - masa rejestrów.. masa'
I wtedy przestałem czytać, bo już byłem pewny, że nie wiesz o czym piszesz, skoro uważasz, że do rejestrów wektorowych masz wyrywkowy dostęp i możesz tam sobie schować łatwo i szybko wynik operacji ALU, czy cokolwiek co jest Ci potrzebne na później :D Tak nie jest, to są rejestry wektorowe, a nie tablice z bezpośrednim dostępem.

Druga kwestia, dotyczy właśnie tej ilości rejestrów. Jakbyś kiedyś coś programował, to byś wiedział, że właśnie duża liczba rejestrów roboczych znacznie ułatwia programiście robotę, bo wie co gdzie jest, a nie żongluje ze stosem chowając wartości i gubiąc się co gdzie jest. Kompilator da radę, ale to zawsze jest kosztem wydajności, bo nawet jak sięga tylko do cache L1 to i tak musi wykonać te operacje, a nie ma danych w superszybkich rejestrach.
Tak samo dopiero w x86-x64 domyślnie standardem jest wywoływanie procedury przekazując argumenty w rejestrach, a nie poprzez stos, co jest w rękach dobrego programisty tak szybkie jak zwykły skok.

Kompletną kompromitację zaliczyłeś natomiast wyliczając ile to pamięci potrzeba, żeby schować cały kontekst procesora. Jeżeli ktoś sobie nie potrafi sobie poradzić z tym z jakich rejestrów korzysta i które trzeba schować/przywrócić, tylko wali od razu ALL na stos, to nie powinien się brać za asm tylko siedzieć w C#. Co najciekawsze, w x64 wywalono zupełnie z tego powodu instrukcje PUSHAD/POPAD, które to robiły xD
Bo programista powinien wiedzieć czego używa i jakich zasobów potrzebuje i sam zadbać o to, by zachować stan przed pracą i go przywrócić.

Jak piszesz zwykły soft w asm to dodatkowo dochodzi konwencja wywołania, gdzie z 2/3 rejestrów jest traktowane jako ulotne i danymi które tam są nie musisz się przejmować zupełnie, zachowujesz tylko te kilka których używasz. Dopiero jak siedzisz w grubszym temacie i procedurach obsługi przerwań, to musisz uważać na wszystko.

A z przełączaniem kontekstów czy wywoływaniem funkcji to sobie poradzono w takim SPARCu bardzo prosto, robiąc okno rejestrów na n wywołań (tak, wtedy rekurencja działa wolno bo szybko wyłazisz poza okno i na stosie siedzisz).

Generalnie to wygląda jakbyś to miał 5 lat temu na studiach i połowę pozapominałeś, a nigdy nie programowałeś tak niskopoziomowo z myślą o optymalizacji ;)
MarianPodjadekZobacz profil
Poziom ostrzeżenia: 0%
MarianPodjadek2016.08.07, 21:51
-4#67
Trzeba mieć niezle nasrane we łbie aby porównywać Nvidie Shield z ponad 10 letnim Xboxem 360! Dlaczego nie porównacie mocy Shield z PS4, które tez już nie jest młode!
Za rok wyjdzie PS4 Neo z mocom 4.5 Teraflupa i zmiecie tego Shielda z powierzchni ziemi!!!
Procesor Arm nigdy nie będzie wstanie pokonać x86 i taka jest brutalna prawda!!! To są procesory które na zawsze utkną w smartfonach i tabletach!!!
h63619Zobacz profil
Poziom ostrzeżenia: 0%
h636192016.08.08, 01:25
@ mICh@eL, Stanley
O rejestrach uczyłem się w czasach gry P4 był nowością i od tego czasu preferuję jednak C#.
Natomiast z tego co pamiętam to problemem jest nie tyle mała ilość rejestrów co brak ich uniwersalności w porównaniu z RISC gdzie każdy rejestr jest taki sam.
Pisanie programów w asemblerze jest obecnie niszowe i nie ma wielkiego wpływu na popularność danego procesora. Natomiast komplikacja rejestrów x86 wpływa na łatwość komplikację kompilacji efektywnego kodu. Mam wrażenie, że testy gdzie x86 zmasakrowało ARM były na Core M z użyciem SSE i/lub GPU a na ARM czystego kodu ARM.
Co do przełączania kontekstu to chyba inaczej jest jak masz jeden proces a inaczej jak kilka i OS co jakiś czas wywala twój program i wsadza coś swojego i wówczas musi wymienić wszystkie rejestry i zdolność programisty tu ma niewiele do gadania.
I tu właśnie przydaje się architektura big.LITTLE gdzie ważny wątek może sobie przez długi czas siedzieć na szybkim jądrze a mniej ważne wątki zmieniają się na małych jądrach. Ciekawym rozwiązaniem mógłby być CPU z 1 jądrem Core i 4 Atomami.
h63619Zobacz profil
Poziom ostrzeżenia: 0%
h636192016.08.08, 01:29
MarianPodjadek @ 2016.08.07 21:51  Post: 996014
Trzeba mieć niezle nasrane we łbie aby porównywać Nvidie Shield z ponad 10 letnim Xboxem 360! Dlaczego nie porównacie mocy Shield z PS4, które tez już nie jest młode!
Za rok wyjdzie PS4 Neo z mocom 4.5 Teraflupa i zmiecie tego Shielda z powierzchni ziemi!!!
Procesor Arm nigdy nie będzie wstanie pokonać x86 i taka jest brutalna prawda!!! To są procesory które na zawsze utkną w smartfonach i tabletach!!!

Mylisz GPU z CPU i mówisz o innych budżetach energetycznych.
Pojawi się ARM połączony z mocnym GPU i będzie się doskonale nadawał do konsoli i zmiecie PS4 Neo.
Orzel94Zobacz profil
Poziom ostrzeżenia: 0%
Orzel942016.08.08, 08:20
Promilus1984 @ 2016.08.07 07:35  Post: 995943
Z czasem oczywiście RISC były rozbudowywane, a CISC od Pentiuma były wewnętrznie RISC i tylko tłumaczyły instrukcje na wewnętrzny kod mikrooperacji.

Następny mitoman ;) Nie ma i nie było żadnego wewnętrznego RISC w Pentium. Mikrokod x86 miały i 386 i nikt nie twierdzi, że w środku siedzi RISC! Skąd mit? Ano bierze się z tego, że dla RISC dekoder jest prosty bo w znaczącej większości 1 rozkaz RISC = 1 mikroinstrukcja. Dlatego mikroinstrukcje Z ZASADY są RISC-like. Teraz skoro x86 czyli procesor CISC też wewnetrznie operuje na mikroinstrukcjach to dla wielu mitomanów 'to jest przefarbowany RISC'. A to jest zwyczajna bujda. Taką drogę obrało AMD w przypadku K5 (rdzeń z Am2900) i o ile znacząco zwiększyło to wydajność całkowitoliczbową to zmiennoprzeciwnkowa leżała i kwiczała. Nx5x86 cechował ten sam problem (przy czym ten procesor nie miał dedykowanego FPU wewnątrz, a zewnętrzny i tak był cienki). Na bazie kolejnego pomysłu NexGena powstał K6 i ... a jakże, nadal były dokładnie te same wady! Pentium to był CISC tylko wspomagany 2 potokiem wykonawczym (potok U dla złożonych instrukcji i potok V dla prostych instrukcji). I Intel nadal rozwija tą samą technologię (od Core 2 - 1 potok dla złożonych instrukcji do 4uops, 3 do prostych instrukcji 1uop). AMD przez moment wybiło się z K7 i jego kontynuacją K8 dzięki napływowi inżynierów z Alphy (kolejny RISCowy procesor) - dzięki nim dopracowali co nie działało we wcześniejszych modelach, przede wszystkim mocno poprawiono FPU i magistrale danych. Nie zmienia to faktu, że w czasach G3, G4 i PIII, P4 nadal była to wojna RISC vs CISC i od tamtego czasu nic się nie zmieniło. Czy zupełnie CISCowe ALU 8051 różni się bardzo od RISCowego z AVR? Pomijając to, że 8051 bazuje na akumulatorze do przechowywania wyniku, a w AVR można sobie wybrać rejestr docelowy? Nie, działa tak samo. Dostaje dane na wejście, linie sterujące się zmieniają... cykl lub kilka później jest wynik. Cała CISCowość kończy się za logiką sterującą. I zawsze kończyła.

Mit nie mit nie wiem bo w środku nie widziałem. Faktem że że uczyli mnie o tym na uczelni że (nie pamiętam od którego momentu) ale że x86 intela przeszło na RISC i dla zachowania kompatybilności intrukcje CISC są tłumaczone na RISC na poziomie mikrokodu. (do tego też gdzieś na jakimś forum o tym czytałem bo już papke z mózgu miałem, nie wiedziałem co jest co i gdzie)
DuchuZobacz profil
Poziom ostrzeżenia: 0%
Duchu2016.08.08, 09:25
Długo czekałem na takiego arta... Świetna Robota.

Najbardziej zaciekawiła mnie 8 i 9 strona... Aż się rozmarzyłem... Gdyby na obecnym rynku GPU było 4 graczy i każdy oferowałby układy w porównywalnej wydajności. Konkurencja wzmaga i pobudza do doskonalenia całą branżę.

Pozdr.
Promilus1984Zobacz profil
Poziom ostrzeżenia: 0%
Promilus19842016.08.08, 20:25
Chyba nie do końca rozumiesz jak działa procesor myląc potokowość z superskalarnością. 8086 miał już potokową realizację - dwie fazy, bo najpierw dekodowanie, potem wykonanie

Nie wiem na jakiej podstawie wysnułeś taką hipotezę, że cokolwiek mylę. Pentium miał 2 potoki wykonawcze, U i V - to jest architektura superskalarna (wiele jednostek wykonawczych), a potok jest po to żeby to efektywnie działało. Pokaż mi efektywnie działający superskalarny procesor bez potoku wykonawczego ;)
BTW każdy procesor wedle Twojego pomysłu jest potokowy, dodatkowo zupełnie mylisz pojęcia. Dlaczego? Bo każdy procesor musi rozkaz pobrać (fetch), zdekodować (decode) i wykonać (execute) - a to jak to jest rozwiązane w różnych procesorach to inna bajka. 8086 owszem coś na kształt potoku miał dzięki rozdzieleniu procesora na 2 bloki 'bus interface unit' i 'execution unit' - niemniej kolejka była krótka, brak przewidywania rozgałęzień etc. Wszystko to co absolutnie MUSI być, szczególnie jeśli potok jest dłuższy i przeładowanie kolejki będzie powodowało znaczące zmniejszanie wydajności. Jakiś jeszcze komentarz co do mojego pojmowania tematu?
Czysty CISC bezpotokowy jak dostaje skomplikowaną instrukcje, to po prostu ją wykonuje, czyli z każdym taktem przełącza linie sterujące, dane wędrują po magistralach, do ALU który wykonuje operacje, do rejestrów, na stos itd. (np. operacje na kolejkach w VAX-ie). Potem leci ostatni cykl i ładowanie kolejnego rozkazu

Serio stary, klawiszem popychałem cykle 8051 rysując stany na magistralach, chcesz kogoś uczyć to proszę bardzo, tylko nie widzę sensu pisać takich rzeczy w odniesieniu do mnie.
Samo wykonywanie skomplikowanego rozkazu może trwać np. 200 taktów

Oczywiście, że może. Wystarczy zobaczyć wykonanie takiego dzielenia na danych z pamięci DRAM na Amidze 500 (68000) - ile cykli zegarowych zajmuje. I jeszcze raz zapytam - co z tego? Każda kolejna konstrukcja motoroli dokładnie jak kolejne konstrukcje intela wprowadzała nowe rozwiązania do starych CISCowych systemów podnoszące MIPSy i FLOPsy bez żyłowania zegara. I później motka rzuciła wszystko w diabły i weszła w AIM - ale wielkiej furory nie zrobili poza specyficznym kawałkiem rynku high performance embedded gdy Apple samo przerzuciło się na Intela.
natomiast sama zasada działania jest właśnie riscowa z tymi mikro-operacjami

Różnica jest w podejściu - czy RISC nie posiadały dekodera? Ależ oczywiście, że posiadały :) Tylko znacznie, znacznie mniej skomplikowany niż CISC. Innymi słowy RISC posiadają mikrooperacje. CISC też posiadają mikrooperacje. RISC zazwyczaj ma 1:1 czasem 1:2, CISC posiada 1:1, czasem 1:2, 1:3, 1:4 (i całkiem skomplikowane specjalnym trybem nawet więcej) jeśli chodzi asm:uops. I ot dla niektórych to wystarczy, żeby napisać, że w środku siedzi RISC. No w końcu mikrokod jest 'inherently RISC' ;) Owszem, problem w tym, że zawsze był. Wykastruj logikę dekodującą (LUT, PLA, ROM) z CISC i zostanie logika, którą można wykorzystać do realizacji mniejszej ilości prostych instrukcji bez żmudnego tłumaczenia i wykonywania w wielu cyklach. Działa to też w drugą stronę. I o tym pisałem. NexGen i AMD na sprawdzony, wydajny, RISCowy układ wykonawczy nakleili układ dekodujący x86. Ten układ nie tłumaczył pośrednio do AM29k, a później mikrokodu ;) On tłumaczył od razu do mikrokodu. Procesor był całkowicie CISCowy. Motorola też robiła procki w których można było zaprogramować listę rozkazów przy z góry ustalonej logice wykonawczej. Sama architektura jednostek wykonawczych nie jest z góry RISCowa czy z góry CISCowa. Więcej zależy od układu dekodującego i logiki sterującej. Co innego transmeta - tam rzeczywiście w środku siedzi VLIW :) I rzeczywiście 'dekoder' tłumaczy w locie. Więc w tym jednym przypadku można powiedzieć, że to CISC z VLIWem w środku. Choć w teorii równie dobrze mógłby być to RISC z VLIWem w środku. I z tego względu jestem strasznie cięty na spłycanie typu 'intel robi RISCowe procesory gdzie balastem jest wspieranie CISC' - jaki balast? Jakby intelowski układ wykonawczy mógł z POWER ISA 2x lepiej działać to by sami odkupili licencję i zamiast Xeonów x86 byłyby powerowe ;) Rzecz w tym, że ta architektura bloków wykonawczych, potoku, rejestrów, predykcji rozgałęzień etc. działa tak dobrze bo jest skrojona na x86 :) I nie będzie nagle cudownie lepiej działać z innym ISA. Można by też iść w drugą stronę - jeśli POWER było takie dobre to czemu go nie ubrali w ISA x86 ;) Kupić licencję, albo dać know-how AMD i niech leje konkurencję. A jednak... nic takiego się nie stało.


h63619Zobacz profil
Poziom ostrzeżenia: 0%
h636192016.08.08, 22:01
x86 przed 486 nie miały potoku. Instrukcje były wykonywane pewną ilość taktów przez różne bloki procesora ale w danym momencie w procesorze była tylko jedna instrukcja i zanim procesor nie skończył jej wykonywać nie pobierał następnej. W efekcie przez większość czasu większość procesora nic nie robiła.
W 486 wprowadzono potok i czyli procesor przewidywał, która będzie kolejna instrukcja i zaczynał ją wykonywać zanim skończył wykonywanie poprzedniej o ile następna instrukcja nie zależała od poprzedniej. W razie błędnego przewidzenia skoku procesor unieważniał częściowo wykonany potok i zaczynał od nowa.
W pentium doszło wykonywanie out of order czyli jak kolejna instrukcja zależała od poprzedniej to procesor szukał instrukcji, która była niezależna i można ją było wykonać a na koniec i tak wyniki ustawiać w kolejności.
xoloxZobacz profil
Poziom ostrzeżenia: 0%
xolox2016.08.09, 09:06
-1#74
* wydajność topowego komputera z przed 10 lat w kieszeni












*- przez około 5 sekund potem procesor troluje
StanleyZobacz profil
Poziom ostrzeżenia: 0%
Stanley2016.08.09, 12:46
mICh@eL @ 2016.08.07 21:39  Post: 996013

I wtedy przestałem czytać, bo już byłem pewny, że nie wiesz o czym piszesz, skoro uważasz, że do rejestrów wektorowych masz wyrywkowy dostęp i możesz tam sobie schować łatwo i szybko wynik operacji ALU, czy cokolwiek co jest Ci potrzebne na później :D Tak nie jest, to są rejestry wektorowe, a nie tablice z bezpośrednim dostępem.


Przez to że nie doczytałeś pewnie nie zrozumiałeś tego co napisałem. Dostep do SSE jest bezpośredni jeśli chcesz! jest wektorowo jeśli chcesz. Problemem owszem jest traktowanie szerokości rejestrów używanych w ten czy inny sposób. Do przechowania pojedynczego 'wyniku operacji ALU' ograniczona jest do arytmetyki 8-64 bit (SSE4 wprowadziło 128bit?) wiec w sumie do skrawka ich pojemności. Dlatego bardziej się opłaca traktować je wektorowo grupując jako np. 4x32, 4 x 64bit niż jako ALU dla pojedynczej operacji. Nie zrobiło to z x86 procków 128bit ale od lat spokojnie można traktować zestaw x86, MMX, XMM jako ~ 14-40 rejestrów ogólnego przeznaczenia... Jeśli bardzo chcesz!

Ale nie potrzeba znać asemblera(instrict). Nawet specjalnie nie potrzeba wnikać ile tych rejestrów faktycznie jest, który jest jaki w który konkretnie to co chcesz trafia. Kompilatory już od dawna zastępują x87 przez SSE, potrafia wykorzystać te rejestry do zrównoleglania pętli, właśnie operacjach 'for_each' do 'zwiększenia ilości rejestrów' jakimi dysponują do operacji na tablicach. Jajec nie urywa bo w takim zastosowaniu SIMD to wcale nie SIMD

Jasne że nie jest to uniwersane i transparentne jak ARM ale sam zauważyłeś że RISC dostał bęcki od x86 datego że nie użyto Neon... no więc jednak Neon (AltiVec, SSE, AVX itp) są kluczowe nie jakieś tam 32 rejestry ogólnego przeznaczenia?

Kompilator da radę, ale to zawsze jest kosztem wydajności, bo nawet jak sięga tylko do cache L1 to i tak musi wykonać te operacje, a nie ma danych w superszybkich rejestrach.


Masz poniekąd racje że odbywa się to zawsze kosztem wydajnosci Visual Studio Standard 32bit (które nie miało opcji optymalizacji zmiennej do rejestru) vs kompilator Intel lub Visual Studio Professional ok 20% przewagi kodu(osobiste obserwacje kodu zrobionego tak aby kluczowe zmienne były w rejestrach - nie tam jakiś na odczep)... Dowodzik bardziej ogólny że ilość rejestrów nie jest świętym gralem i jajec nie urwie to migracja na 64 bit. Ta migracja powinna już dawno uciąć wszelkie dyskusje na temat.

Tak samo dopiero w x86-x64 domyślnie standardem jest wywoływanie procedury przekazując argumenty w rejestrach, a nie poprzez stos, co jest w rękach dobrego programisty tak szybkie jak zwykły skok.


No nie wiem czy tak samo szybkie, piszesz jakby kod wogólnie nie zajmował pamięci, nie potrzeba go pobierać czy jak? Czy faktycznie te kilka bajtów na stosie robi różnice?

Kompletną kompromitację zaliczyłeś natomiast wyliczając ile to pamięci potrzeba, żeby schować cały kontekst procesora. Jeżeli ktoś sobie nie potrafi sobie poradzić z tym z jakich rejestrów korzysta i które trzeba schować/przywrócić, tylko wali od razu ALL na stos, to nie powinien się brać za asm tylko siedzieć w C#.


Kompletna kompromitacją jest komentowanie tekstu którego nie przeczytałeś (jak sam twierdzisz). Proszę cie może przestań pompować swoje ego - bo to chyba główny wątek w Twojej głowie? Przecież napisałem że chodzi o kontekst procesu(słowo wątek nie powinno tu paść - przyznaje) a nie wrzucanie na stos podczas wywołania funkcji.

Nie wiem na pewno jaki statystycznie jest problem dla OS. Wiem natomiast że to się dzieje, tego jest coraz więcej. Zobacz kod dowolnego OS albo np. hyperwizora. 8kB to literalnie tyle ile potrzeba dla zachowania kontekstu nowoczestnego procka AVX przed przełączeniem CPU do innego zadania. Dzieje się to tym częściej im częściej wirtualny OS odwołuje się do syscall.. więc dla wirtualizacji (serwerów) może to mieć znaczenie?
Nie tylko ze wzgledu na czas(bo w sumie to betka) ale zużycie energii? Można zastanwiać sie nad marnowaniem tranzystorów które pozostają puste nie dając wyników (patrz SSE w którym zapałniono raptem 64bit). Ale jeśli już dyskutować o ilości rejestrów sprawa sprowadza się do tego że to nadmiar jest kłopotem Intela a nie ich brak czy jakieś inne teoretyczne rozważania istotne z lat 80 ubiegłego stulecia.
mICh@eLZobacz profil
Poziom ostrzeżenia: 0%
mICh@eL2016.08.09, 18:01
Promilus1984 @ 2016.08.08 20:25  Post: 996270
I z tego względu jestem strasznie cięty na spłycanie typu 'intel robi RISCowe procesory gdzie balastem jest wspieranie CISC' - jaki balast? Jakby intelowski układ wykonawczy mógł z POWER ISA 2x lepiej działać to by sami odkupili licencję i zamiast Xeonów x86 byłyby powerowe ;) Rzecz w tym, że ta architektura bloków wykonawczych, potoku, rejestrów, predykcji rozgałęzień etc. działa tak dobrze bo jest skrojona na x86 :) I nie będzie nagle cudownie lepiej działać z innym ISA. Można by też iść w drugą stronę - jeśli POWER było takie dobre to czemu go nie ubrali w ISA x86 ;) Kupić licencję, albo dać know-how AMD i niech leje konkurencję. A jednak... nic takiego się nie stało.

Jest balast - marnowanie tranzystorów, krzemu i energii na CISCowy narzut, czyli obsługę ponad tysiąca instrukcji różnej długości i ich tłumaczenia na uOps. A dokładniej to:
CISC processors still pay a large complexity tax. A modern x86 processor requires several extra pipe stages and about 40% larger instruction cache to analyze the variable length x86 instruction set and store pre-decode information. The x86 instruction decoders themselves consume one or two million transistors and are quite complex and prone to design errors that are only partially correctable using patchable microcode store. The modern x86 back-end execution engine (the so-called “RISC execution unit”) also has to devote extra resources to handle instruction dependencies related to condition codes and ensuring exceptions encountered, while processing micro-ops can be reported back as precise exceptions within the context of the originating x86 instruction.

Jak wiadomo HW jest szybszy niż SW, więc takie skomplikowane i szczegółowe instrukcje optymalnie tłumaczone przez procek będą szybsze, niż zestaw prostych instrukcji który kompilator użyje by zrealizować to samo.
Ale dzieje się to właśnie kosztem tranzystorów, czyli ceny i zużycia energii. Dlatego w telefonach mamy ARM, który nie jest tak szybki jak x86, ale wygrywa energooszczędnością - Intel nawet w 14nm nie jest w stanie zejść do tego poziomu :P
Promilus1984Zobacz profil
Poziom ostrzeżenia: 0%
Promilus19842016.08.09, 21:01
CISC processors still pay a large complexity tax

To teraz pokaż RISCowy procesor który jednocześnie dźwignie więcej MHz, będzie w obliczeniach wydajniejszy, będzie miał mniejszy (tańszy) rdzeń i zużyje mniej energii. Czekam... Aaaaaa... no właśnie. Dobre rozkazy swoje kosztują... to są rozkazy które kompilator często wypluwa. To są rozkazy których RISC nie ma i kosztują więcej ich instrukcji. Większy kod, większe obciążenie cache i przepustowości pamięci. I czasem właśnie prostota RISC stanowi dla nich wąskie gardło, a problemy CISC intel od ponad dwóch dekad cały czas rozwiązuje, bariery łamie (razem z AMD choć innym sposobem). Intel nawet nie zamierzał iść w RISC pogrzebując CISCowe x86 tylko w jeszcze większe kompilatorowe bagno bo VLIW (EPIC). Ale AMD mu stanęło na drodze, a Itanium okazało się ślepym zaułkiem. I teraz konikiem intela jest x86. Ten sam CISC co lata temu, ale przez kodowanie VEX odświeżony, a stare nieużywane już rozkazy będą znikać. Pewnie w następnej kolejności skasują x87 skoro od kilku lat kompilatory domyślnie wypluwają SSE2. Szczerze mało kto za tym będzie tęsknił, a pewnie obsługa będzie i tak za pomocą wyjątków (wolna bo wolna, ale...)
Dla mnie sprawa jest jasna - kto chce bezkompromisowej wydajności w każdych warunkach bierze x86, kto chce bezkompromisowej energooszczędności bierze ARM. RISC miał wiele świetnych rozwiązań lata temu, później konikiem motoroli był AltiVec (a dla IBM był Cell) tylko, że to jest SIMD, a nie RISC! Intel dogonił konkurencję z AVX (a nawet wyprzedził z AVX512+FMA3) - kod programu będzie się i tak szybciej wykonywał na CISCowym x86, a obliczenia na SIMDowych jednostkach intela. I ot cały czar RISCa prysł. Jasne, nie trzeba wiele by znów go przegonili, tylko mało komu się teraz z intelem chce ścigać.
h63619Zobacz profil
Poziom ostrzeżenia: 0%
h636192016.08.09, 21:05
Jak wiadomo HW jest szybszy niż SW...
Tyle, że C++ kompilujesz raz a C# co prawda JiT ale I tak dany kawałek kodu jest kompilowany i taki pozostaje w RAM a procesor musi na bieżąco kompilować tłumaczyć i w efekcie ten sam kawałek kodu jest tłumaczony wielokrotnie. Co więcej kompilator może przeanalizować znacznie dłuższy odcinek kodu oraz skorzystać z gotowych zoptymalizowanych bibliotek.
SambaVerdeZobacz profil
Poziom ostrzeżenia: 0%
SambaVerde2016.08.12, 19:01
-1#79
Czytam i czytam te wywody powyżej... i zaczynam mieć wrażenie, że nowoczesne procesory są projektowane na zapas, żeby programy tworzone przez sztuczną inteligencję mogły dobrze na nich działać. Czyżbyście sugerowali, że człowiek już tego wszystkiego nie ogarnia?
CortexM3Zobacz profil
Poziom ostrzeżenia: 0%
CortexM32016.08.14, 15:30
Borderlands

https://www.youtube.com/watch?v=NagoUwsrBLQ
Ta gra akurat z tego co wiem da sie tez odpalić na Raspberry Pi, czyli popularnej malince, i tu jestem ciekaw, jak by wyglądało porównanie wydajności i jakości, z Tegrą, X360.
Nie wiem może jest więcej tytułów wspólnych dla Maliki (Raspberry Pi), Tegry i X360/PS3. Bardzo ciekawe byłoby takie porównanie Tegra kontra Boardcom (SOC Raspberry Pi) kontra konsole starej generacji, zważywszy że Raspberry Pi jest bardzo tania platformą. Koszt w okolicy 300zł.
Zaloguj się, by móc komentować