Lista pecet@man.lodz.pl
[Lista archiwów] [Inne Listy]

Re: [PECET] Szybki komputer czy taki istnieje?

To: pecet@man.lodz.pl
Subject: Re: [PECET] Szybki komputer czy taki istnieje?
From: "R.e.m.e.K" <go@dev.null>
Date: Mon, 6 May 2013 20:44:33 +0200
Dnia Mon, 06 May 2013 19:25:11 +0200, the_foe napisał(a):

>> Ale wiesz, ze pierdzielnales glupote?
>>
> 
> nie sądze. Moze jestes młody i nie pamietasz starych czasów, kiedy nikt 

Owszem, jestem mlody, wciaz tak sie postrzegam, choc kolezanki corki pytaja
"stary Cie pusci z chaty?". Ech ta mlodziez.

> nie instalował Javy bo Shitdows juz to miał i nazwyało się M$ java 
> virtual machine. W porównaniu do oryginału Sun'a działal jak demon 
> predkości na tyle, ze po tym jak sad nakazał wywalenie go z systemu, 
> ostatnia instalka jeszcze kilka lat w sieci miała wziecie. Dlaczego 
> implementacja Javy w wykonaniu m$ były tak udana? Bo to co Sun musiał 
> sie domyślac, oni wiedzieli.

Mysle, ze mogly na tym zawazyc dwie sprawy. Pierwsza i fundamentalna jest
analogiczna do historii typu "karty NVidii maja lepsze wyniki w benchmarku X
niz karty AMD", czyli MS jako producent OS mogl mocno wykorzystac swoja
pozycje i znajomosc API, czego Sun/Oracle nigdy nie da rady zrobic (wiesz
np. o tym, ze WinAPI ma nieudokumentowane funkcje?). Druga sprawa to
analogia do MySQLa, to bardzo szybki silnik bazy danych - w bardzo waskich i
specyficznych zastosowananiach, zwlaszcza tam, gdzie nie potrzeba transakcji
a dane maja prosta strukture i nie wymagaja wielu zlozonych zlaczen. Tak
moglo byc z MJVM, mogla wspierac standard w kluczowej czesci i byc zgodna
nie do konca, ale dzieki temu zyskiwac na wydajnosci. Poza tym MS slynie
niestety z tego, ze kazdy standard musi wydac pod wlasnym szyldem. Tak bylo
tez Java Scriptem. A standardy maja to do siebie, ze powinny byc niezalezne
od nikogo i niczego, uniwersalne i otwarte. Zazwyczaj proba klonowania
standardu "po swojemu" konczy sie kleska. A przynajmniej tak powinno byc,
choc czasem kasa moze wiele zdzialac - niestety.

> Co do .net m$ nawet fajnie to opracował i szybkie to jest tyle, ze 
> poległo to na zgodnosci: dzisiejsze kompilacje nie pojda na XP SP2. A 
> takich krzaczków jest o wiele wiecej. Zeby flagowa platforma 
> programistyczna nie działała w pelej zgodnosci z systemem tego samego 
> producenta to jest komedia.

Naprawde? To, ze nowoczesna platforma nie wspiera systemu sprzed dekady to
komedia?? Moze nie zdajesz sobie sprawy, ale akurat Windows jest jednym z
systemow najbardziej trzymajacych zgodnosc wsteczna. Zaden Linuks czy OSX
tego nie potrafi tak jak Windows. Do dzis odpalisz wiekszosc dobrze
napisanego softu z lat '90. Ale skad mozesz o tym wiedziec? Lepiej hejtowac
nie majac wiedzy.

> Produkt Suna jest genialnie przenosny i to powoduje, ze jest popularny, 
> ale majac niby same zalety, C/C++ nie jest w stanie zdetronizowac. Czyli 
> jednak ta powolnosc nie jest wymysłem użyszkodników.

Bredzisz do kwadratu. Poczytaj co to jest JIT (tylko ze zrozumieniem) i
uwierz lub nie, ale programy w Javie i .NET potrafia byc w praktyce szybsze
niz natywny kompilat C++. To, ze nie "detronizuja" C/C++ wynika z czego
innego. A konkretnie z tego, ze te jezyki, trzymajac sie Twojej
nomenklatury, mieszkaja w innych krolestwach. Innymi slowy one ze soba nie
rywalizuja, lecz maja inne przeznaczenie i sie uzupelniaja. Wynika to z ich
natury. Jezyki bazujace na VM, posiadajace GC nie nadaja sie do zastosowan,
gdzie potrzebna jest gwarantowana w czasie wydajnosc przetwarzania, bo np.
taki GC dziala niedeterministycznie i moze nagle sie odpalic, by oczyscic
pamiec powodujac przyciecie. 
Na przyszlosc nim zaczniesz filozofowac poczytaj o tym nieco.

-- 
pozdro
R.e.m.e.K

<Pop. w Wątku] Aktualny Wątek [Nast. w Wątku>