William Bonawentura <n...@m...mnie.pl> napisał(a):

> IMHO więcej osób oczekuje od narzędzia (w tym języka) wysokopoziomowej
> abstrakcji programowania (obiektowe struktury danych, mapowania relacyjne,
> interfejsy, kontekstowe sterowanie zależnościami itp.) niźli szybkości

co rozumiesz przez 'kontekstowe sterowanie zaleznosciami'?


> działania. A wówczas, kiedy np. chcemy by nasz program utworzył "dynamiczną
> kolekcję na typ X" to nie ma różnicy w tym, czy użyjesz najszybszej znanej
> biblioteki w C++ do zarządzania listą, czy też zdasz się na (równie szybką)
> implementację dostarczoną przez dostawcę np. VJM.
>



--
Wysłano z serwisu Usenet w portalu Gazeta.pl -> http://www.gazeta.pl/usenet/

do góry

Sebastian Biały <h...@p...onet.pl> napisał(a):

> On 2012-04-14 02:33, M.M. wrote:
> > Java ma narzut na zużycie pamięci. Gdy dane w całości się zmieszczą do RAM
> > w programie napisanym w C++ to java zaczyna korzystać z pliku wymiany. W
> > takich przypadkach różnica w wydajności jest kolosalna, albo program w
> > javie nie może działać bo skończyła się pamięć.
>
> Odwrotnie. Tam gdzie w C++ kończy sie pamięć w wyniku fragmentacji w
> języku z abstrakcją pamięci można stosować kompaktację i odzyskiwać
> dziury do ciąglych obszarow. Nie ma jednoznacznej i obiektywnej lepszości.
W C++,czy nawet w C, problem polega jedyna na tym że trzeba mieć doświadczenie.
Programista musi przewidzieć że pamięć w danym systemie ulegnie zbytniej
fragmentacji i musi napisać warstwę pośrednią, albo skorzystać z jakiegoś
gotowego liba.
Pozdrawiam



--
Wysłano z serwisu Usenet w portalu Gazeta.pl -> http://www.gazeta.pl/usenet/

do góry

<f...@g...pl> napisał(a):

> Adam Przybyla <a...@r...pl> napisał(a):
>
> > <f...@g...pl> wrote:
> > > yamma <y...@w...pl> napisał(a):
> > >
> > >> UĹźytkownik wrote:
> > >> > tytul jest skrotem bo wiadomo ze to nie jezyki sa
> > >> > kompilowane (podobnie wyrazenie kod natywny jest
> > >> > pewnym zastepnikiem na kod maszynowy)
> > >>
> > >> Nie kryzys, tylko naturalna ewolucja. Języki zarządzane mają kilka
> bardzo
> >
> > >> istotnych cech, którymi biją na głowę C++ czy Delphi.
> > >
> > > niby jakie? - nie kojarze za specjalnie tych cech
> > ... kompilacja nastepuje na maszynie docelowej a nie jakiejs
> > hipotetycznej, mozna lepiej dostosowac parametry do danego
> > stanu systemu, danego, konkretnego systemu. Z powazaniem
> > Adam Przybyla
>
> takie kompilowanie specjalnie pod procka
> jest to ciekawa rzecz ale z tego co wiem ona raczej nie
> stosuje sie na dzisiejszych sprzetach tak ze nie wiem na
> ile to jest praktyczne, choc gdyby przyspieszalo od tego
> ze dwa razy to warto by pomyslec, z tym ze koszty odpalania
> kompilatora są duże - wydajniejsza wersja by bylo pewnie
> przyoptymalizowanie pętli i przygotowanie w asmie kilku
> wersji tej petli pod najwazniejsze procki a na nieznanym
> ew wybranie jednej po benchmarku

Fajnie dla wydajności byłoby jakby każdy język kompilował się do tego
samego bytecode. Wtedy na każdy system/procesor odbywałaby się druga
kompilacja. Niestety aby kompilator mógł wygenerować efektywny kod
maszynowy, to kod bajtowy musiałby być dość czytelny. To z kolei
oznaczałoby udostępnianie wszystkich programów ze źródłami. Czy
może mylę się? Można wygenerować taki kod pośredni aby dekompilacja
była równie trudna jak dekompilacja kodu maszynowego?

Pozdrawiam


Ciekawe dlaczego na świecie nie ma jednego standardowego bytecode i
dlaczego każdy procesor nie ma wbitego kompilatora w ROM. System
operacyjny by sprawdzał czy binarka już została wygenerowana, a
jak nie to by włączał natywny kompilator.


--
Wysłano z serwisu Usenet w portalu Gazeta.pl -> http://www.gazeta.pl/usenet/

do góry

Dnia Sat, 14 Apr 2012 00:09:01 +0000, M.M. napisal:

> Edek Pienkowski <e...@g...com> napisał(a):
>
>> No tu bym się nie zgodził. Może w przypadku małego programiku nakład
>> pracy jest niewielki, ale coś większego trzeba uruchomić pod
>> reprezentatywnym obciążeniem, przebudować jeszcze raz - nie to samo
>> co raz skompilowana poprawka, którą można od razu dostarczyć.
>
> Bardzo często miałem odwrotnie. Gdy PGO uruchamiałem niedbale i
> długo to przyspieszenie miałem większe niż gdy robiłem to
> starannie. Nie wiem dlaczego, błędy w PGO?

PGO to ciągle heurystyki, z optymalizacjami tak już jest, że
statystycznie pomagają, ale w konkretnym przypadku YMMV. Są
optymalizacje oczywiste, ale potem to już się robi różnie.

>
>> Co do 10%-20% przyśpieszenia, też jakoś mam inne doświadczenie.
>> Mieliśmy team, który mierzył takie rzeczy, i średnio wychodziło
>> z niecałe 10%. Optymalizując same pętle w jakimś tylko liczącym
>> kodzie można się mocno naciąć, bywa i -5% (ale zdarza się +20
>> też).
> Może u mnie też to jest niecałe 10%, nie zapisywałem wszystkich
> rezultatów, tak z głowy napisałem 10-20%. Spowolnienia po
> PGO chyba nie miałem ani razu, na pewno nie pamiętam abym miał.

Ja miałem. Bawiłem się jedym algorytmem przez miesiąc, przepisując
często całość inaczej. Najgorsze było to, że czasami efekty były
odwrotne na Core2 niż na i7.

Edek

do góry

Edek Pienkowski <e...@g...com> napisał(a):

> Ja miałem. Bawiłem się jedym algorytmem przez miesiąc, przepisując
> często całość inaczej. Najgorsze było to, że czasami efekty były
> odwrotne na Core2 niż na i7.
Rozumiem że chodzi o zmiany implementacyjne, a algorytm ciągle był
ten sam. Można wiedzieć jakie miałeś przyspieszenia pomiędzy "rozsądną"
implementacją a tą najlepszą i co to za algorytm?
Pozdrawiam



--
Wysłano z serwisu Usenet w portalu Gazeta.pl -> http://www.gazeta.pl/usenet/

do góry

On 2012-04-14 09:31, M.M. wrote:
> W C++,czy nawet w C, problem polega jedyna na tym że trzeba mieć doświadczenie.
> Programista musi przewidzieć że pamięć w danym systemie ulegnie zbytniej
> fragmentacji i musi napisać warstwę pośrednią, albo skorzystać z jakiegoś
> gotowego liba.

To niestety opinia nie poparta doświadczeniem. Systemy 64 bity ten
problem zmarginalizowały, ale jest on ciągle obecny na mikrokontrolerach.

do góry

On 2012-04-14 02:54, Andrzej Jarzabek wrote:
> Ale:
> * Alokacja na stosie

To nie język funkcyjny żeby było to wygodne. Zdecydowana większość kodu
pisanego w C++ i Javie działa intensywnie używając heapu.

> * Kompozycja

Stoi w sprzeczności z separacją funkcjonalności. Wyważenie jest cieżkie.
Wprowadzanie w design od razu optymalizacji na pamięć jest niebezpieczne.

> * Zamiast zwykłej sterty można stosować poole czy regiony.

Poole czy regiony problem tylko zamieniają na mniejszy, lokalny. Ale
bedzie dalej występował.

> Oczywiście teoretycznie można mieć to i to, i w język z abstrakcją
> pamięci może możnaby je nawet lepiej zrelizować niż w C++, ale Java nie
> jest tym językiem.

Nie piszę o Javie. Chodzi ogólnie o to że C++ nie wymyslił niczego
najlepszego w dziedzinie zarządzania pamięcią.

do góry

Sebastian Biały <h...@p...onet.pl> napisał(a):

> On 2012-04-14 09:31, M.M. wrote:
> > W C++,czy nawet w C, problem polega jedyna na tym że trzeba mieć doświadczeni
> e.
> > Programista musi przewidzieć że pamięć w danym systemie ulegnie zbytniej
> > fragmentacji i musi napisać warstwę pośrednią, albo skorzystać z jakiegoś
> > gotowego liba.
>
> To niestety opinia nie poparta doświadczeniem. Systemy 64 bity ten
> problem zmarginalizowały, ale jest on ciągle obecny na mikrokontrolerach.
Nie mam bladego pojęcia jakie widzisz problemy. Jeśli coś (jakiś inny język,
albo zarządca) potrafi ten problem rozwiązać, to to coś prawdopodobnie
zostało napisane właśnie w C albo w C++. Wystarczy że za każdym razem przed
użyciem wskaźnika aplikacja poprosi o ten wskaźnik jakąś warstwę pośrednią.
Wtedy warstwa pośrednia może dowolnie realokować przydzieloną pamięć. W
przypadku aplikacji wielowątkowych trochę trudniejsza sprawa. Aplikacja
jeszcze musi powiedzieć zarządcy że już nie używa danego wskaźnika, aby
ten wiedział które obszary w danej chwili może bezpiecznie realokować. Tak
czy inaczej da się to rozwiązać i nie wydaje się to zbytnio skomplikowane.
Ale właśnie tak jak powiedziałem na początku, jakieś środowisko taki mechanizm
może zapewniać i programista który tego problemu nie przewidzi nie zrobi
sobie krzywdy, a programista w C/C++ musi od razu tak aplikację zaprojektować.
Pozdrawiam




--
Wysłano z serwisu Usenet w portalu Gazeta.pl -> http://www.gazeta.pl/usenet/

do góry

Dnia Sat, 14 Apr 2012 11:26:18 +0000, M.M. napisal:

> Edek Pienkowski <e...@g...com> napisał(a):
>
>> Ja miałem. Bawiłem się jedym algorytmem przez miesiąc, przepisując
>> często całość inaczej. Najgorsze było to, że czasami efekty były
>> odwrotne na Core2 niż na i7.
> Rozumiem że chodzi o zmiany implementacyjne, a algorytm ciągle był
> ten sam. Można wiedzieć jakie miałeś przyspieszenia pomiędzy "rozsądną"
> implementacją a tą najlepszą i co to za algorytm?

Sieć NN, nuda jak cholera. Każdy pseudo-neuron był połączony z
poprzednim(i) layerem(ami) na zasadzie kształtu - layer 2D,
kształt tego rodzaju, że obejmuje neurony "najbliżej", z tymi ma link,
chociaż mógł być "co któryś", jak w iteracji ze step.

Optymalizowałem uczenie, czyli forward pass, ocena, uczenie. Uczenie
na zasadzie zmian przy złym wyniku bez back-prop., potem jeszcze
wzmacnianie połączeń przy "dobrym". Funkcja typu clip (0.,1.),
ale binaryzowana 3-8 bitów na neuron
(przy 3: 0., 0. + 1./7. , ..., 1.). Pomijając gęstość
informacji na podstawie czytanych prac, słabo znam temat NN,
to binaryzowanie fajnie na CUDA działało, bo dużo więcej
się mieściło w shared, chociaż na starych kartach (1.3) to było
jeszcze przewidywalne, ale na cc 2.1 już nie miałem czasami pojęcia,
dlaczego coś jest szybsze lub, oczywiście z zaskoczenia, 30%
wolniejsze.

Jakkolwiek by się nie napisało algorytmu dostępy bywały mocno
nieregularne, to nie każdy-z-każdym. Na i7 lepszy był naiwny
algorytm, każdy link miał dwa floaty i kilka pointerów, alokowany
przez new, a na Core 2 lepsze było SoA, chociaż tu znowu
sporo zależało od "kształtu", ile linków na neuron i proporcji
do rozmiaru layera. Przy wielkich oczywiście pomagało tiling
ze względu na cache, ale ja zazwyczaj miałem dużo layerów
raczej niewielkich (nieliniowe mają inne
właściwości, jest sens robić więcej layerów, ilość informacji
w nieliniowych jest inna niż w liniowych, o ile znam temat;
w każdym razie to nie jest minimalizacja).

Tylko dlatego tak naprawdę sporo czasu na to poświęciłem,
że właśnie nie było to nic regularnego, a jednocześnie w miarę
niewielkie.

Różnice były rzędu kilku %, ale zdarzały się odchyły rzędu
20% gorzej. Całość po kompilacji trafiała do jednej wielkiej
metody, zmieniałem głównie layout danych, kolejność iteracji,
alignment, opcje typu fp+sse/sse z różnym skutkiem no i
to PGO. Oczywiście główną alternatywą był push albo pull,
swoje też dodawał random.

Coś czego do dzisiaj nie rozumiem: pierwsze przebiegi były
sporo wolniejsze, potem kilka ze 2-3% szybsze, potem plateau o ile
system czegoś akurat nie robił. Chyba na i7, nie pamiętam. Tego
że seria przebiegów miała ten peak nie rozumiem,
a sprawdziłem, że mi się wcale nie przywidziało, kilka razy.

Edek

do góry

On 2012-04-14 14:42, M.M. wrote:
> Jeśli coś (jakiś inny język,
> albo zarządca) potrafi ten problem rozwiązać, to to coś prawdopodobnie
> zostało napisane właśnie w C albo w C++.

Co to ma do rzeczy?

> Wystarczy że za każdym razem przed
> użyciem wskaźnika aplikacja poprosi o ten wskaźnik jakąś warstwę pośrednią.

To oznacza przeraźliwy burdel w kodzie. Zamiast skupić się na algorytmie
bedziesz w kółko przeliczał wskaźniki co oznacza dodatkową, nienaturalna
dla C/C++ składnię. Oczywiście wszystko można opakować w klasy (sam tak
mam) ale co z tego - dalej jest nienaturalne.

> Wtedy warstwa pośrednia może dowolnie realokować przydzieloną pamięć.

To szczególnie łatwe kiedy na uC pracuje dodatkowo np. dma.

> W
> przypadku aplikacji wielowątkowych trochę trudniejsza sprawa. Aplikacja
> jeszcze musi powiedzieć zarządcy że już nie używa danego wskaźnika, aby
> ten wiedział które obszary w danej chwili może bezpiecznie realokować.

Właśnie wynadujesz kwadratowe koło. Aplikacja *nie* powinna nic o
pamięci wiedziec poza tym że może jej użyć. Inaczej wrócą czasy jak
przeliczanie segmentów w gównianym 8086.

> Tak
> czy inaczej da się to rozwiązać i nie wydaje się to zbytnio skomplikowane.

Walcz więc. Jesli zrobisz to w sposób który nie kradnie cykli w
systemach RT to zbawisz cale pokolenia programistów uC. I nie, nie można
wziąść wiekszego procka.

> Ale właśnie tak jak powiedziałem na początku, jakieś środowisko taki mechanizm
> może zapewniać i programista który tego problemu nie przewidzi nie zrobi
> sobie krzywdy, a programista w C/C++ musi od razu tak aplikację zaprojektować.

Nie da się zaprojektować sensownie aplikacji, kiedy musisz co instrukcję
sprawdzać czy ten wskaźnik to dalej jest ten sam co przed chwilą.

do góry