Knight's Corner to po prostu Larrabee

1. To się nie ma prawa udać (autor: Grave | data: 28/09/10 | godz.: 15:49)
   będzie duże, gorące, drogie w produkcji i z dużym prawdopodobieństwem niewydajne....
   
   
2. Grave (autor: Aamitoza | data: 28/09/10 | godz.: 16:00)
   Skoro w 65nm miało 700mm2 dla 24, czy tam 32 rdzeni, to w 22nm te około 50rdzeni powinno mieć w miarę akceptowalny rozmiar. - gdzieś pomiędzy GF104 i GF100. A czy będzie wydajne, to już inna sprawa. Jako GPU? - wątpię, ale jako karta do obliczeń, to całkiem prawdopodobne.
   
   
3. i niech mi ktoś jeszcze k...a zarzuci że piszę bez sensu o Larrabee (autor: Qjanusz | data: 28/09/10 | godz.: 16:01)
   Intel tego nigdy nie popuścił i nie popuści!
   
   Poszło się rypać tylko demko gierki w RT.
   Reszta się nie zmieniła.
   
   A NIE MÓWIŁEM!!!???
   
   
4. dodam jeszcze... (autor: Qjanusz | data: 28/09/10 | godz.: 16:10)
   "sam sprzęt bez należytych sterowników i oprogramowania nie jest wiele wart"
   
   czyli sedno pięty achillesowej Intela.
   Nie chce krakać, ale nawet jeżeli projekt wejdzie do produkcji, to zostanie zjedzony przez nVidię na śniadanko.
   
   Rywalizacja między TSMC a Globala zredukuje opóźnienia nowego procesu do minimum opóźnienia po Intelu.
   
   
5. ... (autor: Mariusch1 | data: 28/09/10 | godz.: 16:12)
   I znów ten żal od początku. Przez kolejne 2 lata znów będziemy musieli słuchać wychwalania morgiego i pozostałych że wejdzie ten Knight Corner i zrobi zadymę tak jak miało to Larrabee ponoć zrobić... Intel już na serio nie wie co robić tylko by trochę kasy dostać...
   
   
6. @Qjanusz (autor: Promilus | data: 28/09/10 | godz.: 16:19)
   IIRC intel ma mieć pod koniec roku beta stery OCL.
   
   
7. Knight's Corner (autor: rainy | data: 28/09/10 | godz.: 16:22)
   A co myśleliście, że Intel przejdzie do porządku dziennego nad kilkoma miliardami dolarów "utopionych" w Larrabee?
   
   Owszem zdarzało się im kasować projekty ale nie tak kosztowne jak ten.
   
   Poza tym, dostrzegli rysujące się zagrożenie: jeżeli oprogramowanie będzie ewoluować, to Tesla/Quadro może zacząć wchodzić na ich pole i zabierać im przychody (a przecież AMD może również dołączyć do Nvidii w tym segmencie).
   
   
8. @Promilus (autor: Qjanusz | data: 28/09/10 | godz.: 16:32)
   co z tego że pod koniec roku będzie miał dopiero bety OCL, skoro stery pod GMA mimo wieloletniej egzystencji dalej z tego stadium rozwoju na dobrą sprawę nie wyszły.
   
   Ok, nikt im nie broni. Ich kasa, ich reputacja. Ale znów chcą wejść siłową metodą w działkę, której w ogóle nie ogarniają.
   
   
9. Kolejna wtopa typu Itanium (autor: pomidor | data: 28/09/10 | godz.: 16:39)
   Rynek GPGPU jest zbyt mały aby koszty im się zwróciły (nie wspominając o zysku), tym bardziej że to tylko sam procesor. Nvidia umiejętnie łączy obliczeniówkę z grafiką 3d, i do tego oferuje potężne wsparcie. Te rycerzyki to tylko przejaw przerośniętych ambicji, bez żadnej sensownej przyszłości i znaczenia.
   
   
10. @pomidor (autor: Promilus | data: 28/09/10 | godz.: 16:42)
    "Rynek GPGPU jest zbyt mały"
    GPGPU może, HPC z pewnością nie.
    
    
11. BUAAAAAAAAHAHAHA (autor: Conan Barbarian | data: 28/09/10 | godz.: 16:56)
    Morgi napisz coś teraz o papierach, planach i prezentacjach, gdyż okazja jest świetna.
    
    W 2012 roku AMD/ATi już odpali Radeonki z serii 7000 i takie intelowe smarki będą w low-endowym ogonie.
    
    "ma ona walczyć z przyszłymi akceleratorami Nvidia Kepler i Maxwell" - czyli z AMD nawet nie będą próbować
    
    
12. @pomidor (autor: rainy | data: 28/09/10 | godz.: 17:15)
    Tak jak wspomniał Promilus, rynek GPGPU może być zbyt mały ale HPC to inna para kaloszy - widziałem prognozy mówiące, iż będzie wart w 2014 ponad 21 mld dolarów.
    
    Chyba nie spodziewasz się, że Intel nie będzie chciał mieć sporego (znając życie dużego) kawałka w tym torcie.
    
    Na razie, rzeczywiście Nvidia jest najbardziej zaawansowana jak chodzi o wykorzystanie profesjonalne GPU - AMD w tym względzie jest wyraźnie z tyłu.
    
    Jednak z punktu widzenia interesów Intela, AMD jest także (a może nawet bardziej) groźne - w odróżnieniu od Nvidii mogą zaoferować również własne CPU co czyni ich platformę kompletną.
    
    
13. pomidor (autor: piobzo | data: 28/09/10 | godz.: 18:02)
    tylko, może dojść do tego, że apu wyprą cpu z powodu obliczeń... i dlatego intel dobrze robi, że kombinuje- nie wiadomo jak będzie a w razie czego nie zostanie na lodzie
    
    
14. ... (autor: pawel.xxx | data: 28/09/10 | godz.: 18:14)
    Z tego co pamiętam to oficjalne stanowisko intela w sprawie larrabee było takie że zrezygnowali z wprowadzenia pierwszej wersji układu w 45nm. Powodem były opóźnienia w projekcie w części sprzętowej i programowej, oraz fakt pojawienia się na rynku nowych kart graficznych konkurencji z którymi już larrabee nie mógł konkurować mieszcząc się w targecie rynku jaki dla niego przewidział intel czyli klasa średnia wyższa.
    Intel po rezygnacji z wprowadzenia pierwszej wersji od razu twierdził ze projekt nie został skasowany i ze na rynek maja trafić karty w 22nm.
    Opóźnieniom w częsci softwarowej nie ma sie co dziwić zważywszy ile wersji directX i innych API było do zaimplementowania.
    Z newsa jednak wynika że intel postanowił zmienić przeznaczenie układu i teraz celuje on w HPC.
    To właśnie potencjał w HPC jaki oferował larrabee był tym czynnikiem dla którego układ ten wzbudzał tyle nadziej i emocji wśród zaawansowanych użytkowników.
    Zmiana przeznaczenia układu zdecydowanie nie spodoba się tym użytkownikom bo przekreśla to szansę na dostęp do kart oferujących wydajność kilkudziesięciu atomów w cenie pprzyzwoitej karty graficznej.
    Natomiast Ojanusz pieprzysz jak potłuczony.
    Wielokrotnie juz pisałeś o tym ze projekt zdechł, że był do bani. Podawałeś go jako przykład klęski intela.
    Obecnie pieprzysz głupoty o sterownikach OCL. Nie zdajac sobie widocznie wprawy czym jest larrabee i OCL.
    Intelowi sterownik OCL jest równie potrzebny jak wrzód na dupie . Kod wykonywany przez rdzenie larrabee to kod x86 ia-32. Nie ma żadnego uzasadnionego powodu by programować te rdzenie z wykorzystaniem OCL skoro kod zdolny do wykonania na larrabee może wygenerować ~95% kompilatorów.
    Nie ma potrzeby za pomocą openCL wykorzystywać drobnoziarnistą równoległość jak to się robi w GPGPU, bo larrabee to równoległość gruboziarnista i bardziej przypomina on cluster całkiem mocnych maszyn.
    Nie ma potrzeby by za pomocą OpenCL sięgać lewą ręką do prawego ucha i symulować że fizycznie dostępne jednostki przetwarzające są jednostkami kompletnymi w sensie Turinga bo rdzenie larrabee są są w istocie kompletne.
    Intelowi wystarczy zaimplementować interfejs serwera uruchamiającego dowolne programy użytkownika na poszczególnych rdzeniach larrabee w środowisku ich okrojonego OS-a.
    A programiście chcącego z niego skorzystać wystarczy otworzyć port unixdomain lub tcp połączyć się z serwerem i zlecić wykonanie zadań
    
    
15. @piobzo (autor: rainy | data: 28/09/10 | godz.: 18:15)
    Aż tak to nie będzie: owszem, w części zastosowań GPU mogą śmiało konkurować czy wręcz zastapić CPU ale w częsci będą je co najwyżej wspomagać.
    
    Tak czy siak, jest to dla Intela realne wyzwanie.
    
    
16. rainy (autor: Dabrow | data: 28/09/10 | godz.: 18:19)
    intel na polu Quadro nie istnieje - nie ma kart graficznych, a już szczególnie dedykowanych DCC/CAD/CAM...
    Ten projekt to raczej konkurencja dla Tesli (obecnie) czy też kart typu Art-VPS - ciekaw jestem kto tutaj o nich słyszał/czytał/widział....
    
    
17. @pawel.xxx (autor: Promilus | data: 28/09/10 | godz.: 18:43)
    "Nie ma żadnego uzasadnionego powodu by programować te rdzenie z wykorzystaniem OCL skoro kod zdolny do wykonania na larrabee może wygenerować ~95% kompilatorów. "
    Jakim Larrabee? To raz. Dwa - gdzie ten Visual Studio generuje kod bezpośrednio wykonywalny na peryferyjnym urządzeniu podpiętym do magistrali PCI-E? No właśnie nigdzie. Trzeba do tego napisać sterownik i odwoływać się jak do urządzenia zewn. a nie procesora. Nie pamiętam też aby obecne kompilatory wspierały 512bitowe wektorowe rozszerzenia.
    "Intelowi wystarczy zaimplementować interfejs serwera uruchamiającego dowolne programy użytkownika na poszczególnych rdzeniach larrabee w środowisku ich okrojonego OS-"
    Oh... really? I rozumiem jest to kolejne multiplatformowe rozwiązanie? Nie? Aha...
    
    
18. @pawel.xxx (autor: Qjanusz | data: 28/09/10 | godz.: 19:01)
    nie wiem czy zauważyłeś tę subtelną różnicę, ale OCL ani ziębi ani grzeje. To co o Larrabee myślę napisałem wcześniej. W kwestii OCL odpowiedziałem na post, który do mojego komenta się odwoływał.
    
    "Intelowi wystarczy zaimplementować interfejs serwera..." weź się zastanów co piszesz, a najlepiej przeczytaj co napisałeś i dopiero się zastanów.
    
    
19. w sumie (autor: Markizy | data: 28/09/10 | godz.: 19:17)
    może na HTC intel ma faktycznie szanse, tylko że dobrze napisany sterownik do karty Nvidi (plus gf100 w 28nm) czy też do przyszłej AMD wygryźć może ich z tego rynku, i będą nie mieli wielkiego udziału, a przynajmniej zapewnić na tyle silna konkurencje że nikt nie zdobedzie znaczącej przewagi.
    
    chociaż AMD jak by chciało wkroczyć na ten rynek z bulldozerem i HD7000/8000 po optymalizacji pod ten dział to mogło by wiele dokonać.
    
    Do 2012 mamy jeszcze ponad 15 miesięcy, a też intel nie powiedział w którym kwartale będzie miał tą kartę, wiec wszystko się może zmienić.
    
    Jak dla mnie nie potrzebnie do tej karty ładują x86, ale to tylko moje zdanie.
    
    
20. Teraz znowu przez 2 lata bede sluchal (autor: Wyrzym | data: 28/09/10 | godz.: 19:29)
    mojego ulubionego tekstu: "Przyjdzie mlot i pozamiata" ? :D :D
    
    
21. Wyrzym (autor: Markizy | data: 28/09/10 | godz.: 19:42)
    nie młot tylko Rycerze Rogu :P
    
    Czy jak to na polski przełożyć :)
    
    
22. @Markizy (autor: rainy | data: 28/09/10 | godz.: 19:48)
    Może lepiej Rycerze z kąta (tudzież kantujący Rycerze)? :)
    
    
23. KNIGHT - skoczek, konik (autor: Conan Barbarian | data: 28/09/10 | godz.: 20:39)
    Intel miał na myśli skoczka zagonionego do rogu - można dodać "koziego rogu".
    
    
24. Conan Barbarian (autor: Grave | data: 28/09/10 | godz.: 20:51)
    Ale.. z drugiej skoczek to jedyna figura która może przeskakiwać przez inne, a także jedyna która może zaatakować hetmana samemu nie wystawiając się na jego atak
    
    
25. Grave (autor: Conan Barbarian | data: 28/09/10 | godz.: 20:59)
    Też o tym myślałem, ale zazwyczaj nie lubię wspierać mocniejszego.
    
    
26. @ sterowniki intela do OCL'a (autor: Mariosti | data: 28/09/10 | godz.: 21:21)
    Na procesorach intela można korzystać z OCL'a dzięki implementacji AMD dla x86 i to już od prawie 2 lat ;]
    
    
27. @Mariosti (autor: Promilus | data: 28/09/10 | godz.: 21:31)
    Co nie znaczy, że intel nie robi własnej. Intel chwali się jakoby był aktywnym członkiem KHRONOS i dużo wniósł przy ustalaniu OCL1.1, jednocześnie w dokumentach pokazuje, że ręcznie optymalizowany kod w C(pp) jest niewiele szybszy od tego co daje umiarkowana optymalizacja w OpenCL.
    
    
28. hehehe - ja tak podejrzewałem, że ten "king coś" (autor: mоrgi | data: 28/09/10 | godz.: 23:28)
    to "lajebe czy jakoś tak" (zresztą coś pocichu szybko wyszedł do planów nagle).
    CHYBA NIE MYŚLELIŚCIE, że tyle kasy intela pójdzie w piach !!!
    
    Naleśnik się spalił, ale skórkę zdjąć, trochę przypraw i gotowe :D
    
    
29. @Promilus (autor: pawel.xxx | data: 29/09/10 | godz.: 00:03)
    "Nie ma żadnego uzasadnionego powodu by programować te rdzenie z wykorzystaniem OCL skoro kod zdolny do wykonania na larrabee może wygenerować ~95% kompilatorów.
    Jakim Larrabee? To raz. Dwa - gdzie ten Visual Studio generuje kod bezpośrednio wykonywalny na peryferyjnym urządzeniu podpiętym do magistrali PCI-E? No właśnie nigdzie. "
    
    Jak zwykle nieprecyzyjny i wybiórczy. Zostało równie napisane
    
    ""Intelowi wystarczy zaimplementować interfejs serwera uruchamiającego dowolne programy użytkownika na poszczególnych rdzeniach larrabee w środowisku ich okrojonego OS-"
    
    Co chyba wyczerpuje temat w jaki sposób ten kod wygenerowany przez kompilator wykonać.
    
    
    "Nie pamiętam też aby obecne kompilatory wspierały 512bitowe wektorowe rozszerzenia."
    
    
    I co jak kompilator nie wygeneruje kodu dla SIMD 512 to nie zostanie on wykonany? A co z kompatybilnością wsteczna przestanie obowiązywać?
    Kod zostanie wykonany poprawnie po prostu potencjał tych instrukcji nie zostanie wykorzytany.
    Wykorzystanie tych nowych instrukcji to niewielka modyfikacja fragmentu kompilatora.
    
    
    "Oh... really? I rozumiem jest to kolejne multiplatformowe rozwiązanie? Nie? Aha..."
    
    
    A potrafisz racjonalnie uzasadnić po co intelowi multiplatformowe rozwiązanie?
    W przypadku AMD Nvidii powerVR gdzie nie ma ściśle określonej stałej w czasie listy instrukcji poszczególnych GPU nie ma wyjścia i trzeba uciekać się do interfejsów które ujednolicą dostęp do zasobów.
    Intel jednak IA-32 ma udokumentowaną, od 1983r, ma olbrzymie wsparcie ze strony oprogramowania.
    Ich metodą na wykonanie obliczeń jest już IA-32. Sama lista instrukcji stała się się interfejsem.
    
    
30. @pawel.xxx (autor: Promilus | data: 29/09/10 | godz.: 00:22)
    "Co chyba wyczerpuje temat w jaki sposób ten kod wygenerowany przez kompilator wykonać."
    Tak... to tylko oznacza, że gdzieś po drodze moc się straci, a sam Knight's Ferry i jego następcy po kilkadziesiąt GB RAM mieć nie będą czyli jest to najzwyczajniejszy BAD IDEA.
    "I co jak kompilator nie wygeneruje kodu dla SIMD 512 to nie zostanie on wykonany?"
    Nie zostanie wykorzystana podstawowa zaleta owego rdzenia. Bo tak bez owego swoistego AVXa to te rdzenie łączy więcej z ATOMem niż SB.
    "A potrafisz racjonalnie uzasadnić po co intelowi multiplatformowe rozwiązanie?"
    A ty potrafisz racjonalnie uzasadnić dlaczego ma inwestować w kolejny zamknięty standard gdy już jest gotowy i szeroko stosowany ten do którego przyłożył rękę?
    "Intel jednak IA-32 ma udokumentowaną, od 1983r, ma olbrzymie wsparcie ze strony oprogramowania."
    Tiaa... już to widzę, 50 rdzeni i 4GB RAM...
    "Sama lista instrukcji stała się się interfejsem"
    Bredzisz kolego, właśnie na tym rynku (HPC) kompatybilność z instrukcjami x86, power czy jakimikolwiek innymi ma stosunkowo małe znaczenie.
    
    
31. Bedzie jak zwykle (autor: MateushGurdi | data: 29/09/10 | godz.: 00:27)
    Larrabee tez byl zapowiadany z wyprzedzeniem o 2 lata do przodu, tak jak w/w cosik. Skonczy sie na tym ze za dwa lata stwierdza ze dwa lata temu wypuszczenie tego na rynek mialoby sens a na obecna chwile nie, potem zmienia nazwe, narobia szumu, a morgi kupi Piaskowy Mostek zeby wesprzec Intela w produkcji karty graficznej, swoja droga to mi zaczyna przypominac karte do obliczen a nie karte graficzna, bo z grafa ma to coraz mniej wspolnego
    
    
32. bo z grafa ma to coraz mniej wspolnego (autor: RusH | data: 29/09/10 | godz.: 02:38)
    bolarableee nigdy grafa nie bylo, jedynie implementacja shaderow na x86
    Inzynierowie intela ubzdurali sobie ze skoro znaja x86 na wylot to zaprojektowanie takiego potworka nie sprawi im problemu ... i tu jestesmy po 2 latach :)
    Jak juz ktos napisal za 2 lata jak beda gotowi to sprzedawac okaze sie ze nowe grafy sa kosmicznie szybsze i projekt trafi znowu do szuflady.
    
    Intel - jesli masz tylko mlotek (x86) to wszystko wyglada jak gwozdzie.
    
    
33. a niech (autor: Diamond Viper | data: 29/09/10 | godz.: 07:40)
    kombinują.. W końcu tylko w takim segmencie mogą jeszcze powalczyć, wiadomo, że nie wejdą na rynek zwykłych graf, bo wiedzą doskonale, że nie dogonią pod tym względem ani nvidii ani AMD..
    
    
34. @Promilus (autor: pawel.xxx | data: 29/09/10 | godz.: 08:16)
    "Tak... to tylko oznacza, że gdzieś po drodze moc się straci, a sam Knight's Ferry i jego następcy po kilkadziesiąt GB RAM mieć nie będą czyli jest to najzwyczajniejszy BAD IDEA."
    
    Jakos nie widzę przyczyny dla której ta moc miała by być tracona. Doświadczenia ze stosowanymi obecnie inferfejsami nie wskazują by moc była tracona choć w takim directX Ocl złożoność obliceniowa interfejsu jest jest znacznie większa.
    
    "Nie zostanie wykorzystana podstawowa zaleta owego rdzenia. Bo tak bez owego swoistego AVXa to te rdzenie łączy więcej z ATOMem niż SB."
    
    Jak pisałem dołożenie nowych intrukcji to tylko kwestia niewielkiej modyfikacji kompilatora. Co w historii PC było juz robione wielokrotnie. W związku z czym architektura kompilatorów nawet jest dostosowana do takich operacji dodawania nowych rozszerzeń instrukcji.
    Podstawowa zaletą nie są AVX a właśnie to że te rdzenie są atomami.
    
    
    "A ty potrafisz racjonalnie uzasadnić dlaczego ma inwestować w kolejny zamknięty standard gdy już jest gotowy i szeroko stosowany ten do którego przyłożył rękę?...
    Tiaa... już to widzę, 50 rdzeni i 4GB RAM...
    Bredzisz kolego, właśnie na tym rynku (HPC) kompatybilność z instrukcjami x86, power czy jakimikolwiek innymi ma stosunkowo małe znaczenie."
    
    
    Seroko stosowany a to dobre.To ile serwerów http, ile baz danych, ile interpreterów, php, pythona, ruby, javy, działa obecnie na tym szeroko stosowanym standardzie? Ile środowisk produkcyjnych z niego korzysta? Po stronie x86 mamy miliony wdrożeń.
    
    Co do ram. To najtańsze VPS maja właśnie po 128 MB RAM a mimo to działają i maja się dobre. Tak więc faktycznie powinieneś widzieć. Mało tego w takich zastosowaniach do których larrabee najlepiej by się nadawał i w których będzie najczęściej wykorzystany będzie uruchomionych kilkadziesiąt instancji tego samego softu więc ram na obraz kodu będzie alokowany tylko raz. Najtańsze serwery dedykowane równie śmigają na atomach.
    Faktycznie kompatybilność z jakąkolwiek listą instrukcji ma stosunkowo małe znaczenie. Istotne jest natomiast jaki i ile softu można uruchomić. Po stronie x86 mamy miliardy linii kodu gotowych do uruchomienia.
    
    Weźmy przykład takiego facebooka - 800 serwerów 300.000 request/s mnóstwo identycznego softu działającego w środowisku rozproszonym.
    Weźmy miliony firm które mają mniej lub bardziej rozbudowane usługi internetowe.
    To jest główny nurt rynku HPC - dostarczenie skalowalnych rozwiązań gdy obciążenie wzrasta.
    Przed tą perspektywą staje większość przedsięwzięć które odniosły sukces a więc które maja kasę.
    Soft już powstał, działa wyśmienicie na x86 bo to najpopularniejszy standard, ale wydajność stała sie za niska. Można spróbować przepisać soft od nowa na nowa architekturę, włacznie z technologiami których użyliśmy, ale to koszmarnie kosztowne i bardzo ryzykowne obsuwa lub niepowodzenie wdrożenia kładzie na łopatki wielomilionowy biznes.
    Nie ma pewności że użyte technologie których niekoniecznie musimy być właścicielami będą dostępne na nowej architekturze.
    Można tez przenieść obecny soft bez modyfikacji do chmury lub cluser-a - koszty stosunkowo niskie, ryzyko niepowodzenia niskie, okres wdrożenia krótki, można zarządzać kosztami zwiększając wydajność do aktulanych potrzeb.
    Larrabe jest takim właśnie clusterem atomów.
    
    
35. @pawel.xxx (autor: Promilus | data: 29/09/10 | godz.: 08:53)
    "Jakos nie widzę przyczyny dla której ta moc miała by być tracona. Doświadczenia ze stosowanymi obecnie inferfejsami nie wskazują by moc była tracona choć w takim directX Ocl złożoność obliceniowa interfejsu jest jest znacznie większa."
    Lepiej pooglądaj co o OpenCL i wydajności pisze sam intel.
    "Jak pisałem dołożenie nowych intrukcji to tylko kwestia niewielkiej modyfikacji kompilatora" Jest różnica między dołożeniem a efektywnym wykorzystaniem.
    "Po stronie x86 mamy miliony wdrożeń"
    Pierdzielisz jak zwykle od rzeczy. Jest to szerzej stosowane i dojrzałe niż rozwiązanie które ty zaproponowałeś. Przede wszystkim dlatego że już jest. Co do zastosowań o których pierdzielisz to pokaż mi gdzie tam HPC o którym z kolei JA pisałem? No właśnie - jak zwykle potrafisz tylko przekręcać czyjeś słowa.
    "Mało tego w takich zastosowaniach do których larrabee najlepiej by się nadawał i w których będzie najczęściej wykorzystany będzie uruchomionych kilkadziesiąt instancji tego samego softu więc ram na obraz kodu będzie alokowany tylko raz"
    I te zastosowania wg ciebie pełnymi garściami biorą z x86? Nie! to że są tam rdzenie x86 jest zaletą, ale nie tak wielką jak twierdzisz, właśnie ze względu na ograniczenia.
    "To jest główny nurt rynku HPC - dostarczenie skalowalnych rozwiązań gdy obciążenie wzrasta. "
    Facebook? I co kutwa jeszcze? NK? Weź człowiecze zastanów do czego chcesz wkleić Knights Ferry! Nie do rozwiązań gdzie najlepiej mieć milion wątkowy system szybko obsługujący kolejne zapytania. Intel jasno określił że to akcelerator do obliczeń... przeznaczeniem jest rynek HPC, po to właśnie rozszerzenia wektorowe. A reszta architektury podobna do atoma (z tym że 4 wątki na rdzeń iirc) żeby to nie żarło niewiadomo ile prądu! A ty pieprzysz o bazach danych, serwerach www czy portalach społecznościowych. OPAMIĘTAJ SIĘ! Naprawdę od serca radzę przyjrzeć się tobie temu co o OpenCL napisali specjaliści Intela, co o Knights Ferry napisali specjaliści intela, a nie tworzyć własne wizje!
    
    
36. pawel.xxx (autor: Markizy | data: 29/09/10 | godz.: 09:42)
    mówisz że obecny soft z x86 działa wyśmienicie, ale głównie na jednym rdzeniu, duży problem jest wykorzystaniem na 4 rdzeniach , a co dopiero na 50. Oczywiście cześć programów radzi sobie z każdym kolejnym rdzeniem dobrze, ale co z resztą?
    
    Knight's Corner ma być akceleratorem trochę na wzór obecnych GPU on nie ma się zastawiać nad logiką przetwarzania wątku, tylko ma przetwarzać możliwie szybko dane i zwracać wyniki.
    
    A czy intelowi uda się uzyskać podobne wyniki podobne do konkrecji w podlonych zastosowaniach zobaczymy, bo konkrecja głównie nvidia już w tej dziedzinie działa i ich układy są można je programować, kwestia optymalizacji i usprawnień architektury która siep pojawi prawdopodobnie w 28nm.
    http://www.benchmark.pl/...-3084/strona/10213.html
    http://www.benchmark.pl/...ATI_Evergreen-3084.html
    
    Teraz zobacz jak daleko jest architektura x86(x87) za GPU, które dopiero zaczynają przygodę w rynku obliczeń (ale nie da się nimi zastąpić x86), a za dwa lata może być już tylko lepiej.
    
    
37. @Promilus (autor: pawel.xxx | data: 29/09/10 | godz.: 10:06)
    Pierdzielisz jak zwykle od rzeczy. Jest to szerzej stosowane i dojrzałe niż rozwiązanie które ty zaproponowałeś. Przede wszystkim dlatego że już jest."
    
    Jak zwykle gdy brakuje ci wiedzy zaczynasz fantazjować. A wiedzy ewidentnie ci brakuje bo gdybys ja miał to byś wiedział że obecnie stosowane rozwiązania wykorzystują przetwarzanie rozproszone.
    Co sprowadza się do tego ze klient rozsyła żądania do rozproszonych serwerów posługując się konfiguracją postaci adres:port
    W przypadku larrabee zmieni sie jedynie konfiguracja na postać 127.0.0.1:port.
    Co jeszcze: google, nasza klasa, bankowość intenetowa cloud computing, miliony innych.
    Podkreślam miliony a nie 408 kompów z top500.
    przecietny serwer kosztuje zdaje sie 9000$ o ile dobrze pamiętam dane z wyników della. W polsce centra danych są w każdym wiekszym mieście. Ile jest polskich kompów w top 500?
    
    Rzecz w tym że intel nic nie wspomniał o opencl
    http://fwd4.me/gd1
    
    
    "Knights Ferry! Nie do rozwiązań gdzie najlepiej mieć milion wątkowy system szybko obsługujący kolejne zapytania."
    
    Zapytam jak demony z logo netBSD why not?
    
    
38. @up (autor: Promilus | data: 29/09/10 | godz.: 10:09)
    Przepisanie CERNowcom benchmarka obliczeń równoległych na MIC zajęło kilka dni. Nie konieczne byłoby żadne przepisywanie gdyby ów benchmark był na OpenCL, dla którego to nie ma różnicy czy jest 1 rdzeń, czy 20, czy też 300. Czy jest CPU o architekturze ARM, x86, x86-64 czy POWER. Intel z Knights Ferry (developer's board) udostępnia toolsy do HPC właśnie. Nie daje nic co miałoby pozwolić na działanie akceleratora jako swoistego klastra do zastosowań o których pisałeś powyżej. Tak jak na rynku HPC nie ma znaczenia czy mieszasz x86 z PowerXCell, czy z Teslami, czy wciskasz POWER6 albo 7 i wzbogacasz Spursengine, tak fakt iż w MIC intela siedzą x86 ma niewielkie znaczenie. Stosowane tam rozwiązania i tak nie są uzależnione od jednej architektury sprzętowej, bo po prostu nie mogą. Dzięki OpenCL taki Knights Ferry (board, nie sam CPU jakim jest Knights corner) będzie w systemie widziany jak akcelerator albo CPU, zależnie jak będą to chcieli panowie z intela rozwiązać. Dzięki elastyczności rdzeni kod będzie się wykonywał niemal tak szybko jak w wysoko zoptymalizowanym C++ (multithreaded, simd). Ze slajdów gdzie odpalali OCL na i7 wynika, że wielki cache L3 jest niezbyt użyteczny, za to architektura MIC wygląda na idealnie dopasowaną do tego by OCL korzystał z niej pełnymi garściami. Jeszcze raz przypomnę - intel JEST członkiem KHRONOS GROUP i JEST zainteresowany wykorzystaniem OpenCL. Różnica między Intelem a nvidią jest taka, że implementacje OCL na CPU są z reguły bardziej dojrzałe i osiągają większą efektywność niż te na GPU. Działanie Core 2 czy Nehalema na implementacji AMD jest bez zarzutu. Intel zrobi swoją implementację wtedy gdy rzeczywiście będzie to konieczne.
    
    
39. @pawel.xxx (autor: Promilus | data: 29/09/10 | godz.: 10:15)
    "Co jeszcze: google, nasza klasa, bankowość intenetowa cloud computing, miliony innych."
    Sam intel pisze, że to nie ich target, a właśnie laboratoria, ośrodki naukowe, placówki badawcze...ale TY wiesz od nich lepiej.
    "Zapytam jak demony z logo netBSD why not?"
    Bo od tego są lepiej przystosowane platformy. A ty widzisz w MIC uniwersalną platformę zastępującą wszystkie obecnie wyspecjalizowane. I tu tkwi twój błąd.
    "A wiedzy ewidentnie ci brakuje bo gdybys ja miał to byś wiedział że obecnie stosowane rozwiązania wykorzystują przetwarzanie rozproszone" A jak to się wiąże z tym, że intel nigdzie nie pisze o takich zastosowaniach swojego projektu o których piszesz ty? I kto tu fantazjuje...
    
    
40. @ Markizy (autor: pawel.xxx | data: 29/09/10 | godz.: 10:21)
    Skoro jak piszesz jest duży problem z wykorzystaniem 4 rdzeni to 4 rdzeniowe procesory nie powinny mieć racji bytu, że o 6 rdzeniowych AMD które sa na tpc bardzo zachwalane nie wspomnę. A co z 12 rdzeniowymi opteron-ami. równiez sa bezuzyteczne bo soft działa na jednym rdzeniu.
    Po co te płyty z dwoma, czterema, ośmioma gniazdami procesorów. Przecież to nie ma sensu - soft działa wyśmienicie na jednym rdzeniu.
    Potrafiłbyś uzasadnić po co w takim razie takiemu facebookowi 800serwerów.
    Owszem masz racje tylko cześć programów radzi sobie dobrze na każdym kolejnym rdzeniu. Ta część która działa dobrze to te programy które wymagają dużej mocy obliczeniowej, które znajdują zastosowanie w wysoko obciążonych serwerach.
    A reszta - reszta programów nie potrzebuje HPC ani w wersji intela ani w wersji GPU
    
    
41. @ Promilus (autor: pawel.xxx | data: 29/09/10 | godz.: 10:26)
    sami intel pisze w HIGHLIGHTS
    
    "
    * The first product codenamed "Knights Corner" will target Intel's 22nm process and use Moore's Law to scale to more than 50 Intel cores.
    * Intel® Xeon® processors and Intel® Many Integrated Core architecture-based products to share common tools, software algorithms and programming techniques.
    * Products build upon Intel's history of many-core related research including Intel's "Larrabee" program and Single-chip Cloud Computer.
    * The share of the TOP500 list that features Intel processors grows to 408 systems, nearly 82 percent.
    "
    
    
    Wspomina o cloud computing ale juz o open cl nie bardzo. Wspomina o dzieleni wsuólnych narszędzi i technik programistycznych, algorytmów.
    Nie wodzę natomiast wzmianki o konieczności przwenoszenia algorytmów do niskopoziomowej drobnoziarnistek równoległości.
    
    
42. pawel.xxx (autor: Markizy | data: 29/09/10 | godz.: 10:26)
    kiedy przemijały czasy pentium 4 i athlona 64, ani Intel ani AMD nie mogły śrubować taktowań tak jak wcześniej, porostu sie dało ( a jak tak to za dużym kosztem) , wiec zaczęli dokładać rdzenie.
    
    Ty pisałeś o multum programów x86 które można łatwo przenieść, ale zapomniałeś o tym że 80% z nich nie potrafi wykorzystać 2 rdzeni, i do tego porostu nawiązałem.
    
    
43. @pawel.xxx (autor: Promilus | data: 29/09/10 | godz.: 10:30)
    Jeśli się wczytałeś w technikalia to musisz wiedzieć, że intel sam pisze iż to Xeony nadal będą obsługiwać większość algorytmów, za to MIC będzie dla wysoko zrównoleglonych algorytmów jako AKCELERATOR. Nic więcej. Ale kreowanie własnej wersji rzeczywistości to coś co tobie wychodzi najlepiej.
    
    
44. @Promilus (autor: pawel.xxx | data: 29/09/10 | godz.: 11:09)
    "While the vast majority of workloads will still run best on award-winning Intel® Xeon® processors, Intel® MIC architecture will help accelerate select highly parallel applications."
    
    Intel nie pisze o równoległych algorytmach. Pisze o wysoko równoległych aplikacjach
    No i kto kreuje rzeczywistość? Zacytowałem co napisał intel. Ty wyczytałeś że chodzi o wysoko równoległych algorytmach. Intel pisze o aplikacjach.
    Szczegół
    
    Jakież to równoległe apilkacje mogą działać na 800
    serwerach facebooka? Serwery http na pewno. Nie wiem na jakeij technologi fb działa ale jakieś interpretatory serwer side scripting pewnie tez tam działają jako rozproszone aplikacje. Aplikacje nie algorytmy.
    
    
45. @Markizy (autor: pawel.xxx | data: 29/09/10 | godz.: 11:23)
    No tak. tyle ze czasy pentium 4 minęły i nadal dokłada się rdzenie. Obecnie nadal nie bardzo można podnieść taktowania. Od tamtego czasu ilość rdzeni w cpu serwerowych wzrosła z 2 do 12. Taktowanie moze o 50%.
    
    Pisałem o tym multum programów które można łatwo przenieść bo to prawda. Program nie musi natywnie obsługiwać wielowątkowości by skorzystać z cloud computing jaki daje larrabe.
    Co stoi ma przeszkodzie by na tym naszym hipotetycznym serwerze http na Xeon działał tylko haproxy balansujący obciążenie i rozdzielający zadania do 50 czy 100 jednowątkowych procesów serwerów http działających na rdzeniach larrabe?
    Nic.
    Te procesy działajace na larrabee mogą być jednowątkowe mogą być prymitywne, ale jest ich legion :)
    Tak wiec to nie problem że aplikacja nie potrafiłaby obsłużyć wielu rdzeni to wcale nie jest wymagane.
    
    
46. @pawel.xxx (autor: Promilus | data: 29/09/10 | godz.: 11:54)
    "Szczegół "
    A cóż to? Czyżby nagle wPrime był aplikacją wysokorównoległą? Nie. Jedynie sam algorytm liczący liczby pierwsze. To, że pisze się o aplikacjach to uproszczenie, jak najbardziej dozwolone. Zresztą sam o tym dobrze wiesz. Dlaczego o tym więc piszesz? Czego konkretnie się czepiasz?
    "Jakież to równoległe apilkacje mogą działać na 800
    serwerach facebooka"
    Pokaż info że facebook zamierza użyć Knights Corner w swoich serwerach to może ci uwierzę. Cały czas piszemy o twoim wyssanym z palca pomyśle na to by na 1 chipie bez VT, out of order execution i limitowanym branch prediction, z niewielką lokalną pamięcią i udziwnionym "współdzieleniem" z pamięcią hosta odpalać serwery www, bazy danych itp. itd. Człowieku! Toż to jest intelowski, bardziej dopracowany, ale ciągle CELL!! Dobry koprocesor, świetna wydajność/W ale nic więcej. To nie jest żadna konkurencja do serwerów blade, albo klastrów komputerowych. To jest co najwyżej konkurencja dla Tesli. Spóźniona, bo spóźniona, ale jest.
    "Pisałem o tym multum programów które można łatwo przenieść bo to prawda. Program nie musi natywnie obsługiwać wielowątkowości by skorzystać z cloud computing jaki daje larrabe"
    To by intel nie inwestował w mocne xeony tylko walił hurtowo Knights Corner, a jak dobrze wiesz kolejne generacje desktopowych procesorów (sandy bridge, ivy bridge) będą miały swoje wersje serwerowe. Po co jak można na jedną płytę wrzucić z 7 knights ferry? Po 50 rdzeni każdy. Prymitywnych bo prymitywnych...ale ciągle multum... Plączesz się w swoich wizjach, przeznaczenie zostało jasno określone, twoje wizje tego nie zmienią. A na Siggraph 09 intel opowiadał dość o OpenCL by wiedzieć, że w Knights Ferry będzie stosowany.
    Polecam bodajże 4 link z wyszukiwania Intel OpenCL (ze strony KHRONOS, pisany gdy LRB był jeszcze na topie). A jak już przeczytasz to wyciągnij wnioski. Bo coś naprawdę słabo ci to idzie.
    
    
47. @Promilus (autor: pawel.xxx | data: 29/09/10 | godz.: 15:40)
    "A cóż to? Czyżby nagle wPrime był aplikacją wysokorównoległą? Nie. .... "
    
    Jeszcze na studiach pisałem program liczący liczby pierwsze. Na zaliczenia przedmiotu przetwarzanie rozproszone. Jeden klient i 25 serwerów działających na wszystkich kompach w laboratorium.
    Tak jak pisałem adres:port i jedziemy. Czyli aplikacja wysoce równoległa.
    
    
    "Cały czas piszemy o twoim wyssanym z palca pomyśle na to by na 1 chipie bez VT, out of order execution i limitowanym branch prediction, z niewielką lokalną pamięcią i udziwnionym "współdzieleniem" z pamięcią hosta odpalać serwery www, bazy danych itp. itd."
    
    Dokładnie to ten pomysł to jest intela i nazywają go oni Single-chip Cloud Computer.
    Ten link jest na stronie podanej wcześniej. Trza było kliknąć na link Single-chip Cloud Computer
    http://fwd4.me/gf8
    I cóż to koleś mówi... o datacenters, web serwers, financial analytics . Wow. To nie mój wyssany z palca pomysł. Pomysł jest intela. Choć trzeba przyznać że dla mnie taka właśnie idea wykorzystywania takich układów jest naturalna i oczywista i bez potrzeby oglądania filmów z deklaracjami intela widziałem ich wykorzystanie w takich właśnie zadaniach.
    
    Jadę dalej i dementuje bzdury które piszesz.
    
    "Out of order ... " - zbędny. Nie są potrzebne wysokowydajne rdzenie. Potrzebne są rdzenie o wysokiej perf/watt i perf/square. Out of order obniży te wskaźniki.
    
    "bez VT" - VT jest zbędny w tym wypadku. Kierunek migracji ci się popieprzył. Przy virtualizacji serwery/usługi migrują na wysokowydajne jednostki dzięki czemu można zminiejszyć liczbę fozycznych serwerów, podnieść niezawodność przez dynamiczne zarządzanie. Na słabym rdzeniu i tak nie będzie sensu uruchamiać wielu virtualnych os wiec VT niepotrzebny
    
    udziwnionym "współdzieleniem" z pamięcią hosta - nie bardzo wiem o jaki aspekt ci tu chodziło czy o możliwość wymiany danych z płytą główna i CPU czy o współdzielenie zasobów w ramach chmury zarządzanej przez mechanizmy na karcie.
    
    "Coż to jest intelowski, bardziej dopracowany, ale ciągle CELL!! Dobry koprocesor, "
    
    Nie to nie jest odpowiednik cell. Chyba większość świata IT wyciągnęła już naukę z tego jak cell sie sprawdził. Instrukcje wektorowe jeśli będą dodane -to będą tylko dodatkiem bo implementacja wektorowej jednostki do juz istniejącego rdzenia jest stosunkowo tania a w niektórych zastosowanich jej obecność jest przydatna .
    
    "To by intel nie inwestował w mocne xeony tylko walił hurtowo Knights Corner, a jak dobrze wiesz kolejne generacje desktopowych procesorów (sandy bridge, ivy bridge) będą miały swoje wersje serwerowe. Po co jak można na jedną płytę wrzucić z 7 knights ferry?"
    
    
    Znowu błyszczysz ignorancją. Szybkie procesory będą również potrzebne. Do zarządzania kartami z Knights Corner. Jako klienci dostarczający im zadań. Oraz w zadaniach w których obecnie się je wykorzystuje.
    Knights Corner - nie wyprze jednostek o szybkim pojedynczym wątku. Jego zadaniem jest zapewnienie skalowalności rozwiązań gdy możliwości zwiększenia wydajności poprzez zwiększanie mocy wątku zostaną wyczerpane.
    
    
48. @pawel.xxx (autor: Promilus | data: 29/09/10 | godz.: 16:16)
    "Czyli aplikacja wysoce równoległa. "
    Tiaaa... aqrat.
    "Dokładnie to ten pomysł to jest intela i nazywają go oni Single-chip Cloud Computer."
    Ten chip to nie x86, bliżej mu do okrojonego Polarisa niż LRB. Nie wiem co chcesz przez to udowodnić. Swoją drogą nie leciało to na karcie PCI-E tylko na własnym mobo. Jak i Polaris. FAIL!
    "Jadę dalej i dementuje bzdury które piszesz. "
    Dementujesz tylko jakiekolwiek wrażenie na temat twojej inteligencji miałem... Jest gorzej niż źle.
    "Nie są potrzebne wysokowydajne rdzenie"
    Czyli z tej ogromnej ilości aplikacji x86 które to niby są zaletą większość z owych rdzeni MIC skorzysta niewiele...a nawet gorzej niż niewiele. Nie skorzysta wcale.
    "VT jest zbędny w tym wypadku" jest bardziej niż przydatny w przypadku chęci zastosowania tego układu tam gdzie ty to widziałeś w swoich niespełnionych snach.
    "nie bardzo wiem o jaki aspekt ci tu chodziło"
    O kopiowanie fragmentu RAM do VRAM i spowrotem z akcesem read only. Taki pseudo shared memory.
    "Instrukcje wektorowe jeśli będą dodane -to będą tylko dodatkiem"
    O RLY? Rzeczywiście, 8 DP/cykl dla HPC albo 1DP/cykl ... co za różnica. Dodatek miły acz niekonieczny. Hueh.
    "Nie to nie jest odpowiednik cell"
    Ależ jest, sam intel traktuje to jako koprocesor więc nie wiem czemu tkwisz w swoim uporze i twierdzisz że jest inaczej.
    "Znowu błyszczysz ignorancją."
    A ty arogancją. "Do zarządzania kartami z Knights Corner." Oh... serio? Niesamowite! Wg intela będzie całkiem inaczej. To Knights corner będzie dodatkiem do Xeonów.
    "ego zadaniem jest zapewnienie skalowalności rozwiązań gdy możliwości zwiększenia wydajności poprzez zwiększanie mocy wątku zostaną wyczerpane"
    Czyli do highly parallel tasks... podkreślam HIGHLY.
    Czemu nie potrafisz po prostu pogodzić się z tym, że nie miałeś racji? Próbujesz błyszczeć wiedzą wyniesioną ze studiów, a tymczasem za każdym razem przeczysz nie mnie, ale inżynierom intela :) Weź wypełnij druczek i zgłoś swoją kandydaturę na ich pracownika, może twoje fantazje się spełnią... kiedyś.
    
    
49. @Promilus (autor: pawel.xxx | data: 29/09/10 | godz.: 17:20)
    Masz jakieś wątpliwości czy to było przetwarzanie równoległe?
    
    "Ten chip to nie x86, bliżej mu do okrojonego Polarisa niż LRB."
    
    Tek tek śnij dalej tylko jak wyjaśnisz deklaracje intela
    "Intel® Xeon® processors and Intel® Many Integrated Core architecture-based products to share common tools, software algorithms and programming techniques."
    Tia na polarisie.
    No i co z tego że developerska wersja leciała na własnej płycie?
    Owszem dementuje pierdoły które wciskasz.
    
    "Czyli z tej ogromnej ilości aplikacji x86 które to niby są zaletą większość z owych rdzeni MIC skorzysta niewiele...a nawet gorzej niż niewiele. Nie skorzysta wcale."
    
    A to czemu nie skorzysta?
    
    "VT jest zbędny w tym wypadku" jest bardziej niż przydatny w przypadku chęci zastosowania tego układu tam gdzie ty to widziałeś w swoich niespełnionych snach."
    
    A dokładnie do czego sie VT przyda na rdzeniu larrabee? Jedno sdanie wyżej twierdziłeś że na skutek in order i niska wydajnoscia rdzenia żadna aplikacja z tego nie skorzysta. Jedno zdanie później uważasz że potrzebne jest VT by uruchomić na tym rdzeniu kilka systemów operacyjnych.
    
    "O kopiowanie fragmentu RAM do VRAM i spowrotem z akcesem read only. Taki pseudo shared memory."
    
    To w ogóle nie będzie miało znaczenia, przwwdopodobnie wogóle nie będzie stosowane Nie ten model programowania.
    
    "O RLY? Rzeczywiście, 8 DP/cykl dla HPC albo 1DP/cykl ... co za różnica. Dodatek miły acz niekonieczny. Hueh."
    
    No intel wymienił gdzie widzi jego zastosowania web serwers, datacenters, financial medical analystisc. Tm dp to miły acz nie niezbędny dodatek.
    
    
    "Ależ jest, sam intel traktuje to jako koprocesor więc nie wiem czemu tkwisz w swoim uporze i twierdzisz że jest inaczej."
    
    Już ci nie przeszkadza ze to leciało na własnym mobo? Kilka zdań wyżej co to przeszkadzało. A teraz ci nie przeszkadza ze kooprocesor działał bez procesora hosta? Nie przeszkadza ze kooprocesor miał własny system operacyjny. To raczej niezwykłe jak na kooprocesor że ma własny OS.
    
    "Niesamowite! Wg intela będzie całkiem inaczej. To Knights corner będzie dodatkiem do Xeonów."
    
    czego oczekuje intel można obejrzeć w linakch które podałem.
    
    
    "a tymczasem za każdym razem przeczysz nie mnie, ale inżynierom intela :) "
    
    Raczej tobie. Napisałeś:
    "Cały czas piszemy o twoim wyssanym z palca pomyśle na to by na 1 chipie bez VT, out of order execution i limitowanym branch prediction, z niewielką lokalną pamięcią i udziwnionym "współdzieleniem" z pamięcią hosta odpalać serwery www, bazy danych itp. itd. Człowieku!
    
    
    A inżynier intela w 2:10 http://fwd4.me/ggO mówi właśnie o web serwers datacenter
    
    
50. @pawel.xxx (autor: Promilus | data: 29/09/10 | godz.: 18:54)
    "A to czemu nie skorzysta?"
    Bo na kilku beznadziejnie słabych rdzeniach będzie działać beznadziejnie słabo...a więcej rdzeni nie wykorzysta. Jak pokazały testy Magny Cours AMD tak naprawdę w niewielu sytuacjach na rynku profesjonalnym aplikacja zajebiaszczo się skaluje z ilością rdzeni. Nadal ogromne znaczenie ma wydajność pojedynczego rdzenia.
    "Jedno zdanie później uważasz że potrzebne jest VT by uruchomić na tym rdzeniu kilka systemów operacyjnych" By w miarę sensownie wykorzystać układ wg twojej ideologii - tak. Natomiast wg idei intela gdzie knights corner jest tylko koprocesorem do działania w bardzo specyficznych przypadkach już nie. I właśnie tak to wygląda. Ma działać w specyficznych przypadkach.
    "To w ogóle nie będzie miało znaczenia, przwwdopodobnie wogóle nie będzie stosowane Nie ten model programowania"
    Ależ to jest właśnie obecne rozwiązanie intela kolego.
    "No intel wymienił gdzie widzi jego zastosowania"
    Nie. Wymyślił exploration, weather simulation, financial simulations...SCC to nie Knights Ferry i vice versa. To także nie LRB choć właśnie z nim ma KF więcej wspólnego (bo prawie wszystko).
    "Już ci nie przeszkadza ze to leciało na własnym mobo?"
    Nie, SCC nie leciało na własnym mobo tylko na platformie developerskiej podpiętej do PC przez FPGA z uruchamianym linuksem na tych małych rdzeniach. Bynajmniej to nie jest to samo co Knights Ferry choć rdzeń rzeczywiście (mea culpa) ten sam bo P54C.
    " teraz ci nie przeszkadza ze kooprocesor działał bez procesora hosta"
    Nie działał, inicjację musiał rozpocząć właśnie host, komunikacja i zarządzanie także było przez hosta.
    "czego oczekuje intel można obejrzeć w linakch które podałem"
    Dzięki, też odwiedzam strony intela i jakoś nie zgadza się to z tym co ty z owych wypowiedzi wyciągasz.
    "web serwers datacenter"
    TEN CHIP NIE MIAŁ 4 threads/core ani 512bit SIMD!! To NIE KNIGHTS CORNER!!
    Teraz to JA twoje bzdury sprostuję
    
    "While the vast majority of workloads will still run best on Intel Xeon processors, Intel MIC architecture will help accelerate select highly parallel applications."
    Wiesz co to VAST MAJORITY? Nie? To sobie wejdź w google translate!
    Dalej
    "The Intel MIC architecture is derived from several Intel projects, including "Larrabee" and such Intel Labs research projects as the Single-chip Cloud Computer (SCC)"
    W KF nie ma owych routerów między 2 rdzeniowymi modułami. Za to jest większy cache, więcej wątków na rdzeń i jednostka wektorowa. Czemu cały czas piszesz tak jakby chodziło to zupełnie o TO SAMO skoro są to inne projekty?