W dniu wtorek, 17 listopada 2015 12:46:43 UTC+1 użytkownik M.M. napisał:
> On Tuesday, November 17, 2015 at 11:20:35 AM UTC+1, fir wrote:
> > W dniu wtorek, 17 listopada 2015 10:49:13 UTC+1 użytkownik AK napisał:
> > > Użytkownik "M.M." 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
> W typowych programach przetwarzających dane masz rację. Jednak jeśli jakiś
> program długo operuje na małej ilości danych, to już racji nie masz,
> ponieważ wszystkie dane mogą zmieścić się w rejestrach procesora.
>
ciekawe co to za programy robiace miliardy operacji na kilkudziesieciu bajtach input
and output ??

pozatym jesli kolega tak mowi to raczej nie zrozumial o czym pisze (bo pisze o pewnym
oglnym problemie - wlasnie o tym ze ta przepustowosc pamieci symboliczne 4 GB/s to
absolutnie kluczowa sprawa)