Elle parle de travaux dérivé qui est un concept de la loi qui régit les droits d'auteurs. Tu as le droit de poser des conditions sur la manière dont tu réutilises un code pour en faire autres choses.
Par contre, cela n'est pas une restriction sur l'usage du produit en lui-même.
Je suis d'accord que dans le cas d'un plug-in, la limite entre dérivation du code et utilisation de l'outils est mince. Mais il me semble que seul le plug in était distribué pas l'ensemble plug in + MS machin chose.
Donc si jamais MS a quelques choses à dire, c'est uniquement à l'utilisateur de l'accouplement, pas à l'éditeur du plug in.
Le cas dont tu parles ressemble beaucoup à apache... sans load balancer. Toutes les applications serveur avec beaucoup de client sont dans le même cas.
La solution la plus propre au problème serait que le serveur de jeu inclus le load balancer (au niveau du serveur de jeu, cela reviendrait presque uniquement à proposer une nouvelle ip, non ?).
Pour des raisons d'Interropérabilité, tu peux faire du reverse.
Et quelque part cette limitation légal d'utiliser certaines api présentent ne me parait pas très légal. (MS vient de se faire taper sur les doigts par la CE pour ne pas documenter toutes ses api windows)
Mais franchement, je suis de tout coeur avec Ms sur cette histoire. Faites un bon proces à ceux qui osent utiliser de façon trop pousser vos outils.
Le plus possible, surtout pour un portable, si tu swap cela bouffe de la batterie. Linux utilise tout ce qu'il peux en cache disque, donc pour chaque Mo utilisé tu peux gagner en vitesse.
Si tu ne fais que de la bureautique, 1 Go suffit voir 512 Mo.
Si tu fais de la video ou si tu manipules des photos, monte au max (2Go ?).
En terme matheux, il augmente la taille de la coupure (je ne me plante pas), ce qui permet d'avoir une bande passante moyenne point à point meilleur et par la même occasion réduire la distance et donc diminuer les latences.
Je vois bien l'intérêt de manager moins de machines, mais pour l'utilisation de apache, à part si on peut se passer d'un load balancer, je voix difficilement l'intérêt. Surtout que niveau performance, cela doit être plus lent (puisque qu'il y a de la gestion à faire qui n'existe pas avec les systèmes actuels).
Un tel système doit être sympa sur des applications qui peuvent utiliser plein de processeurs mais qui nécessite tout de même une image unique. C'est pas courant (notamment car il n'existe pas vraiment de machine pour:). Je pense aux simulations.
Au boulot, on a un cluster de calcul géré par lsf. Si on avait juste à se loguer dessus, cela serait plus simple. Idem, pour se connecter à "un linux" depuis un serveur X sous windows, pas besoin de chercher une machine libre (non chargé).
Concernant les réseaux, avez-vous essayer les systèmes à plusieurs liens ?
Habituellement un réseau est connecté en arbre à des switchs, et souvent les switchs son cascadé si le nombre de machines est grand. (imaginé que 32 machines en gigabit doivent partager un seul giga pour parler à un voisin sur un autre switch!)
J'avais vu un projet de cluster à 256 machines. Il avait gagné beaucoup de performance réelles en ne reliant pas entre eux les switchs. En fait, il avait plusieurs cartes réseaux par machines et utilisait la règles suivantes : un seul switch à traverser pour aller d'une machine à l'autre (le top étant les liaison n à n ou encore l'utilisation de carte réseau qui font aussi switch mais cela devient énorme).
Les problèmes à régler sont multiples : la topologie du réseau est complexe à produire (nombre de carte par noeud, connections à quel switch,...). Et surtout, j'ai du mal à imaginer la gestion des adresses IP et le routage que cela implique (gestion des tables, trouver le lien direct à tous les coups, etc...). Bref, pour que cela soit pleinement fonctionnelle, il y a encore du soft à écrire.
Mais au final, on a des performances notamment par diminution des latences (on parallélise les connections) à un cout bien inférieur à un réseau rapide spécial.
Si on compte juste la multiplication, c'est 2 fmul/cycle/core en 64 bits. Je n'ai pas vérifié mais il est tout a fait possible que les opérations 64 bits soient plus que 2x plus lente que les opérations 32 bits.
C'est vrai que le SX-8 pourrait se faire rattraper mais il faudrait douler les ressource mathématique du x86 (genre 4 controleurs mémoire et 2 unités vectoriel pour les multipliations).
Et puis ce genre de processeurs disposent de moyen de communication trés rapide. Il faut en général des controleurs de réseau et autres assez complexe. (sur les ascii d'IBM, il y avait 3 réseau, un arbre, un mesh à 6 branche et un truc que j'ai oublié :)
En moyenne, l'ipc (instruction per clock) d'un Xeon n'est pas 4. J'avais lu 1.9 pour un athlon. Un Xeon doit à peine sortir une multiplication par cycle en double (64 bits) même en SSE2.
Les SX8 disposent d'unité vectoriel. Genre il traite une dizaine de nombre à la fois. vu le rapport entre 2.2 et 35.2, cela tombe pile poil sur 16. Donc les vecteurs font 16 nombres de 64 bits. C'est déjà bien plus que ce que permet un xeon en SSE2.
Selon la doc Nec, le SX8R dispose manipule des vecteurs de 4 nombres sur 4 pipelines (d'ou le x16), par contre un dessin montre seulement 2 pipes avec multiplication. Donc, on doit être à 17.6 MMACS flottant ce qui est déjà énorme. De plus, le cpu dipose de 70 Go/s de bande passante.
Le xeon devrait doubler sa puissance de calcul pour se rapprocher (genre 2 unités de multiplication au lieu d'une et augmenter sa bande passante mémoire)
C'est vrai que pour du développement software, le must c'est d'avoir le maximum de core. Ensuite, pour la vitesse disque, il faut plusieurs raptor en raid0, et 2 disques plus normal en raid1 pour les données.
Avec mini 2 Go de ram, là, cela commence à être une station de travail digne de ce nom (avec grand écran genre 2 24" ou un 30" ).
un processus erlang prends 300 octets, et n'est pas un appel a fork() ni à pthread_create ou à clone().
Erlang utilise les thread pour se répartir sur les différents cores des processeurs, mais une thread OS peut contenir 30000 process erlang...
En gros les 300 octets, c'est la taille prise même si le nouveau thread contient uniquement un "RET". La taille réservée pour la pile et le code sera bine plus grande.
Erlang dérive des telco, c'est à dire qu'il doit assurer 99,99999 % de disponibilité.
Je le sais bien. On peut même rajouter que les performances n'étaient qu'un problème secondaire, c'est pour ça que je considère que cela n'est qu'un langage de niche.
Et cela n'est pas ce que l'on demande principalement à un langage actuellement (c'est plutôt de la productivité, et un moindre cout de formation).
Le bench montré n'a que peut d'interret. Pour ce genre de serveur, c'est le nombre de requètes par seconde en fonction du nombre de session en parralèle qui est la métrique utilisée.
Je parie que Erlang doit très bien scaler jusqu'à plus de 30000 sessions parrallèle avec une courbe bien plate. Mais que pour les cas d'utilisation moyen avec ~100 à 1000 sessions, je parie que apache gère bien plus de transactions.
Dans mon domaine, la microélectronique, il y avait beaucoup de station. Puis les gens ont bien mis 5 ans à s'apercevoir que le moindre PC était bien plus rapide qu'une SUN. Résultat tout bascule doucement vers des machines Linux. Peut-être que l'utilisation par SUN d'AMD va ralentir le phénomène mais je pense que la différence de prix avec un PC dell ou HP à du mal à ce justifier.
Donc, j'aurais tendance à dire que les stations de travails autre que PC ont tendance à disparaire sauf peut-être en mécanique où les cartes de chez HP ou SGI sont encore plus rapide que les NVIDIA quand il faut afficher beaucoup de polygones.
Je n'ai pas le back ground de math necessaire pour affirmer ça.
Par contre, l'interret est dans la somme de code qui disparait. En fait, il y a plein de classes mères virtuelles qui deviennent inutile et en plus cela retire une dépendance qui est souvent artificielle.
Erlang était très bon pour le paralèlisme par la VM executait une instruction par thread après l'autre. Le compilo ne peut pas faire ça. Il utilise les threads de base de l'os?
[^] # Re: Faut apprendre a lire
Posté par Nicolas Boulay (site web personnel) . En réponse au journal L'effet girouette .... Évalué à 4.
Elle parle de travaux dérivé qui est un concept de la loi qui régit les droits d'auteurs. Tu as le droit de poser des conditions sur la manière dont tu réutilises un code pour en faire autres choses.
Par contre, cela n'est pas une restriction sur l'usage du produit en lui-même.
Je suis d'accord que dans le cas d'un plug-in, la limite entre dérivation du code et utilisation de l'outils est mince. Mais il me semble que seul le plug in était distribué pas l'ensemble plug in + MS machin chose.
Donc si jamais MS a quelques choses à dire, c'est uniquement à l'utilisateur de l'accouplement, pas à l'éditeur du plug in.
"La première sécurité est la liberté"
[^] # Re: Performances
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Sortie de la version 2.1.0 de Kerrighed. Évalué à 2.
La solution la plus propre au problème serait que le serveur de jeu inclus le load balancer (au niveau du serveur de jeu, cela reviendrait presque uniquement à proposer une nouvelle ip, non ?).
"La première sécurité est la liberté"
[^] # Re: Faut apprendre a lire
Posté par Nicolas Boulay (site web personnel) . En réponse au journal L'effet girouette .... Évalué à 6.
Et quelque part cette limitation légal d'utiliser certaines api présentent ne me parait pas très légal. (MS vient de se faire taper sur les doigts par la CE pour ne pas documenter toutes ses api windows)
Mais franchement, je suis de tout coeur avec Ms sur cette histoire. Faites un bon proces à ceux qui osent utiliser de façon trop pousser vos outils.
"La première sécurité est la liberté"
# 241 Mo ?!
Posté par Nicolas Boulay (site web personnel) . En réponse au message Lenteur LINUX. Évalué à 2.
"La première sécurité est la liberté"
[^] # Re: memoire
Posté par Nicolas Boulay (site web personnel) . En réponse au message Lenteur LINUX. Évalué à 2.
Si tu ne fais que de la bureautique, 1 Go suffit voir 512 Mo.
Si tu fais de la video ou si tu manipules des photos, monte au max (2Go ?).
"La première sécurité est la liberté"
[^] # Re: Performances
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Sortie de la version 2.1.0 de Kerrighed. Évalué à 3.
"La première sécurité est la liberté"
# ?
Posté par Nicolas Boulay (site web personnel) . En réponse au message types (float, int) indépendant de l'architecture?. Évalué à 2.
"La première sécurité est la liberté"
[^] # Re: Performances
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Sortie de la version 2.1.0 de Kerrighed. Évalué à 3.
Un tel système doit être sympa sur des applications qui peuvent utiliser plein de processeurs mais qui nécessite tout de même une image unique. C'est pas courant (notamment car il n'existe pas vraiment de machine pour:). Je pense aux simulations.
Au boulot, on a un cluster de calcul géré par lsf. Si on avait juste à se loguer dessus, cela serait plus simple. Idem, pour se connecter à "un linux" depuis un serveur X sous windows, pas besoin de chercher une machine libre (non chargé).
Concernant les réseaux, avez-vous essayer les systèmes à plusieurs liens ?
Habituellement un réseau est connecté en arbre à des switchs, et souvent les switchs son cascadé si le nombre de machines est grand. (imaginé que 32 machines en gigabit doivent partager un seul giga pour parler à un voisin sur un autre switch!)
J'avais vu un projet de cluster à 256 machines. Il avait gagné beaucoup de performance réelles en ne reliant pas entre eux les switchs. En fait, il avait plusieurs cartes réseaux par machines et utilisait la règles suivantes : un seul switch à traverser pour aller d'une machine à l'autre (le top étant les liaison n à n ou encore l'utilisation de carte réseau qui font aussi switch mais cela devient énorme).
Les problèmes à régler sont multiples : la topologie du réseau est complexe à produire (nombre de carte par noeud, connections à quel switch,...). Et surtout, j'ai du mal à imaginer la gestion des adresses IP et le routage que cela implique (gestion des tables, trouver le lien direct à tous les coups, etc...). Bref, pour que cela soit pleinement fonctionnelle, il y a encore du soft à écrire.
Mais au final, on a des performances notamment par diminution des latences (on parallélise les connections) à un cout bien inférieur à un réseau rapide spécial.
"La première sécurité est la liberté"
[^] # Re: et les \r \n ?
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Emacs 22 est déclaré stable. Évalué à 2.
"La première sécurité est la liberté"
[^] # Re: et les \r \n ?
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Emacs 22 est déclaré stable. Évalué à 2.
"La première sécurité est la liberté"
[^] # Re: et les \r \n ?
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Emacs 22 est déclaré stable. Évalué à 2.
Donc, d'après la règle du "moins étonnant", le comportement par défaut devrait masquer ces "^M" de m...
"La première sécurité est la liberté"
# gc lèche
Posté par Nicolas Boulay (site web personnel) . En réponse au message Galerie photo. Évalué à 3.
Il est élégant et rapide.
J'ai juste pas compris comment ajouter un nouvel album à un album existant ... mais cela doit forcément exister :)
"La première sécurité est la liberté"
[^] # Re: Pourquoi ne pas utiliser de processeurs graphiques ?
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Super calculateur météo france et langage. Évalué à 3.
"La première sécurité est la liberté"
[^] # Re: et les \r \n ?
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Emacs 22 est déclaré stable. Évalué à 1.
"La première sécurité est la liberté"
[^] # Re: et les \r \n ?
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Emacs 22 est déclaré stable. Évalué à 3.
Mais cela reste un comportement super chiant.
"La première sécurité est la liberté"
# et les \r \n ?
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Emacs 22 est déclaré stable. Évalué à 4.
Genre j'écris le mode que l'on m'indique mais je lis les 2 sans broncher. C'est franchement laid à gérer ce problème.
"La première sécurité est la liberté"
[^] # Re: concours de b*te
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Super calculateur météo france et langage. Évalué à 3.
C'est vrai que le SX-8 pourrait se faire rattraper mais il faudrait douler les ressource mathématique du x86 (genre 4 controleurs mémoire et 2 unités vectoriel pour les multipliations).
Et puis ce genre de processeurs disposent de moyen de communication trés rapide. Il faut en général des controleurs de réseau et autres assez complexe. (sur les ascii d'IBM, il y avait 3 réseau, un arbre, un mesh à 6 branche et un truc que j'ai oublié :)
"La première sécurité est la liberté"
[^] # Re: concours de b*te
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Super calculateur météo france et langage. Évalué à 5.
Les SX8 disposent d'unité vectoriel. Genre il traite une dizaine de nombre à la fois. vu le rapport entre 2.2 et 35.2, cela tombe pile poil sur 16. Donc les vecteurs font 16 nombres de 64 bits. C'est déjà bien plus que ce que permet un xeon en SSE2.
Selon la doc Nec, le SX8R dispose manipule des vecteurs de 4 nombres sur 4 pipelines (d'ou le x16), par contre un dessin montre seulement 2 pipes avec multiplication. Donc, on doit être à 17.6 MMACS flottant ce qui est déjà énorme. De plus, le cpu dipose de 70 Go/s de bande passante.
Le xeon devrait doubler sa puissance de calcul pour se rapprocher (genre 2 unités de multiplication au lieu d'une et augmenter sa bande passante mémoire)
"La première sécurité est la liberté"
[^] # Re: euh...
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Quelle est votre station ?. Évalué à 2.
Avec mini 2 Go de ram, là, cela commence à être une station de travail digne de ce nom (avec grand écran genre 2 24" ou un 30" ).
"La première sécurité est la liberté"
[^] # Re: Pas de candidats
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Quelle est votre station ?. Évalué à 3.
"La première sécurité est la liberté"
[^] # Re: Erlang ?
Posté par Nicolas Boulay (site web personnel) . En réponse au journal L'expressivité des langages. Évalué à 2.
un processus erlang prends 300 octets, et n'est pas un appel a fork() ni à pthread_create ou à clone().
Erlang utilise les thread pour se répartir sur les différents cores des processeurs, mais une thread OS peut contenir 30000 process erlang...
En gros les 300 octets, c'est la taille prise même si le nouveau thread contient uniquement un "RET". La taille réservée pour la pile et le code sera bine plus grande.
Erlang dérive des telco, c'est à dire qu'il doit assurer 99,99999 % de disponibilité.
Je le sais bien. On peut même rajouter que les performances n'étaient qu'un problème secondaire, c'est pour ça que je considère que cela n'est qu'un langage de niche.
Et cela n'est pas ce que l'on demande principalement à un langage actuellement (c'est plutôt de la productivité, et un moindre cout de formation).
Le bench montré n'a que peut d'interret. Pour ce genre de serveur, c'est le nombre de requètes par seconde en fonction du nombre de session en parralèle qui est la métrique utilisée.
Je parie que Erlang doit très bien scaler jusqu'à plus de 30000 sessions parrallèle avec une courbe bien plate. Mais que pour les cas d'utilisation moyen avec ~100 à 1000 sessions, je parie que apache gère bien plus de transactions.
"La première sécurité est la liberté"
# euh...
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Quelle est votre station ?. Évalué à 9.
Donc, j'aurais tendance à dire que les stations de travails autre que PC ont tendance à disparaire sauf peut-être en mécanique où les cartes de chez HP ou SGI sont encore plus rapide que les NVIDIA quand il faut afficher beaucoup de polygones.
"La première sécurité est la liberté"
[^] # Re: Génial !!
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Un laptop Palm.... sous Linux. Évalué à 2.
"La première sécurité est la liberté"
[^] # Re: cduce ? et les sous type ?
Posté par Nicolas Boulay (site web personnel) . En réponse au journal L'expressivité des langages. Évalué à 2.
Par contre, l'interret est dans la somme de code qui disparait. En fait, il y a plein de classes mères virtuelles qui deviennent inutile et en plus cela retire une dépendance qui est souvent artificielle.
"La première sécurité est la liberté"
[^] # Re: Erlang ?
Posté par Nicolas Boulay (site web personnel) . En réponse au journal L'expressivité des langages. Évalué à 2.
Erlang était très bon pour le paralèlisme par la VM executait une instruction par thread après l'autre. Le compilo ne peut pas faire ça. Il utilise les threads de base de l'os?
"La première sécurité est la liberté"