On 2015-11-17 10:49, AK wrote:
> 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,

Był w ARM. Jazelle, obecnie ThumbEE.

https://en.wikipedia.org/wiki/Jazelle

Nie sprawdził sie głównie dlatego że latwiej jest przerobic bytecode na
natywny asm a ponadto było to z lekka złudne, czyli co chwile był
callback do kodu natywnego "nie wiem co z tym zrobić". Jakos szerokiem
popularnosci nie zdobyło. Ponadto specyfikacja nie dośc ze kiepska to
zamknięta.

> .NETa, chocby semicode LLVMa, itp - albo i wprost AST
> (ujednolicone/ustandaryzowane)

Jeśli jest to niezbędne to da się zrobic w FPGA. Współczesne FPGA nie
mają duzych kompleksow w stosunku do współczesnych CPU. Czekam aż
pojawią się hybrydy CPU z FPGA dzięki którym będzie można częściowo się
przekonfigurować. Nie, nie chodzi np. o Zynq, tam procesor jest
statyczny. Chodzi o FPGA w środku CPU aby dynamicznie tworzyć liste
rozkazów i jednostek przetwarzających. Gołe FPGA są za drogie ;)

> po parsingu (niepoetrzeben by sie wreszcie staly te glupawe dzis
> linkery, a i interpretety, vm-y) ?

To nie jest proste, jesli jezyk jest statycznie typowany to proces
linkowania jest przydatny aby sprawdzić czy gniazdko pasuje do wtyczki.
Coś z linkowania musiało by chyba pozostać. Ponadto nie wyobrażam sobie
wydajności systemu który pochłania skomplikowane struktury AST i bez
żadnej elaboracji ich w pamięci nagle wykonuje kod interpetując drzewo
wyrażeń. Być może w specjalnym języku ale to będzie katorga dla programisty.

do góry

On Tuesday, November 17, 2015 at 7:49:10 PM UTC+1, fir wrote:
> W dniu wtorek, 17 listopada 2015 19:24:02 UTC+1 użytkownik M.M. napisał:
> > On Tuesday, November 17, 2015 at 7:06:46 PM UTC+1, fir wrote:
> > > W dniu wtorek, 17 listopada 2015 18:49:37 UTC+1 użytkownik M.M. napisał:
> > > > On Tuesday, November 17, 2015 at 6:41:09 PM UTC+1, fir wrote:
> > > > > W dniu wtorek, 17 listopada 2015 18:31:16 UTC+1 użytkownik M.M. napisał:
> > > > > > On Tuesday, November 17, 2015 at 6:13:31 PM UTC+1, fir wrote:
> > > > > > > W dniu wtorek, 17 listopada 2015 17:56:17 UTC+1 użytkownik fir napisał:
> > > > > > > > > > >
> > > > > > > > > > ciekawe co to za programy robiace miliardy operacji na
kilkudziesieciu bajtach input and output ??
> > > > > > > > > Może poszukiwanie minimum funkcji jednej lub kilku zmiennych?
> > > > > > > > >
> > > > > > > > a umiesz zarysowac szkic takiego kodu zebym mogl to sobie
zwizualizowac ;l ? (tak zeby dyskusja byla ciekawa i miala jakis sens )
> > > > > > No właśnie czemu nie wziąć choćby mandelborta?
> > > > > >
> > > > > >
> > > > > > > z moich doswiadczen optymalizacją wynika wlasnie ze jak cos ma bogara
arytmetyke to da sie ja koniec konców po dlugasnych bojach tak uproscic ze zostaje
wlasciwie sam lub prawie sam bandwidth, nawet 'nieliniowa' arytmetyke da sie nap
zlinearyzowac kafelkami i tak dalej
> > > > > > Da się.
> > > > > >
> > > > > >
> > > > > > > co prawda np w zbiorze mandelbrota odpala sie długa iterecyjna petle
gdzie inputem są dwa floaty ale to moze wlasnie znaczyc ze
> > > > > > > ta metoda jest wybitnie wlasnie niezoptymalizowana 9ciekawe co by dalo
chocby optymalizowanie przez rozwijanie, moze potrzebe szybkiej funkcji pow?)
> > > > > >
> > > > > > Sam podałeś dobry przykład, w którym ilość danych jest bardzo mała,
> > > > > > nieprzewidzianych skoków też jest bardzo mało. Czyli dane można zmieścić
w
> > > > > > rejestrach, a instrukcje do procesora lecą ciurkiem. Moim zdaniem wąskim
> > > > > > gardłem w tym przykładzie będzie przetwarzanie instrukcji a nie dostęp
> > > > > > do pamięci.
> > > > > >
> > > > > >
> > > > > > Pozdrawiam
> > > > > >
> > > > > >
> > > > > > Pozdrawiam
> > > > >
> > > > > no to gratuluje, tylko jak to ma swiadczyc za tym ze kolega zrozumial temat
o ktorym ja pisalem ;r (mz swiadczy raczej przeciw ale widze ze raczej szkoda czasu
chyba w to brnać bo szczerze mowiac zawsze szkoda mi czasu na wyjasnienia, jak ktos
jest minimalnie łapiacy to zrozumie a jak nie to sory ale nie mam czasu na takie
bzdety)
> > > >
> > > > Nie jestem przekonany że to jest bzdet. Może właśnie te przypadki
> > > > zdegenerowane wyznaczają dobrą granicę pomiędzy 'szybsze przetwarzanie
> > > > instrukcji' vs 'szybsze transfery ram <-> procesor' ? Bo jednego i
> > > > drugiego tym samym kosztem nie da się ulepszyć.
> > > >
> > > > Pytanie: w przeciętnym PC zwiększamy przepustowość 10 razy, o ile
> > > > zwiększy się szybkość przeciętnych programów?
> > > >
> > > mz kolega brnie w jakies fikcje wlasnego wymyslu, to nie jest mz zbyt owocny
sposob spedzania czasu (przynajmniej ja nie mam
> > > na to cohoty) NORMALNE podejscie bym moim zdaniem obejmowalo raczej
> > > - przestudiowanie jakiejs tam polki literatury i dowiedzenie sie czemu (troche
odpada bo kto ma na to czas)
> > > - zapytamnie na forum moze ktos wie
> > >
> > > (no i tyle moim zdaniem lepsze to nic tracenie godzin na dziwaczne fikcje, eot)
> >
> > No ma kolega rację, uprawiam fikcję, nie wiem jakie byly prawdziwe
> > przyczyny. Uznałem jednak że to czego się domyślam jest na tyle
> > prawdopodobną odpowiedzią, aby nadawało się do wysłania.
> >
>
> boje sie wlasnie ze mam racje, z osobowosci nie jestem szczerze mowiac jakims
maniakiem
> dyscypliny ;o ale szczerze mowiac tutaj
>
> jesli juz mowi sie na jakis temat to sila rzeczy zeby nie plesc bezsensów jakies
trzymanie sie jakiegos tam "pionu" (jakiejs tam przedmiotowosci i jakiejs tam
sensownosci) musi byc -
>
> gdyby tego bylo wiecej to moze jeszcze mialoby to jakies resztki sensu

Ja jeszcze nie wiem że napisałem bezsens :) Nie wiedziałem że chcesz
tylko i wyłącznie informacje od kogoś, kto zajmuje się projektowaniem
procesorów na co dzień, więc odpowiedziałem, nie trzymając się
dyscypliny, na swoje wyczucie :)

Pozdrawiam

do góry

fir wrote:
>>
> 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,
>
z szybkością przesyłania po miedzi.
Nie da się szybciej przy takiej długości szyny. "za daleko". A blizej
upakowac narazie się nie daje (lub sie nie chce).
Drugi aspekt to grzanie. Im szybciej i gęściej tym goręcej.
Do tego dochodzą jeszcze zjawiska juz na poziomie molekularnym,

do góry

M.M. wrote:
>
> Pytanie: w przeciętnym PC zwiększamy przepustowość 10 razy, o ile
> zwiększy się szybkość przeciętnych programów?
>
Prawo Amdahla?

do góry

On Wednesday, November 18, 2015 at 8:55:54 AM UTC+1, witek wrote:
> M.M. wrote:
> >
> > Pytanie: w przeciętnym PC zwiększamy przepustowość 10 razy, o ile
> > zwiększy się szybkość przeciętnych programów?
> >
> Prawo Amdahla?

Chyba tak, ale chciałem konkretną liczbę. Czy to
będzie 1.2 raza, czy 3 razy? W programach o dostępie
losowym do dużej ilości danych pewnie będzie to z
5-7 razy.

Pozdrawiam

do góry

w wiki
https://en.wikipedia.org/wiki/Memory_bandwidth

w sumie uzywają pojecia "memory interfaces"
i pisza tam z tego co rozumiem ze memory bandwidth po prostu mnozy sie przez ilosc
tych "memory interfaces" - jesli tak to znaczyloby ze nalezy zrobic kilka (np
dwadziescia zamaist dwu) i kompy przyspieszą 10 razy

Ale chyab jest to jaksa zbyt uproszczona
wizja, (bo jesli tak to czemu tego nie zrobiono..)

do góry

M.M. wrote:
> On Wednesday, November 18, 2015 at 8:55:54 AM UTC+1, witek wrote:
>> M.M. wrote:
>>>
>>> Pytanie: w przeciętnym PC zwiększamy przepustowość 10 razy, o ile
>>> zwiększy się szybkość przeciętnych programów?
>>>
>> Prawo Amdahla?
>
> Chyba tak, ale chciałem konkretną liczbę. Czy to
> będzie 1.2 raza, czy 3 razy? W programach o dostępie
> losowym do dużej ilości danych pewnie będzie to z
> 5-7 razy.
>
> Pozdrawiam
>

Nie da sie odpowiedziec, bo nie ma przeciętnych programów.
Kazdy program da inne przyspieszenie w zależności od tego co robi.
I tak wszystko "umrze" na powolnym dysku.

do góry

On Wednesday, November 18, 2015 at 7:20:06 PM UTC+1, witek wrote:
> M.M. wrote:
> > On Wednesday, November 18, 2015 at 8:55:54 AM UTC+1, witek wrote:
> >> M.M. wrote:
> >>>
> >>> Pytanie: w przeciętnym PC zwiększamy przepustowość 10 razy, o ile
> >>> zwiększy się szybkość przeciętnych programów?
> >>>
> >> Prawo Amdahla?
> >
> > Chyba tak, ale chciałem konkretną liczbę. Czy to
> > będzie 1.2 raza, czy 3 razy? W programach o dostępie
> > losowym do dużej ilości danych pewnie będzie to z
> > 5-7 razy.
> >
> > Pozdrawiam
> >
>
> Nie da sie odpowiedziec, bo nie ma przeciętnych programów.
Racja, przeciętnych nie ma. A jakby losowo wybrać 100 programów?


> Kazdy program da inne przyspieszenie w zależności od tego co robi.
Tak tak, mialem na myśli średnie przyspieszenie.


> I tak wszystko "umrze" na powolnym dysku.
Racja, to powiedzmy że chodzi o przyspieszenie tej części która
nie zawiera operacji wejścia/wyjścia.

Pozdrawiam

do góry

M.M. wrote:
> On Wednesday, November 18, 2015 at 7:20:06 PM UTC+1, witek wrote:
>> M.M. wrote:
>>> On Wednesday, November 18, 2015 at 8:55:54 AM UTC+1, witek wrote:
>>>> M.M. wrote:
>>>>>
>>>>> Pytanie: w przeciętnym PC zwiększamy przepustowość 10 razy, o ile
>>>>> zwiększy się szybkość przeciętnych programów?
>>>>>
>>>> Prawo Amdahla?
>>>
>>> Chyba tak, ale chciałem konkretną liczbę. Czy to
>>> będzie 1.2 raza, czy 3 razy? W programach o dostępie
>>> losowym do dużej ilości danych pewnie będzie to z
>>> 5-7 razy.
>>>
>>> Pozdrawiam
>>>
>>
>> Nie da sie odpowiedziec, bo nie ma przeciętnych programów.
> Racja, przeciętnych nie ma. A jakby losowo wybrać 100 programów?
>
>
>> Kazdy program da inne przyspieszenie w zależności od tego co robi.
> Tak tak, mialem na myśli średnie przyspieszenie.
>
>
>> I tak wszystko "umrze" na powolnym dysku.
> Racja, to powiedzmy że chodzi o przyspieszenie tej części która
> nie zawiera operacji wejścia/wyjścia.
>
> Pozdrawiam
>


za dużo gdybania.
Możnaby się pokuśić o policzenie proporcji pomiedzy czasem wykonwania
instrukcji w procesorze, a czasem potrzebnym na przesył
danych/instrukcji do pamieci. I tą drugą cześć przyśpieszyć 10 razy i
policzyć proporcję z prawa Amdahla.
Strzelając powiedziałbym, że gdyby program miał pełną kontrolę nad
procesorem to moze do 3 by doszło.
Zrobi sie jezcze bardziej skomplikowanie jak uwzgledni sie, ze ładownia
i dekodowania instrukcji i tak jest robione potokowo wiec czas cieżko tu
uwzględniac
Z drugiej strony jak wuzględnisz przerwania, odwołania do OS, i mielenie
windowsa po dysku zupełnie bez potrzebny to pszyspieszenie bedzie
znikome w przypadku tego systemu.

do góry

On Wednesday, November 18, 2015 at 8:47:59 PM UTC+1, witek wrote:
> M.M. wrote:
> > On Wednesday, November 18, 2015 at 7:20:06 PM UTC+1, witek wrote:
> >> M.M. wrote:
> >>> On Wednesday, November 18, 2015 at 8:55:54 AM UTC+1, witek wrote:
> >>>> M.M. wrote:
> >>>>>
> >>>>> Pytanie: w przeciętnym PC zwiększamy przepustowość 10 razy, o ile
> >>>>> zwiększy się szybkość przeciętnych programów?
> >>>>>
> >>>> Prawo Amdahla?
> >>>
> >>> Chyba tak, ale chciałem konkretną liczbę. Czy to
> >>> będzie 1.2 raza, czy 3 razy? W programach o dostępie
> >>> losowym do dużej ilości danych pewnie będzie to z
> >>> 5-7 razy.
> >>>
> >>> Pozdrawiam
> >>>
> >>
> >> Nie da sie odpowiedziec, bo nie ma przeciętnych programów.
> > Racja, przeciętnych nie ma. A jakby losowo wybrać 100 programów?
> >
> >
> >> Kazdy program da inne przyspieszenie w zależności od tego co robi.
> > Tak tak, mialem na myśli średnie przyspieszenie.
> >
> >
> >> I tak wszystko "umrze" na powolnym dysku.
> > Racja, to powiedzmy że chodzi o przyspieszenie tej części która
> > nie zawiera operacji wejścia/wyjścia.
> >
> > Pozdrawiam
> >
>
>
> za dużo gdybania.
Tak, taki sam widzę problem, jest bardzo dużo różnych specyficznych
sytuacji, kombinuję jak to przyzwoicie uśrednić.

> Możnaby się pokuśić o policzenie proporcji pomiedzy czasem wykonwania
> instrukcji w procesorze, a czasem potrzebnym na przesył
> danych/instrukcji do pamieci. I tą drugą cześć przyśpieszyć 10 razy i
> policzyć proporcję z prawa Amdahla.
Może jakis programik wydziargam, a potem część obliczeniową powiększę
2, 3, 4 razy i uzyskam wzór aproksymacyjny.


> Strzelając powiedziałbym, że gdyby program miał pełną kontrolę nad
> procesorem to moze do 3 by doszło.
Ja bym strzelał że by doszło do około 1.8 - 2.2.


> Zrobi sie jezcze bardziej skomplikowanie jak uwzgledni sie, ze ładownia
> i dekodowania instrukcji i tak jest robione potokowo wiec czas cieżko tu
> uwzględniac
Tak, jest to skomplikowane. Może właśnie trzeba napisać programik do
oszacowania.


> Z drugiej strony jak wuzględnisz przerwania, odwołania do OS, i mielenie
> windowsa po dysku zupełnie bez potrzebny to pszyspieszenie bedzie
> znikome w przypadku tego systemu.
Tak, prawo Amdahla też uwzględnia te czynnik.

Pozdrawiam

do góry