Názory k článku MAC OS X je taky unix (3): Dědictví NeXTStepu
-
petr neptun (neregistrovaný)nejak nechapu, k cemu je dobre, kdyz je jazyk ciste objektovy ... resp jediny takovy jazyk, ktery jsem dosud poznal, je smalltalk a nenasel jsem u nej zatim zadnou vyhodu treba oproti jave. naopak - vzhledem k tomu, ze jsou promenne netypovane funguje prapodivne code-completion, coz je pro me dost zasadni nevyhoda, dale se mi ani pramalo nelibi reseni ridicich struktur tim, ze podminka je objekt typu boolean s metodami ifTrue,ifFalse atd a cyklu pres metodu do: objektu typu collection - to je podle meho nazoru naprosto silene reseni, ktere nic neprinasi krome zmateni neznaleho programatora :) -ja uz sem si na to pomalu zvykl (bohuzel) ale porad v tom nejak nenachazim tu krasu - spis me to otravuje :D
-
Adam Šindelář (neregistrovaný)Nejsem sice dostatetečně znalý Objective C abych mohl vést debatu v rovině specificky tohoto jazyka, ale obecně objektovost jazyka chápu jako ohromné plus. Stačí se podívat o kolik jednodušší je vývoj aplikací pro objektově založené knihovny jako Cocoa, KDE nebo .NET... A to nemluvím o přehlednosti a čistotě kódu. Nakolik je zrovna Objective C správně navrženo nejsem erudován posoudit, ale věřím že když přežilo z dob NeXTStepu a dnes je nejpoužívanějším jazykem na Mac OS X (přestože kdokoliv může zrovna tak dobře použít C++ a Carbon aby dosáhnul stejných výsledků) nejspíš bude mít své přednosti :)
-
paskma (neregistrovaný)ObjectiveC je opravdu velmi, velmi silný nástroj. Je to síla Smalltalku s rychlostí céčka. Co vím, tak doplňování kódu tam funguje dobře, protože ObjC má interfejsy atd. Ale pořád můžeš jakémukoliv objektu poslat jakoukoliv zprávu. Je to perfektní objektová nadstavba nad čistým céčkem (čili primitivní typy tam normálně jsou).
Doporučuji články Ondřeje Čady ve starých Chipech, případně jeho slavnou hádku s prof. Miroslavam Viriusem (Java vs ObjC vs C++) -
Objective C rozhodne neni "ciste objektovy". Je to vlastne "jen" nadstavba C (v podstate se da implementovat jen preprocesorem + knihovny). Ale jsou tam objekty tak, jak by mely byt, zadne zhuverilosti jako "nevirtualni" a "virtualni" metody (fujtajxl).
A code-completion funguje velice dobre, vlastne v ProjectBuilderu jsem se s nim setkal vubec poprve. -
No, to máte těžké. Pokud tu krásu nedokážete najít, asi na ni nemáte buňky. To už tak bývá, že každému svědčí něco jiného a že není programovací jazyk ten, aby se zavděčil lidem všem.
Krása Smalltalkovských metod Boolean>>ifTrue: a Boolean>>ifFalse: je v tom, jak eliminují potřeu řídicích struktur a převádějí ji na jednotný mechanismus volání metod. Pokud si člověk uvědomí, jak vlastně ifTrue: a ifFalse: pracují, dojde mu, že si může dělat vlastní řídicí struktury, které jsou neodlišitelné od těch standadních. (Máte chuť kupříkladu na ternární logiku? Tak si ji dopřejte! ;-))
Souvisí s tím i zjednodušení jazyka. Jak se píše třeba tady: "A language is at its best when it is simple enough for people to have a deep enough understanding of it to use it to its fullest potential. This means there should be few different concepts to master, even while improving on the functionality of earlier languages. One of the trickiest parts of language design is knowing what features you don't need." Zjišťuji čím dál tím víc, že s těmito názory nejsem ani zdaleka sám (další krásná zmínka ohledně "features stockpiling" je v R5RS).
Takhle by šlo pokračovat dál, třeba metatřídy jsou moc šikovná věc...ale pokud říkáte, že to nedoceníte, asi to opravdu nedoceníte... :-)
-
Ondra NekolaZlatý podporovatelV Tigru. Na apple com je ke stazeni binarka 1.5ky JDK, ale defaultne je i k Tigrovi dodavana 1.4.2. 1.5 pro Panthera neni a velmi pravdepodobne nebude. -
Adam Šindelář (neregistrovaný)Eclipsu neznám, ale XCode umí Javu velice dobře. Nejrychlejší procáky nejsou ani náhodou pomalejší než PCčka... na těch skutečně nejvyšších stupních výkonu (PowerMac G5 vs. nadupané amd64 třeba) je to spíš nastejno, spíš je G5 rychlejší. Přispívá k tomu hlavně krátká pipeline, vektorová jednotka a pár dalších optimalizací. Na druhou stranu jsou powerpc procesory pomalejší při přepočtu float na integer.
Osobně používám G4 na 1.2ghz (tedy starou generaci procesorů na relativně nízké frekvenci) a rozhodně je všechno mnohem rychlejší než na Linuxovém Athlonu XP 2ghz nebo windowsovém Duronu 1.5ghz. A to je G4 už zastaralá a montuje se jenom do notebooků (kvůli nižší spotřebě proudu).
Na druhou stranu je fakt, že OpenGL na Mac OS X (a tedy i většina her) se svým výkonem nemůže měřit s OpenGL nebo DirectX na PC platformách, ale o tom budu mluvit v jednom z dalších dílů článku ;) -
Yenya (neregistrovaný)Mozna by bylo dobre, kdybyste sva tvrzeni podporil treba nejakymi cisly. Ja mam pocit ze iMac za 35kKc se vykonem nemuze ani zdaleka rovnat PCcku za 35kKc, a to ani kdyz do toho PCcka
zapocitam cenu nejakeho monitoru.
Zkouseli jsme na iMacu takovy klasicky fixed-point test
time sh -c 'echo 2^1000000 | bc >/dev/null'
Athlon XP 2500+ 11.7s
Itanium 1400 14.1s
Athlon XP 3000+ 8.9s
Athlon FX-51 7.5s
iMac G4 1.6GHz 3m15.8s
a vubec nemam pocit, ze by ten iMac (kupovany koncem minuleho roku za neco pod 40 tisic) byl nejak vykonnejsi nez muj Athlon FX-51 (kupovany bez monitoru koncem _predminuleho_ roku za neco pod 40 tisic). Uz jen to ze ten iMac ma 256MB pameti a FX-51 ma 1GB. Ale i tak je ten iMac _dost_ zdechly.
Kdyztak uvedte nejake testy, ktere jste provadel, a ze kterych snad nejak uvidite, ze by Mac byl rychlejsi nez srovnatelne drahe PC.
-Yenya -
Adam Šindelář (neregistrovaný)Nevím sice co tenhle test říká o výkonu počítače (chápu to správně tak že mac je 20x pomalejší než ty ostatní počítače?) ale už z výsledků bych tipoval že něco jako výkon interpretru shellových scriptů či něco podobného :)
Podpořit své tvrzení benchmarky bych samozřejmě mohl a na internetu si jich kdokoliv může najít kolik chce. Faktem ale je, že do těhle čísel se dá zabalit ledacos... stejně jako si MS vytvoří studii ukazující pomalost a děravost Linuxu, může si Apple udělat studii ukazující ohromnou rychlost Applu.
Dám příklad:
Dělám hodně grafiky a používám photoshop; na applu mi filtr radial blur (kráuhové rozmazání) reaguje i v nejlepší kvalitě do vteřiny, na PC (Windows XP) se to počítá cca 6 vteřin. (Tedy PC je 6x pomalejší)
Jenže ouha! teď zkusím komprimovat DivX a zatímco na PC pod Linuxem mi mencoder stíhal jeden díl futuramy za 30 minut, tady to trvá skoro hodinu!
Žeby bylo zpracování MPEG4 na Applu pomalejší? Tak proč mi potom kódování H.264 běží 2x rychleji než pod Linuxem na i686?
Tohle se NEDÁ určit a každý podobný benchmark je jenom důvodem k dalšímu flame. Takže používejte si co chcete, mně osobně se zdá práce na macu nejrychlejší a odezva systému nejkratší a to mi vyhovuje. -
Yenya (neregistrovaný)"Vykon interpretu shellovych skriptu"? Ten shell se tam vola jen kvuli tomu, abych mohl do /dev/null presmerovat vysledek toho bc(1) a ne zaroven vysledek time(1). Spis bych tipoval ze u Applu maji nejak divne zkompilovane bc.
Ale jak rikam - uvedte nejake srovnani vykonu vcetne pouziteho hardwaru (nejlepe i s porizovaci cenou). Navic myslim ze zrovna Photoshopove filtry nebo kodovani videa neni uplne smerodatne, protoze to muze byt nejaky rucne vyladeny kod na miru konkretnimu procesoru. Zkuste neco, co si muzu stahnout a beznym zpusobem zkompilovat.
Hmm, vase tvrzeni ze "Přispívá k tomu hlavně krátká pipeline, vektorová jednotka a pár dalších optimalizací." je taky dost divne - Athlon nebo treba Itanium maji taky kratkou pipeline, vektorovou jednotku ma dnes uz kazdy, takze zustavame u tech blize nespecifikovanych "dalsich optimalizaci". WTF?
Ano, samozrejme mate pravo na nazor, ze se Vam na Macu pracuje rychleji nez na (blize nespecifikovanem) PC, ale pokud chcete tvrdit, ze obecny Mac je rychlejsi nez obecny Opteron nebo Itanium ("Nejrychlejší procáky nejsou ani náhodou pomalejší než PCčka..."), mel byste to podporit nejakymi fakty. Jak jsem rikal, rychlost odezvy meho FX-51 (v beznem grafickem prostredi) mi prijde podstatne lepsi nez rychlost odezvy iMacu za priblizne stejnou cenu.
-Yenya -
Yenya (neregistrovaný)> otazkou je, proc?
Protoze puvodni prispevek tvrdil, ze jsou rychlejsi. Podle me nejsou.
> nejlepsi je studovat si TOP500.
Top500 obsahuje masivne paralelni stroje. U tech je temer jedno jaky maji procesor, dulezita je konektivita mezi nimi. Navic Top500 meri v podstate nasobeni obrovskych matic, coz na svem pocitaci opravdu temer nedelam (ani tech mensich - hry nehraju).
Ja jsem mel za to ze diskuse neni o superpocitacich ale o tom, jestli Mac/MacOS je lepsi (rychlejsi?) pracovni stanice nez PC (v mem pripade s Linuxem). A to si myslim ze dost jednoznacne neni (rychlejsi urcite ne, u "lepsi" asi zalezi na jake rozhranije clovek zvykly, resp. ochotny si zvyknout).
-Yenya -
Adam Šindelář (neregistrovaný)Tak v tom případě to řeknu takhle:
Ať už je to HW, nebo Softwarem... Ve věcech které dělám já tj. grafika (Photoshop, Illustrator, Acrobat), nějaká média (střih videa, komprese) a kancelářské věci (MS Office (Ano používám MS Office, kamenujte mně ;) ne vážně, já je musim mít :)) je Macovský noťas nesrovnatelně rychlejší než PC noťas za stejnou cenu.
Do stolních počítačů moc nevidím, protože je nemám rád a nepoužívám, ale za dobrý notebook od Applu jsem dal 27 tisíc, za Acer jsme dali 30 tisíc a přestože má 2x víc paměti a o polovinu lepší frekvenci CPU, stejné aplikace na něm běhají tak pomalu, že na něm členové domácnosti odmítají dělat cokoliv kromě mailu a browsení po webu.
Pokud vám záleží na číslech, násobení matic, nebo testy unixových komponent... prosím. Mně daleko víc vadí mizerný výkon Javy... kromě toho je ale můj low-endový mac rychlý jako blesk. A je mi jedno jestli je to kvůli Velocity Enginu, geniálnímu návrhu XNU, nebo skvrnám na slunci. Hlavně že to funguje :)
P.S s čestnou výjímkou mencoderu... ten je na Mac OS nějak podivně pomalý... řekněte, dělám něco špatně, nebo vážně má být tak pomalý? :) -
Ano. Prinejmensim grabovani z TV karty do lavc kodeku - to je vec u ktere mi ta pomalost dost vadi, protoze mam nastavene filtry aby to v 32b rezimu jelo akorat real-time. Nevim, jestli to plati obecne pro vsechny kodeky, vsechny filtry a po pravde to muze delat i pouze to grabovani ... jestli te to opravdu zajima, muzu to nekdy vyzkouset.
-
nm (neregistrovaný)Rozhodne nejde o moc rozumny test, nicmene jsem to spustil (na pozadi pri cteni tehle diskuse):
[11] aleph:~% time sh -c 'echo 2^1000000 | bc >/dev/null'
sh -c 'echo 2^1000000 | bc >/dev/null' 25,72s user 0,21s system 97% cpu 26,685 total
iBook G3 800MHz, (r.v. 2002 jako uplny lowend) -
Yenya (neregistrovaný)Samozrejme ten nas vysledek na iMacu 1.6GHz je divny, melo by to bezet rychleji, ale je to implicitni bc na implicitni konfiguraci MacOSu. Proc je to pomale se ptejte Applu. Ale kazdopadne je to priklad konkretni veci u ktere mam konkretni opakovane namerene udaje o rychlosti. Uvedte jiny test, chcete-li. Muzeme porovnavat dal.
Nejde mi o to presvedcit puvodniho autora o tom ze on nema pouzivat Mac, jen polemizuji s jeho tvrzenim ze high-end G5 je rychlejsi nez high-end PC, coz je dost velky nesmysl. Hmm, proc asi Apple nepublikuje zadne vysledky na www.spec.org?
-Yenya -
Yenya (neregistrovaný)Ok, odpovim si sam - na spec.org nic neni, ale nasel jsem treba tohle:
http://www.xbitlabs.com/articles/cpu/display/powerpc-g5_18.html
Nevypada to, ze by G5 1.8 GHz byla rychlejsi nez Opteron 148, a to ani priblizne (dokonce neni rychlejsi ani nez 3GHz P4).
-Yenya -
Yenya (neregistrovaný)Jeste k tomuto a k clanku celemu: Ja samozrejme ocenuji jak je MacOS konzistentni ve svem navrhu a v uzivatelskem rozhrani a vubec, Objective-C povazuju za vyborny jazyk (rozhodne lepsi nez C++). HW od Applu vypada pekne na pohled a asi se i dobre pouziva, jen je drazsi nez je obvykle a pritom mene vykonny nez je obvykle. A pak je tady navic naprosto nesympaticka firma Apple ktera vetsinou vyviji ryze proprietarni technologie (QuickTime, iTunes, ...) a je ochotna zalovat kazdeho kdo treba zkusi vyrabet HW kompatibilni s jejich OS nebo dokonce kdo zverejni tyden dopredu fotku jejich noveho produktu, nebo kdo vyrobi ke svemu oblibenemu window manageru theme ktere vypada podobne jako Aqua.
-Yenya -
anonymníTak například celý kernel a vlastně i celý Darwin jsou open source včetně všeho co do nich apple přidal. A to rozhodně nemuseli dělat, BSD licence nic takového nevyžaduje. Navíc Apple podporuje OpenDarwin. Myslím že když pomineme IBM a Sun, kteří sledují vlastní zájmy (a rozhodně nejednají z dobré vůle :)), je Apple jedna z nejvíc open source friendly korporací v Silicon Valley. Navíc si alespoň nevymýšlí vlastní standardy, jejich prohlížeč umí CSS2 (z mých zkušeností mnohem lépe než gecko) a jejich systém je pořádně zdokumentovaný. Nechci tady říkat že je Apple nějaký svatoušek, ale ve srovnání například s MS&spol je Apple samaritán roku. :))
-
Yenya (neregistrovaný)
celý kernel a vlastně i celý Darwin jsou open source včetně všeho co do nich apple přidal.
Opravdu? Ja jsem mel za to ze jejich kernel je FreeBSD portovane na jejich platformu a nad mikrojadro Mach. A ani od tech jejich modifikaci nejsou zdrojaky (ale na druhou stranu, opravy chyb a nektere veci se snazi propagovat zpet k FreeBSD).
Byl jsem jeste upozornen, ze situace neni tak cerna - nektere veci Apple uvolnuje, i kdyz to vyvinuli kompletne oni (treba RendezVous). Ale to je spis dano snahou o to, aby se protokol uchytil a bylo mozne ho pouzit i jinde (treba v sitovych tiskarnach a podobne). Celkove ale porad vidim Apple jako spis zapornou firmu.
Hmm, co s tim bc? Mate-li srovnatelny HW, kde vam 2^1000000 nebezi tri minuty, jakou mate verzi bc? Primo od Applu nebo neco co jste si kompilovali sami?
-Yenya
-
zzen (neregistrovaný)zzen$ time sh -c 'echo 2^1000000 | bc > /dev/null'
real 0m26.383s
user 0m21.313s
sys 0m0.389s
zzen$ sysctl -a | fgrep cpufr
hw.cpufrequency = 999999997
zzen$ w
4:18 up 1 day, 2:16, 2 users, load averages: 0.17 0.20 0.32
G4 1GHz eMac, 2 roky starý, defaultní bc, stejně jako u ostatních předpokládám. OS X 10.4... Ty iMacy v hale jsou skutečně PODIVNě pomalé.
Můj soukromý tip je, že to je tou RAMkou, s 256MB je pomalu s podivem, že to nabootuje. Je tam docela hluk a disky v iMacích jsou docela tiché, takže nemusí být slyšet, že celou dobu testu to nehorázně swapuje...
Druhá možnost je, že to je nějaká zvláštnost na G5, zatím tu byly všechny výsledky z G4, jestli se nepletu... Zkusím získat nějaké z G5 PowerMaca...
At tak či onak je ta diskuze asi zbytečná. PPC/Mac rozhodně není paušálně rychlejší x86/PC, ale ani naopak to nejspíš moc platit nebude. HW je možná trochu pomalejší (ovšem zdaleka ne tak šíleně jak ukazují ty testy), nicméně OS to v praxi často docela dorovná/předhoní. -
S aplem sice nemam zadne zkusenosti. Ale tohle dokazu vysvetlit.
Dlouho jsem pouzival gcc na RS/6000 a musim rict, ze tenhle kompilator generuje
pro PPC velice spatny kod. Bohuzel si stroj s timhle procesorem muze malokdo dovolit, takze se ani nikdo nevenuje optimalizaci kodu pro PPC.
Pokud to bc bylo na Aple kompilovano pomoci gcc, tak ho zkuste zkompilovat necim jinym. Napriklad xlc od IBM muze generovat pro PPC 2x-3x rychlejsi kod. -
Roman (neregistrovaný)porovnani mitu o frekvencich jsem nasel zde
http://pegasos.jinak.cz/clanky/powerpc/ppc_01_historie.html -
Tomas (neregistrovaný)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í.
-
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.
ČLÁNKY DO MAILU