Nicolas Boulay a écrit 15824 commentaires

le 1er est compressé non ?

si tu zip les 2, la taille restent en proportion ?

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

Pratiquer du mono ? :(

Disons que j'avais déjà vu cette légende urbaine concernant la taille des binaires (java à l'époque). Tout ça était venu de la taille des instructions limitées à 1 octets, une instruction étant forcément plus petites que les 16 bits ou plus d'un cpu classique.

Sauf que l'on parle de jeu d'instruction à pile, ce qui signifie "plein" d'instructions à pile pour émuler une seul instruction à registre.

Donc, je voulais savoir si tu avais des arguments autre que des argument d'autorité.

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

Je pensais à ça car la gestion d'un raid 5 introduit toujours des latences de fou, surtout si il y a des cycles de lecture/écriture. Si la RAM est pleine, cela doit bien bloquer au niveau IOs à cause des fifo trop petites pour absorber la latence.

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

D'ailleurs avec une base aussi petite, l'utilisation d'un SSD "moderne" pourrait améliorer les choses (gamme Vertex de chez OCZ et la gamme pro de chez Intel).

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

A force de lire des docs google, j'aurais tendance à vouloir utiliser leur téchnique : prendre le meilleur rapport qualité prix, en gros qq serveurs quadricore mono cpu pas trop chère en SATA avec des disques en RAID 10 (4?) avec 3 Go de ram.

Combien on peut avoir de serveur sata mono-socket pour le prix d'un monstre avec disque à 15k ?

En plus, dans 2 ans, si cela rame, il suffit de rajouter un serveur (et de virer la machine la plus ancienne).

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

Si la base fait 2Go, passer à plus de RAM actuellement à 2 Go, devrait beaucoup se voir non ?

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

tu lis où tu reposes la question pour le fun ?

je pensais au démarrage.

Tu peux concevoir qu'une instruction écrite dans un bytecode de plus haut niveau corresponde à un paquet d'instructions en code machine ?

Et est-ce que tu peux aussi imaginer l'inverse ?

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

Comment le code natif peut être plus lent que le code bytecode ?

Tu considères la VM comme préchargé avec toutes les bonnes lib ?

Tu considères par défaut qu'un bytecode est plus compacte que du code natif, donc que la copie mémoire est plus longue ? (ce qui est faux en passant, difficile de faire plus compact que du x86)

Pour moi, la VM a un dilemme entre travailler le code pour le rendre ensuite plus rapide et l'interpréter au plus vite pour ne pas avoir une trop grosse latence.

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

En gros, tu accèptes de perdre du temps au début le temps que le JIT compile et ensuite, tu dépasses la vitesse du natif.

En gros, tu dit aussi que le cache n'est pas petit et peut contenir une application complète.

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

Tu veux dire que la majorité des windowsien avec un anti-virus Kaspersky dispose d'une jolie backdoor ?

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

Dans des tests fait par qui ? Sun ?

J'aurais tendance à dire qu'une VM doit pouvoir faire du code plus rapide que du natif dans certain cas et beaucoup plus lent dans d'autres.

Par exemple, une bonne grosse boucle de traitement numérique avec la moitier des data étant constant pendant cette boucle (un gros filtre numérique sur une image par exemple); La VM peut te faire de la constante propagation et te simplifier de beaucoup le code avant d'en faire du code natif (pour un JIT).

Par contre dans une grosse application métier, avec tout plein de code dans tous les sens, sans vraiment de grosses boucles de calcul, le jit ne fait pas vraiment effet car il y a trop de code en jeu et dans ce cas, le natif serait plus rapide.

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

Tu as des liens ?

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

Ou peut être que le principal facteur c'est pas les outils mais la sémantique et les services qu'il y a derrière le langage... Le truc que j'appelle VM.

je dirais plutôt leur capacité à être optimiser en statique, ce qui rend les langage comme perl et pyhton incapable d'être compiler correctement.

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

Et cela se passe comme une fleur avec la partie commune ?

Tu me dira mono doit faire des testes de conformité avec l'implémentation de MS.

Il n'y a guère que le C/C++ qui a autant de fournisseur de compilateur C.

D'ailleurs, une question à part: est-ce que mono tourne sous d'autre cible que le x86 ?

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

Tu veux que je te trouve un compilo C# autre que celui de MS ? C'est une blague ?

Je t'ai trouvé des exemples de langages ayant les 2 technologies. En OCaml, je crois que la version native est plus rapide que la VM.

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

Gni ? Tu confonds pas tout là ? on parle de quoi ? Du langage ? Du compilateur ? Du runtime ou des bibliothèques ?

Je parle des framework MS et ceux de Novell.

Encore un truc que je supporte pas dans ce langage, l'absence de spécification pour l'ABI du code produit.

Il faut voir la taille du bousin.

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

ocaml ? lisp ? Java avec gcj ? Mais je ne connais pas assez.

En général, on développe un langage pour un usage avec un runtime. Faire 2 runtime est difficile et surtout a un intérêt pratique faible.

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

Ou que le compilateur natif est mauvais.

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

Des fois je préfères moins d'optimisation :)

tu imagines ne pas inliner l'équivalent de tab[i] ?

Mais bon c'est tout le concept des templates que je trouve foireux.

Moi aussi. Mais c'est en même temps la force de C++ qui lui permet d'être encore très utilisé maintenant.


Le problème, c'est quand les étapes de compilation ne se font pas en même temps par le même compilateur, c'est là que c'est le bordel : tu diffuse une lib, tu regénères qu'une partie, t'utilises un compilateur ou une plateforme différente, etc. Les risques de désynchro ou d'incompatibilité entre les modules est trop forte.

Cela a toujours été vrai. Ce qui tourne sous .NET à peu de chance de tourner correctement sous Mono (sauf à y faire des tests spécifiques).
En plus, l'ABI C++ de gcc 3.* changeait beaucoup.

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

Ils interdisent la présence de proxy, et surtout il interdisent les scan qui partent de leur réseau (si ils ne le font pas il risque de se faire couper l'accès par les réseaux scanné).

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

on pourrait imaginer que c'est la classe qui fait concrètement la réservation mémoire

Et comment tu fais les allocations dans la pile pour les objets automatique ?

Enfin déjà interdire la présence du moindre code pour éviter qu'il soit compilé différemment dans la lib et par celui qui l'utilise ca serait bien.

Dans ce cas tu te prives de beaucoup de possibilités d'optimisation, typiquement les accesseurs devraient être dans le .h pour être inline.

Ca suppose que le code des templates notamment puisse être mis ailleurs (me semble que ca va être le cas dans la prochaine version).

Il doivent être compiler, donc cela parait difficile.


Enfin bref, c'est trop tard, je dis juste que ca a été très mal conçu ce système de .h et que c'est une vraie plaie à l'utilisation : y'a intérêt d'avoir des conventions et d'être très rigoureux. Et surtout que tout le monde fasse comme toi dans le même projet sinon c'est la merde.

Chaque élément de compile doit avoir toutes les infos. Et les infos partagées sont dans le .h. La seul étape qui reste est le link (long car il concerne l'ensemble du projet).

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

Évidement que cela un intérêt.

Si C# peut utiliser les 2 modes tant mieux. Mais cela ne rend pas le concept de VM comme flou.

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

A ma connaissance, il y a peu de GC qui soit parfait.

Il y a le reference counting qui a un gros cout d'execution à faire tourner des counter partout auquelle il faut rajouter ensuite un parcours pour attraper les cycles (et en cas de graphe ?).

Il y a les systèmes de recopie par suivi des pointeurs, il y a la recopie en estimant que toute données est un pointeur.

Les techniques de GC ne sont pas parfaite non plus. Ce n'est pas encore un moyen d'avoir un binaire qui tourne 10 ans sans problème.

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

Mais non la limite n'est pas flou du tout.

Elle est même évidente quand tu regarde l'exécution d'un programme sous VM et un binaire natif.

Dans le cas du binaire, tu as le loader qui map le fichier en mémoire, puis la libc va chercher les libs dynamique qui vont bien, puis le program counter est mis sur le _main().

Dans le cas d'une VM, (comme pour les shell), un programme est démarrer, la VM, qui ensuite lit le code sous forme de bytecode qui est une donné pour lui, et ensuite il le transforme pour soit l'interpréter, soit le compiler (JIT).

La différence est flagrante !

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

Si tu n'as pas de données privées dans les déclarations de class comment le compilo peut connaitre la taille de l'objet ?

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