On Tuesday, November 17, 2015 at 3:10:03 AM UTC+1, witek wrote:
> M.M. wrote:
> > On Monday, November 16, 2015 at 9:16:08 PM UTC+1, AK wrote:
> >> Użytkownik "wloochacz" <> napisał:
> >>
> >>> Super, że opracował.
> >>> I o ile wiem, to jest kod zarządzalny, a nie interpereter.
> >>
> >> A kod zarzadzalny to niby sam sie wykonuje ?
> >>
> >> No dobra :). Wszystko jest interpreterem.
> >> Procesor to ostatecznie tez interpreter kodu binarnego.
> >
> > A wszystko ( w dzisiejszym kompie ) jest kodem binarnym :D
> >
>
>
> Nie o to chodziło.
Sorki, czepiam się tylko dla żartów :)



> kod maszynowy "wpadający" do procesora też i de facto interpretowany na
> poziomie mikro kodu.
> Już od co najmniej 30 lat kod maszynowy nie jest wykonywany "sprzętowo".

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. No może trochę przesadzam, że możliwości
takie same, ponieważ sprzętowo może działać szybciej. Chociaż
czy na pewno szybciej? Od jakiegoś czasu producenci GPU dają możliwość
programowej ingerencji, a GPU jakoś nie działają wolniej z roku na rok ;-)


Nie jestem na bieżąco, ale chyba wiele operacji jest wykonywana
sprzętowo. Sprzętowo dla mnie oznacza, że argumenty 'instrukcji' wchodzą
na wejście 'sieci bramek logicznych' i właśnie magicznie otrzymujemy wyjście.
Myślę, że im szybszy procesor, tym więcej ma różnych wyspecjalizowanych
układów kombinacyjnych, więcej ma takich gotowców.


Natomiast całością na pewno zarządza mikrokod, albo jakiś jego odpowiednik -
nie wiem co zostało w nowoczesnych procesorach ze starego poczciwego
mikrokodu :)


Pozdrawiam

do góry

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


---
Ta wiadomość została sprawdzona na obecność wirusów przez oprogramowanie antywirusowe
Avast.
https://www.avast.com/antivirus

do góry

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)

do góry

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)

do góry

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.


Pozdrawiam

do góry

W dniu poniedziałek, 16 listopada 2015 18:19:44 UTC+1 użytkownik platformowe głupki
napisał:
> co Wy na to, że MS opracował interpreter C# dla platform embedded?

To jest dowód na postęp w dziedzinie sprzętu a nie w dziedzinie software'u.

Np. smartfon to jest embedded system zgodnie ze wszystkimi możliwymi definicjami - a
masz na nim już właściwie wszystko, co świat software'u wymyślił. W tym konkteście
informacja o tym, że Microsoftowi zadziałało coś na czymś to nie jest żaden news.

Jak napiszesz, że MS opracował interpreter C# dla systemów krytycznych albo
real-time, to wtedy będzie news.

--
Maciej Sobczak * http://www.inspirel.com

do góry

Dnia Tue, 17 Nov 2015 02:20:33 -0800 (PST), fir napisał(a):

> pytalem na chyab 4 roznych forach o tą kwestie, czemu TEGO nie da sie przyspieszyc
i z czym to sie wiąże

Z prędkością światła a raczej z prędk. rozchodzenia się fali e.m. w
przewodach między procem a pamięcią. IMO to główny czynnik ograniczający
przepustowość przy kilku GHz.
--
Jacek
Dziesięć przykazań ma 279 słów.
Deklaracja Niepodległości Stanów Zjednoczonych 1300 słów.
Dyrektywa UE w sprawie przewozu cukierków karmelkowych - 25 911 słów.

do góry

W dniu wtorek, 17 listopada 2015 13:50:59 UTC+1 użytkownik Jacek Maciejewski napisał:
> Dnia Tue, 17 Nov 2015 02:20:33 -0800 (PST), fir napisał(a):
>
> > pytalem na chyab 4 roznych forach o tą kwestie, czemu TEGO nie da sie
przyspieszyc i z czym to sie wiąże
>
> Z prędkością światła a raczej z prędk. rozchodzenia się fali e.m. w
> przewodach między procem a pamięcią. IMO to główny czynnik ograniczający
> przepustowość przy kilku GHz.

to ogranicza dostep do jednego bajtu ale co ogranicza dostep do np calego megabajta?
(memset.memcopy 1 MB trwa powiedzmy okolo 0.5 milisekundy czemu nie dajmy na to 100 -
1000 razy szybciej? - predkosc swiatla tego nie ogranicza)

do góry

W dniu wtorek, 17 listopada 2015 16:43:32 UTC+1 użytkownik fir napisał:
> W dniu wtorek, 17 listopada 2015 13:50:59 UTC+1 użytkownik Jacek Maciejewski
napisał:
> > Dnia Tue, 17 Nov 2015 02:20:33 -0800 (PST), fir napisał(a):
> >
> > > pytalem na chyab 4 roznych forach o tą kwestie, czemu TEGO nie da sie
przyspieszyc i z czym to sie wiąże
> >
> > Z prędkością światła a raczej z prędk. rozchodzenia się fali e.m. w
> > przewodach między procem a pamięcią. IMO to główny czynnik ograniczający
> > przepustowość przy kilku GHz.
>
> to ogranicza dostep do jednego bajtu ale co ogranicza dostep do np calego
megabajta?
> (memset.memcopy 1 MB trwa powiedzmy okolo 0.5 milisekundy czemu nie dajmy na to 100
- 1000 razy szybciej? - predkosc swiatla tego nie ogranicza)

nie znam sie niestaty na konstrukcji hardware i jak ktios zaczyna cos gadac o szynach
i busach to sie gubie, ale poki co
po prostu nie widze fizykalnego powodu czemu
jesli te dane sa czytane jakims kanalem typu 32 czy 64 bity w jednym cyklu nie moga
byc czytane w jednym cyklu kanalem powiedzmy 512 czy 2048 bitowym - nie rozumiem tego
i nikt nigdy nie udzilil mi na to wyjasnienia..
to pytanie jest dosyc proste i jest tym samym dosyc glupie ze nikt nic nie wie w tym
temacie

do góry

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)

do góry