Reprise du message précédent :

 
80% faut y aller quand même...J'attends de voir.

 
c'est juste 5x plus rapide la.

])

Juste

c'est le matin, trop compliqué à calculer.

Le contenu de ce message a été effacé par son auteur

1 - 0,8 = 0,2

http://shootout.alioth.debian.org/ [...] &lang2=gcc
 
C'est largement jouable. Là où ça l'est moins, c'est garder un truc qui ressemble à du PHP et qui soit correctement compilable en C. Mais bon, Python a bien Cython donc pourquoi pas, surtout s'ils laissent tomber la compatibilité binaire/APIs avec PHP.

Related : http://www.korokithakis.net/node/109

ça peut etre sympa
Si c'est x5 sur un bench aprticulier mais rien que x2 dans le cas général , c'est déjà énorme. Et pour peu que ça puisse être intégré de manière transparent ( le site de dev tourne en interpreté, le site de prod est compilé ) je signe tout de suite

Ca me fait marrer quand je pense à tous ces gens qui répètent que les applications web ne sont pas CPU bound  

Elles ne le sont pas. Si tu avais un input aussi important pour des applications de type number crunching, ta puissance necessaire exploserait.
PHP est lent, c'est un fait, mais le travail qu'il a a fournir pour livrer une page web est assez minime, c'est la masse des utilisateurs qui rend l'appli gourmande.

client side pas trop quand meme (sauf flash bien sur mais flash c'est pas du web )

Hello
 
La meilleure solution du moment pour générer à la volée du PDF c'est quoi ? (génération cell by cell ou html->pdf)
 
(ps:en payhashpay bien sur)
merci

 
"quand l'application est utilisée elle est gourmande "
 
Qu'est ce que j'en ai à faire d'optimiser mon site pour 100 hits par jour ?

j'pense que la feinte c'est d'être plus rapide que du C justement

C'est ultra rare que le frontend le soit, quand même. Elles sont quand même bien plus souvent DB-bound (ou JS-bound, quand elles sont très très mal codées) que CPU bound.

si ton pdf est assez simple cell by cell  
sinon html->pdf ( le rendu est parfois un poil moins bon, mais tu vas bcp plus vite )

change de taf pour avoir un site avec du trafic ?

 
A-partir de code php?

C'était une image, je ne travaille (encore) pas dans le web, pour répondre à gizmo.

ah non, pour l'environnement d'exécution, tous les coups sont permis
 
C'est juste le langage source du client qui est PHP.

 
Oui mais c'est bien ce que je dis...il faut qu'ils génèrent du code plus performant que du C une fois compilé à-partir de code PHP...pour moi ça tient du rêve.

 
heu en fait, je voulais savoir, dans les deux cas, si il y avait un outil plébiscité en ce moment (à l'époque je faisait du ezPDF)
FPDF c'est le top ?

Vu qu'ils réécrivent au passage le code PHP du site, chuis pas certain que ça soit 100% compatible avec le runtime PHP existant.

ça me parait quand même méchamment surréaliste cette histoire.

bof, c'est surtout du traitement de chaines PHP, déjà avec un allocateur qui tient la route et une représentation sans le \0 au bout, ça doit commencer à donner.

C'est vrai, mais peut-être que le chiffre donné vaut uniquement pour Facebook. C'est demain qu'ils font leur annonce je crois

y'a des gens qui testent leur javascript ici ? vous utilisez quoi ? comment ?

Petite question :
avec view-source:URL on peut afficher la source de l'url donnée, mais est-il possible aussi de scroller vers une ligne en particulier (càd sans passer par un script) ?
La raison de la chose est un système de gestion d'erreur JS... en JS
Pour l'instant j'ai l'url et la ligne qui a déclenché l'erreur, et un système à la FireBug ou la console Firefox, ca serait tiptop.
Merci d'avance

JSpec

http://github.com/visionmedia/jspec

En hook pre-commit et nightly

interessant c't'affaire
 
c'en est ou des outils de test en js? Celui-ci est "le" standard de fait, ou c'est encore la zone, avec tout le monde qui utilise son propre outil ?

C'est la zone, principalement parce que les mecs veulent réinventer la roue. Du coup, t'as pleins de petits projets qui se ressemblent et qui sont plus ou moins complets.

il serait temps qu'ils se décident un peu qd meme...
celui-ci à l'air plutot complexe, et leur premier exemple me repousse un peu (on dirait un mauvais usage de mocks, ou tu ne fais que tester que l'implementation que tu tests fait effectivement ligne-pour-ligne ce que tu voulais qu'elle fasse) - par contre le coup de pouvoir mocker un appel ajax, c'est classe, évidemment.
 
Vu que t'as l'air plus au courant que Nico et moi, les choses genre Selenium, t'en penses quoi ?

merde, j'ai pas trop envie de leur imposer une nouvelle grammaire là, ils ont encore du mal avec JS et PHP

Tu peux écrire tes tests en pseudo ruby ou en js, pour ce qui est de la grammaire ça s'inspire Rspec.
 
@the real moins moins : Selenium  j'ai jamais eu l'occasion de m'en servir de maniere appronfondie ( surtout dans avec les technos Mozilla ou on utilise d'autres outils plus adaptés ), maintenant y'a pas grand chose d'autres pour les tests fonctionnels x-browsers.
 
Pour ce qui est de l'intégration continue faut surveiller TestSwarm

- interessant si ça peut se combiner avec un hudson local (parce que j'ai ni l'envie ni les moyen d'avoir 14 slaves hudson, 1 pour chaque browser, mais que je veux garder mon hudson comme maître)

je sais pas ou poser la question alors je tente ici : l'arrivée de la video H264 avec le html 5 faciliterait il l'accélération hardware des GPU, accélération qui marche assez mal (en terme de compatibilité) avec ce même H264 en Flash...

j'ai un netbook a base de GMA500 qui decode les doigts ds le nez le 1080 via un Kmplayer ou WMP mais qui rame avec des simple video Youtube en flash.

bah, ça dépendra des browsers au lieu de dépendre du plugin flash, quoi

Voila, mais c'est déjà une bonne avancée quand on regarde l'utilisation du CPU. Flash est vraiment pas adapté pour la video.

mais on ne peux pas imaginer que les browsers se servent d'un moteur de player video ?   ca me parait lourd entre les filtres, codec et réglage de tout gerer en interne non ?

sinon ca va etre mal barré pour les gpu

 
À part le fait qu'ils aient pas d'effort à faire par manque de concurrence, le problème est pas super facile pour flash, et risque d'être difficile aussi pour html5. Flash ou html5 permettent de postprocesser la video (du simple overlay à la convolution + déformation + duplication), devoir supporter ces effets ça coupe facilement des fastpath.
 
Au lieu d'avoir une video entièrement gérée par le GPU, il faut aller la renvoyer coté CPU pour faire le postprocess (qui va peut-être aussi être fait par le GPU à coup d'opengl/glsl/etc..., c'est balot), mais pour peu que les 2 étapes soient gérées par des libs différents ça va être super difficle d'éviter le détour).
 
Bon après ça n'empèche pas qu'ati/nvidia fournissent des API pour faire-faire coté GPU des parties avant le rendu qui sont déjà bien lourdes (mc, idct...) , mais à part du code bien clean qui fait ultra-gaffe pour détecter le cas parfait à chaque étape (clip flash video non transformé, positionné sur une valeur entière de pixel, l'embed qui le contient non-zoomé et sans objet par dessus et sans transparence activée, fenêtre du navigateur elle même en rendu direct), ton flash pourra jamais faire pile aussi bien qu'un lecteur spécialisé, et vu les capacités d'HTML5 ce sera un poil plus simple de faire mieux mais pas complètement.

ha bon? tain.

http://www.dailymotion.com/openvideodemo