W procesorach Sandy Bridge i Ivy Bridge Intela GPU jest podłączone magistralą pierścieniową do pamięci podręcznej L3 i kontrolera pamięci.
Dokładnie tak samo RSX komunikuje się z XDR (poprzez magistrale pierścieniową EIB). Pomijając L2 i cache dla GPU, XDR w uproszczeniu to nic innego jak L3 (taktowanie takie samo jak CPU, praktycznie zerowe latency i taka sama przepustowość jak rdzenie).
Samo połączenie GPU i pamięci na oddzielnej płytce w Haswell bardzo przypomina sposób w jaki w PSVITA podłączono DRAM do GPU (położono 128MB DRAM na kości GPU co dało prawdopodobnie 12.8GB/s @2x512bit połączenie face-to-face znane jeszcze z PSP). Całe innowacje Intela.
Nie wiem czy to podłączenie będzie w samym krzemie czy ten eDRAM połozą na rdzeniu - tego artykuł nie wyjaśnia.
Typowy x86 zwalnia, wydaje się że nawet następna generacja konsol nie pomoże. Choć progress pewnie jest możliwy to okazuje się nieopłacalny, procki na PC mogą aż za dużo w stosunku do potrzeb, widoczne jest kierowanie się do mobilnych rozwiązań. Wszystko skupia się powoli na mobilnym rynku...
polecam też artykuł dla nieco bardziej zaawansowanych czytelników: http://www.realworldtech.com/haswell-cpu/
@ghetto.pimp x86 w zasadzie dobiło do ściany jeśli chodzi o wydajność/MHz, teraz tylko wydajność/wat daje się nieco poprawiać. Bez zmiany architektury PC raczej szybsze już nie będą. Intel musiałby usiąść nad x86 i zredefiniować ją, tzn przede wszystkim w końcu odciąć się od dekodowania CISC->RISC. W takim kierunku dałoby się jeszcze wydobyć około 50% więcej mocy/MHz/wątek, przykładem architektura SPARC, gdzie czysto RISCowe procesory są właśnie o około 50% wydajniejsze od x86 na MHz.
'S0i3 to techniczne zaplecze funkcji „connected standby”, która obiecuje oszczędność energii typową dla stanu uśpienia połączoną z nieprzerwanym funkcjonowaniem urządzenia – przenośny komputer czy tablet będzie mógł spędzić w tym stanie wiele dni, periodycznie wybudzając się na krótkie okresy aktywności, w których programy będą mogły połączyć się z siecią (i na przykład pobrać pocztę). Poprawne działanie connected standby wymaga odpowiednio przygotowanych aplikacji, systemu operacyjnego'
I to jest dla mnie najciekawsze. Implementacja mechanizmu 'connected standby' oraz dodatkowych trybów S0i któe zostały dodane w Windows 8. To główny powód dla którego tablety z CloverTrail działają tak długo na baterii. Współpraca sysemu oraz procesora.
Warto jednak zaznaczyć że tylko i wyłącznie aplikacje 'metro' mogą rejestrować się do pracy w trybie 'connected standby'. W tym celu programista tworzy w aplikacji metro specjalną usługę i to ona pracuje w tym trybie a nie właściwa aplikacja. Dzięki czemu całość może pracować przy minimalnym zużyciu energii. Cyklem życia/aktywacji takiej usługi zarządza system operacyjny a nie aplikacja.
Zwykłe aplikacje desktop nie mają możliwości pracy w tym trybie. Mają one zbyt dużo zależności do systemu i MS zdecydował że wiązałoby się to z wybudzeniem całego Windows. A więc operacja byłaby bez sensu. Zamiast tego pozwolono wybudzać się tylko aplikacjom metro. I mogą one wykonywać tylko z góry ustalone czynności takie jak: ściąganie/wysyłanie plików na zdalny serwer, odtwarzanie muzyki, synchronizacja itp.
Jest to chyba pierwszy raz gdy system operacyjny wdrożył specjalny tryb pracy, oraz specjalny typ aplikacji zaprojektowany wspólnie z twórcami sprzętu. Praca aplikacji w 'connected standby' zupełnie nie przypomina pracy zwykłej aplikacji Windows ale raczej pracę aplikacji w urządzeniach mobilnych
Trochę nie rozumiem podejścia AMD. Intel próbuje narzucić to, jak powinna wyglądać przyszłość i na czym się opierać.
A co jest wydajniejsze - GPU czy CPU? Zatem mam nadzieję, że Czerwoni skupią wszystkie swoje siły na przejmowaniu przez GPU wszelkich obliczeń.
Być może już zaczęli to robić wraz z Bulldkami, teraz konsole i ich priorytety zdają się klarować.
Witam wszystkich forumowiczów
To Mój pierwszy post na Lab'ie
Jako że od niedawna jestem posiadaczem IVY(I5 3750, nie bawię się w podkręcanie), stwierdzam że Haswell jest dobrym krokiem(małym - bo małym, ale dobrym)w przód Intela pod względem poprawy architektury rozwijanej od Sandy Bridge.
Jak napisano powyżej rynek idzie coraz bardziej w mobilność, konsumencike życie w biegu wymaga innego podejścia producentów, więc zarówno AMD, jak i Intel idą w integry i energooszczędność. Oczywiście to co napisałem -wiadomo - Ameryki żadnej nie odkryłem, ale wszystko idzie w dobrym kierunku ... żeby jeszcze tak gry były 'lepiej' optymalizowane pod wielowątkowość - to byłoby już całkiem ok.
Oczywiście rewolucja w klasie PC nadejdzie dopiero z chwilą permanentnego skrócenia opóźnień wynikającej ze specyfikacji RAM, PCI-E oraz NB(płyta główna) oraz zwiększenia IPC(tu mamy kolejne 5 do 7% w stosunku do IB - ale to już też wszyscy wiedzą)...Panaceum może być na to(jak kolega Bany_krk powyżej napisał zmiana architektury x86 na RISC i prace nad jej udoskonaleniem(co zresztą zbyt prędko nie nastąpi).
Zresztą w zamierzchłych czasach przykład przykład Sony z jej pierwszym Playstation ze swoim 'marnym' 33Mhz procesorkiem RISC dawał w kość pentiumowi 120 MHz z kartą Virge 3D ...
Mam nadziej że sobie kupie Haswella, moim zdaniem wnosi dużo usprawnień w architekturze. Najbardziej jestem ciekaw nowych instrukcji AVX i usprawnień w wielowątkowości. Może Ht będzie wydajniejszy.
No, podoba mi się że wzrasta energooszczędność, ale szkoda że wydajność tylko małymi krokami, fajnie by było jak by co generację przynajmniej o te 20% był wzrost.
Być może wydajność krzemu się kończy, jeśli tak to niedługo pierwsze skrzypce we wszelkich technikach wymagających dużej wydajności powinny przejść na GPU,lub open CL, a procesor będzie tylko utrzymywał system.
Wydajność kart graficznych rośnie często ponad 50% z generacji na generację, nawet czasami ponad 100% no i możliwości SLI/CROSS FIRE.
Super jak by nowe gry odeszły od zapotrzebowania na mocny procesor a wszystkie efekty, SI liczone by były w kodzie dla kart graficznych np w technice dostępnej dla amd jak i nvidia, open CL, ale większość programistów to lenie, lepiej coś zrobić na odwal w dobrze znanym C++ niż zrobić to samo, może i nawet parę razy dłużej ale w technice umożliwiającej parokrotne zwiększenie wydajności aplikacji.
ale większość programistów to lenie, lepiej coś zrobić na odwal w dobrze znanym C++ niż zrobić to samo, może i nawet parę razy dłużej ale w technice umożliwiającej parokrotne zwiększenie wydajności aplikacji.
Programiści robią to za co im kadra zarządzająca płaci i co im rozkazuje, więc zażalenia tylko i wyłącznie pod adresem kadr zarządzających proszę kierować. Programiści z chęcią pobawiliby się w najnowsze cuda programistyczne, ale za darmo nie będą tego robić, zwłaszcza jeśli ktoś inny miałby z tego zysk zamiast nich.
polecam też artykuł dla nieco bardziej zaawansowanych czytelników: http://www.realworldtech.com/haswell-cpu/
@ghetto.pimp x86 w zasadzie dobiło do ściany jeśli chodzi o wydajność/MHz, teraz tylko wydajność/wat daje się nieco poprawiać. Bez zmiany architektury PC raczej szybsze już nie będą. Intel musiałby usiąść nad x86 i zredefiniować ją, tzn przede wszystkim w końcu odciąć się od dekodowania CISC->RISC. W takim kierunku dałoby się jeszcze wydobyć około 50% więcej mocy/MHz/wątek, przykładem architektura SPARC, gdzie czysto RISCowe procesory są właśnie o około 50% wydajniejsze od x86 na MHz.
Ojj z tym SPARC różnie jest. To procesor 'dedykowany' podobnie jak iltanium. Sprawdzi się w 'niewielu' zastosowaniach.
Heh...
Wydajność z MHz może bardzo wzrosnąć o ile użyte byłyby instrukcje najnowsze. Więc już dziś możesz mieć znacznie większą wydajność. W tradycyjnych aplikacjach po prostu nie wiem, w teorii po C2D już nie powinno być wzrostu, krótki potok, sporo cache l2, wydajny, a jednak.... wydajność wzrosła w SB mimo dłuższego potoku, cache L3.
Po co oni do procków do stacjonarek wrzucają GPU? Nikt z tego nie korzysta a zajmuje tylko miejsce
Komputery biurowe działają na integrach i głupotą jest wstawianie tam dedykowanych GPU. Często praca wymaga mocnego CPU nie wymaga grafiki 3D więc i i7 z integrą ma sens.
ale większość programistów to lenie, lepiej coś zrobić na odwal w dobrze znanym C++ niż zrobić to samo, może i nawet parę razy dłużej ale w technice umożliwiającej parokrotne zwiększenie wydajności aplikacji.
Programiści robią to za co im kadra zarządzająca płaci i co im rozkazuje, więc zażalenia tylko i wyłącznie pod adresem kadr zarządzających proszę kierować. Programiści z chęcią pobawiliby się w najnowsze cuda programistyczne, ale za darmo nie będą tego robić, zwłaszcza jeśli ktoś inny miałby z tego zysk zamiast nich.
Sama prawda.
Nie ma się co dziwić managerom bo takie sa wymagania rynku. Klient oczekuje szybkiej implementacji i dużej stabilności, z brakiem optymalizacji najłatwiej się pogodzić.
Dlatego też i C++ nie jest tak popularne jak .Net i Java.
polecam też artykuł dla nieco bardziej zaawansowanych czytelników: http://www.realworldtech.com/haswell-cpu/
@ghetto.pimp x86 w zasadzie dobiło do ściany jeśli chodzi o wydajność/MHz, teraz tylko wydajność/wat daje się nieco poprawiać. Bez zmiany architektury PC raczej szybsze już nie będą. Intel musiałby usiąść nad x86 i zredefiniować ją, tzn przede wszystkim w końcu odciąć się od dekodowania CISC->RISC. W takim kierunku dałoby się jeszcze wydobyć około 50% więcej mocy/MHz/wątek, przykładem architektura SPARC, gdzie czysto RISCowe procesory są właśnie o około 50% wydajniejsze od x86 na MHz.
To dlaczego Sparki ni są tak popularne jak x86? Bo nie są kompatybilne z ogromna ilością aplikacji. No i jakby tak Intel wpadł na pomysł zmiany architektury to by ich nowy procek skończył jak Itanium.
Programiści robią to za co im kadra zarządzająca płaci i co im rozkazuje, więc zażalenia tylko i wyłącznie pod adresem kadr zarządzających proszę kierować. Programiści z chęcią pobawiliby się w najnowsze cuda programistyczne, ale za darmo nie będą tego robić, zwłaszcza jeśli ktoś inny miałby z tego zysk zamiast nich.
Rzeczywiście nie pomyślałem o tym, zwracam honor programistom, przez właśnie takich kierowników wszystko stoi w miejscu, wszyscy powielają schematy i boją się spróbować czegoś nowego, drepczą w kółko w jednym miejscu.
Jednak należy mieć na uwadze to, że implementacja zestawu instrukcji XYZ oznacza:
a) brak kompatybilności ze starszymi procesorami
b) droższy program(potrzeba napisania tego samego, raz dla maszyn z XYZ a drugi raz dla tych bez XYZ)
Kiedyś była gra(/gry) która pozwalała wybrać czy uruchomić się z SSEx czy bez.
Wydajność kart graficznych rośnie często ponad 50% z generacji na generację, nawet czasami ponad 100% no i możliwości SLI/CROSS FIRE.
Są zadania które łatwo zrównoleglić i grafika akurat należy do najlepszych z nich, co też nawet podkreślił CEO Nvidii na ostatnim GTC.
W przypadku X86 już jest różnie w zależności od typu programu. Część instrukcji jest od siebie zależna i często nie da się tego łatwo rozdzielić.
... Nawet w tych, które się da, GPU nie jest dobre, gdy np. ma robić dwie rzeczy równocześnie. W CPU spadek jest niewidzialny, ale np. jak GPU miałoby równcoześnie liczyć fizykę, grafikę i jeszcze w tle bitcointy... to wydajność spada ojj spada.
Dokładnie tak samo RSX komunikuje się z XDR (poprzez magistrale pierścieniową EIB). Pomijając L2 i cache dla GPU, XDR w uproszczeniu to nic innego jak L3 (taktowanie takie samo jak CPU, praktycznie zerowe latency i taka sama przepustowość jak rdzenie).
Samo połączenie GPU i pamięci na oddzielnej płytce w Haswell bardzo przypomina sposób w jaki w PSVITA podłączono DRAM do GPU (położono 128MB DRAM na kości GPU co dało prawdopodobnie 12.8GB/s @2x512bit połączenie face-to-face znane jeszcze z PSP). Całe innowacje Intela.
Nie wiem czy to podłączenie będzie w samym krzemie czy ten eDRAM połozą na rdzeniu - tego artykuł nie wyjaśnia.
http://www.realworldtech.com/haswell-cpu/
@ghetto.pimp x86 w zasadzie dobiło do ściany jeśli chodzi o wydajność/MHz, teraz tylko wydajność/wat daje się nieco poprawiać. Bez zmiany architektury PC raczej szybsze już nie będą. Intel musiałby usiąść nad x86 i zredefiniować ją, tzn przede wszystkim w końcu odciąć się od dekodowania CISC->RISC. W takim kierunku dałoby się jeszcze wydobyć około 50% więcej mocy/MHz/wątek, przykładem architektura SPARC, gdzie czysto RISCowe procesory są właśnie o około 50% wydajniejsze od x86 na MHz.
I to jest dla mnie najciekawsze. Implementacja mechanizmu 'connected standby' oraz dodatkowych trybów S0i któe zostały dodane w Windows 8. To główny powód dla którego tablety z CloverTrail działają tak długo na baterii. Współpraca sysemu oraz procesora.
Warto jednak zaznaczyć że tylko i wyłącznie aplikacje 'metro' mogą rejestrować się do pracy w trybie 'connected standby'. W tym celu programista tworzy w aplikacji metro specjalną usługę i to ona pracuje w tym trybie a nie właściwa aplikacja. Dzięki czemu całość może pracować przy minimalnym zużyciu energii. Cyklem życia/aktywacji takiej usługi zarządza system operacyjny a nie aplikacja.
Zwykłe aplikacje desktop nie mają możliwości pracy w tym trybie. Mają one zbyt dużo zależności do systemu i MS zdecydował że wiązałoby się to z wybudzeniem całego Windows. A więc operacja byłaby bez sensu. Zamiast tego pozwolono wybudzać się tylko aplikacjom metro. I mogą one wykonywać tylko z góry ustalone czynności takie jak: ściąganie/wysyłanie plików na zdalny serwer, odtwarzanie muzyki, synchronizacja itp.
Jest to chyba pierwszy raz gdy system operacyjny wdrożył specjalny tryb pracy, oraz specjalny typ aplikacji zaprojektowany wspólnie z twórcami sprzętu. Praca aplikacji w 'connected standby' zupełnie nie przypomina pracy zwykłej aplikacji Windows ale raczej pracę aplikacji w urządzeniach mobilnych
http://software.intel.com/en-us/articles/o...nnected-standby
http://msdn.microsoft.com/en-US/library/wi...rdware/jj128256
.
Tak więc puszczasz przykładowo muzykę z dysku lub np. spotify... usypiasz komputer... a muzyka leci dalej. Inną możliwością 'connected standby' jest odebranie rozmowy przez Skype bezpośrednio na uśpionym komputerze który to może zasygnalizować dźwiękiem. Jak na telefonach
A co jest wydajniejsze - GPU czy CPU? Zatem mam nadzieję, że Czerwoni skupią wszystkie swoje siły na przejmowaniu przez GPU wszelkich obliczeń.
Być może już zaczęli to robić wraz z Bulldkami, teraz konsole i ich priorytety zdają się klarować.
To Mój pierwszy post na Lab'ie
Jako że od niedawna jestem posiadaczem IVY(I5 3750, nie bawię się w podkręcanie), stwierdzam że Haswell jest dobrym krokiem(małym - bo małym, ale dobrym)w przód Intela pod względem poprawy architektury rozwijanej od Sandy Bridge.
Jak napisano powyżej rynek idzie coraz bardziej w mobilność, konsumencike życie w biegu wymaga innego podejścia producentów, więc zarówno AMD, jak i Intel idą w integry i energooszczędność. Oczywiście to co napisałem -wiadomo - Ameryki żadnej nie odkryłem, ale wszystko idzie w dobrym kierunku ... żeby jeszcze tak gry były 'lepiej' optymalizowane pod wielowątkowość - to byłoby już całkiem ok.
Oczywiście rewolucja w klasie PC nadejdzie dopiero z chwilą permanentnego skrócenia opóźnień wynikającej ze specyfikacji RAM, PCI-E oraz NB(płyta główna) oraz zwiększenia IPC(tu mamy kolejne 5 do 7% w stosunku do IB - ale to już też wszyscy wiedzą)...Panaceum może być na to(jak kolega Bany_krk powyżej napisał zmiana architektury x86 na RISC i prace nad jej udoskonaleniem(co zresztą zbyt prędko nie nastąpi).
Zresztą w zamierzchłych czasach przykład przykład Sony z jej pierwszym Playstation ze swoim 'marnym' 33Mhz procesorkiem RISC dawał w kość pentiumowi 120 MHz z kartą Virge 3D ...
Być może wydajność krzemu się kończy, jeśli tak to niedługo pierwsze skrzypce we wszelkich technikach wymagających dużej wydajności powinny przejść na GPU,lub open CL, a procesor będzie tylko utrzymywał system.
Wydajność kart graficznych rośnie często ponad 50% z generacji na generację, nawet czasami ponad 100% no i możliwości SLI/CROSS FIRE.
Super jak by nowe gry odeszły od zapotrzebowania na mocny procesor a wszystkie efekty, SI liczone by były w kodzie dla kart graficznych np w technice dostępnej dla amd jak i nvidia, open CL, ale większość programistów to lenie, lepiej coś zrobić na odwal w dobrze znanym C++ niż zrobić to samo, może i nawet parę razy dłużej ale w technice umożliwiającej parokrotne zwiększenie wydajności aplikacji.
Programiści robią to za co im kadra zarządzająca płaci i co im rozkazuje, więc zażalenia tylko i wyłącznie pod adresem kadr zarządzających proszę kierować. Programiści z chęcią pobawiliby się w najnowsze cuda programistyczne, ale za darmo nie będą tego robić, zwłaszcza jeśli ktoś inny miałby z tego zysk zamiast nich.
http://www.realworldtech.com/haswell-cpu/
@ghetto.pimp x86 w zasadzie dobiło do ściany jeśli chodzi o wydajność/MHz, teraz tylko wydajność/wat daje się nieco poprawiać. Bez zmiany architektury PC raczej szybsze już nie będą. Intel musiałby usiąść nad x86 i zredefiniować ją, tzn przede wszystkim w końcu odciąć się od dekodowania CISC->RISC. W takim kierunku dałoby się jeszcze wydobyć około 50% więcej mocy/MHz/wątek, przykładem architektura SPARC, gdzie czysto RISCowe procesory są właśnie o około 50% wydajniejsze od x86 na MHz.
Ojj z tym SPARC różnie jest. To procesor 'dedykowany' podobnie jak iltanium. Sprawdzi się w 'niewielu' zastosowaniach.
Heh...
Wydajność z MHz może bardzo wzrosnąć o ile użyte byłyby instrukcje najnowsze. Więc już dziś możesz mieć znacznie większą wydajność. W tradycyjnych aplikacjach po prostu nie wiem, w teorii po C2D już nie powinno być wzrostu, krótki potok, sporo cache l2, wydajny, a jednak.... wydajność wzrosła w SB mimo dłuższego potoku, cache L3.
Komputery biurowe działają na integrach i głupotą jest wstawianie tam dedykowanych GPU. Często praca wymaga mocnego CPU nie wymaga grafiki 3D więc i i7 z integrą ma sens.
Programiści robią to za co im kadra zarządzająca płaci i co im rozkazuje, więc zażalenia tylko i wyłącznie pod adresem kadr zarządzających proszę kierować. Programiści z chęcią pobawiliby się w najnowsze cuda programistyczne, ale za darmo nie będą tego robić, zwłaszcza jeśli ktoś inny miałby z tego zysk zamiast nich.
Sama prawda.
Nie ma się co dziwić managerom bo takie sa wymagania rynku. Klient oczekuje szybkiej implementacji i dużej stabilności, z brakiem optymalizacji najłatwiej się pogodzić.
Dlatego też i C++ nie jest tak popularne jak .Net i Java.
http://www.realworldtech.com/haswell-cpu/
@ghetto.pimp x86 w zasadzie dobiło do ściany jeśli chodzi o wydajność/MHz, teraz tylko wydajność/wat daje się nieco poprawiać. Bez zmiany architektury PC raczej szybsze już nie będą. Intel musiałby usiąść nad x86 i zredefiniować ją, tzn przede wszystkim w końcu odciąć się od dekodowania CISC->RISC. W takim kierunku dałoby się jeszcze wydobyć około 50% więcej mocy/MHz/wątek, przykładem architektura SPARC, gdzie czysto RISCowe procesory są właśnie o około 50% wydajniejsze od x86 na MHz.
To dlaczego Sparki ni są tak popularne jak x86? Bo nie są kompatybilne z ogromna ilością aplikacji. No i jakby tak Intel wpadł na pomysł zmiany architektury to by ich nowy procek skończył jak Itanium.
Wydajność kart graficznych rośnie często ponad 50% z generacji na generację, nawet czasami ponad 100% no i możliwości SLI/CROSS FIRE.
Są zadania które łatwo zrównoleglić i grafika akurat należy do najlepszych z nich, co też nawet podkreślił CEO Nvidii na ostatnim GTC.
W przypadku X86 już jest różnie w zależności od typu programu. Część instrukcji jest od siebie zależna i często nie da się tego łatwo rozdzielić.
Programiści robią to za co im kadra zarządzająca płaci i co im rozkazuje, więc zażalenia tylko i wyłącznie pod adresem kadr zarządzających proszę kierować. Programiści z chęcią pobawiliby się w najnowsze cuda programistyczne, ale za darmo nie będą tego robić, zwłaszcza jeśli ktoś inny miałby z tego zysk zamiast nich.
Rzeczywiście nie pomyślałem o tym, zwracam honor programistom, przez właśnie takich kierowników wszystko stoi w miejscu, wszyscy powielają schematy i boją się spróbować czegoś nowego, drepczą w kółko w jednym miejscu.
a) brak kompatybilności ze starszymi procesorami
b) droższy program(potrzeba napisania tego samego, raz dla maszyn z XYZ a drugi raz dla tych bez XYZ)
Kiedyś była gra(/gry) która pozwalała wybrać czy uruchomić się z SSEx czy bez.
Widzę że żarty się Was trzymają
Wydajność kart graficznych rośnie często ponad 50% z generacji na generację, nawet czasami ponad 100% no i możliwości SLI/CROSS FIRE.
Są zadania które łatwo zrównoleglić i grafika akurat należy do najlepszych z nich, co też nawet podkreślił CEO Nvidii na ostatnim GTC.
W przypadku X86 już jest różnie w zależności od typu programu. Część instrukcji jest od siebie zależna i często nie da się tego łatwo rozdzielić.
... Nawet w tych, które się da, GPU nie jest dobre, gdy np. ma robić dwie rzeczy równocześnie. W CPU spadek jest niewidzialny, ale np. jak GPU miałoby równcoześnie liczyć fizykę, grafikę i jeszcze w tle bitcointy... to wydajność spada ojj spada.