Vlákno názorů k článku
MAC OS X je taky unix (3): Dědictví NeXTStepu

Ty články Ondřeje Čady o objective C je možno stáhnout tady http://www.ocs.cz/text/index.html

Velmi zajímavé čtení. Objective C má objekty dotažené dále než v Javě a přitom výsledek je zkompilovaná (=rychlá) binárka. ( Pro nevěřící: opravdu lze jít v objektech dále než v Javě.)

P.S.
PowerPC a Intel processory nelze srovnávat podle frekvence. PowerPC dosahuje stejných výkonů (flops) asi tak na 2/3 frekvenci oproti x86. A ve srovnání AltiVec a MMX/SSE nevychází většinou MMX/SSE jako vítěz.

tj

Mám praktické zkušenosti s obojím a věta

"Velmi zajímavé čtení. Objective C má objekty dotažené dále než v Javě a přitom výsledek je zkompilovaná (=rychlá) binárka. ( Pro nevěřící: opravdu lze jít v objektech dále než v Javě."

je velmi, velmi nepřesná.

Porovnání rychlostí by možná stálo za pokus, overhead zasílání zpráv v Objective C není zanedbatelný a hlavně ho prakticky nelze omezovat. Větší význam než samotný fakt statické kompilace do nativního kódu má (dle mých zkušeností) to, že náročné části kódu se prostě napíší postaru, plain C.

Dále jsou zde věci jako garbage collector nebo bytecode manipulace. Porovnání by asi trochu zabralo víc času. Většina těch rozdílů je dána odlišnou koncepcí a účelem Javy.

Co se týče objektovosti, tak samozřejmě Java není žádný zázrak (a ani nikdy nebyla). Největší rozdíl je absence metod tříd, to opravdu často bolí.

A můžete to nějak doložit? Nevím, kde přesně jsem k té informaci přišel (rozhodně po ní zapátrám znovu!), ale v ObjC by cena message sendu měla být asi jedenapůlnásobkem ceny staického volání funkce. To mi nepřijde až tak nevýhodné...

Omlouvám se za špatné slovo, v tom postu má místo "nedá omezit" být "nedá optimalizovat". Co se týče overheadu, tak ten plyne už z principu funkce a napsal jsem že "není zanedbatelný", což není ani v případě overheadu 50%.

Osobně jsem nikdy neuznával postoje "fuj, to je pomalé" (od "fuj, bytecode interpreter" až po "fuj, virtuální metody" a "fuj, assembler rulez"). Vždy záleží na použití. Některý kód se klidne může interpretovat (zvlášť když se stejně čeká na periferie jako disk, síť či uživatel) a u jiného je každé procento zrychlení znát.

Abych byl trochu konkrétnější (OpenSTEP 4.2, 1999): NSArray a NSDictionary jsou docela pěkné, ale několikrát se mi stalo že jsem si musel na větší zpracování (hlavně při zobrazování) to pěkne vzít do normálního pole normálních struktur a pěkně zpracovat v C. Původní (objektová) varianta na základních pokusných datech byla v pohodě, ale jak se tam pustila radarová data z většího letiště...

Nicméně hlavní pointa toho co jsem napsal je: Výhoda "je to objektové, ale zkompiluje se do binárky, což je rychlejší" je vcelku málo významná. V mnoha situacích to není potřeba, v mnoha to zase nestačí.

"Fuj, assembler rulez" ... tedy, chtel jsem rict ze vlastne souhlasim. "Některý kód se klidne může interpretovat (zvlášť když se stejně čeká na periferie jako disk, síť či uživatel) a u jiného je každé procento zrychlení znát." Proto je pro druhy pripad nejlepsi pouzit assembler. Jazyky, ktere to neumoznuji nebo nejak komplikuji, budou vzdy horsi nez jazyky, ktere to podporuji.

A myslim, ze ve sporu Java x Objective C je tenhle argument na strane objective C ....
... prestoze na druhou stranu samotna kompilace do binarky v dnesni dobe neprinasi prilis velkou vyhodu proti JIT kompilaci hotspotu.