eGospodarka.pl

eGospodarka.plGrupypl.comp.programming › Kiedy będzie milion rdzeni?
Ilość wypowiedzi w tym wątku: 18

  • 1. Data: 2019-09-17 20:10:05
    Temat: Kiedy będzie milion rdzeni?
    Od: "M.M." <m...@g...com>

    Dziś zobaczyłem pierwszy w rankingu wydajności procesor AMD EPYC
    zawierający 64 rdzenie:

    https://www.cpubenchmark.net/cpu.php?cpu=AMD+EPYC+77
    42&id=3547


    Mocno wyprzedził w rankingu zarówno najlepszy procesor Intela jak i
    dotychczasowy procesor AMD, aż trudno uwierzyć:

    https://www.cpubenchmark.net/high_end_cpus.html

    Cena też nie jest mała, 7tys USD.

    Pozdrawiam


  • 2. Data: 2019-09-17 20:45:17
    Temat: Re: Kiedy będzie milion rdzeni?
    Od: Wojciech Muła <w...@g...com>

    On Tuesday, September 17, 2019 at 8:10:06 PM UTC+2, M.M. wrote:
    > Dziś zobaczyłem pierwszy w rankingu wydajności procesor AMD EPYC
    > zawierający 64 rdzenie:
    >
    > https://www.cpubenchmark.net/cpu.php?cpu=AMD+EPYC+77
    42&id=3547
    >
    >
    > Mocno wyprzedził w rankingu zarówno najlepszy procesor Intela jak i
    > dotychczasowy procesor AMD, aż trudno uwierzyć:
    >
    > https://www.cpubenchmark.net/high_end_cpus.html

    Intel od paru lat produkuje Xeona Phi, który ma 72 rdzenie
    i może opalać 4 wątki / rdzeń = 288 wątków. Nie potrafię
    znaleźć go w tym zestawieniu.

    w.


  • 3. Data: 2019-09-17 21:15:48
    Temat: Re: Kiedy będzie milion rdzeni?
    Od: "M.M." <m...@g...com>

    On Tuesday, September 17, 2019 at 8:45:18 PM UTC+2, Wojciech Muła wrote:
    > On Tuesday, September 17, 2019 at 8:10:06 PM UTC+2, M.M. wrote:
    > > Dziś zobaczyłem pierwszy w rankingu wydajności procesor AMD EPYC
    > > zawierający 64 rdzenie:
    > >
    > > https://www.cpubenchmark.net/cpu.php?cpu=AMD+EPYC+77
    42&id=3547
    > >
    > >
    > > Mocno wyprzedził w rankingu zarówno najlepszy procesor Intela jak i
    > > dotychczasowy procesor AMD, aż trudno uwierzyć:
    > >
    > > https://www.cpubenchmark.net/high_end_cpus.html
    >
    > Intel od paru lat produkuje Xeona Phi, który ma 72 rdzenie
    > i może opalać 4 wątki / rdzeń = 288 wątków. Nie potrafię
    > znaleźć go w tym zestawieniu.
    >

    Chyba tam nie ma ani koprocesorów a kart typu tesla, chyba są tylko
    główne procesory, gpu, pamięci i dyski twarde. Xenon Phi jest bardzo
    drogi, ale jest bardzo wygodny, normalnie aplikację dzieli się na
    wątki i działa - albo i nie, jeśli wąskim gardłem będą transfery.

    Ciekawe jak w praktyce wygląda przyspieszenie obliczeń na Tesli
    względem Xenon Phi. I ciekawe czy w ogole warto inwestować w te drogie
    rozwiązania, jak za 150usd można kupić: GeForce GTX 1650 - tania,
    wydajna, a 10 takich kart z lekkim underclockingiem na niektórych
    obliczeniach pobiera tylko 500 wat mocy. No ale na GPU trzeba się
    nauczyć jakiegoś OpenCL albo CUDA.

    Pozdrawiam




  • 4. Data: 2019-09-18 15:29:01
    Temat: Re: Kiedy będzie milion rdzeni?
    Od: fir <p...@g...com>


    zalezy co rozumiec za rdzen/sprzetowy watek

    w swiecie gpu mowia o ile wiem o tzw kanalach, jeden kanal przypada na jednego floata
    (przypadajacego niezaleznie do obrobki)

    o tyle powstaje koncepcja zbudowania czegios w rodzaju komputacyjnej macierzy
    (powiedzmy 1024x1024 floato) zdolnej np do zaladowania megabajta floatow w jednym
    cyklu dodania do niej drugiego miliona floatow w drugim cyklu i zapisania tego
    spowrotem w trzecim czy piatym

    taka komputacyjna macierz wydaje mi sie dobrym pomyslem, pisalem juz o tym choc nie
    jestem epwien czy na tej grupie.. (np o tym jak to zintegrowac z c)

    sporo czesc kodow np rysowanie zbioru mandelbrota (ale i zapewne wiele innych )
    daloby sie puscic na tej tablicy prawie bez zmian z milionowym przyspieszeniem (o ile
    sprzet mialby milion kanalow)

    jakies inne przykladowe kody typu jakis kontrast czy usrednienie pikseli itd (mam na
    mysli takie kody w ktorych kanal "czyta" wartisci np z 8-miu przylagajacych kanalow)
    tez chyab dobrze by szly bo jako ze wszystko jesli liczone w jednym kroku/cyklu to
    nei trzeba sie chyba martwic konfliktami w dostepach do pamieci, nie trzeba nic
    synchronizowac (choc moze to zalezy od przypadku trzebby przesledzic jakie
    algorytmy/kody dobrze wykonuja sie na takiej solidnej tablicy

    (solina nazywam ja bo kazdy taki kanal nie ma niezlaleznego instruction
    pointer...alternatywna bylaby jakas inna tablica gdzie kazdy z milionow kanalow
    mialby swoje ip, ale bylby to jakis inny rodzaj tablicy)

    gdyby mi sie chcialo to bym sie pozastanawial jak rozne algorytmy wpisuja sie ten
    schemat, ale ostatnio cos slabo z motywacja - nad pewnymi drobnymi rzeczami mozna sie
    jednak zastanowic

    np smieszne wydalo mi sie zastanowienie jak dzialalby na tym jakis raytracer/kod z
    duzymi ifami, bo byloby to wyglada smieszne:

    zalozmy ze taki kod mialby postac w stylu

    if(a)
    {
    if(b)
    {

    }
    }

    if(c)
    {

    }

    gdzie te ify sa 'duze'

    wyglada na to ze taka macierz komputacyjna musialaby wchodzic w kazdy (scislej prwie
    kazdy) if poniewaz jakas czesc watkow mialaby byc dla nich liczona, resztka kanalow
    by w tym czasie sobie robila nic, alebo nic uzytecznego
    po wyjsciu z ifa inne watki by wchodzily w inny if a inne by lezaly odlogiem -
    slowem taki kod zawsze by wlazl w prawie wszystkie ify i tak by wygladal pojedynczy
    przebieg (akurat w przypadku raytracerow gdy odbicia promieni sie liczy do kilku
    odbic w glab itd to by moglo nieco zwolnic ale i tak bylby spory zysk na prostocie)
    *(choc w tych niektorych raytracerach nie tylko liczy sie zalamane odbicia ale
    jeszcze np przy odbiciu wprowadza sie cala nowa petle by zeskanowac swiatlo z
    otoczenia dla roznych katow, wtedy jeden taki kanal by byl zatrudniony dla liczenia
    calej petli i mamy klasyczne zmulando, wiec moze w tym wypadku dynamiczna tablica
    kanalow z osobnymi ip sprawdzalaby sie lepiej, ale ja i tak pozostaje chyab pewnym
    fanem tej solidnej prostej tablicy 'wykonawczej' (choc tej drugiej pewnie tez)

    nie wiem jednak czy chce mi sie to rozwazac bo jest to dla nie troche malo praktyczne
    (bardziej praktyczne to mogloby byc dla intela/amd/nvidia ;c)


  • 5. Data: 2019-09-18 15:46:00
    Temat: Re: Kiedy będzie milion rdzeni?
    Od: fir <p...@g...com>

    W dniu środa, 18 września 2019 15:29:03 UTC+2 użytkownik fir napisał:
    > zalezy co rozumiec za rdzen/sprzetowy watek
    >
    > w swiecie gpu mowia o ile wiem o tzw kanalach, jeden kanal przypada na jednego
    floata (przypadajacego niezaleznie do obrobki)
    >
    > o tyle powstaje koncepcja zbudowania czegios w rodzaju komputacyjnej macierzy
    > (powiedzmy 1024x1024 floato) zdolnej np do zaladowania megabajta floatow w jednym
    cyklu dodania do niej drugiego miliona floatow w drugim cyklu i zapisania tego
    spowrotem w trzecim czy piatym
    >
    > taka komputacyjna macierz wydaje mi sie dobrym pomyslem, pisalem juz o tym choc nie
    jestem epwien czy na tej grupie.. (np o tym jak to zintegrowac z c)
    >
    > sporo czesc kodow np rysowanie zbioru mandelbrota (ale i zapewne wiele innych )
    daloby sie puscic na tej tablicy prawie bez zmian z milionowym przyspieszeniem (o ile
    sprzet mialby milion kanalow)
    >
    > jakies inne przykladowe kody typu jakis kontrast czy usrednienie pikseli itd (mam
    na mysli takie kody w ktorych kanal "czyta" wartisci np z 8-miu przylagajacych
    kanalow) tez chyab dobrze by szly bo jako ze wszystko jesli liczone w jednym
    kroku/cyklu to nei trzeba sie chyba martwic konfliktami w dostepach do pamieci, nie
    trzeba nic synchronizowac (choc moze to zalezy od przypadku trzebby przesledzic jakie
    algorytmy/kody dobrze wykonuja sie na takiej solidnej tablicy
    >
    > (solina nazywam ja bo kazdy taki kanal nie ma niezlaleznego instruction
    pointer...alternatywna bylaby jakas inna tablica gdzie kazdy z milionow kanalow
    mialby swoje ip, ale bylby to jakis inny rodzaj tablicy)
    >
    > gdyby mi sie chcialo to bym sie pozastanawial jak rozne algorytmy wpisuja sie ten
    schemat, ale ostatnio cos slabo z motywacja - nad pewnymi drobnymi rzeczami mozna sie
    jednak zastanowic
    >
    > np smieszne wydalo mi sie zastanowienie jak dzialalby na tym jakis raytracer/kod z
    duzymi ifami, bo byloby to wyglada smieszne:
    >
    > zalozmy ze taki kod mialby postac w stylu
    >
    > if(a)
    > {
    > if(b)
    > {
    >
    > }
    > }
    >
    > if(c)
    > {
    >
    > }
    >
    > gdzie te ify sa 'duze'
    >
    > wyglada na to ze taka macierz komputacyjna musialaby wchodzic w kazdy (scislej
    prwie kazdy) if poniewaz jakas czesc watkow mialaby byc dla nich liczona, resztka
    kanalow by w tym czasie sobie robila nic, alebo nic uzytecznego
    > po wyjsciu z ifa inne watki by wchodzily w inny if a inne by lezaly odlogiem -
    > slowem taki kod zawsze by wlazl w prawie wszystkie ify i tak by wygladal pojedynczy
    przebieg (akurat w przypadku raytracerow gdy odbicia promieni sie liczy do kilku
    odbic w glab itd to by moglo nieco zwolnic ale i tak bylby spory zysk na prostocie)
    > *(choc w tych niektorych raytracerach nie tylko liczy sie zalamane odbicia ale
    jeszcze np przy odbiciu wprowadza sie cala nowa petle by zeskanowac swiatlo z
    otoczenia dla roznych katow, wtedy jeden taki kanal by byl zatrudniony dla liczenia
    calej petli i mamy klasyczne zmulando, wiec moze w tym wypadku dynamiczna tablica
    kanalow z osobnymi ip sprawdzalaby sie lepiej, ale ja i tak pozostaje chyab pewnym
    fanem tej solidnej prostej tablicy 'wykonawczej' (choc tej drugiej pewnie tez)
    >
    > nie wiem jednak czy chce mi sie to rozwazac bo jest to dla nie troche malo
    praktyczne (bardziej praktyczne to mogloby byc dla intela/amd/nvidia ;c)

    skladnie w c w ekstremalnym uproszczeniu
    w jaki mozna by to wyrazic to cos w stylu

    for(1000) {}

    for(1000,1000) {}

    gdzie zamiast for moze byc tez jakies inne slowo np moze 'map' o ile tu pasuje
    (ciezko mi ocenic czy apsuje) lub jakies inne, podaje for dla uproszczenia

    liczba w for podaje ile watkow ma to liczyc, a numer watku jest domyslnie zapodany w
    i, jesli podac dwie liczby to i,j a jesli 3 to i,j,k


    for(1024,1024)
    {
    tab[i+j*1024] = tab[(i+1)+j*1024];
    }

    //przesuwa tablice 1 MB pixeli w lewo na milionie kanalow na raz


  • 6. Data: 2019-09-18 15:50:06
    Temat: Re: Kiedy będzie milion rdzeni?
    Od: fir <p...@g...com>

    W dniu środa, 18 września 2019 15:46:02 UTC+2 użytkownik fir napisał:
    > W dniu środa, 18 września 2019 15:29:03 UTC+2 użytkownik fir napisał:
    > > zalezy co rozumiec za rdzen/sprzetowy watek
    > >
    > > w swiecie gpu mowia o ile wiem o tzw kanalach, jeden kanal przypada na jednego
    floata (przypadajacego niezaleznie do obrobki)
    > >
    > > o tyle powstaje koncepcja zbudowania czegios w rodzaju komputacyjnej macierzy
    > > (powiedzmy 1024x1024 floato) zdolnej np do zaladowania megabajta floatow w jednym
    cyklu dodania do niej drugiego miliona floatow w drugim cyklu i zapisania tego
    spowrotem w trzecim czy piatym
    > >
    > > taka komputacyjna macierz wydaje mi sie dobrym pomyslem, pisalem juz o tym choc
    nie jestem epwien czy na tej grupie.. (np o tym jak to zintegrowac z c)
    > >
    > > sporo czesc kodow np rysowanie zbioru mandelbrota (ale i zapewne wiele innych )
    daloby sie puscic na tej tablicy prawie bez zmian z milionowym przyspieszeniem (o ile
    sprzet mialby milion kanalow)
    > >
    > > jakies inne przykladowe kody typu jakis kontrast czy usrednienie pikseli itd (mam
    na mysli takie kody w ktorych kanal "czyta" wartisci np z 8-miu przylagajacych
    kanalow) tez chyab dobrze by szly bo jako ze wszystko jesli liczone w jednym
    kroku/cyklu to nei trzeba sie chyba martwic konfliktami w dostepach do pamieci, nie
    trzeba nic synchronizowac (choc moze to zalezy od przypadku trzebby przesledzic jakie
    algorytmy/kody dobrze wykonuja sie na takiej solidnej tablicy
    > >
    > > (solina nazywam ja bo kazdy taki kanal nie ma niezlaleznego instruction
    pointer...alternatywna bylaby jakas inna tablica gdzie kazdy z milionow kanalow
    mialby swoje ip, ale bylby to jakis inny rodzaj tablicy)
    > >
    > > gdyby mi sie chcialo to bym sie pozastanawial jak rozne algorytmy wpisuja sie ten
    schemat, ale ostatnio cos slabo z motywacja - nad pewnymi drobnymi rzeczami mozna sie
    jednak zastanowic
    > >
    > > np smieszne wydalo mi sie zastanowienie jak dzialalby na tym jakis raytracer/kod
    z duzymi ifami, bo byloby to wyglada smieszne:
    > >
    > > zalozmy ze taki kod mialby postac w stylu
    > >
    > > if(a)
    > > {
    > > if(b)
    > > {
    > >
    > > }
    > > }
    > >
    > > if(c)
    > > {
    > >
    > > }
    > >
    > > gdzie te ify sa 'duze'
    > >
    > > wyglada na to ze taka macierz komputacyjna musialaby wchodzic w kazdy (scislej
    prwie kazdy) if poniewaz jakas czesc watkow mialaby byc dla nich liczona, resztka
    kanalow by w tym czasie sobie robila nic, alebo nic uzytecznego
    > > po wyjsciu z ifa inne watki by wchodzily w inny if a inne by lezaly odlogiem -
    > > slowem taki kod zawsze by wlazl w prawie wszystkie ify i tak by wygladal
    pojedynczy przebieg (akurat w przypadku raytracerow gdy odbicia promieni sie liczy do
    kilku odbic w glab itd to by moglo nieco zwolnic ale i tak bylby spory zysk na
    prostocie)
    > > *(choc w tych niektorych raytracerach nie tylko liczy sie zalamane odbicia ale
    jeszcze np przy odbiciu wprowadza sie cala nowa petle by zeskanowac swiatlo z
    otoczenia dla roznych katow, wtedy jeden taki kanal by byl zatrudniony dla liczenia
    calej petli i mamy klasyczne zmulando, wiec moze w tym wypadku dynamiczna tablica
    kanalow z osobnymi ip sprawdzalaby sie lepiej, ale ja i tak pozostaje chyab pewnym
    fanem tej solidnej prostej tablicy 'wykonawczej' (choc tej drugiej pewnie tez)
    > >
    > > nie wiem jednak czy chce mi sie to rozwazac bo jest to dla nie troche malo
    praktyczne (bardziej praktyczne to mogloby byc dla intela/amd/nvidia ;c)
    >
    > skladnie w c w ekstremalnym uproszczeniu
    > w jaki mozna by to wyrazic to cos w stylu
    >
    > for(1000) {}
    >
    > for(1000,1000) {}
    >
    > gdzie zamiast for moze byc tez jakies inne slowo np moze 'map' o ile tu pasuje
    > (ciezko mi ocenic czy apsuje) lub jakies inne, podaje for dla uproszczenia
    >
    > liczba w for podaje ile watkow ma to liczyc, a numer watku jest domyslnie zapodany
    w i, jesli podac dwie liczby to i,j a jesli 3 to i,j,k
    >
    >
    > for(1024,1024)
    > {
    > tab[i+j*1024] = tab[(i+1)+j*1024];
    > }
    >
    > //przesuwa tablice 1 MB pixeli w lewo na milionie kanalow na raz

    oczywiscie to wyzej by nieladnie przesunelo, by ladnie przesunelo trzebby dodac
    troche ifow (ktorych nie che mi sie pisac bo wychodze z dumu) ale pogladowo wiadomo o
    co chodzi
    (a o tym jak taka macierz kanalow mialaby traktowac ify bylo napisane wczesniej,
    kazdy z miliona kanalow musialby sprawdzic tego ifa ale to nie jest taka wielka srata
    jesli wezmiemy pod uwage prostote kodowania)


  • 7. Data: 2019-09-19 04:55:41
    Temat: Re: Kiedy będzie milion rdzeni?
    Od: k...@g...com

    W dniu wtorek, 17 września 2019 21:15:49 UTC+2 użytkownik M.M. napisał:
    > Ciekawe jak w praktyce wygląda przyspieszenie obliczeń na Tesli
    > względem Xenon Phi. I ciekawe czy w ogole warto inwestować w te drogie
    > rozwiązania, jak za 150usd można kupić: GeForce GTX 1650 - tania,
    > wydajna, a 10 takich kart z lekkim underclockingiem na niektórych
    > obliczeniach pobiera tylko 500 wat mocy. No ale na GPU trzeba się
    > nauczyć jakiegoś OpenCL albo CUDA.
    Jak ktoś umie napisać sensownie równoległy kod to OpenCL/CUDA nie są
    żadnym problemem. Owszem, to nie są jakieś przepiękne API, ale
    praktycznie każdy ostro sprzętowy kod w C wygląda równie źle;)
    Do tego można się tego uczyć bezproblemowo na dowolnym komputerze
    z jakąś sensowną kartą graficzną, odpalenie Hello World na CUDA
    (domyślny program to bodajże jakieś równoległe dodawanie wektorów
    czy tam sortowanie) zajmuje jakieś 15 minut, z czego 10 to rejestracja
    na stronie nvidii żeby ściągnać toolchain. To jest wręcz przerażająco
    łatwe w porównaniu do dawnego oprogramowywania "grubych" platform
    obliczeniowych gdzie potrzeba było komercyjnego kompilatora za grubą
    kasę na uczelnianym klastrze i wczytywania się w dokumentację żeby
    coś się w ogóle uruchomiło.

    Pozdrawiam,
    --
    Karol Piotrowski


  • 8. Data: 2019-09-19 11:00:17
    Temat: Re: Kiedy będzie milion rdzeni?
    Od: fir <p...@g...com>

    W dniu czwartek, 19 września 2019 04:55:42 UTC+2 użytkownik k...@g...com
    napisał:
    > W dniu wtorek, 17 września 2019 21:15:49 UTC+2 użytkownik M.M. napisał:
    > > Ciekawe jak w praktyce wygląda przyspieszenie obliczeń na Tesli
    > > względem Xenon Phi. I ciekawe czy w ogole warto inwestować w te drogie
    > > rozwiązania, jak za 150usd można kupić: GeForce GTX 1650 - tania,
    > > wydajna, a 10 takich kart z lekkim underclockingiem na niektórych
    > > obliczeniach pobiera tylko 500 wat mocy. No ale na GPU trzeba się
    > > nauczyć jakiegoś OpenCL albo CUDA.
    > Jak ktoś umie napisać sensownie równoległy kod to OpenCL/CUDA nie są
    > żadnym problemem. Owszem, to nie są jakieś przepiękne API, ale
    > praktycznie każdy ostro sprzętowy kod w C wygląda równie źle;)
    > Do tego można się tego uczyć bezproblemowo na dowolnym komputerze
    > z jakąś sensowną kartą graficzną, odpalenie Hello World na CUDA
    > (domyślny program to bodajże jakieś równoległe dodawanie wektorów
    > czy tam sortowanie) zajmuje jakieś 15 minut, z czego 10 to rejestracja
    > na stronie nvidii żeby ściągnać toolchain. To jest wręcz przerażająco
    > łatwe w porównaniu do dawnego oprogramowywania "grubych" platform
    > obliczeniowych gdzie potrzeba było komercyjnego kompilatora za grubą
    > kasę na uczelnianym klastrze i wczytywania się w dokumentację żeby
    > coś się w ogóle uruchomiło.
    >
    ktos tu przemilczal pare istotnych rzeczy i o tyle moim zdaniem pieprzy glupoty


  • 9. Data: 2019-09-19 21:12:38
    Temat: Re: Kiedy będzie milion rdzeni?
    Od: fir <p...@g...com>

    W dniu środa, 18 września 2019 15:46:02 UTC+2 użytkownik fir napisał:
    > W dniu środa, 18 września 2019 15:29:03 UTC+2 użytkownik fir napisał:
    > > zalezy co rozumiec za rdzen/sprzetowy watek
    > >
    > > w swiecie gpu mowia o ile wiem o tzw kanalach, jeden kanal przypada na jednego
    floata (przypadajacego niezaleznie do obrobki)
    > >
    > > o tyle powstaje koncepcja zbudowania czegios w rodzaju komputacyjnej macierzy
    > > (powiedzmy 1024x1024 floato) zdolnej np do zaladowania megabajta floatow w jednym
    cyklu dodania do niej drugiego miliona floatow w drugim cyklu i zapisania tego
    spowrotem w trzecim czy piatym
    > >
    > > taka komputacyjna macierz wydaje mi sie dobrym pomyslem, pisalem juz o tym choc
    nie jestem epwien czy na tej grupie.. (np o tym jak to zintegrowac z c)
    > >
    > > sporo czesc kodow np rysowanie zbioru mandelbrota (ale i zapewne wiele innych )
    daloby sie puscic na tej tablicy prawie bez zmian z milionowym przyspieszeniem (o ile
    sprzet mialby milion kanalow)
    > >
    > > jakies inne przykladowe kody typu jakis kontrast czy usrednienie pikseli itd (mam
    na mysli takie kody w ktorych kanal "czyta" wartisci np z 8-miu przylagajacych
    kanalow) tez chyab dobrze by szly bo jako ze wszystko jesli liczone w jednym
    kroku/cyklu to nei trzeba sie chyba martwic konfliktami w dostepach do pamieci, nie
    trzeba nic synchronizowac (choc moze to zalezy od przypadku trzebby przesledzic jakie
    algorytmy/kody dobrze wykonuja sie na takiej solidnej tablicy
    > >
    > > (solina nazywam ja bo kazdy taki kanal nie ma niezlaleznego instruction
    pointer...alternatywna bylaby jakas inna tablica gdzie kazdy z milionow kanalow
    mialby swoje ip, ale bylby to jakis inny rodzaj tablicy)
    > >
    > > gdyby mi sie chcialo to bym sie pozastanawial jak rozne algorytmy wpisuja sie ten
    schemat, ale ostatnio cos slabo z motywacja - nad pewnymi drobnymi rzeczami mozna sie
    jednak zastanowic
    > >
    > > np smieszne wydalo mi sie zastanowienie jak dzialalby na tym jakis raytracer/kod
    z duzymi ifami, bo byloby to wyglada smieszne:
    > >
    > > zalozmy ze taki kod mialby postac w stylu
    > >
    > > if(a)
    > > {
    > > if(b)
    > > {
    > >
    > > }
    > > }
    > >
    > > if(c)
    > > {
    > >
    > > }
    > >
    > > gdzie te ify sa 'duze'
    > >
    > > wyglada na to ze taka macierz komputacyjna musialaby wchodzic w kazdy (scislej
    prwie kazdy) if poniewaz jakas czesc watkow mialaby byc dla nich liczona, resztka
    kanalow by w tym czasie sobie robila nic, alebo nic uzytecznego
    > > po wyjsciu z ifa inne watki by wchodzily w inny if a inne by lezaly odlogiem -
    > > slowem taki kod zawsze by wlazl w prawie wszystkie ify i tak by wygladal
    pojedynczy przebieg (akurat w przypadku raytracerow gdy odbicia promieni sie liczy do
    kilku odbic w glab itd to by moglo nieco zwolnic ale i tak bylby spory zysk na
    prostocie)
    > > *(choc w tych niektorych raytracerach nie tylko liczy sie zalamane odbicia ale
    jeszcze np przy odbiciu wprowadza sie cala nowa petle by zeskanowac swiatlo z
    otoczenia dla roznych katow, wtedy jeden taki kanal by byl zatrudniony dla liczenia
    calej petli i mamy klasyczne zmulando, wiec moze w tym wypadku dynamiczna tablica
    kanalow z osobnymi ip sprawdzalaby sie lepiej, ale ja i tak pozostaje chyab pewnym
    fanem tej solidnej prostej tablicy 'wykonawczej' (choc tej drugiej pewnie tez)
    > >
    > > nie wiem jednak czy chce mi sie to rozwazac bo jest to dla nie troche malo
    praktyczne (bardziej praktyczne to mogloby byc dla intela/amd/nvidia ;c)
    >
    > skladnie w c w ekstremalnym uproszczeniu
    > w jaki mozna by to wyrazic to cos w stylu
    >
    > for(1000) {}
    >
    > for(1000,1000) {}
    >
    > gdzie zamiast for moze byc tez jakies inne slowo np moze 'map' o ile tu pasuje
    > (ciezko mi ocenic czy apsuje) lub jakies inne, podaje for dla uproszczenia
    >
    > liczba w for podaje ile watkow ma to liczyc, a numer watku jest domyslnie zapodany
    w i, jesli podac dwie liczby to i,j a jesli 3 to i,j,k
    >
    >
    > for(1024,1024)
    > {
    > tab[i+j*1024] = tab[(i+1)+j*1024];
    > }
    >
    > //przesuwa tablice 1 MB pixeli w lewo na milionie kanalow na raz


    mozna by sie zastanowic jak rozne algorytmy/kody by sie zachowywaly/jak by sie je
    pisalo w takim ujeciu na owa tablice komputacyjna/macierz obliczeniowa, ale nie wiem
    czy mi sie chce

    na przyklad kod rasteryzera (czyli wazna rzecz): w pierwszej fazie po prostu bierzesz
    trojkaty z tablicy trojkatow i mnozysz przez maciez modelu i macierz kamery,
    wyrzucasz te ktore sa poza polem widzenia - w wyniku dostajesz np tablice trojkatow
    2d+depth, to sie paralelizuje chyba idealnie

    dalszy proces jednak juz jest gorszy bo trzeba wypelniac framebufor i tu juz tak
    prosto nie jest, chopc ew mozna by nad tym sie zastanowic


  • 10. Data: 2019-09-20 15:00:14
    Temat: Re: Kiedy będzie milion rdzeni?
    Od: "M.M." <m...@g...com>

    On Thursday, September 19, 2019 at 4:55:42 AM UTC+2, k...@g...com wrote:
    > W dniu wtorek, 17 września 2019 21:15:49 UTC+2 użytkownik M.M. napisał:
    > > Ciekawe jak w praktyce wygląda przyspieszenie obliczeń na Tesli
    > > względem Xenon Phi. I ciekawe czy w ogole warto inwestować w te drogie
    > > rozwiązania, jak za 150usd można kupić: GeForce GTX 1650 - tania,
    > > wydajna, a 10 takich kart z lekkim underclockingiem na niektórych
    > > obliczeniach pobiera tylko 500 wat mocy. No ale na GPU trzeba się
    > > nauczyć jakiegoś OpenCL albo CUDA.
    > Jak ktoś umie napisać sensownie równoległy kod to OpenCL/CUDA nie są
    > żadnym problemem. Owszem, to nie są jakieś przepiękne API, ale
    > praktycznie każdy ostro sprzętowy kod w C wygląda równie źle;)
    > Do tego można się tego uczyć bezproblemowo na dowolnym komputerze
    > z jakąś sensowną kartą graficzną, odpalenie Hello World na CUDA
    > (domyślny program to bodajże jakieś równoległe dodawanie wektorów
    > czy tam sortowanie) zajmuje jakieś 15 minut, z czego 10 to rejestracja
    > na stronie nvidii żeby ściągnać toolchain. To jest wręcz przerażająco
    > łatwe w porównaniu do dawnego oprogramowywania "grubych" platform
    > obliczeniowych gdzie potrzeba było komercyjnego kompilatora za grubą
    > kasę na uczelnianym klastrze i wczytywania się w dokumentację żeby
    > coś się w ogóle uruchomiło.
    >
    > Pozdrawiam,
    > --
    > Karol Piotrowski

    Możesz polecić jakiś praktyczny tutorial od podstaw OpenCLa dla kogoś, kto wie
    co to C++ i programowanie rownoległe na CPU, ale z GPU nie miał nigdy
    do czynienia?

    Pozdrawiam

strony : [ 1 ] . 2



Szukaj w grupach

Szukaj w grupach

Eksperci egospodarka.pl

1 1 1

Wpisz nazwę miasta, dla którego chcesz znaleźć jednostkę ZUS.

Wzory dokumentów

Bezpłatne wzory dokumentów i formularzy.
Wyszukaj i pobierz za darmo: