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)