Firefox ve Wine rychlejší než nativně

To je smutné, kde asi udělali soudruzi z Mozilla chybu? Chápu, že Phoenix vznikal původně pro Windows, ale za ty roky bych přece jen čekal optimalizaci. Snad to kluci zlatí vyladí, rozšíření jako Ubiquity dělají z FF dost killer aplikaci.

Asi neexistuje kvalitní konkurence. Uvidíme, co s tím udělá Google Chrome...

nic, je totiz rovnez pro gtk :(

QT je po programátorské stránce lepší, ale GTK je díky Ubuntu a pošramocenému KDE4 rozšířenější. Google to vidí, tak jde do mainstreamu = GTK.

Já bych řekl, že to bude spíš tím, že GTK+ je LGPL, zatímco Qt je (zatím) jen GPL nebo komerční.

Žišmarjá, co má vykreslování JavaScriptu společnýho s GTK? Lidi zamyslete se než začnete něco psát.

GTK neznamená optimalizaci pro Windows. :-P

Neěšel bych hlavu. Blíží se verze 3.1 a ta (já vím, jako vždycky, ale stejnak) slibuje mnohé.
Navíc. No a co? Chodí to, jak to chodí a špatně to nechodí. K čemu řešit, jak to chodí u souseda.

V testu byla pouzita verze Firefoxu pro Windows optimalizovana s pomoci dat z profileru, zatimco na Linuxu nikoli. BTW ani neexistuje zadny duvod proc by "nativni" verze mela byt rychlejsi protoze Wine neni zadny emulator, je to v podstate alternatvni API k Linuxovym knihovnam. Format spouteciho souboru je mirne odlisny na obou platformach ale to ma roli jen v zavadeni aplikace do pameti, potom je provadeny kod uz identicky.

No cekat by se to dalo, ale wine je dost vymakane, pokud uz aplikace ve wine jede, jede nezridka mnohem rychleji nez na windows, nadherne je to videt na klientovi lotus notes v 6.5 ... ktera slapa ve wine podstatne rychleji, nez na windows.

To bude tím, že Wine implementuje 65% Win32 API, a zbytek volání ignoruje. Kupodivu to pak někdy běhá i rychleji, než když Windows ta volání opravdu provádějí všechna :)

Tak soudíte z faktu, že autoři Wine spoustu funkcí API nejsou schopni implementovat?

Vy už to nehulte. Win32 API vrací v případě úspěšného volání nulu, v případě chyby něco jiného. Když Wine něco neimplementujete, stačí mu vrátit volající aplikaci nulu. Pokud aplikace danou funkci nezbytně nepotřebovala k běhu, tak prostě poběží dál. Nejvýš dojde k nějaké návazné chybě tady, nebo tam. A že mají aplikace pod Wine dlouhé řady problémů, to asi není třeba zdůrazňovat.

Samozřejmě když aplikace neprovádí některé věci, které dělala na Windows, mohla by jet rychleji. Jestli rychleji pojede, to je věc implementace Wine. Zpravidla jede pomaleji, ale zato s hromadou chyb. Například ve Windows aplikace používají shodu barev (color management), na což Wine kašle. To pak skoro překvapí, když Wine rychlejší není.

Nic z toho nesvědčí o bordelu a podprumernem kodu ve Windows. Svědčí to jen o tom, že zase jednou nevíte, o čem mluvíte.

A co kompilator? Treba Visual C++ neni takovej sit, jako si uzivatele gcc mysli.

Ja si nemyslim ze VC++ je shit (ani v gcc mailing listu jsem nezaznamenal takovy nazor). Kvalitu kompilatoru sleduji delsi dobu a v testech ktere jsem videl VC++ byl dlouhodobe mezi Intelem a GCC. Postupne se ale rozdil mezi prekladaci zmensuje (vcetne LLVM) protoze vykon zlepsovat nelze donekonecna a u kompilatoru je to po jiste dobe velmi slozite (az si vsichni navzajem vygenerovany kod odkoukaji navzajem a podle toho upravi vlastni kompilaci). Navic VC++ od verze 6.0 udelal velky posun k dodrzovani C++ standardu (coz oceni kazdy kdo vyviji komponenty ktere chce pouzivat treba i za 10 let).

VC++ je naozaj dobra vec, mojich 8 pracovnych hodin travim vo visualku 2005. V niektorych oblastiach by sa gcc malo poucit od MS, napr. velmi dobre maju zmaknute precompiled headers. Akurat ludia co tomu nerozumeju, nadavaju na to (ja som tiez prechadzal z gcc na vc++ a nadaval :D).

Je fakt že z toho důvodu používám radši epiphany, i když má myslím ve f10 pořád jako jádro gecko

Problem je v tom, ze GTK2 je neuveritelne pomale (a co vim, nejde to jiz moc zoptimalizovat - je o tom docela pekny thread nekde na GTK devel listu), spolecne obecne se zobrazovanim v Linuxu - Xka jsou proste pomala. "Dole" se toho bude muset jeste hodne prepsat, nez to bude frcet, jak ma...

Další, co si myslí, že GTK může za všechno?
GTK vykreslí menu a vokno a konec. Javascript, renderování stránky, vše je plně v režii Firefoxu.
To samé Inkscape apod.

Ehm. File-open dialog GTK je neuveritelne pomaly kvuli (alespon co si shruba pamatuji) pollingu vsech souboru a traverzovani filesystemem. Vykresleni menu ve Firefoxu je pomaly opruz nejen kvuli GTK, ale i kvuli XUL, uznavam. Veskere _aktivni_ prvky na strance (selektitka, radiobuttony, atd.) jsou GTK. Pomalost GTK widgetu (zkuste si udelat 100x radiobutton na strance a pomoci JS je nahodne zapinat + vypinat a uvidite) je zpusobena pomalosti Caira, nicmene rozhodnuti delat vse pres Cairo pochazi od vyvojaru GTK.

Takze ano, za vetsinu pomalosti muze GTK + low level.

Mozna bych doplnil, ze prefereuji GTK nad QT (moje uzivatelska zkusenost - proste je mi GTK prijemnejsi, no flame), nicmene je GTK objektivne pomalejsi. Jednim z duvodu pomalosti nekterych veci (a to i u QT) je treba chyba v nVidiackych driverech s X-RENDER extenzi. Bohuzel (mozna i Bohudik ;) v Linuxu vse souvisi se vsim, takze tuning nekterych soucasti je nezbytne nutny pro tuning jinych ...

Tak o tom, že GTK je pomalejší než Qt se nikdo nepře.
Ale o co se pře je, že na rychlost Javascriptu a renderování stránek to opravdu nemá vliv. Až bude stránka s objevujícíme se a mizícími tisíci checkboxy, tak dobrá. Ale jelikož je článek o rychlosti gecka zpracovávat JavaScript, je výtka na GTK opravdu směšná.

No, pomalost JavaScriptu je jedna vec, dle mereni Googlu to zas tak hrozne neni. Co se tyka vypoctu layoutu, to take neni tak hrozne. Co je hrozne je ta posledni mile - tj. naflakani dat do framebufferu - zde do toho vstupuje GTK, Cairo, XFt a X-RENDER. A spolecne z toho delaji pomaly shit. Jakoze ve widlich zvetsuji fonty ve FF opravdu dynamicky (tj. krasne plynule), v Linuxu je to cukatura.

Hmm ja od GTK odesel u verze 1.2.4, tehdy mi zastanci GTK vysvetlovali, ze slozitost GTK je obrovska vyhoda a ze je nesmysl psat GUI framework v C++(jako u QT). "Rucne" udelany objekty pomoci maker preprocesoru jsou prej lepsi a hlavne rychlejsi, protoze kompilator C++ nedodaze vygenerovat lepsi kod nez by to za nej udelal programator.

A k ty mozille, mozilla ma snad nejhorsi coding style ze vsech opensource programu ve kterych jsem se hrabal. (Na opacny strane je u me vede CUPS - abych jen nekritizoval;) Nejdulezitejsi casti XPCOMu jsou napsany v preprocesoru kompilatoru, a skoro kazdy makro zavisi na cilove architekture. V tech makrech je takovej bordel, ze se v tom nikdo nedkaze zorientovat. Je dost dobre mozny ze na wonkach kompiluje cl uplne jinej zdrojak nez to co vidi na linuxu g++.

"Rucne" udelany objekty pomoci maker preprocesoru jsou prej lepsi a hlavne rychlejsi, protoze kompilator C++ nedodaze vygenerovat lepsi kod nez by to za nej udelal programator.

To je mýtus, kompilátor dokáže udělat téměř stejně efektivní kód (ty rozdíly jsou tak malé, že jsou zanedbatelné) a na rozdíl od programátora s daleko menší chybovostí. Navíc ty samé optimalizační finty a hacky, jaké jdou udělat v C, jdou udělat úplně stejně i v C++.

Ano ano, mýtus ... to říkají všichni ... nicméně realita okolního světa je taková, že aplikace jsou rozhodně větší a pomalejší, než když by to člověk v assembleru nabouchal ručně ;-)

Proti assembleru jo, ale ne proti Céčku.

Ano, GTK moze za vsetko. Ked je QT rychle, tak moze byt aj GTK. Nevidim jediny dovod na tvorbu GTK aplikacii okrem historickych.

Vyjma licence Qt :(

To je pěkné, důvod existence GTK tím možná skončí.

Ovšem nebude to jen napůl?
Why would I want to buy a commercial license? What is the difference?
The commercial Qt license includes email support, access to upgrades and allows you to develop fully closed source software. The LGPL carries some restrictions regarding the ability for users to relink libraries and other restrictions that may impose architectural requirements that some organizations might not be comfortable with.

http://www.qtsoftware.com/about/licensing/frequently-asked-questions#what-versions-of-qt

Nevidim jediny dovod na tvorbu GTK aplikacii okrem historickych.

No, krom zminovane licence napriklad kvuli podpore technologii usnadneni.

Problem bude mozno v tom, ze to testovali na Fedore 10. Pouzivam FF 3.0.x v Ubuntu 8.10 a s kolegovym na Fedore sa to neda ani porovnat. A stazuje sa na to uz dost dlhu dobu, aj pri starsich verziach. A ja som zase stastny, ze je FF v GTK a nie Qt, to nemozem ani vystat. Ale to je iba moj nazor. Mozno by stalo za to vyskusat Epiphany s WebKit jadrom.

Tam v te diskusi nekdo pise, ze podobny rozdil nameril i v Ubuntu.

No ja mam FC10 a zadny problem, ale mam samozrejme 64bit, no a diky novemu HW taky na 4 jadru zadne zpomaleni nepozoruji ;-))

Hmm, a nemůže za to nakonec i386 architektura ve spojení s ELF PIC? ELF Position Independent Code, který je používán ve sdílených knihovnách, má takovou ošklivou vlastnost, že dělá odkazy relativně, na rozdíl od windowsího PE, kde jsou absolutní a v případě potřeby při startu přepsané dle tabulky odkazů, což na i386 a PowerPC způsobuje nutnost načítat GOT (Global Offset Table), neboť tyto architektury neumožňují jednoduchý přístup k instruction pointeru, což je extrémně pomalé? ELF tímhle problémem na jiných architekturách (třeba x86-64) netrpí, protože tam se dá adresovat relativně k instruction pointeru a tím se celá tahle šaškárna vypustí.

Ten rozdíl se týká odkazů uvnitř jedné knihovny, nikoliv o odkazy mezi více knihovnami, tam se PE a ELF chovají stejně a musí jít přes relokační tabulky. Jinak to zaprvé není problém formátu, ale architektury a zadruhé to lze obejít přes nedokumentovanou instrukci (de facto push eip), ale je to prasárna a nikdo nezaručuje, že to bude fungovat na všech implementacích x86.

Firefox je na linuxu ultrapomalej a to nepocitam, kdyz tam clovek provozuje este javascript nebo dokonce flash, to se pak neda s naroky na cpu a pamet s windows verzi srovnavat. navic v linuxovem flashi je par neprijemnych bugu napriklad pokud jde o zamrzani pri prehravani videa a alsu... Doufám, že chrome bude rychlejší, případně, že pomůže firefox s JIT javascriptem. pak bych ale doporučoval zapnout ve ff jit i pro chrome, nejen pro web. to ale stále neřeší paměťové nároky při prohlížení velkých stránek, případně hodně tabů...