W dniu wtorek, 17 listopada 2015 11:20:35 UTC+1 użytkownik fir napisał:
> W dniu wtorek, 17 listopada 2015 10:49:13 UTC+1 użytkownik AK napisał:
> > Użytkownik "M.M." <m...@g...com> napisał:
> >
> > > Mnie jest trudno uchwycić różnicę pomiędzy sprzętowo a programowo,
> > > ponieważ efekt jest taki sam, możliwości takie same, a program można
> > > wbić na stałe w sprzęt.
> >
> > A mnie sie kiedys bardzo marzylo podejscie takie jak chocby w (chyba upadlych)
> > pocesorach Transmeta.
> > https://en.wikipedia.org/wiki/Transmeta_Crusoe
> > https://en.wikipedia.org/wiki/Code_Morphing_Software
> >
> > Na drugim biegunie baardzo odobala mi sie tez upadla Alpha DECa.
> > https://pl.wikipedia.org/wiki/DEC_Alpha
> >
> > PS: Az mnie dziwi, ze powszechnie (Intel, AMD) nie powrocono do idei "wbicia"
> > w procesor rozkazow o wiele wyzszego poziomu nic dzisiejszy ASM (chyli bytecodes
Javy,
> > .NETa, chocby semicode LLVMa, itp - albo i wprost AST
(ujednolicone/ustandaryzowane)
> > po parsingu (niepoetrzeben by sie wreszcie staly te glupawe dzis linkery, a i
interpretety, vm-y) ?
> >
> > AK
> >
> >
> juz pisalem nie raz ze moim zdaniem nie tyle predkosc procesorow jest kluczowym
czynnikiem w dzisiejszym swiecie co "memory bandwidth/throughput" -> czyli pamiec ew
styk pamiec procesor, szybkosc memcopy mowiac w uproszczeniu
>
> pytalem na chyab 4 roznych forach o tą kwestie, czemu TEGO nie da sie przyspieszyc
i z czym to sie wiąże (i czy to cpu czy raczej kosci ram czy moze szyna miedzy jednym
a drugim) ale okazuje sie ze jakos
> nikt nie potrafil na to odpowiedziec,
>
> byc moze sa to jakies kwestie oszczednosciowe bo nie wiem co by
> to moglo byc (a pytanie jest niezwykle ważkie)

mam jedynie przez to zrabki wiedzy na ten temat w tym waznym temacie: jesli sie myle
ktos moze wyprowadzic mnie z bledu lub wyjasnic sprawe

I. ogolne praktyczne memory throughtput/bandwidth na wspolczesnych rdzeniach wynosi
jakies kilka GB na sekunde
[ nie jestem pewien czy to sie dzili
na pol jesli mowa o kopiowaniu czy tez read i write sa niezalezne, chyba sie nieststy
dzieli tak ze 4 GB memset dale 2 GB memcopy]

II. (na moim starszym core2 jest to ztcp jakies 4 GB na nowszym haswellu jest to ztcp
bardziej jak 6 GB) - czyli tak to mw wyglada, ta przepustowosc rosnie ale raczej
powoli

III. ZTCW jest to predkosc na rdzeń, tj dla dwu rdzeni jest dwa razy szybciej bo
dostepy do pamieci nie kolidują (WIELKI PLUS)

IV. ZTCW ta pradkosc jest stala niezaleznie czy sa to odczyty skalarne czy simdami
(WIElKI MINUS)

V. ZTCW GPU mają czy tez moga miec (zwlaszcza te droższe) nawet 10 ktornie wiekszą
przepustowosc siegajaca nawet ponad 100 GB (czyli da sie zrobic, ze da sie zrobic
widac juz zreszta z tego ze dalo sie
ta przepustowosc pomnozyc przez rdzenie na CPU (o ile sie nie myle i tak to jest jak
pisze)

czemu jednak nie udalo sie tego rozszerzyc na simdy? na zwykla przepustowosc na
rdzen?

SA to mz absolutnie wazne i kluczowe pytania dla kogos kto sie interesuje
optymalizacja i wydajnoscią - bo dobrze zoptymalizowany program osiaga wlasnie
wydajnos limitowaną
przez ten ogolny memory bandwidth i to jest po prostu kluczowy czynnik, Jesli ktos
przrobi kopy tak by ta memory bandwidth wzrosla np 6 razy to praktyczni ekompy
przyspieszą 6 razy - co by sie oczywiscie niezmiernie przydalo nawet w moich
zabawkowych zastosowaniach, kilkukrotne przyspieszenia ciagle most welcome)