Vu sur slashdot.fr : http://developers.slashdot.org/story/09/12/20/1433257/The-En(...)
L'idée est de dire : C++ est plus efficace que PHP d'un point de vue performances, donc PHP est une catastrophe en termes de consommation d'énergie côté serveur. Oui, cher lecteur, vous avez compris : ça s'appelle enfoncer une porte ouverte même s'il n'y a pas de rapport avec la choucroute.
Mais plus que le fond, c'est la forme d'un tel article qui est intéressant : pourquoi justifier l'écart de performance quand on peut se contenter de balancer : "assuming a conservative ratio of 10 for the efficiency of C++ versus PHP code" , c'est à dire en assumant un ratio prudent de 10 entre l'efficacité du C++ face à celle du PHP. C'est gratuit, c'est un peu du FUD, c'est surtout un gros troll de bas étage. Même pas discret.
De plus, comment faire du bruit autour de son article un brin générique ? En accusant un site à fort potentiel trollistique, Facebook. Loin de moi l'idée de défendre ou d'accuser, mais pourquoi se restreindre à un seul site qui ne représente qu'une faible partie du traffic internet (même s'il est classé 4ème au monde selon http://www.lepoint.fr/actualites-technologie-internet/2009-0(...) ) D'ailleurs même eux le concède : "it is a bit unfair to isolate Facebook here", c'està dire c'est un peu injuste de mettre Facebook ici en exergue.
Enfin, en termes d'efficacité énergétique, l'idée de se livrer à une démarche globale est maintenant répandue : par exemple, certaines études affirment que les lampes basse consommation ont un impact négatif, car une ampoule à incandescence clasique de 60 W participe aussi au chauffage et que ces 60W manquants font parfois mettre en route le chauffage à Madame Michu qui du coup peut consommer plus. Revenons à nos moutons : quid de l'efficacité énergétique globale ? Temps de développement, consommation des environnements de dev, temps de mise au point... Je n'avancerais aucun chiffre faute de source, mais ce point n'est pas anecdotique : il me semble clair que le cycle de vie d'un logiciel n'est pas le même entre 2 technologies aussi éloignées. Par exemple, le moindre développeur junior fraîchement entré en SSII se sent capable de modifier un site web PHP, mais il faut beaucoup plus d'inconscience pour se jeter dans une modification d'allocation mémoire en C++ :)
En d'autres termes, est-ce quelqu'un oserait poser encore la question : quel est le meilleur langage ?
Bref, voilà un acte gratuit que je dénonce gratuitement. M'enfin !
Journal On n'est pas vendredi et pourtant : impact environnemental de nos langages
21
déc.
2009
# Comme on n'est pas encore vendredi
Posté par yellowiscool . Évalué à 6.
Personnellement, j'aime bien la langue française car c'est celle que je connais depuis que je suis tout petit, mais je ne doute pas que des langues telles que le swahili possèdent elles aussi leurs charmes.
Envoyé depuis mon lapin.
[^] # Re: Comme on n'est pas encore vendredi
Posté par Jérôme Nègre (site web personnel) . Évalué à 5.
[^] # Re: Comme on n'est pas encore vendredi
Posté par Axioplase ıɥs∀ (site web personnel) . Évalué à 2.
>> Personnellement, j'aime bien la langue française
Bien qu'on ne soit pas encore vendredi, je fais le commentaire désobligeant sur l'orthographe du message qui parle d'orthographe ou de langue française.
--->[ ]
# On y était presque
Posté par Brioche4012 (site web personnel) . Évalué à 4.
Pourquoi ne pas poursuivre en tentant de quantifier les temps de développement de PHP et C++ pour une même application? Pourquoi ne pas essayer simplement voire si cela fait une différence?
Le temps de développement d'un facebook est-il négligeable par rapport à son temps d'utilisation?
Tout ça ça se teste, ça se mesure, on peut envoyer un email a droite à gauche et piocher des infos pour finir sur de simples calculs. Dommage que tu n'aie fait qu'importer un troll de Slashdot plutôt que tenter d'y apporter une réponse sérieuse (même en estimant).
[^] # Re: On y était presque
Posté par tom120934 . Évalué à 4.
comme dit dans mon poste, "acte gratuit que je dénonce gratuitement".
Mon propos n'était pas d'aller au fond de la question mais simplement de montrer succinctement pourquoi traiter ainsi une telle question est indigne. Oui tu as raison il faudrait quantifier un certain nombre de choses, et l'on voit tous assez bien les quelles, et du coup ce problème ne peut se traiter avec un tel raccourci aussi facile. Ce troll, je n'ai juste pas eu envie de marcher dedans.
Trouver une solution sérieuse en termes de serveurs/logiciels, qui soit eco-friendly et qui soit capable de passer à grande échelle, c'est un vrai problème compliqué. Techniquement, la réponse n'est pas immédiate : langages, méthodes de dév, méthodes de recette, technologie hardware, équipements en datacenter... De plus le marché / les décideurs ne sont pas prêts à augmenter la facture de réalisation sous prétexte d'économiser "du C02" en prod. Qu'on leur démontre qu'il y a une économie pécuniaire peut être retenu comme critère de choix, mais je n'ai pas entendu parler de réalisations sérieuse de ce type. Sans parler de la contrainte calendaire.
Je n'ai donc pas eu la prétention de trouver à moi tout seul, la réponse correcte :)
[^] # Re: On y était presque
Posté par Rémi baudruche . Évalué à 1.
Je t'encourage à le faire si tu en as l'envie
# Commentaire supprimé
Posté par Anonyme . Évalué à 5.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: La différence principale entre php et c++
Posté par Antoine . Évalué à 6.
Ça m'étonne beaucoup ça. Une barrette de RAM consomme une fraction de ce que consomme un CPU. D'ailleurs si tu regardes bien à l'intérieur de ton PC, le CPU a un gros dissipateur bien lourd avec un ventilateur posé dessus, tandis que la RAM n'a strictement rien sur elle ;-)
le code n'est pas considéré comme du code par l'os mais des données => tu lances 2 fois la même applic et pouf pas de segments partagés
C'est faux ça. Les OS modernes (Linux) font du COW (copy-on-write) lorsqu'on forke un processus, du coup les données qui ne changent pas sont partagées de facto.
(évidemment si tu lances des processus individuels au lieu de forker, ce sera pas la même chose ; mais est-ce un cas courant ? d'autant qu'on parle d'applis Web ici)
on se rend vite compte que les processes restent un certain temps en mémoire mais ne foutent rien.
Et alors ? Qu'elle soit vide ou pleine, la mémoire va consommer la même énergie. Ce qui modifie la consommation de la mémoire, ce sont les accès. Mais si comme tu le postules les processus "ne foutent rien" alors il n'y aura pas d'accès à la mémoire de ces processus.
[^] # Re: La différence principale entre php et c++
Posté par yellowiscool . Évalué à 2.
Envoyé depuis mon lapin.
[^] # Re: La différence principale entre php et c++
Posté par Antoine . Évalué à 2.
Bon mais je ne suis pas spécialiste.
[^] # Re: La différence principale entre php et c++
Posté par Vador Dark (site web personnel) . Évalué à 1.
Ceci dit, ça ne retire rien au faîte que la RAM consomme très peu comparé au processeur.
[^] # Re: La différence principale entre php et c++
Posté par guepe . Évalué à 8.
En fait, le problème des fortes consommation mémoire, c'est que la mise à l'échelle ne passe pas. Tu dois faire tourner beaucoup de serveurs, beaucoup de CPU qui ne font à peu près rien, mais stockent en mémoire.
Et _ça_ c'est clairement pas efficace sur le plan énergétique. Réduire la consommation mémoire permet avec nos super CPU multi-cores de faire tourner des tonnes de process : d'où réduction du coût _et_ du coût énergétique.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 3.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: La différence principale entre php et c++
Posté par Antoine . Évalué à 1.
Heu, ben, il faudrait quantifier un minimum.
Un CPU serveur c'est grosso modo entre 10 W (au repos) et 100 W (en charge) de consommation.
Une barrette de RAM (disons 2 ou 4 Go), c'est combien?
Réduire la consommation mémoire permet avec nos super CPU multi-cores de faire tourner des tonnes de process
Evidemment, ça dépend du tonnage de la tonne ;-)
Mais bon, si tu mets trop de processus sur un CPU unique, tu prends le risque d'une montée en charge simultanée des différents processus qui va écrouler ton joli serveur.
Après, des chiffres concrets sont les bienvenus ;)
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 3.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: La différence principale entre php et c++
Posté par Antoine . Évalué à 3.
De plus prendre Java comme modèle de ce que peuvent consommer PHP ou Python, ça tient du troll.
Par ailleurs il est reconnu que top est un très mauvais indicateur de la consommation mémoire. Tu peux essayer smem pour de meilleurs chiffres (mais bon, c'est un outil écrit en Python, j'espère que ça ne te dérangera pas trop :-)).
http://www.selenic.com/smem/
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 0.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: La différence principale entre php et c++
Posté par Antoine . Évalué à 4.
Je vois, c'est précis et circonstancié :)
la plupart des grosses boîtes travaille avec java (c'est la vie)
En même temps, c'est pas le sujet du journal (PHP / C++).
[^] # Re: La différence principale entre php et c++
Posté par khivapia . Évalué à 2.
En même temps, il ne faut pas être grand clerc pour passer d'un exemple PHP/C++ à une comparaison entre logiciels interprétés et logiciels compilés nativement, surtout quand on prend pour exemples des langages compilés vers du bytecode généralement plus rapides que PHP.
[^] # Re: La différence principale entre php et c++
Posté par thedude . Évalué à 0.
Sinon, tu devrais savoir que java n'est pas interprete..
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 3.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: La différence principale entre php et c++
Posté par thedude . Évalué à 1.
Oui, dans le point trois, le [1] que t'as pas copie, probablement parce que tu l'as pas lu, il dit:
In this sense, the CPU is also an interpreter, of machine instructions.
forcement, avec cett edefinition d'interpreteur, on va aller loin...
[^] # Re: La différence principale entre php et c++
Posté par lolop (site web personnel) . Évalué à 4.
http://www.python.org/about/success/
Chacun sait que les langages statiquement typés, compilés en natif, et testé avec des méthodes à base de test case ne plantent jamais, dans le monde merveilleux des bisounours.
Python 3 - Apprendre à programmer dans l'écosystème Python → https://www.dunod.com/EAN/9782100809141
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 2.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: La différence principale entre php et c++
Posté par Antoine . Évalué à 2.
Ça ne change rien. L'OS fait du COW aussi pour les segments data.
Du reste, un des avantages du bytecode des langages interprétés c'est que c'est en général beaucoup plus compact que le code machine équivalent (car les opérations représentées sont plus haut niveau). Donc je ne crois pas que ton argument tienne.
Mais pendant ce temps la mémoire est full et provoque du swaping
Heu, faut pas pousser mémé dans les orties. S'il y a du swapping ton machin est mal dimensionné, c'est tout (et il s'écroulera dès qu'il y a une montée en charge).
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 2.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: La différence principale entre php et c++
Posté par Antoine . Évalué à 3.
Il s'en fout, banane.
Le COW est fait au niveau des pages de la mémoire virtuelle, le premier accès en écriture sur une page partagée est intercepté (tu sais, le noyau a le pouvoir de modifier les flags de lecture/écriture de chaque page ; non, ce n'est pas un truc de « bisounours ») afin de départager la page.
Va voir http://fr.wikipedia.org/wiki/Copy-On-Write
Lance 10 instances jboss avec struts pour un simple hello world, on en reparle après. Plus simple, lance 100 fois php sur le même code.
C'est un benchmark stupide. On ne compare pas l'efficacité de différents langages sur un hello world.
Ensuite, je répète : si ton truc est mal dimensionné au point de swapper, c'est ta faute et pas celle de PHP/Java/Python/C++. Point barre.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 1.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: La différence principale entre php et c++
Posté par Antoine . Évalué à 3.
(mais l'interpréteur peut aussi faire un mmap() du bytecode auquel cas l'OS est capable de partager les données)
[^] # on peut partager des pages identiques qui ont été crées indépendamme
Posté par Krunch (site web personnel) . Évalué à 6.
http://www.complang.tuwien.ac.at/ulrich/mergemem/
http://lwn.net/Articles/330589/
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: La différence principale entre php et c++
Posté par thedude . Évalué à 0.
C'est sur que si tu charges un framework monstrueux concu pour rendre des choses tres complexe possibles, juste pour faire un simple System.out.println("He, gros, ca va bien, ouaich?"); la consommation memoire va te paraitre quelque peu excessive
Lance 10 instances d'un appli c++ linkee statiquement aux MFC, Qt, GTK, ncurses, kdelib, gtk lib de threading, connecteur db et lib xml, moultes template et tout le trala pour faire un simple cout << "Ouaich, gros!"; tu vas arriver au meme genre de conclusion.
Ecrit une appli metier un tant soit peu consequente en J2EE (pas un forum phpbb quoi), si t'arrives ne serait ce qu'a produire un truc qui marchotte en c++ en 4 fois le temps de dev, ca sera impressionant.
Et a ce moment la, tu comprendras peut etre l'interet de ce genre de langage, c'est pas d'economiser 120ko de ram, c'est tout simplement d'etre capable de resoudre un enorme probleme, et tu auras une petite idee de pourquoi l'idee meme de ton benchmark est completement debile. On s'en fout que ca soit pas ultra optimal en ram, tant que ca repond au probleme, c'est deja un enorme gain.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 2.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: La différence principale entre php et c++
Posté par thedude . Évalué à 1.
tu peux.
Dans ce cas, tu penseras a compiler ton code java avec gcj, virer le GC, virer tout le sandboxing, bref, tu peux virer tout ce qu'il ya dans la jvm, le code inutile sur un println("hello world"), c'est quasiment tout.
Ce que t'as pas l'air de comprendre, c'est que si java est lourd, c'est parce qu'il embarque tout un tas de trucs.
Tout ces trucs, ca sert a rien pour un hello world, mais ils sont la quand meme. Forcement, ca alourdit le benchmark.
Par contre, quand tu sors un jboss avec spring, hibernate t'as ptetre 15 couches, mais en general tu fais pas ca pour une appliquette, comme ca au passant, mais parce que t'as besoin de l'artillerie lourd. Et au final:
- t'as un code bien plus robuste
- t'as un code bien plus efficace (je te met au defi de coder un truc plus efficace qu'hibernate avec le 2nd level cache active)
- t'as un code beaucoup plus souple et maintenable
Alors, oui, c'est sur, ton jboss il va prendre 1go de ram d'emblee.
Maintenant, code la meme chose en c++, si t'arrives a faire tourner ton appli dans 800Mo (ce dont je suis meme pas sur), t'auras d'une part tres peu gagne en ram (ca reste gros, que ca te plaise ou pas), d'autre part t'auras mit 4 fois plus de temps a sortir ton appli...
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 8.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: La différence principale entre php et c++
Posté par Ontologia (site web personnel) . Évalué à 4.
Parce que même si tu compiles tout ça, et que le compilateur te vire les 3/4 des appels qui ne sont que des appels, tu te retrouves avec un paquet de code qui ne sont que des abstractions.
Or, une abstraction, c'est une organisation humaine destinée à se retrouver mentalement dans la complexité du software.
On a le choix à faire du spécifique comme tu as fait, mais à donc ne plus avoir d'outil de "prémachage" sous la main, ou avoir les outils de prémachage et à devoir se battre contre une usine à gaz (où Spring/hibernate, etc... en sont le paroxysme, j'ai subi moi aussi...) tellement complexe qu'elle rend le développement impossible.
La hauteur de niveau des langages peut être une réponse. On peut voir par exemple avec Ruby, que certaines choses ne sont pas forcément nécessaire (au prix de performances moindre évidemment), vu l'approche interprété.
Le problème, c'est qu'en bas, on a toujours une bête machine de turing de base.
je ne sais pas ce qu'on pourrait faire de mieux... Un générateur de code, qui prend la description de ce qu'on veut faire, et génèrerai un truc spécifique... lisible ?
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 3.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: La différence principale entre php et c++
Posté par Ontologia (site web personnel) . Évalué à 2.
- Chaque tables est un objet singleton (en prototype, il sera non clonable). On pourra prendre comme convention qu'il a un s à la fin (comme dans ruby activerecord). Exemple, l'objet Tables
- chaque objet au singulier est clonable et représente une ligne d'une table. Exemple Tables contient une liste de Table.
Là ça pourrait marcher, grâce au fait qu'on ai un singleton par table ?
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: La différence principale entre php et c++
Posté par thedude . Évalué à 0.
Alors de deux choses l'une, soit tes gars sont une bande de bras casses, soit t'es un surhomme.
La voie du milieu c'est que le management etait tellement pourri que ton projet est parti en eau de boudin.
Quelques reflexions inspirees, la comme ca, de ton message:
- des workarounds a struts/jboss/jpa, ca veut dire que tes gars n'avaient pas la moindre idee de ce qu'ils font. Ou qu'ils ont prit / leur a impose la pire techno pour leur projet, ce qui revient sensiblement au meme.
Hint: quand tes devs te disent qu'ils ont des bugs dans une de ces libs utilisees par 95% de l'industrie, c'est qu'ils te racontent des conneries. C'est un peu comme si je te disais que malloc etait bugge, ca devrais te faire lever un sourcil.
- 2go de ram bouffe sur un projet de meme pas 6 mois, je commence a reellement me poser des questions sur tes devs/admins. C'est la quantite de ram de notre serveur de test, qui fait tourner 6 instances d'une appli, 2 de la mienne, pgsql avec 6 bases bien chargees et oracle XE avec 2 base assez legeres. Et ca tourne.
- Quand je lit "des problemes de stabilite avec DB2 JBoss et Java" je commence vraiment a me dire que t'as une sacre brochette de bras casses dans ton equipe. Ou que t'es de tres mauvaise foi.
Personnellement, je cherche toujours, une appli où tout ce brol apporte un plus. J'ai surtout l'impression que la machine s'est emballée et que beaucoup de gens n'ont plus assez de recul.
Sur un projet de 6 mois, oui, on peut clairement se poser la question de sortir l'artillerie lourde. Je bosse presentement sur un enorme systeme qui va nous prendre facile 2 a 3 ans avant de sortir une 1.0 tout juste fonctionnelle et avec la moitie des features. J'ose pas imaginer le delai si on enleve ne serait ce qu'hibernate (ainsi que l'impact sur les perfs, vu la difference de temps entre une requete SQL en cache et pas en cache).
[^] # Re: La différence principale entre php et c++
Posté par Thierry Thomas (site web personnel, Mastodon) . Évalué à 4.
Si vous utilisez Oracle, comme tu le dis plus haut, le SGBD gère déjà lui-même un cache, et ce n'est pas non plus la peine d'empiler les caches.
[^] # Re: La différence principale entre php et c++
Posté par thedude . Évalué à 4.
Si tu connais deja le fonctionnement d'hibernate la dessus, alors tu comprends la difference entre les 2, sinon, le pave ci dessous devrait te permettre de comprendre pourquoi le cache d'hibernate est tres efficace.
Meme si je suis convaincu que le cache d'oracle est tres efficace, ca implique quand meme d'empiler un appel jdbc, recuperer une connection, tres probablement passer par le reseau, taper oracle, va falloir qu'il compile son truc et te le retournes, re reseau, puis marshalling et pour enfin avoir ton objet.
En gros, ca veut dire:
Select foo, bar, toto from MaTable join MaCollectionAttribut where joincolum = id outer join MonAutrecollection where id = pw00t envoye a oracle.
Oracle va devoir parser tout ca, se dire qu'il a tout ca en memoire et que ca a pas ete modifie, et te retourner le contenu de son cache.
Retour a ton appli, tu te tapes tous tes:
MonObjetTable table = new MonObject()
table.setAttribut(new ObjetMachin()...);
MaCollection collection = new ArrayList()
blabla
Avec tous les tests d'integrite et tout le tralala, pour des objets qui n'ont au final pas ete modifie (ca s'trouve, ils sont meme immutables, tes objets...)
Si ton graphe d'objet est relativement costaud et que tes setters sont plus que de simples setters et font des trucs, ca fait potentiellement vachement de boulot.
Le 2nd level cache d'hibernate en revanche, contient tous tes objets java caches, grosso modo indexe par la PK.
Donc si ta requete est faite par la PK, ca va donner:
TonAppli fait une requete par PK,
Hibernate fait grosso modo un check:
if(monCachePourCetteClasse.containsKey(PK))
{
return monCachePourCetteClass.get(PK)
}
else
{
demander a oracle.
}
Dans la vraie vie, c'est un chtouille plus complexe que ca, parce qu'il faut gerer l'isolation, mais comme hibernate utilise des proxy a gogo, ca se gere sans recopie.
Ca te booste *tres sensiblement* les perfs, tu squeezes toute ta partie reseau, toute la partie SGBD et tout le "parsing"/allocation de ta reponse, tout ca c'est remplace par un getHashCode suivi d'un acces direct dans une table de hashage.
Pour quantifier, je m'amusais recemment a mesurer une requete serveur (ie, du point d'entree dans le remote facade jusqu'au return, c'est a dire de la requete marshalle jusqu'a juste avant la serialization de la reponse, en gros la seule partie sur laquelle tu peux accelerer les choses) passe de 0.75s a 0.1s entre la version cachee et pas cachee. La fonction en question, c'est uniquement un appel a la BD et return l'objet en question.
L'objet recupere etait tres touffu (grosso modo, un planning de visites en forme d'arbre, a la structure assez complexe) a cardinalite assez faible (45 visites, mais chaque visite a un gros paquet de machin complexe qui sont stockes dans d'autres tables).
Et en plus ca va t'economiser un gros paquet d'allocations potentiellement totalement inutiles.
Exemple tout con:
Je gard mon VisitSchedule, parce que c'est un bon exemple. Ton schedule contient une liste de Visit. Chaque Visit a lieu a une Location (4 ou 5 differentes dans le systeme), donc sans cache, ton impleme naive va te faire une allocation pour chaque Visit la ou tu pourrais partager une seule et meme instance.
C'est meme pire que ca en fait, a priori tu ne veux pas plusieurs allocation pour chaque Location, parce que tu vas potentiellement te retrouver avec un gros paquet d'instance d'une meme Location logique (== returns false but equals returns true), mais qui sont modifiees independament les unes des autres. Bon courage pour retrouver tes petits la dedans.
Resultat, tu te retrouve a devoir implementer un genre de cache si tu veux eviter de passer ton temps a demander a la db ce qu'il se passe et si tu veux avoir un graphe d'objet coherent en ram. Tu commences a avoir une couche DB qui a besoin de savoir comment fonctionne la couche metier, bref, ca devient un gros bordel a gerer.
Alors, apres, ce cache, il est pas magique non plus, tu peux te taper un retour de flamme tres violent.
Deja, ca ne marche que sur les requets par PK.
Genre select from chat where couleur = "noir" and cri="miaou" ira chez oracle quoi qu'il arrive. Et c'est la que tu profiteras du cache d'oracle :) Quand je te disais qu'il etait pas inutile.
Par contre select fromt chat where id = "45745715156874851ab47", ca ira dans le cache.
Ca implique aussi de faire assez gaffe a ce que tu fais dans ton code: Hibernate va faire une synchro cache => DB mais jamais dans l'autre sens. Si un objet est en cache, hibernate ne le rechargera jamais depuis la db (sauf si l'objet degage du cache, of course).
Ce que ca veut dire? C'est que si t'as une requete qui n'a pas vocation a persister quoi que ce soit, et que le dev se dit: bon, je vais pas me faire chier, je vais me permettre de prendre un raccourci ici et de laisser l'objet en peu en vrac, de toutes facons, c'est local, ben tu vas peter toute l'appli. Je l'avais perso sur un one to many bi directionnel que l'utilisateur pouvait modifier de chaque cote de l'association (region -> pays), je changeais la region d'un pays sans ajouter le pays a la region, en pensant betement qu'hibernate rechargerais le tout depuis la DB. grosse erreur, je me suis retrouve avec un pays qui affichait region bla et region bla qui ne contenait pas le pays.
Bref, dans ce cas: paf pasteque, et ce meme si ta DB est integre (bah vouais, en relationnel, ca marche tres bien ce que j'avais fait).
Dans le meme genre, t'as des effets de bords bizarre avec les sorts sur les collections aussi: si t'oublie de specifier un sort SQL, tu t'en rendras pas compte tant que ta collection a pas ete chargee depuis la DB.
Tu crees une liste cote serveur avec 1, 2, 3, tu persistes. Tu recharges, tu retrouves 1,2,3. Tu coupes le serveur, tu le relance, tu retrouve 2,3,1. Ca m'est arrive de mettre 2 mois a voir qu'un sort manquait.
Et bien evidemment, ca bouffe de la ram, faut bien stocker toute une palanquee de machin qui vont potentiellement jamais etre utilisee.
Mais bon, comme dit plus haut, tu sors pas ca pour un forum phpbb. Notre truc va tourner sur son serveur a lui rien que pour l'appli, donc on peut se permettre de goinfrer qq Go de ram pour notre cache.
[^] # Re: La différence principale entre php et c++
Posté par Krunch (site web personnel) . Évalué à 2.
Bien que je sois assez d'accord sur le fond de ton message, je pense que ton test n'est pas forcément pertinent. Une grosse partie du développement consiste à définir comment le tout va marcher. Si t'as déjà un truc qui marche sous les yeux, tu sais déjà comment le faire et les pièges à éviter. Je pense que c'est un énorme gain de temps et d'énergie.
Ton résultat ne dépend que très partiellement de tes outils en fin de compte. There is no silver bullet, toussa.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: La différence principale entre php et c++
Posté par Psychofox (Mastodon) . Évalué à 2.
Oui bon maintenant, même les serveurs de bas de gamme acceptent 64 ou 128GB de ram, donc faut aussi savoir dimenssionner correctement hein. Je connais pas beaucoup d'applis qui bouffent toutes seules 128GB de ram, quelque soit le langage. En général, si on bouffe de la ram, c'est parce qu'on a 15 couches de cache pour tout et n'importe quoi, à se demander si on utilise encore les disques ;-)
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 3.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: La différence principale entre php et c++
Posté par khivapia . Évalué à 3.
Non, l'augmentation des besoins en mémoire fait surconsommer le CPU pour la raison suivante (bien décrite par le post d'alenvers) : la gestion de la mémoire, oui, mais la mémoire cache.
Dans le cas du cache de niveau 1, généralement segmenté en deux sous-caches, instructions et données, le code compilé réside intégralement dans le cache instruction là où le code interprété sépare l'interpréteur dans le cache instruction et le (éventuellement byte)code dans le cache données. Soit une surconsommation du cache données avant même de toucher aux données réelles manipulées par le programme.
Quand on sait ensuite que les accès au cache de second niveau se comptent en trentaines de cycles au minimum, il ne faut pas longtemps pour comprendre que la surpression sur le cache L1 entraîne un surnombre de cycles inutiles rien que pour la gestion des données réelles du programme !
Et ceci est totalement indépendant des calculs supplémentaires induits par l'interprétation des instructions (décoder en soft des instructions alors qu'un processeur fait ça très bien en matériel pour son langage induit également une perte de temps énorme). Le goulot d'étranglement des processeurs modernes réside dans les accès à la mémoire, pas dans le calcul.
[^] # Re: La différence principale entre php et c++
Posté par Antoine . Évalué à 0.
Le cache instruction fait 32 ou 64K selon les CPUs, tu auras du mal à me trouver une application moderne qui tient dans cet espace.
il ne faut pas longtemps pour comprendre que la surpression sur le cache L1 entraîne un surnombre de cycles inutiles rien que pour la gestion des données réelles du programme
Sauf que comme mentionné plus haut, le bytecode d'un langage interprété est plus compact que le code machine équivalent. Donc l'efficacité cache de ce bytecode est meilleure et non moins bonne.
[^] # Re: La différence principale entre php et c++
Posté par khivapia . Évalué à 4.
oui, je me suis mal exprimé, je voulais dire qu'il faut comparer à utilisation similaire. L'optimisation des programmes montre qu'en général le cache instruction n'est pas le facteur limitant mais bien le cache de données (relis par exemple cpumemory.pdf d'Ulrich Drepper, aka "What every programmer should know about memory"). Donc supposer que le cache instruction est rempli dans les deux cas n'est pas une hypothèse aberrante, et on s'intéresse au cache de données.
Sauf que comme mentionné plus haut, le bytecode d'un langage interprété est plus compact que le code machine équivalent. Donc l'efficacité cache de ce bytecode est meilleure et non moins bonne.
Sauf que comme mentionné plus haut [dans mon post] même dans le cas d'un langage interprété à bytecode, dans tous les cas le code du langage interprété réside dans le cache de données et pas dans le cache d'instructions. Il a beau être compact, il prend toujours plus de place que rien du tout dans le cas du langage compilé. L'efficacité cache de données du code interprété est donc moins bonne et non meilleure.
# Il y a tant de serveurs PHP chez facebook ?
Posté par Bruno Michel (site web personnel) . Évalué à 5.
Je ne connais pas l'architecture de facebook, ni le nombre de leurs serveurs, mais j'imagine qu'il n'y a pas tant que ça de serveurs PHP comparé au reste : serveurs de bases de données, serveurs web statiques, serveurs de fichiers, serveurs de cache (memcached), calculs asynchrones (thrift), serveurs de logs (scribe), data warehouse (hadoop / hive), serveur de chats (erlang)...
Au final, même si Facebook remplaçait tout son code PHP par du C++, ça diminuerait de combien leur nombre de serveurs ? 1% ? 10% ? 50% ? 90% ?
[^] # Re: Il y a tant de serveurs PHP chez facebook ?
Posté par Dring . Évalué à 4.
[^] # Re: Il y a tant de serveurs PHP chez facebook ?
Posté par Bruno Michel (site web personnel) . Évalué à 4.
[^] # Re: Il y a tant de serveurs PHP chez facebook ?
Posté par netsurfeur . Évalué à 5.
Encore faut-il lire les commentaires sur Slashdot avant de reprendre aveuglément les chiffres cités, ça permet de comprendre rapidement que l'auteur de l'article s'est contenté de faire des extrapolations simplistes sans aucune connaissance réelle de l'architecture de Facebook.
Certains arguments ont déjà été cités ici.
Personnellement, j'insisterais sur:
- le facteur 10 provient de benchs de calcul pur, ils ne tiennent pas compte de:
1) la possibilité d'utiliser un accélérateur PHP. Il suffit de lire l'article http://blog.facebook.com/blog.php?post=2356432130 pour s'apercevoir que Facebook sait comment optimiser les performances de PHP.
2) les traitements PHP consistent souvent à interroger une base MySQL (qui est codé en C). L'impact de la performance de PHP sur la performance globale n'est probablement pas majeur.
- Facebook n'utilise pas que des serveurs PHP. Voir l'article http://www.datacenterknowledge.com/archives/2008/04/23/faceb(...) : 10000 serveurs sont utilisés uniquement pour gérer du cache.
De même, il faut quelques serveurs pour stocker les quelque 1,5 Po de photos (voir http://www.facebook.com/note.php?note_id=76191543919), avec 2,3 To de plus par jour. A raison de 10 To par serveur, je vous laisse faire la division. Et on n'a pas le nombre total de serveurs MySQL, répliqués sur deux datacenters.
Finalement, le gain potentiel en nombre de machines est probablement ridicule et largement contrebalancé par la simplicité de développement en PHP comparé à C++.
# s/assumer/supposant/
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 6.
Assumer, dans un sens pareil, c'est un affreux anglicisme. On dit « supposer », « se baser sur », « considérer »…
Quant au ratio, autant parler de rapport, le latin n'apporte strictement rien.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 4.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: s/assumer/supposant/
Posté par claudex . Évalué à 4.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
# Par exemple...
Posté par romain . Évalué à 8.
Ce qui est à la fois un atout et à la fois... une plaie.
D'une, parce que ce n'est pas parce que c'est en PHP que n'importe qui peut venir mettre sa patte dedans (importance de l'expérience, de l'encadrement, de la vision d'ensemble du projet - de sa structure).
De deux, parce que les managers de l'étage du dessus n'ont pas forcément conscience de ce qu'implique "modifier un site web PHP" (selon l'adage "un pisseur de code en vaut bien un autre - tu me mets un marquee là et on n'en parle plus").
Comme souvent, la barrière d'accès à la bonne prise en main d'une technologie (PHP ou C++) n'équivaut pas à celle d'une prise en main d'un projet réalisé avec celle-ci (et un projet ne se mesure pas aux seules technos qu'il emploie).
[^] # Re: Par exemple...
Posté par tom120934 . Évalué à 4.
Entièrement d'accord, c'est bien pour ça que je disais "se sent capable de modifier".
Entre se croire capable et l'être, il y a un boulevard. Il n'y a qu'à regarder l'effarant niveau de certains tutoriaux PHP, la frénesie pour les COTS genre CMS, gallerie d'image ou moteur de blog en PHP alors que les frameworks MVC (CakePHP, Symfony ou autres) sont loin de rencontrer le succès de frameworks dans d'autres languages (vous avez déjà vu un site en Ruby sans Rails ?)
Le plus gros ennemi de PHP, c'est bien sa popularité. C'est comme comparer son permis B et la conduite d'une F1 de 900 ch pour 600kg, sous prétexte que ça a un moteur et 4 roues tout pareil : les gens croient que c'est facile.
>> un pisseur de code en vaut bien un autre
C'est le problème de la théorie de la gestion de projet prise trop au sérieux. J'ai quitté l'informatique pour le bâtiment, mais les problématiques de gestion de ressources sont les mêmes : ouvrier ou pisseur de code, même combat. La gestion de projet / de chantier déshumanisée ne peut marcher, à moins d'un budget sans fond et d'absence de contraintes calendaires.
# Lampes basse consommation
Posté par Pascal Terjan (site web personnel) . Évalué à 0.
Négatif je pense pas. Deja ca ne concerne que les gens avec un chauffage individuel, ensuite ca ne doit jouer sur quelques jours de chauffage par an (quand on est proche de la limite) contre une utilisation quotidienne, mais oui ca réduit l'économie d'énergie.
Il y a des consequences plus génantes :
http://blog.makezine.com/archive/2009/12/led_traffic_lights_(...)
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.