Nicolas Boulay a écrit 15828 commentaires

Est-ce emacs va gentiment oublier les "^M" à la fin des buffers quand on travails dans un environnement mixtes (windows/unix) ?

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é"

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é :)

"La première sécurité est la liberté"

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)

"La première sécurité est la liberté"

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" ).

"La première sécurité est la liberté"

Chez Sun, il y a les ultra sparc 4 quand même, sur les sun blade 1000.

"La première sécurité est la liberté"

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é"

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.

"La première sécurité est la liberté"

moins de 1 kg ? Avec de la mémoire flash ?

"La première sécurité est la liberté"

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.

"La première sécurité est la liberté"

Et cela donne quoi en perf ?

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é"

2-3000 lignes en 15 jours mais de temps plein, non ?

"La première sécurité est la liberté"

Je ne pensais pas attendre une masse pareil de commentaire sans aucun interret.

Ta question aussi est à coté de la plaque. D'après les normes de dev, un produit à un nombre fixe de ligne de code pour taux de bug donné pour des logiciels semblables.

Donc ma question n'a aucun rapport sur le fait que N lignes de codes, c'est trop pour le logiciel L. Vu que L n'est pas spécifié...

"La première sécurité est la liberté"

Je l'attendais depuis longtemps le portable utilsant les technos PDA.

Reste plus qu'a attendre un écran ~13/14"(A4 quoi), un clavier utilisable et cela sera parfait (mais en restant ultra fin et ultra léger et sans transfo de 2kg à trimbaler)

"La première sécurité est la liberté"

Comme préciser plus bas, le code ne se parralèlise pas tout seul. C'est peut-être facile à faire en erlang mais si ton code ne le permet pas tu es eu définitivement.

En plus, il me semble que Erlang tourne dans une VM pas encore jit et pas encore SMP aware. Bref, j'imagine que même Perl ou Java doit être plus rapide.

En gros à part dans les applications serveur ou le parralèlisme est trivial, Erlang pourrait s'en sortir. Et encore, faire de la distribution de charge sur plusieurs apache n'est pas bien difficile et chaque noeud sera bien plus rapide.

"La première sécurité est la liberté"

non car c'est à faire à la compilation.

Mais pas besoin de filtre de source pour faire ça, il "suffit" d'un bon propagateur de constante suivi d'une élimination de code mort.

Le filtre de source est plus pour se permètre d'ajouter un sucre syntaxique. C'est crade mais si lisaac contient son propre compilo, on peut imaginer utiliser le parseur de lisaac lui même avant de faire une modification.

Lisaac étant minimaliste, je ne pense pas que bidouiller sa grammaire soit super utile et propre.

"La première sécurité est la liberté"

erlang ne pourra jamais percer à cause de ses performances déplorables multicore ou pas. Il ne sera utile que dans les marchés de niche pour lequel il a été conçu ou sa fiabilité et sa robustesse le rend le plus interrescant des langages.

"La première sécurité est la liberté"

Bah si lisaac est suffisement souple, cela devient une histoire de lib.

Si il permet de remplacer les Makefile, les autotools, des générateurs de codes, c'est déjà pas mal.

Lisaac a pour lui ça syntaxe hyper simple de base. Si ensuite, il intègre de la preuve et le système de "contenaire magique", il peut faire déjà beaucoup !

"La première sécurité est la liberté"

Je ne voie pas trop ça comme un problème.

Pour une telle lib, tu as besoin de la reflexivité.

Si le système de build est géré par lisaac lui-même, tu peux imaginer de la compilation paramètrique (en gros, cela revient à compiler à la volé, modulo le fait que l'on ne cherche pas du tout à être léger et que cela intervient à la compilation du projet). Donc, cela permet de faire des filtres de code comme certain module perl (je sais cela peut paraitre immonde mais cela ne se passe qu'à la compilation et c'est juste pour une lib).

Tu peux imaginer une fonction qui contient du code en "string" mais qui sera compiler elle-même, un peu comme les regex du perl.

"La première sécurité est la liberté"

Je croyais que tu réfléchissais à une lib pour lisaac et non à un nouveau langage.

"La première sécurité est la liberté"

C'est au vendeur d'assurer la garantie.

"La première sécurité est la liberté"

tu peux aussi n'installer que la xlib et exporter par le réseau l'affichage. Cela évite l'utilisation de WM. Mais bon, cela signifie aussi recoder une application graphique.

"La première sécurité est la liberté"

sauf que cela n'est pas légal...

"La première sécurité est la liberté"

http://www.cduce.org/ fait ce que tu as l'air de décrire pour manipuler facilement du XML. Et je trouve plus souple la notion de sous-type qui ressemble aux ensembles mathémtiques que la notion de classe.

"La première sécurité est la liberté"

Je crois que justement ff n'utilise pas de threads.

"La première sécurité est la liberté"

Si tu n'a pas de donné : réinstall le linux, il va choisir pour toi le bon kernel.

Sinon, sur une mdv fait un urpmi d'un kernel pour plus de 1 Go.

Si tu veux jouer les warriors, recompile le kernel. Mais bon, tu va péter toute possiblité d'update de ta distrib.

"La première sécurité est la liberté"