Trolloscope Who is the best ? - Page 16

Hum ici c'est webkit vs le reste alors Kevin avec tes x86-64 ->poubelle !


Tu as qu'a ouvrir un nouveau tropic.

Voyons voir...

Les procos 32 bits sont obsolètes ©®™ ?

Godzil (./451) :
Hum ici c'est webkit vs le reste alors Kevin avec tes x86-64 ->poubelle !

Ben, WebKit sux parce qu'ils ont un JIT qui ne gère même pas les x86_64.

x8664+linux+firefox+flash=rien, donc poubelle direct.

-> nspluginwrapper

(Mais personnellement, je n'utilise pas du tout ce logiciel propriétaire.)

Kevin Kofler (./453) :

Godzil (./451) :
Hum ici c'est webkit vs le reste alors Kevin avec tes x86-64 ->poubelle !

Ben, WebKit sux parce qu'ils ont un JIT qui ne gère même pas les x86_64.

Et alors ? ça reste le moteur qui est le plus rapide et le plus respectueux des standards, tout en étant un des plus légers... mais bon, ce genre de critère n'a d'importance que quand ils vont dans ton sens...

KHTML est plus rapide. J'ai déjà montré les benchs, pas envie de les chercher à nouveau. Maintenant, ça change avec le JIT, mais comme déjà expliqué, le JIT ne peut pas être exploité dans les binaires x86_64, donc sur mon nouveau PC portable F9 x86_64, il ne changera strictement rien tant qu'il n'est pas compatible 64 bits. Et je signale que le QtWebKit qu'on a actuellement (Qt 4.4) n'a même pas SquirrelFish, Qt 4.5 ne sortira vraisemblablement que l'année prochaine. Va donc utiliser le snapshot du jour de WebKit si ça t'amuse, ici on utilise des releases!

SquirrelFish est en stable avec Safari 3.1.1 si je me souviens bien... Après, si vous préférez utiliser des applications obsolètes, c'est votre problème... (et franchement, je pense que webkit en snapshot est bien plus stable et fini que KDE 4.0 )

On a KDE 4.1.0 dans Fedora 9 maintenant et KDE 4.1.1 sera dans la prochaine publication groupée de mises à jour (probablement dans la semaine qui vient - normalement, les mises à jour sont signées numériquement et publiées 1 ou 2 fois par semaine), KDE 4.0 est obsolète.

Bah oué, mais s'il n'y a pas SquirrelFish, Qt aura toujours des composants obsolètes, que veux-tu que j'y fasse...

Kevin > tiens ça me rappelle le codage des tableaux dans ocaml : ils utilisent 10 bits pour diverses informations et seulement ceux qui restent pour coder la taille du tableau. Du coup sur 32bits la taille des tableaux est limitée à 4M, et des gens s'en sont plaints ; mais pourquoi ont-ils fait ça ? ben parce que ocaml a été développé en 64bits et que la version 32bits n'est qu'un backport, sur lequel ils se sont pas trop fait chier parce que « le 32bits est voué à disparaître de toute façon »
...
ça date d'il y a au moins 15 ans

et quand le 64 bits sera enfin adopté on aura déjà besoin de tableaux de plus de 16 Po ?

Qui sait ce que l'avenir nous réserve...
Mais bon vu qu'à l'heure actuelle il est pas très loin d'être réellement adopté (quasiment tout les OS récents s'ils ne sont pas 64 bits, existent en version 64 bits, tous les processeurs récents gèrent le 64 bits) je pense que la réponse à ta question est non
Et je ne sais pas d'ailleurs si les processeurs 64 bits actuels supportent déjà la totalité de l'espace 64 bits. On a commencé à 48 bits, étendu à 52 bits, qu'en est-il actuellement ?
Sinon pour les histoires de JIT 32 bits: je ne comprends pas l'intérêt de développer deux machines virtuelles 64 et 32 bits séparément sachant que les instructions (à la taille d'opération près) 64 bits sont majoritairement les mêmes que les instructions 32 bits pour l'architecture x86... Il me semble bien plus intéressant de travailler d'abord sur la version 32 bits, ce qui permet par la suite de passer facilement au 64 bits (moyennant quelques légers changements car tout n'est pas pareil non plus), quitte à ne pas directement utiliser réellement les nouvelles fonctionnalités apportées par l'architecture... (Puis ensuite d'optimiser comme il se doit ce qui doit l'être bien entendu)

Kevin Kofler (./457) :
ici on utilise des releases!

Comme KE 4.0.x ?

Bon et puis ça me saoule, second avertissement : Merci de rester sur WebKit et autres navitaguer, exit Qt, KDE & co

MERCI (la prochaine fois c'est un call d'un admin)

Sally (./461) :
ça date d'il y a au moins 15 ans

Bah, je sais que le passage aux 64 bits n'est pas survenu aussi vite que certaines personnes le croyaient (il faut s'y prendre aux fabriquants de processeurs grand public, surtout Intel, mais aussi AMD dans une certaine mesure (même si eux, ils ont compris en premier)), mais là on y est, à part pour les ultraportables (et même là ça va sans doûte changer quand tous les logiciels intéressants seront 64-bit-only - ils ont choisi le x86 pour être compatibles avec les PCs, si tous les logiciels PC seront en x86_64, ils devront s'adapter aussi! L'architecture Atom est déjà capable x86_64, c'est juste désactivé sur les versions pour ultraportables pour des histoires de consommation d'énergie et/ou de stratégie commerciale (pour ne pas vendre aussi bon marché un produit trop puissant), si la demande arrive, Intel pourra facilement la satisfaire), tous les CPUs récents sont capables 64 bits, autant chez Intel que chez AMD. Même les Celerons récents sont capables 64 bits.

Godzil (./464) :
Bon et puis ça me saoule, second avertissement : Merci de rester sur WebKit et autres navitaguer, exit Qt, KDE & co
MERCI (la prochaine fois c'est un call d'un admin)

Vu qu'il s'est écoulé près de 5 heures, je pense que ce n'est pas un cross...

!kick Kevin Kofler
--- Kick : Kevin Kofler kické(e) par vince

http://www.pcinpact.com/actu/news/46149-navigateurs-comparaison-javascript-sunspider.htm?vc=1#vc

D'autres chiffres sur Sunspider :

Firefox 3.1 avec TraceMonkey : 2144 ms
Firefox 3.1 sans TraceMonkey : 3470 ms
Opera 9.60 : 5876 ms
Internet Explorer 8 : 9013 ms
Chrome : 2117 msSafari avec Webkit r36712 : 1817 ms

Finalement, v8 (moteur JS de Chrome) est très bon, mais en lisant la pub de Google je pensais qu'il mettrait vraiment la pâtée aux autres, ça n'a pas l'air d'être le cas.

Erf me suis trompé de topic, je pensais être dans coller votre presse-papier, dsl.

edit: les méfaits de l'alcool

Ah ok

Flanker (./467) :
http://www.pcinpact.com/actu/news/46149-navigateurs-comparaison-javascript-sunspider.htm?vc=1#vc

D'autres chiffres sur Sunspider :

Firefox 3.1 avec TraceMonkey : 2144 ms
Firefox 3.1 sans TraceMonkey : 3470 ms
Opera 9.60 : 5876 ms
Internet Explorer 8 : 9013 ms
Chrome : 2117 msSafari avec Webkit r36712 : 1817 ms

Finalement, v8 (moteur JS de Chrome) est très bon, mais en lisant la pub de Google je pensais qu'il mettrait vraiment la pâtée aux autres, ça n'a pas l'air d'être le cas.

A mon avis le probleme de V8 c'est qu'il a été commencé alors que SquirelFish etait pas encore annoncé/présenté et sachant que SquirelFish est le mainstream de WebKit, utiliser V8 est a mon avis une mauvaise idée.. On verra bien

Mauvaise idée, mais compatible ARM, et je pense que ça compte pour Google

Bah SquirrelFish a aussi interet a l'etre vu que WebKit est utilisé pour l'iPhone qui est en ARM

Webkit passe désormais ACID3 complètement ( http://webkit.org/blog/280/full-pass-of-acid-3/ ), et il a l'air d'être le premier

y'en a qui vont s'envoyer en l'air avec leur souris là

bon faut avouer que le js est effectivement rapide dessus ^^
après ils ont testé sur un macbookpro 2,4GHz, donc j'avoue qu'ils sont loins devant les temps que j'obtiens chez moi sur l'acid3

Voici un bench comparant différents moteurs HTML/JS : http://www.kdedevelopers.org/node/3701

dommage qu'il n'y ait pas les versions nightly qui donneraient un aperçu de ce qu'on va avoir dans quelques semaines / mois (ça dépend des moteurs)

Yep, mais les nightlies ça reste quand même destiné à un public restreint.