Dekoder H.264 w JavaScript

Tia, pewnie dałoby radę napisać dekoder H.264 w plikach skryptów BASHa, tylko po co robić takie chore kombinacje alpejskie ?

Paranoja.

Do takich rzeczy jak odtwarzanie video są języki niższych poziomów takie jak C++, C i niżej.

W językach wysokiego poziomu NIGDY nie osiągnie się nawet zbliżonej wydajności do tych niskiego poziomu.

Dokładnie, sztuka dal sztuki, czy to ma być docelowo szybsze od natywnej obsługi, nie wydaje mi się, więc strata czasy aby.

W kodekach to robią optymalizacje asm,mmx, sse i nowsze, a ci z czym do ludzi...

Dekoder + Firefox = MASAKRA.+ cieplej w domu

Nie jest tak źle jak się spodziewałem, spodziewałem się pokazu slajdów, a obraz jest w zasadzie płynny (minimalnie spowolniony).
Jakby co testowałem na Firefoksie 7.0.1 na systemie Windows Vista 64-bit na procesorze Intel Core 2 Quad Q6600 2.4 GHz i 4 GB pamięci RAM.

@DonM$:
Teraz to kodeki dobre się robi przy użyciu DXVA (tj. wykorzystując procesor graficzny), przykładami są: systemowy dekoder MPEG-2, systemowy dekoder H.264 (od Windows 7), DivX Plus, ffdshow, systemowy dekoder VC-1, dekoder H.264 Flash Player'a, dekoder WebM Chrome'a.

Spróbuje temu cudu podłożyć 1080p...

H.264 to kolejne własnościowe dziadostwo i kolejny przykład na to, że jak się chce to można.

Apple i ms zapiera sie przy faworyzowanych przez siebie formatach, w czasie gdy w browserach Open Source odtwarzanie wszystkich formatów powoli staje się możliwe.

Paradoksalnie, produkty (czyli przeglądarki internetowe) za które pośrednio się płaci (cena wliczona w zakup systemu operacyjnego) są mniej funkcjonalne od kompletnie darmowych i otwartych odpowiedników.

Ciekawi mnie co kieruje użytkowników faworyzujących odpłatne oprogramowanie? Chyba za tym wszystkim przemawia przyzwyczajenie i uzależnienie. Nic więcej. Nie uwierzę, że ktoś wybrał msie czy safari ze względu na prędkość ładowania stron, wygodę czy funkcjonalność.

@TheBlackMan
Po to, żeby np. nie trzeba było korzystać z zewnętrznych kodeków. A pisanie bzdur o wydajności języków świadczy jedynie o tym, że nie masz bladego pojęcia jak działają współczesne interpretery JS (a wydawało się, że Java ostatecznie takie mity rozwiała, ale zdaje się, że przy każdym języku będzie trzeba tę uświadamiającą batalię toczyć od nowa).

@GL1zdA

[[[Po to, żeby np. nie trzeba było korzystać z zewnętrznych kodeków. A pisanie bzdur o wydajności języków świadczy jedynie o tym, że ]]]

Widzę że kolega nie ma zielonego pojęcia o czym pisze.
Szczerze rozumiem twoją chęć "pojechania po mnie" , ale ci nie wyszło i paploczesz farmazony kompletnie bez sensu. Może wyjaśnię tutaj szczegółowo, dlaczego napisałeś kompletne bzdury:

Są obecnie 3 poziomy języków.

POZIOM III. Języki skryptowe, interpretowalne (najwyższy poziom) [PHP, Javascript, Python, BASH, *.CMD) - języki, które wymagają innego programu do uruchomienia kodu.
Program taki musi najpierw się uruchomić, zinterpretować kod, a następnie go wykonać za pomocą własnych procedur. Przy każdym uruchomieniu kod jest najpierw interpretowany, a potem wykonywany - dlatego to jest najwolniesza opcja.

POZIOM II. Języki poziomu (średni poziom) [Java, C#] - kompilowane do szybkiego kodu pośredniego (odczytywalnego tylko przez maszynę), który jest uruchamiany przez maszynę wirtualną - wykonuje się o rzędy wielkości szybciej niż kod interpretowalny najwyższego poziomu (POZIOM III), ale nadal dużo wolniej niż kod najniższego poziomu. Kod może być też skompilowany do kodu maszynowego produkowanego przez języki niskiego poziomu (POZIOM I), ale do aplikacji trzeba też wkompilować maszynę wirtualną, co powoduje zwiększone użycie pamięci i procesora, przez co języki tego poziomu są mniej wydajne od języków poziomu I.

POZIOM I. Języki kompilowane do kodu maszynowego [C, C++, Pascal, Delphi, Visual Basic (ale nie VB.NET)]. Języki, które trzeba najpierw skompilować do właściwego kodu maszynowego aby były wykonywane przez procesor/system operacyjny. Skompilowany kod jest wykonywany BEZPOŚREDNIO przez procesor, dlatego też ta opcja jest najszybsza.

POZIOM 0. Assembler. Kod najniższego możliwego poziomu, zapisywany bezpośrednio jako instrukcje procesora (kod maszynowy). Zalety takie, że jest zdecydowanie najszybszy ze wszystkiego co może być, wady takie że niesamowicie trudny do opanowania i nieczytelny.
.
.
[[[nie masz bladego pojęcia jak działają współczesne interpretery JS (a wydawało się, że Java ostatecznie takie mity rozwiała, ale zdaje się, że przy każdym języku będzie trzeba tę uświadamiającą batalię toczyć od nowa).]]]

Hmmm...
http://en.wikipedia.org/wiki/JavaScript

{{{Java is loaded from compiled bytecode; JavaScript is loaded as human-readable source code. Java's objects are class-based; JavaScript's are prototype-based. JavaScript also has many functional features based on the Scheme language.
[edit] }}}

Coś mi się zdaje że to ty nie masz pojęcia.

CZYSTY Javascript nie będzie NIGDY nawet zbliżony szybkością do kodu maszynowego.

@TheBlackMan
Teoretyczna prędkość, a prawdziwa jest czymś zupełnie inny. Nie można zakładać, że prędkość zależy tylko i wyłącznie od języka programowania, a dokładniej sposobu jego interpretacji.
Aplikacja w C++ skompilowana przez nowoczesny kompilator będzie tak mocno zoptymalizowana, że zapewne przerośnie prędkością większość podobnych aplikacji w asemblerze, ponieważ nie ma możliwości aby człowiek dokonywał takich aplikacji.
Paradoksalnie im język jest wyższego "poziomu" tym łatwiej go zoptymalizować.
Trzeba też założyć, że wiele współczesnym interpretatorów dokonuję konwersji kodu bajtowego/pośredniego w kod binarny wykonywany bezpośrednio przez procesor. Tym samym jedyną stratą będzie czas uruchomienia, jednak już czas samego wykonania operacji może okazać się szybszy.
Niestety wiele teorii co do wydajności ludzie opierają patrząc na np. źle napisane programy. I np. przez takiego Minecraft'a większość będzie przekonana, że wydajność jest tylko i wyłącznie winą Javy, a nie programisty (w końcu z dodatkiem OptiFog gra nagle działa normalnie).

JavaScript jest natomiast wolna, bo nie była przeznaczona do takich zadań jak dekodowanie materiałów wideo/audio i nikt nie zastanawiał się nad tworzeniem takich optymalizacji jak to się robi w np. Javie czy Pythonie. Co nie znaczy, że będzie wolna wiecznie, wystarczy przepisać interpretator i już ;)

Zapomniałeś o językach czwartej generacji http://pl.wikipedia.org/wiki/4GL i czystym kodzie bitowym, który stosunkowo niedawno jeszcze niektórzy czytali (nadal czytają?).

@

[[[czystym kodzie bitowym, który stosunkowo niedawno jeszcze niektórzy czytali (nadal czytają?).]]]

Masz na myśli kod maszynowy chyba.

Faktycznie, pominąłem go. Ale celowo, bo to nie do końca można nazwać "językiem programowania". To jest raczej język instrukcji procesora.

ERRATA:

Oczywiście powyższa wypowiedź była skierowana do @Druedain

@TheBlackMan
Bardzo ładnie przypomniałeś czego kiedyś cię nauczyli, ale to była teoria. Tylko poczytaj sobie chociażby o JIT. To co powtarzasz jest prawdą dla najbardziej prymitywnych interpreterów. Nie żyjemy jednak w latach 70-tych - sprawdź sobie jak działa JagerMonkey w silniku JS Firefoxa czy dowolny inny współczesny interpreter.

"CZYSTY Javascript nie będzie NIGDY nawet zbliżony szybkością do kodu maszynowego."
Jak widać są już benchmarki, w których googlowy V8 potrafi pokonać g++:
http://shootout.alioth.debian.org/u64/benchmark.php?test=all&lang=gpp&la...
W połowie pozostałych jest to ten sam rząd wielkości, więc rokowania na przyszłość są bardzo pozytywne.

@GL1zdA

[[[Jak widać są już benchmarki, w których googlowy V8 potrafi pokonać g++:
http://shootout.alioth.debian.org/u64/benchmark.php?test=all&lang=gpp&la...
W połowie pozostałych jest to ten sam rząd wielkości, więc rokowania na przyszłość są bardzo pozytywne.]]]

Ten benchmark powyżej dowodzi jednej z trzech rzeczy:

a) Kod wykorzystany do benchmarku Javascript jest napisany specjalnie tak, aby pod Javascriptem wykonywał się szybciej niż pod którymkolwiek z innych jęzków.

b) Kod wykozystany do benchmarku G++ jest po prostu tragiczno-badziewnie napisany albo nie wykorzystuje odpowiednio możliwości sprzętu.

c) Silnik Javascriptu wykorzystuje przy algorytmie jakieś dodatkowe możliwości sprzętu (co jest zaimplementowane sprzętowo na poziomie - ekhm - KODU MASZYNOWEGO) , których nie wykorzystuje G++, bo użyty w nim kod nie został do tego przystosowany.

Ogólnie z definicji nie ma takiej FIZYCZNEJ MOŻLIWOŚCI aby kod interpretowalny działał na tych samych poziomach prędkości co kod uruchamiany na procesorze !!

Jest to logicznie sprzeczne, gdyż kod interpretowalny musi zostać przed uruchomieniem skompilowany do kodu pośredniego (bytecode) [co zajmuje dodatkowe zasoby], który dodatkowo jest zwyczajnie wolniejszy od maszynowego.

@GL1zdA

W PHP też jest ogromna liczba funkcji i struktur (takich jak strpos(), in_array(), md5() etc), które działają na poziomach prędkości porównywalnych z kodem maszynowym.
Z tym że one są zaimplementowane w kodzie maszynowym PHP lub rozszerzeń PHP i zwyczajnie korzystają z kodu maszynowego.

Różnica jest taka, iż te funkcje są zaimplementowane na znacznie niższym poziomie, a nie w samym PHP.

Jeżeli napisać funkcję strpos() w CZYSTYM PHP, nie używając funkcji wbudowanej, to będzie ona spokojnie tak 100 x wolniejsza od funkcji wbudowanej lub kodu maszynowego.

@TheBlackMan:
Nowoczesne silniki JavaScript (jak V8 z Google Chrome) kompilują skrypt do kodu natywnego, a potem uruchamiają bezpośrednio na procesorze.

@przemek1234

[[[@TheBlackMan:
Nowoczesne silniki JavaScript (jak V8 z Google Chrome) kompilują skrypt do kodu natywnego, a potem uruchamiają bezpośrednio na procesorze.]]]

[potrzebne źródło]

Chyba ci chodziło o bytecode podobny do bytecode'u znanego Javy, a nie kod natywny. Też słyszałem że nowoczesne silniki mają maszynę wirtualną podobnie jak JAVA i też kompilują kod do kodu pośredniego. Ale to jest kod pośredni, a nie natywny kod maszynowy.

Kod natywny to może ci wygenerować najwyżej pełnoprawny kompilator. Poza tym to kompilacja średnio skomplikowanego programu trwa dość długo, strony ładowały by się 30 sekund, a nie 0,3 sekundy gdyby było tak jak mówisz.

@przemek1234

Sprawdziłem na szybko i wygląda że miałem rację:

http://www.google.com/search?q=javascript+to+native+code&ie=utf-8&oe=utf...

To o czym mówiłeś to jest POZIOM II (kod pośredni), a nie POZIOM I (kod maszynowy).

@TheBlackMan:
http://en.wikipedia.org/wiki/V8_(JavaScript_engine)
"V8 increases performance by compiling JavaScript to native machine code before executing it, rather than to execute bytecode or interpreting it. Further performance increases are achieved by employing optimization techniques such as inline caching. With these features, JavaScript applications running within V8 are said to have an effective speed comparable to a compiled binary." - w skrócie pisze o tym, że są kompilowane przed uruchomieniem do natywnego kodu maszynowego i wraz ze stosowanymi optymalizacjami daje to szybkość porównywalną do natywnych aplikacji. Od siebie dodam, że V8 był najprawdopodobniej pierwszym silnikiem JS w masowym obrocie, który tak robił. Jest on używany przez przeglądarkę Google Chrome, wersję Open Source tej przeglądarki, czyli Chromium, a także przez wbudowaną przeglądarkę Androida. Aczkolwiek myślę, że inni twórcy mogli też to już powprowadzać co niektórzy.

@przemek1234

[[[V8 increases performance by compiling JavaScript to native machine code before executing it, rather than to execute bytecode or interpreting it. Further performance increases are achieved by employing optimization techniques such as inline caching. With these features, JavaScript applications running within V8 are said to have an effective speed comparable to a compiled binary."]]]

O, wiedziałem że wyciągniesz ten artykuł, bo właśnie sam go znalazłem.

Niestety, nie jest to prawda, a artykuł na wikipedii jest błędny.

stackoverflow.com/questions/1152367/how-to-turn-the-v8-compiled-javascript-into-an-exe
stackoverflow.com/questions/2962210/compile-javascript-to-native-code-with-v8


{{{JavaScript can't be completely compiled as it's a dynamic language. With V8, it's JIT-compiled (like .NET, for example.) It's still possible to turn it into a stand-alone executable though (like .NET, for example.)

If you want to develop stand-alone applications that make use of HTML for rendering, you could have a look at Adobe Air as well.}}}

{{{Javascript cannot be compiled just once. The language has eval() which is pretty widely used. (for JSON for instance) You need to carry around the JIT, and the whole runtime.

JIT here is only an optimization, not the way to get rid of the compiler/interpreter.
}}}

W skrócie: Nie można skompilować Javascriptu do *.EXE / pliku wykonywalnego.

Jest tak dlatego, bo jest to język dynamiczny, który stale się zmienia i jeden kod generuje drugi kod za pomocą funkcji eval().

Dlatego też nie jest możliwe wykonanie ahead-of-time-compilation

en.wikipedia.org/wiki/AOT_compiler

i pozbycie się kompilatora, jedyne co robi V8 to just-in-time compilation (JIT)

en.wikipedia.org/wiki/Just-in-time_compilation

do kodu pośredniego, tak jak Java.

W jeszcze większym skrócie: Kod jest niby natywny, ale nadal potrzebna jest maszyna wirtualna do wykonania go, czyli wcale nie jest natywny, tylko to taka mała ściema.

Postaram się poprawić artykuł na wikipedii w najbliższym czasie.

@przemek1234

No dobra, przyznam że sprawa jest zagmatwana jak cholera, ale znalazłem wiarygodne źródło na stronach Google'a.

code.google.com/intl/pl/apis/v8/design.html#mach_code

Wygląda że V8 jednak kompiluje do kodu natywnego, ale mimo tego jest potrzebna maszyna wirtualna. Czyli jest to coś pomiędzy POZIOM II (Java) a POZIOM I (C++).

W momencie gdy kod natywny jest dynamiczny i nie może zostać wykonany, przywoływana jest maszyna wirtualna wykonująca dynamiczne części. Tak to rozumiem.

Ale google namieszał.

{{{V8 compiles JavaScript source code directly into machine code when it is first executed. There are no intermediate byte codes, no interpreter. Property access is handled by inline cache code that may be patched with other machine instructions as V8 executes.

During initial execution of the code for accessing a property of a given object, V8 determines the object's current hidden class. V8 optimizes property access by predicting that this class will also be used for all future objects accessed in the same section of code and uses the information in the class to patch the inline cache code to use the hidden class. If V8 has predicted correctly the property's value is assigned (or fetched) in a single operation. If the prediction is incorrect, V8 patches the code to remove the optimisation.}}}

{{{If the object's hidden class does not match the cached hidden class, execution jumps to the V8 runtime system that handles inline cache misses and patches the inline cache code. If there is a match, which is the common case, the value of the x property is simply retrieved.}}}

No dobra. Jest dekoder h.264 w JS. A ja się pytam jak jest z licencją i patentami? Czy jeżeli dam ten dekoder na stronke to nie musze placic haraczu?

Marudzicie, cytujecie Wikipedię a tak naprawdę jeśli to będzie działało dość szybko, to pewnie się przyjmie i większość ludzi się ucieszy, że im filmiki pójdą :]

@TheBlackMan
"V8 optimizes property access by predicting that this class will also be used for all future objects accessed in the same section of code and uses the information in the class to patch the inline cache code to use the hidden class. If V8 has predicted correctly the property's value is assigned (or fetched) in a single operation. If the prediction is incorrect, V8 patches the code to remove the optimisation."

To jest właśnie JIT o którym mówiłem... Więc jednak jest
"FIZYCZNA MOŻLIWOŚCI aby kod interpretowalny działał na tych samych poziomach prędkości co kod uruchamiany na procesorze !! "

Czyli podsumowując: teoria teorią, a w praktyce widać wszystko da się zrobić. Czekać jeszcze tylko na dekoder działający na GPU.

A fakt faktem, kiedyś wraz z kolegami pracowaliśmy nad projektem, którego celem było porównanie szybkości działania PHP, Javy paru innych języków. Analiza pokazała, że Java (Poziom II) i PHP (Poziom III) w praktyce nie różniły się rzędem wielkości, a wręcz często były bardzo zbliżone.

@seiya
Od dawna H.264 jest akcelerowany na GPU...

GL1zdA,
To w takim razie o co biega z tym: "Nadal jednak dekoder bardzo obciąża procesor..."? (to z newsa)

@seiya
OK, nie załapałem, że mówisz od tym JSowym. Co do akceleracji z JSa, to może być podobny problem ja z WebGL - bezpieczeństwo.

@GL1zdA

[[[To jest właśnie JIT o którym mówiłem... Więc jednak jest
"FIZYCZNA MOŻLIWOŚCI aby kod interpretowalny działał na tych samych poziomach prędkości co kod uruchamiany na procesorze !! " ]]]

No ale to nie jest czyste JIT, tylko taki MIX natywnego kompilera oraz JIT-kompilera.

Czyli zawsze to będzie wymagać do uruchomienia maszyny wirtualnej, czyli nie będzie nigdy działać na poziomach prędkości czystego C/C++.

Chociaż może być szybsze od Javy w niektórych rzeczach, a już na pewno będzie szybsze od zwykłego interpretera JS.

@TheBlackMan: Błędnie zakładasz, że ludzie odpowiedzialni za V8 nie są w stanie na podstawie analizy statycznej kodu określić, czy całość można skompilować, czy też nie. Jeśli kod nie wymaga ewaluacji stringów, nie jest konieczny trzymanie wersji pośredniej. Jeśli nie korzysta z refleksji i introspekcji, można wyciąć sporą część tłuszczu dookoła typów. Jeśli silnik jest wystarczająco sprytny i podobnie do CLR wykonuje boksowanie typów, to koszt większości operacji jest równy analogicznemu kodowi wykonanemu w C. Co więcej, jeśli wersja kodu w C wykonuje sporo naiwnych alokacji, to język z zarządzaniem pamięcią i dobrze zoptymalizowanymi natywnymi strukturami danych może się okazać wydajniejszy (bo to, czego używasz, już ktoś zoptymalizował).

V8 wysypuje w konsoli przy próbie uruchomienia tego na Chrome, że XMLHttpRequest może być tylko przez HTTP,a nie do lokalnego pliku i na tym kończy, spróbuje to dać na serwer.

Postawiłem lokalny serwer i wtedy Chrome to otworzył i demo Mozilla było w zasadzie płynne, spokojnie film dałoby się z taka płynnością oglądać film.

@Ryan (redakcja)

[[[@TheBlackMan: Błędnie zakładasz, że ludzie odpowiedzialni za V8 nie są w stanie na podstawie analizy statycznej kodu określić, czy całość można skompilować, czy też nie. Jeśli kod nie wymaga ewaluacji stringów, nie jest konieczny trzymanie wersji pośredniej]]]

Eeeee.... gdzie tak napisałem ?

Nie zrozumieliśmy się. Właśnie że zakładam że na podstawie analizy kodu z łatwością mogą określić czy kod będzie dynamiczny czy nie.

Wystarczy sprawdzić czy są jakieś evale() czy jakieś inne dynamiczne wynalazki.

[[[Jeśli silnik jest wystarczająco sprytny i podobnie do CLR wykonuje boksowanie typów, to koszt większości operacji jest równy analogicznemu kodowi wykonanemu w C. Co więcej, jeśli wersja kodu w C wykonuje sporo naiwnych alokacji, to język z zarządzaniem pamięcią i dobrze zoptymalizowanymi natywnymi strukturami danych może się okazać wydajniejszy (bo to, czego używasz, już ktoś zoptymalizował).]]]

Całkowicie sie zgadzam, ale faktem jest iż na dzień dzisiejszy kod V8 wymaga do uruchomienia maszyny wirtualnej.
Tak więc kod wymagający maszyny wirtualnej nigdy nie będzie szybszy od kodu nie wymagającego takiej maszyny. Jednak ze względu na to, że JavaScript używa oprócz eval()-ów dynamicznej typizacji, to nie będzie takie proste napisanie klasycznego kompilatora, który zniwelowałby potrzebę posiadania maszyny wirtualnej lub/ii interpretatora.

Sprawa jest podobna jak z JAVą - wszyscy "Javovcy" twierdzą, iż w TEORII da się w Javie napisać program, który będzie tak samo szybki jak kod binarny.

Jednakże w PRAKTYCE to jeszcze nie widziałem programu napisanego w Javie, który by nie "zamulał". Od teorii do praktyki jeszcze daleka droga, no chyba że specjaliści z Google całkowicie wyeleminują maszynę wirtualną z równania. Zobaczymy jak to się rozwinie.

Słowo "nigdy" jest tutaj całkowicie nie na miejscu, bo nie ma reguły mówiącej, że kod uruchamiany przez maszynę wirtualną musi być wolniejszy. W szczególności może być szybszy w przypadku, o którym pisałem - istnienie dobrze zoptymalizowanych struktur danych i wydajnego alokatora jako części języka interpretowanego. Jasne, mówimy tutaj o potencjalnym, szczątkowym zysku w przypadkach brzegowych, ale właśnie to testują wszelkiej maści syntetyczne benchmarki. ;S

Zamulanie Javy wynika w znacznej mierze z konstrukcji języka i (na Windowsie przynajmniej) jakości środowiska uruchomieniowego. Brak jednolitej hierarchii typów w Javie oraz organizacja języka pośredniego sprawiają, że ciężko jest wspiąć się na wyżyny wydajności. Ogólnie też języki interpretowane mają problemy w nowoczesnym, wielowątkowym kodem, głównie z uwagi na globalny lock interpretera (*kaszl* Python *kaszl*) albo narzut synchronizacji interpretera wielowątkowego.

@Ryan (redakcja)

[[[Słowo "nigdy" jest tutaj całkowicie nie na miejscu, bo nie ma reguły mówiącej, że kod uruchamiany przez maszynę wirtualną musi być wolniejszy]]]

No w sumie to masz rację, "nigdy" jest może zbyt mocnym słowem, ale spokojnie może powiedzieć iż istnieje niskie prawdopodobieństwo iż ten sam kod będzie działał z podobną prędkością na V8 i w czystym C/C++.

Właściwie o to tutaj się cała dyskusja rozchodzi, że użyłem za mocnego słowa, prawda ?

[[[Zamulanie Javy wynika w znacznej mierze z konstrukcji języka i (na Windowsie przynajmniej) jakości środowiska uruchomieniowego. Brak jednolitej hierarchii typów w Javie oraz organizacja języka pośredniego sprawiają, że ciężko jest wspiąć się na wyżyny wydajności. ]]]

Czy ja wiem... .NET zamula całkiem podobnie, ale jest trochę bardziej responsywny.

Działanie .NETa opiera się na tej samej koncepcji co JAVA z resztą. W końcu Microsoft wyprodukował .NETa po tym jak bodajże przegrał proces o użycie swojej (zerżniętej od suna) maszyny wirtualnej Javy w windzie.

Tak, o moc słowa zasadniczo chodzi. A z .NET to jest trochę inaczej, niż piszesz. Diabeł tkwi w szczegółach. ;) Sposób działania typów w CLR, w przeciwieństwie do JRE, sprawia, że typy mapowane wprost do wspieranych przez sprzęt (inty, floaty, tego typu rzeczy) są jako takie traktowane, póki nie dokonasz boksowania na Object. JRE nie wspiera boksowania typów (a przynajmniej nie wspierał, jak ostatnio sprawdzałem). Responsywność jako słowo też niewiele w tej dyskusji znaczy, bo nie wiem o jaką responsywność Ci chodzi. Czas zimnego startu? No, zasysa, bo ładują się asemble. Ale i tak jest lepszy niż Javy bez JQS. ;)

A kwestia RE Microsoftu podobna była do obecnej "Androidowej": w imię iluzorycznej przenośności Sun/Oracle pluje się o brzegowe przypadki różnic w implementacji. Ofcoz w przypadku Microsoftu Teh Internetz twierdziło, że to złośliwe działanie mające na celu zniszczenie Javy. W przypadku Google z kolei mamy do czynienia z biciem dziecka, bo przecież Google wszystko robi w ramach misji czynienia dobra. ;>

pierdu pierdu...
widac ze ktos czegos tutaj nie kmini...
C++, Assembler... ? LOOOL

przecie to ma omijac patent, a nie go lamac i wlaczajac go do aplikacji...

@Ryan (redakcja)

[[[A z .NET to jest trochę inaczej, niż piszesz. Diabeł tkwi w szczegółach. ;) Sposób działania typów w CLR, w przeciwieństwie do JRE, sprawia, że typy mapowane wprost do wspieranych przez sprzęt (inty, floaty, tego typu rzeczy) są jako takie traktowane, póki nie dokonasz boksowania na Object.]]]

Dla mnie ważny jest fakt posiadania przez .NET maszyny wirtualnej.
Maszyna wirtualna = dodatkowe obciążenie. Dodatkowe obciążenie = mniejsza prędkość i większe wymagania co do zasobów aplikacji.
Choć to i tak dużo lepsze niż jakikolwiek język skryptowy.
.
.
[[[JRE nie wspiera boksowania typów (a przynajmniej nie wspierał, jak ostatnio sprawdzałem).]]]

Jak się domyślam, "Boksowanie typów" to pewnie coś w stylu twardej typizacji, ale generowanej dynamicznie ?
Nie orientuję się akurat dokładnie w takich szczegółach dotyczących .NET-u.
.
.
[[[Responsywność jako słowo też niewiele w tej dyskusji znaczy, bo nie wiem o jaką responsywność Ci chodzi. Czas zimnego startu? No, zasysa, bo ładują się asemble. Ale i tak jest lepszy niż Javy bez JQS. ;) ]]]

Nie tylko czas zimnego startu. Chodzi mi o responsywność interfejsu (czasu w milisekundach jaki trzeba czekać aż będzie można kliknąć następną zakładkę) aplikacji .NETowych w stosunku do natywnych aplikacji C/C++ łączonych z natywnymi bibliotekami też obsysa.
Chociaż przyznaję, że i tak jest dużo lepsza od Javy. Tyle że przyczyną tutaj może być cholernie dobra integracja z systemem (w końcu producent systemu oraz producent .NETa to ta sama organizacja).

Dodam że tak - jestem w stanie wyczuć zamulanie interfejsu co do kilku setnych sekundy przy kliknięciach kolejnych przycisków. Takie małe zboczenie.
Przy komputerze siedzę już ponad 14 lat, więc pewnie wyewoluowałem w tym kierunku i mam inaczej okablowany mózg niż "normalny" człowiek :D