Názory k článku
Firefox ve Wine rychlejší než nativně
-
Cartman (neregistrovaný)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.
-
Lael Ophir (neregistrovaný)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. -
Cartman (neregistrovaný)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).
-
jard (neregistrovaný)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).
-
Mr. Zdeeck (neregistrovaný)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...
-
Mr. Zdeeck (neregistrovaný)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. -
Mr. Zdeeck (neregistrovaný)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á. -
Mr. Zdeeck (neregistrovaný)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.
-
ivan (neregistrovaný)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++. -
Sten (neregistrovaný)
"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++.
-
anonymníAssembler nechme stranou. Realita je takova ze framework napsany v C++ je rychlejsi nez framework napsany v CPP a C. Z toho vyplyva ze argument ktery se pouzil pred nekolika lety byl chybny. Na podobnych zakladech je postavena cela mozilla, autori neveri systemovym knihovnam ani kompilatoru a chteji si vsechno implementovat sami. Vysledek takoveho procesu je kupodivu pomalejsi nez WebKit, ktery je napsany v cistem C++.
-
Lael Ophir (neregistrovaný)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 -
krtko (neregistrovaný)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.
-
Sten (neregistrovaný)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í.
-
Sten (neregistrovaný)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ů...
