On Friday, April 13, 2012 8:36:58 AM UTC+1, yamma wrote:
> Nie kryzys, tylko naturalna ewolucja. Języki zarządzane mają kilka bardzo
> istotnych cech, którymi biją na głowę C++ czy Delphi.
> yamma

Jezyki kompilowane do kodu natywnego maja sie dobrze i nie odejda.

RW

do góry

> pozatym nie calkiem cos takiego mam na mysli jak zapytuje
> o 'jezyki nie kompilowane do kodu natywnego'

.. zwlaszcza ze zeby to szybko dzialalo takie jezyki musialyby byc
raczej projektowane w taki sposob aby dawaly sie dobrze kompilowac
do kodu natywnego (tak jak te wlasnie kompilowane do kodu natywnego)
- a ja nie pytam o jezyki kompilowane do kodu natywnego od razu
czy pozniej tylko o te inne pomyslane inaczej (ile mw programow
w jezykach z tej nienatywnej grupy dziala w ten sposob ze ladują
skompilowane do kodu natywnego - czy to raz czy przez jit a ile
nie jest odpalana w kodzie natywnym? - pytam bo nie mam pojecia jak to
wyglada)


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

do góry

>> Nie wszystko nadaje się do wszystkiego.
>> Poza tym te stwierdzenia ograniczają się do Windows, a linux i inne
>> Unixy.

>Na Linuxa nie ma jezykow "zarzadzanych"? Jave wylaczyli?

Kto powiedział że nie ma.

Ja się nie zgadzam z twierdzreniem ze to ewolucja lub kryzys.

do góry

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.

do góry

Adam Klobukowski <a...@g...com> napisał(a):

> Do tego kompilacja, w językach "zarządzanych" kompilacja może być procesem
> inkrementacyjnym. Klasyczny kompilator ma tylko jedną szanse na skompilowanie
> kodu, przez co jest to powolny i skomplikowany proces, a sam wynik nie do
> końca idealny.
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. Problem stanowią rozszerzone
możliwości jakie języki oferują. Na przykład wywołanie małej metody po nazwie
z dynamicznym dopasowaniem do typu parametrów nigdy nie będzie równie szybkie
jak wcielona metoda inline. Do języka C/C++ od wielu lat są dostarczane
optymalizatory PGO, efekt z rzadka bywa zdumiewający, a z reguły daje
10%-20% przyspieszenia bez żadnego nakładu pracy na optymalizowanie.

Pozdrawiam



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

do góry

Dnia 13-04-2012 o 13:00:35 Adam Przybyla <a...@r...pl> napisał(a):

> ... kompilacja nastepuje na maszynie docelowej a nie jakiejs
> hipotetycznej, mozna lepiej dostosowac parametry do danego
> stanu systemu, danego, konkretnego systemu. Z powazaniem
> Adam Przybyla

A dany system i tak często działa na maszynie wirtualnej :)

--
Boguś

do góry

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.

--
Grzegorz Niemirowski
http://www.grzegorz.net/
OE PowerTool i Outlook Express: http://www.grzegorz.net/oe/
Uptime: 1 day, 14 hours, 44 minutes and 58 seconds

do góry

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;-)
Z powazaniem
Adam Przybyla

do góry

Dnia Fri, 13 Apr 2012 11:00:35 +0000, Adam Przybyla napisal:

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

Nikt jeszcze nie napisał, że to bzdurny argument? Bo to bzdurny argument.
Fakt, można, tylko jak na razie to nic nie daje, jeżeli mówimy o
przewagach nad innym podejściem.

Edek

do góry

Dnia Fri, 13 Apr 2012 14:54:32 +0000, M.M. napisal:

> Do
> języka C/C++ od wielu lat są dostarczane optymalizatory PGO, efekt z
> rzadka bywa zdumiewający, a z reguły daje 10%-20% przyspieszenia bez
> żadnego nakładu pracy na optymalizowanie.

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

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ż).

Edek

do góry