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.
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.
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.
Lenže by sa dalo čakať, že natívne GUI bude optimalizované pre danú platformu, keďže neni zaťažené nutnosťou kompatibility...
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 :)
Z toho, ze je implementovanych 65% win32 api a aplikace funguji a to dokonce rychleji nez na originalnich windows. Kolik bordelu a podprumerneho kodu v tech windows asi bude?
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.
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).