On 13/04/2012 18:04, Adam Przybyla wrote:
> Roman W<b...@g...pl> wrote:
>> On Friday, April 13, 2012 12:00:35 PM UTC+1, Adam Przybyla wrote:
>>
>>> ... kompilacja nastepuje na maszynie docelowej a nie jakiejs
>>> hipotetycznej, mozna lepiej dostosowac parametry do danego
>>> stanu systemu, danego, konkretnego systemu. Z powazaniem
>>
>> W wielu wypadkach (i na ogol w tych, w ktorych najbardziej zalezy Ci na wydajnosci
kodu) kompilowac do natywnego tez mozesz pod konkretna maszyne.
> ... ktora moze miec rozna ilosc pamieci, zmienna od obciazenia itp;-)

Tylko że to niewiele zmienia.

Póki co statyczna optymalizacja jest chyba jednak znacznie skuteczniejsza.

do góry

>
> * ogolnie ja jestem zwolennikiem tego typu jezykow, i uwazam
> ze mogalaby tu byc konkurencja, moze nie tyle wydajnosciowa
> w stosunku do c (oby!) ale chocby stylistyczna i dotyczaca
> tez pewnie sporego obszaru innych roznic
>
Co by tu nie powiedzieć, to ostatecznie program sprowadzany jest do
postaci maszynowej. Kompilowanie jeśli nie jest dostosowane do procka,
to do jakiegoś pośrednika, co właściwie na jedno wychodzi.
pozdro
apl

do góry

Grzegorz Niemirowski <g...@p...onet.pl> napisał(a):

> M.M. <m...@g...pl> napisał(a):
> > Nie rozumiem o co chodzi. Zarówno te języki kompilowane bezpośrednio do
> > kodu maszynowego jak i te które generują kod maszynowy pośrednio, mają
> > takie same szanse na to że ów wygenerowany kod będzie wydajny.
>
> Nie mają, bo przy kompilacji bespośredniej nie wiadomo jak program będzie
> używany. Dlatego też stosuje się np.
> PGO (Profile-Guided Optimizations), gdzie optymalizacja przeprowadzana jest
> na podstawie serii uruchomień programu.

I w jednych i w drugich językach można stosować PGO z taką samą skutecznością.
Pozdrawiam


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

do góry

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?

> 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ł.

Pozdrawiam



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

do góry

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

> 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
Ehh miało być niedługo :)

Gdy profilowałem krótko i dla niestatystycznych danych to program
działał szybciej niż gdy profilowałem np. cały dzień dla dużego
zbioru danych. Dosłownie 5 sekund profilowania dawała najlepsze
efekty.

Pozdrawiam



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

do góry

Andrzej Jarzabek <a...@g...com> napisał(a):

> Póki co statyczna optymalizacja jest chyba jednak znacznie skuteczniejsza.
Też tak myślę.

Pozdrawiam


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

do góry

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
> 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.
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ęć.
Pozdrawiam




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

do góry

apl <a...@i...pl> napisał(a):

> >
> > * ogolnie ja jestem zwolennikiem tego typu jezykow, i uwazam
> > ze mogalaby tu byc konkurencja, moze nie tyle wydajnosciowa
> > w stosunku do c (oby!) ale chocby stylistyczna i dotyczaca
> > tez pewnie sporego obszaru innych roznic
> >
> Co by tu nie powiedzie=E6, to ostatecznie program sprowadzany jest do
> postaci maszynowej. Kompilowanie je=B6li nie jest dostosowane do procka,
> to do jakiego=B6 po=B6rednika, co w=B3a=B6ciwie na jedno wychodzi.
No właśnie też tak uważam. Potencjalnie mają takie same możliwości
optymalizacji.
Pozdrawiam




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

do góry

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.

do góry

On 14/04/2012 01:42, Sebastian Biały wrote:
> 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.

Ale:
* Alokacja na stosie
* Kompozycja
* Zamiast zwykłej sterty można stosować poole czy regiony.

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.

do góry