komentarze
p_liderZobacz profil
Poziom ostrzeżenia: 0%
p_lider2019.06.28, 15:54
16#1
Wow, bardzo fajny artykuł! :) Jedyne czego mi tutaj brakuje, to opis Infiniti Fabric I jak nowa wersja IF różni się od starej.
mbrzostekZobacz profil
Poziom ostrzeżenia: 0%
Autor publikacjimbrzostek2019.06.28, 16:02
p_lider @ 2019.06.28 15:54  Post: 1208942
Jedyne czego mi tutaj brakuje, to opis Infiniti Fabric I jak nowa wersja IF różni się od starej.

Niestety nie wiemy jeszcze zbyt wiele - więcej szczegółów będzie zapewne na Hot Chips w sierpniu. Na razie AMD nie pokazało nawet zdjęcia jądra - wszystko jest sekretne.
Orzel94Zobacz profil
Poziom ostrzeżenia: 0%
Orzel942019.06.28, 16:56
-1#4
Już mogliby zostawić te 64kB tylko zrobić je 8 drożne... :P
SleepyZobacz profil
Poziom ostrzeżenia: 0%
Sleepy2019.06.28, 17:28
AVX to też instrukcje 256bitowe. AVX2 na dobra sprawę 'jedyne' co wprowadził to obsługę intow dla operacji wektorowych 256bitowych. AVX to arytmetyka na floatach/doublach ale ciągle na 256bitach.
MitycznyJeżZobacz profil
Poziom ostrzeżenia: 0%
MitycznyJeż2019.06.28, 18:04
kontrolery PCI-E 4.0, łącznie 24 linie, z których 20 jest przeznaczonych do wykorzystania przez użytkownika, a 4 zarezerwowane na komunikację z chipsetem

Czy to znaczy, że coś się zmieniło?
Bo w poprzednich ryzenach te linie nie były zarezerwowane, a po prostu prawie zawsze używane do łączenia z chipsetem. Ale gdy producent płyty nie decydował się na konwencjonalny chipset, mógł tych linii normalnie użyć - przykładowo w asrocku deskmini A300 te linie zostały przeznaczone na gniazdo M.2 NVMe.
jarekzonZobacz profil
Poziom ostrzeżenia: 0%
jarekzon2019.06.28, 19:02
-3#7
Na tym portalu są najlepsze artykuły jakie można znaleźć w sieci.
znafcaZobacz profil
Poziom ostrzeżenia: 33%
znafca2019.06.28, 19:30
A mozna sprawdzic jak szybszy ram 4000 mhz wplywa na Infity Fabric i wydajnosc?
Moze szybsze Ramy zmienia dzielniki dla IF i bedzie efektywnie gorzej stednio lepiej?
Czy test dyskow pcie od razu zrobicie?
CY dacie same gry czy tez jakies bardziej proczastosowania? W tym np wietalka, bazy danych granie streamowanie JEDNOCZESNIE?
KituZobacz profil
Poziom ostrzeżenia: 0%
Kitu2019.06.28, 20:01
11#9
Każdy rdzeń ma rozdzielone pamięci podręczne L1: jedna część, L1I, przechowuje dane, druga, L1D, kod.

Nie powinno być odwrotnie - L1I na kod (instrukcje), L1D na dane?

Ogólnie artykuł świetny - jak chyba wszystkie opisujące architektury podzespołów ;)
mbrzostekZobacz profil
Poziom ostrzeżenia: 0%
Autor publikacjimbrzostek2019.06.28, 20:11
MitycznyJeż @ 2019.06.28 18:04  Post: 1208962

Czy to znaczy, że coś się zmieniło?

Nie, jest tak samo - można włożyć Ryzena 3000 do ASRocka DeskMini A300 (o ile będzie odpowiednia aktualizacja UEFI) i będzie można wykorzystać wszystkie 24 linie PCI-E po swojemu.
Kitu @ 2019.06.28 20:01  Post: 1208985

Nie powinno być odwrotnie?

Tak, to pomyłka, już poprawione!
Edytowane przez autora (2019.06.28, 20:11)
nojeZobacz profil
Poziom ostrzeżenia: 0%
noje2019.06.28, 20:38
Takie artykuły to powód dla którego tu zaglądam!
mbe2019.06.28, 21:04
-2#12
MitycznyJeż @ 2019.06.28 18:04  Post: 1208962
kontrolery PCI-E 4.0, łącznie 24 linie, z których 20 jest przeznaczonych do wykorzystania przez użytkownika, a 4 zarezerwowane na komunikację z chipsetem

Czy to znaczy, że coś się zmieniło?
Bo w poprzednich ryzenach te linie nie były zarezerwowane, a po prostu prawie zawsze używane do łączenia z chipsetem. Ale gdy producent płyty nie decydował się na konwencjonalny chipset, mógł tych linii normalnie użyć - przykładowo w asrocku deskmini A300 te linie zostały przeznaczone na gniazdo M.2 NVMe.

Od Ryzena 1000 masz 24linie PCIe w CPU z których 16 jest podpięte pod pierwszy PCIe, 4 pod M.2 i 5 do komunikacji z chipsetem. W X570 zmieni się to że dostaniesz PCIe 4.0 co podniesie przepustowość w każdym przypadku dwukrotnie.
TrepciaZobacz profil
Poziom ostrzeżenia: 0%
Trepcia2019.06.28, 21:53
Widze ze ktos tutaj odrobil prace domowa! ;)
AMDK11Zobacz profil
Poziom ostrzeżenia: 0%
AMDK112019.06.29, 00:41
Orzel94 @ 2019.06.28 16:56  Post: 1208954
Już mogliby zostawić te 64kB tylko zrobić je 8 drożne... :P


Już L1I 64KB 4-Way zajmowało dużą część rdzenia a co dopiero gdyby jeszcze dołożyli 8-Way. Nie bez powodu Intel od SandyBridge do Skylake stosuje 32KB 8-Way bo Nehalem(pierwsza generacja Core i) miał 32KB 4-Way.
Nawt w rdzeniu SunnyCove dalej jest L1I 32KB 8-Way. Przypuszczam że rdzeń WillowCove lub GoldenCove może już mieć L1I 48KB 12-Way wzorem L1D.


Skoro 32KB 8-Way ma taką samą efektywność jak 64KB 4-Way a przy tym większą przepustowość ale zajmuje mniej miejsca to zaoszczędzone miejsce na tranzystory można spożytkować na logikę w rdzeniu która da wyższe IPC a tym samym wydajność.


Dużą część rdzenia K7(Athlon-Athlon XP), K8(Athlon64) i K10(Phenom) stanowił cache L1I 64KB 2-Way i L1D 64KB 2-Way dopiero w module Bulldozer/Piledriver L1D dla każdego bloku stałoprzecinkowego było po 16KB 4-Way ale nadal L1I 64KB 2-Way. O ile dobrze pamiętam to Steamroller miał L1I 96KB 3-Way.

Może łatwiej dodać dużo cache L1 ale z mniejszą ilością dróg choć to rozwiązanie zajmuje więcej tranzystorów a tym samym miejsca niż mniej cache L1 ale z większą ilością dróg ponieważ potrzeba bardziej złożonego/skomplikowanego Front-endu do skutecznej obsługi tej drożności? Tu niech jakiś ekspert się wypowie.
Edytowane przez autora (2019.06.29, 01:02)
WibowitZobacz profil
Poziom ostrzeżenia: 0%
Wibowit2019.06.29, 02:28
Oprócz drożności, przepustowości, pojemności, kosztu energetycznego i zajętej powierzchni są jeszcze opóźnienia i tolerancja na wysokie taktowanie. Generalnie im większa pamięć podręczna tym większe opóźnienia. Być może AMD nie udało się zrobić L1 64 KiB 8-drożnej z opóźnieniami 4 takty, tolerancją na wysokie taktowanie, niskim zapotrzebowaniem na energię i małą powierzchnią? Gdzieś trzeba pójść na kompromis.
AMDK11Zobacz profil
Poziom ostrzeżenia: 0%
AMDK112019.06.29, 06:46
Rzecz w tym że w czasach K7 Athlon AMD stosowało L1I 64KB 2-Way i L1D 64KB 2-Way.
Intel w Pentium III L1I 16KB 4-Way i L1D 16KB 4-Way.

Rdzeń K7 Athlon 22 mln tranzystorów(bez L2)
Rdzeń Pentium III 9.5 mln tranzystorów(bez L2)
Ja podejżewam że w AMD chcieli nadrobić pewne braki w mikroarchitekturze większym L1 natomiast Intel zachował stosunek drożności do pojemności L1 przy jej puźniejszym podwojeniu.
Markiz88Zobacz profil
Poziom ostrzeżenia: 0%
Markiz882019.06.29, 08:29
14#17
noje @ 2019.06.28 20:38  Post: 1208989
Takie artykuły to powód dla którego tu zaglądam!

natomiast nowy layout powód dla którego szybko stad uciekam ;)
PutoutZobacz profil
Poziom ostrzeżenia: 0%
Putout2019.06.29, 11:08
12#18
wielu ludzi nei zdaje sobie sprawy ile srania się jest potrzebne aby zrobić 'głupie' kilkanaście procent IPC.

(chyba) świetny techniczny artykuł. piszę 'chyba' bo jest to raczej trudny tekst dla typowego czytelnika stron IT (bo takie rzeczy trafiają się zbyt rzadko). liczę na więcej podobnych praC!
Promilus1984Zobacz profil
Poziom ostrzeżenia: 0%
Promilus19842019.06.29, 12:26
AMDK11 @ 2019.06.29 06:46  Post: 1209020

Ja podejżewam że w AMD chcieli nadrobić pewne braki w mikroarchitekturze większym L1 natomiast Intel zachował stosunek drożności do pojemności L1 przy jej puźniejszym podwojeniu.

Pomijając błędy ortograficzne - nie kolego. Pierwsza sprawa - intelowski cache L2 zawierał kopię danych z L1 więc był bardziej obłożony. Druga - początkowo w obu przypadkach (intel i amd) cache L2 pracował z max. 50% prędkości rdzenia (a w przypadku AMD nawet tylko 33%) ze względu na to, że relatywnie duży rdzeń 512KB to były zewnętrzne kości o ograniczonej prędkości (do zdaje się 300MHz max). AMD poszło w rozwiązanie gdzie cache L2 uzupełniał duży cache L1, ale nie musiał przechowywać kopii danych z L1 (dlatego fully exclusive). Dodatkowo dostęp do pamięci zewnętrznej był szybszy dzięki 200MHz FSB (100MHz dla Pentium III) więc tak się składa, że AMD nie musiało robić takich sztuczek by jakieś braki w mikroarchitekturze łatać, a dlatego że podeszli do problemu z inną koncepcją i wdrażali ją wiedząc, że DLA MOŻLIWOŚCI ICH MIKROARCHITEKTURY JEST LEPSZA. Dlaczego więc gracze decydowali się tak często na Celerony? Aaaa, to jest ciekawa rzecz. Celerony nie miały L2 na osobnej kości. Pierwsze nie miały wcale (z druzgocącym wpływem na wydajność), kolejne miały ledwie 128KB cache L2 o pełnej prędkości rdzenia i z mniejszymi opóźnieniami niż cache off-die. Było to na tyle sprytne rozwiązanie, że po podkręceniu potrafiło walczyć z późniejszymi PII i wczesnymi PIII (!!!). Duron też się kręcił, ale problemem dla wielu amatorów było odsłonięte jądro, które mogło się ukruszyć przy montażu chłodzenia. Z czasem by kręcić trzeba też było używać noża, ołówka a nawet drucików (przecinając i łącząc mostki na PCB, łącząc otwory w socket itp.) W przypadku Celeronów z kolei kręciło się FSB dość przyjemnie na niektórych płytach (szczególnie jeśli miały niesynchroniczne zegary PCI/AGP/Mem) a do większych zmian wystarczał kawałek izolacji na bsel albo wymuszenie FSB o numerek wyżej (gdzie nawet przy synchronicznych zegarach pci zmieniały się automatycznie dzielniki więc częstotliwości były ok). Zatem duży cache L1 w K7 nie był wynikiem walki z BRAKAMI mikroarchitektury, a próbą uwypuklenia jej zalet przy aktualnych problemach technicznych z L2. Gdy problemy z L2 rozwiązano to nikt nie ruszał L1 bo nie było po co... Gdyby problemy z K7 wynikały z braków samej mikroarchitektury to do skutecznej walki z intelem zamiast powiększać L2 nadal musieliby powiększać L1.
Rybaczek KoziołkaZobacz profil
Poziom ostrzeżenia: 0%
Rybaczek Koziołka2019.07.08, 08:32
Orzel94 @ 2019.06.28 16:56  Post: 1208954
Już mogliby zostawić te 64kB tylko zrobić je 8 drożne... :P


ja nie dałem ci minusa. teoretycznie jest to dobry argument. jednak mniejszy cache jest łatwiejszy do przeszukania i zarządzania. poza tym cache zajmuje ogromną ilość miejsca. masz to po części opisane w artykule. moim zdaniem projektanci bardzo dobrze rozdysponowali budżet dostępnej puli tranzystorów, równoważąc wydajność i koszt produkcji. rynek nie kupii masowo mega drogich procesorów, bo mega drogie procesory sprzedają się albo w rozwiązaniach serwerowych, a na rynku konsumenckim kupuje je pewna grupa fanbojów która nie liczy się z kosztami. a to jest bardzo wąska grupa zainteresowanych, bardzo opiniotwórca, ale nie dająca bezpośredniego zbytu.

Tendencja i tak jest taka, aby zwiększać ilość bloków, i po zsumowaniu cache wszelkich poziomach będzie 'rósł' automatycznie. Dla mnie jest to bardzo optymalne rozwiązanie.

Artykuł mega, bardzo konkretny. szkoda że nie można oceniać.

mam nadzieję też że redakcja zrobi coś wreszcie z minusowymi przegrywami.
Zaloguj się, by móc komentować