ooc est un langage de programmation libre, orienté objet, compilé, et portable. Il se veut léger, rapide, pratique et surtout libre !
Un des buts d'ooc est de combiner les avantages de langages de haut niveau comme Java ou C# avec la rapidité du C. Pour ce faire, les fichiers sources .ooc sont traduits en C, puis compilés avec GCC, ICC (Intel), ou n'importe quel compilateur C99.
ooc est orienté objet, profite du ramasse-miettes conservatif Boehm (garbage collector), organise les classes en paquetages, gère automatiquement les dépendances et toutes les bibliothèques C sont utilisables nativement. Malgré la jeunesse relative du langage (5 mois) et de son compilateur, il est déjà très utilisable. Son SDK (bibliothèque standard) contient quelques classes pour les entrées/sorties, la manipulation de chaîne de caractères, la gestion du temps, etc.
L'implémentation de référence du compilateur est codée en Java, donc il est assez portable. Cependant, des binaires sont construits pour Linux et Windows avec GCJ (le compilateur Java de la famille GNU), donc il n'y a pas besoin du JRE pour faire fonctionner le compilateur. En outre, les programmes produits sont en C99 pur, ils ne nécessitent donc pas Java du tout.
La version 0.2 du langage et de son compilateur introduisent les changements suivants :
- Une syntaxe plus claire et lisible ;
- Beaucoup de corrections de bugs ;
- De meilleurs bindings GTK/SDL/OpenGL/GLU/GLUT ;
- Une meilleure compatibilité Windows (MinGW) ;
- Désormais distribué sous forme binaire pour Linux et Windows ;
- Pour plus d'informations, voir le journal des modifications sur GitHub.
Aller plus loin
- Site officiel (68 clics)
- Téléchargement (13 clics)
- Guide de Référence (16 clics)
- Le dépot git (11 clics)
# Hmmm
Posté par dest . Évalué à 3.
C'est pas pour rien qu'on parle de plus en plus d'approches formelles.
De plus OCAML dispose d'un garbage collector très puissant, c'est objet, y'a des exceptions, c'est fortement typé, pas de buffer overflow,... (liste non exhaustive).
Bref ooc d'après ta description ne me rassure pas sur les buffer overflow, les cast, les pointeurs. Plein de sources à trous.
[^] # Re: Hmmm
Posté par Amos Wenger . Évalué à 4.
Il est vrai que pour l'instant, la "sécurité" n'a pas ete un objectif prédominant dans l'implémentation. Cependant, rien dans le design du langage/du compilateur ne s'oppose a l'intégration de mécanismes de contrôle tel qu'on peut trouver dans OCaml, par exemple.
Malheureusement la sécurité a un coût performance, c'est pour ça que je pense laisse l'option de désactiver les (futurs) mécanismes de sécurité/vérification dans les prochaines versions. (Exemple: activé pendant le développement/débuggage, désactivé en environnement ou la performance est critique)
Après, il faut garder a l'esprit qu'aucun langage n'est la réponse définitive a tous les besoins. Quant a coder "sécurisé", pourquoi ne pas choisir Ada?
En résumé, pour continuer la série des métaphores, je dirais que: "ooc still allows you to shoot yourself in the foot, but with a cooler weapon" ;)
[^] # Re: Hmmm
Posté par dest . Évalué à 4.
OCaml est sécurisé et s'exécute presqu'aussi vite que du C.
Après les performances sont nécessaires si tu fais du calcul très lourd comme en crypto mais de nos jours, avec la puissance dont nos machines disposent, il faut d'abord miser sur la sécurité avant de penser aux performances.
[^] # Re: Hmmm
Posté par Amos Wenger . Évalué à 4.
[^] # Re: Hmmm
Posté par oops (site web personnel) . Évalué à 2.
Avec ObjC, tu peux mélanger du C et de l'ObjC. Ce qui est interessant pour les parties à optimiser.
Sinon pour les appels de fonctions/méthodes/messages j'avais vu passer des benchs sur une liste GNUstep (la personne qui avait posté s'appelé Alexender Malmberg) mais je ne retrouve plus le post.
En gros pour ces appels :
1-ObjC avec IMP-caching
2-C
3- appel ObjC "standard"
[^] # Re: Hmmm
Posté par Nicolas Roard (site web personnel) . Évalué à 1.
http://camaelon.blogspot.com/2007/01/fun-with-objective-c.ht(...)
Note qu'en pratique, la seule fois ou j'ai fait du IMP-caching c'etait sur un algo de rendu volumetrique qui devait aller aussi vite que possible (pour avoir du rendu interactif reparti), et encore c'etait loin d'avoir ete LE facteur determinant au niveau rapidite...
Pour un logiciel 'normal' y'a franchement peu d'interet de nos jours je trouve. Maintenant bon, ce qu'il y a de bien c'est qu'on peut toujours le faire si vraiment on veut ;-)
[^] # Re: Hmmm
Posté par barmic . Évalué à 1.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Hmmm
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
"La première sécurité est la liberté"
[^] # Re: Hmmm
Posté par Amos Wenger . Évalué à 1.
Pour les intéressés, voici le rapport de bug correspondant: [https://bugs.launchpad.net/ooc-language/+bug/392551]
[^] # Re: Hmmm
Posté par chicco . Évalué à 5.
Je ne sais pas si vous connaissez ATS (Applied Type System), ça a presque toutes les bonnes propriétés du Caml: typage statique, garbage collector, efficace, fonctions de première classe, etc.
Mais en plus il y a plein d'autres choses vraiment bien:
- types linéaires et types dépendants
- possibilité de gérer sa mémoire à la main, mais de manière sûre. C'est à dire que si l'on ne veut pas du coût supplémentaire introduit parfois par le GC, on peut faire ses mallocs à la mains, mais il faut que le code reste bien typé ( ce sont les types linéaires qui gèrent ça: il est imposible de faire une segfault )
- les fonctions C sont typables ( on doit ajouter des annotations de type bien sûr ). Il est donc possible d'appeler des fonctions C sans avoir à écrire de binding.
Bon il y a forcément quelques petits problèmes, déjà, contrairement au Caml, les types ne sont pas complètement inférables, il faut donc annoter les fonctions. En pratique ce n'est pas un problème car quand on code une fonction, on sait toujours quel type elle devrait avoir.
Le compilateur est un peu jeune ( c'est un projet de recherche ), et ça manque un peu de finition ( les erreurs de type ne sont pas toujours facile à comprendre par exemple ).
Ça manque aussi d'un toplevel.
Et c'est peut être un peu difficile au début de comprendre à quoi correspondent tous les types.
Et ne me dites pas "oui mais il n'y a pas d'objets". Le système de type est largement assez puissant pour faire tout ce qu'on pourrait vouloir faire avec des objets.
Pour se faire une idée: [http://www.ats-lang.org/TUTORIAL/tutorial.html]
[^] # Re: Hmmm
Posté par Jérémie Dimino . Évalué à 4.
La sécurité en ocaml est assuré par du typage 'statique'. Il n'y a donc aucun impact sur les performances vu que tout est vérifié au moment de la compilation. En fait c'est même le contraire, vu que le compilateur connaît plus de truc sur le code il est capable de faire plus d'optimisations qu'un compilateur C.
[^] # Re: Hmmm
Posté par Amos Wenger . Évalué à 2.
Pour ce qui est du typage, ooc est déjà sensiblement plus malin/contraignant qu'un simple compilateur C. Si on déclare les variables avec le bon type, le compilateur vérifie tous les appels fonctions et accès aux champs.
La seule manière de contourner cette sécurité est de faire un méchant cast (seuls les casts ne sont pas vérifiés). Donc en gros, le programmeur a potentiellement les problèmes qu'il mérite / est puni selon les risques qu'il prend.
[^] # Re: Hmmm
Posté par JoeltheLion (site web personnel) . Évalué à 6.
La sécurité en ocaml est assuré par du typage 'statique'. Il n'y a donc aucun impact sur les performances vu que tout est vérifié au moment de la compilation. En fait c'est même le contraire, vu que le compilateur connaît plus de truc sur le code il est capable de faire plus d'optimisations qu'un compilateur C.
Je rappelle qu'en pratique, le code Ocaml s'execute environ 2 fois moins vite que du code en C ou en C++
http://shootout.alioth.debian.org/u64q/benchmark.php?test=al(...)
On peut critiquer le benchmark tout ce qu'on veut, il reflète en général bien la réalité.
[^] # Re: Hmmm
Posté par Nicolas Boulay (site web personnel) . Évalué à 3.
"La première sécurité est la liberté"
[^] # Re: Hmmm
Posté par auve . Évalué à 1.
[^] # Re: Hmmm
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
En quoi C, même totalement tordu, n'est pas complètement défini ?
"La première sécurité est la liberté"
[^] # Re: Hmmm
Posté par reno . Évalué à 1.
Il doit y en avoir d'autre..
[^] # Re: Hmmm
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
Dans les faits, tu as sois une access violation, soit d'anciennes données, soit des données d'autres structures.
Donc, formel veut dire que tout les cas sont spécifiés, qu'il n'y aucun comportement user defined, ou aléatoire ou dépendant de l'implémentation .
"La première sécurité est la liberté"
[^] # Re: Hmmm
Posté par auve . Évalué à 1.
Par contre, dire qu'un langage de programmation a une sémantique formelle, ça veut dire que tu peux trouver quelque-part une description mathématique, i.e. précise et claire, de son comportement, que toutes les implantations sont sensées respecter. Ça a malheureusement été le cas de très peu de langages de programmation ; citons pour les plus connus Algol 60 et Standard ML, ou encore un certain Esterel (;-)).
Pour en revenir à OCaml, malheureusement il n'a pas de sémantique formelle complète écrite quelque-part ; par contre, les diverses fonctionnalités spécifiques et innovantes du langage (la partie objet, les variantes polymorphe, sa machine abstraite, son système de modules...) sont décrites formellement dans les publications associées.
[^] # Re: Hmmm
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
"La première sécurité est la liberté"
[^] # Re: Hmmm
Posté par Vivi (site web personnel) . Évalué à 1.
et Scheme
[^] # Re: Hmmm
Posté par reno . Évalué à 2.
Je ne suis pas certain d'avoir raison..
[^] # Re: Hmmm
Posté par Vivi (site web personnel) . Évalué à 1.
sauf qu'OCaml n'est pas une surcouche du C !
# ObjectiveC
Posté par Paul . Évalué à 3.
Simple curiosité.
[^] # Re: ObjectiveC
Posté par Amos Wenger . Évalué à 2.
Voici les quelques différences qui me sautent aux yeux:
- Objective-C utilise l'envoi de messages au lieu de l'appel de méthode
- Objective-C est un sur-ensemble strict du C, donc il hérite de ses bizarreries syntaxiques.
- Objective-C met l'accent sur les décisions au temps de l'execution, alors qu'ooc essaie d'attraper les erreurs au temps de la compilation.
- Objective-C n'est pas traduit en C mais compilé directement. Parmi les inconvénients, cela veut dire qu'il faut porter le compilateur sous toutes les plateformes visées. Dans le cas d'ooc, on peut utiliser le compilateur ooc pour traduire .ooc -> .c/.h, puis utiliser gcc pour cross-compiler sur un des 50+ architectures qu'il supporte.
Enfin, ooc est inspiré en partie de Java, lui-meme inspire (entre autres) d'Objective-C, lui-meme inspire de Smalltalk. Concrètement, Objective-C est un langage mature qui apparamment ne changera plus beaucoup. Cela permet une grande stabilité, mais le langage est condamné a rester dans ses habitudes: il est trop tard pour tirer les leçons du passé (par exemple, gcc semble ne pas supporter totalement ObjC 2.0). Par contraste, ooc est un jeune galopin qui essaie d'apprendre de ses grands-parents. Il est largement encore temps de s'impliquer et d'influer sur le design.
[^] # Re: ObjectiveC
Posté par Damien Cassou . Évalué à 4.
Pour moi «envoi de message» signifie juste que tu vas choisir la méthode à appeler (son implémentation) au moment de l'exécution et pas de la compilation. Quand tu fais de l'objet, je ne vois pas bien comment tu pourrais faire autrement : tu choisis la méthode en fonction du type dynamique de ton objet que tu ne connais pas, par définition, au moment de la compilation. Tu as une autre définition qui te permet de dire que vous avez 2 approches différentes ?
[^] # Re: ObjectiveC
Posté par Amos Wenger . Évalué à 1.
[^] # Re: ObjectiveC
Posté par Damien Cassou . Évalué à 2.
Je dois manquer quelque chose. Dans l'exemple suivant:
class Wheel {
func roll {printf("Quelque-chose ne tourne pas rond.\n");}
}
class BetterWheel from Wheel {
override roll {printf("Pierre qui roule n'amasse pas mousse\n");}
}
func main {
BetterWheel bw = new;
Wheel w2 = (Wheel) bw; // cast as in C/Java
w2.roll; // prints "Pierre qui roule", etc.
}
Lors de la compilation de w2.roll, tu associes l'appel à roll à la méthode roll de Wheel (le type statique de w2). Lors de l'exécution, il te faut exécuter la méthode roll de BetterWheel et pas celle de Wheel.
Le principe de base étant de partir de la classe dynamique de l'objet pour remonter la chaîne d'héritage jusqu'à tomber sur une implémentation de la méthode appelée.
C'est pas ça que tu fais ?
[^] # Re: ObjectiveC
Posté par Amos Wenger . Évalué à 1.
Quand tu construis le premier objet BetterWheel, il est assigné au champ "roll" dans sa structure de class l'adresse de la fonction roll tel qu'implémenté dans BetterWheel. Ainsi, quand w2.roll est traduit par le compilateur en w2->_class->_roll() cela référence la bonne version.
L'assignation des pointeurs de méthodes dans les structures de classes n'est faite qu'une seule fois par classe, et toutes les structures d'objet pointent vers la meme structure de classe, donc il n'y a quasiment aucun gaspillage mémoire ni CPU.
[^] # Re: ObjectiveC
Posté par Damien (site web personnel) . Évalué à 2.
Si, parce que si tu as 100 méthodes dans une superclasse A, et une redéfinition dans sa sous-classe B, alors la table de lookup de B contient 101 entrées dont 100 redondantes.
Le lookup récursif marche très bien et s'optimise avec les polymorphic inline caches. Cherche les papiers sur le compilateur de Self (http://selflanguage.org ), ou http://www.lirmm.fr/prm/language.html .
[^] # Re: ObjectiveC
Posté par Amos Wenger . Évalué à 2.
En revanche, comme la table de lookup est partagée entre toutes les instances d'une même classe, je trouvais ça correct comme utilisation mémoire. J'ai plus souvent 10'000 objets avec 10 méthodes que 10 objets avec 10'000 méthodes.
[^] # Re: ObjectiveC
Posté par Marc (site web personnel) . Évalué à 2.
gcc inclue un frontal objc. Donc ton approche pourrait se justifier pour les cibles où gcc n'est pas porté, mais pour laquelle un autre compilo C existe. Mais là, on peut répondre qu'il existe des s2s objc->c (comme POC: http://users.telenet.be/stes/compiler.html ).
(c'était juste pour info... sur le reste, j'ai pas d'avie pertinent à donner)
[^] # Re: ObjectiveC
Posté par Marc (site web personnel) . Évalué à 2.
il parait même que ça s'écrit avis. Trop fou.
(ah, et bien vu la geekscote lors de la détection de l'auto-réponse :D)
[^] # Re: ObjectiveC
Posté par Amos Wenger . Évalué à 1.
Ha oui, bien vu le coup des source a source ObjC. Sont-ils bien aussi bien maintenus/compatibles que les compilateurs plus standards?
[^] # Re: ObjectiveC
Posté par Marc (site web personnel) . Évalué à 1.
[^] # Re: ObjectiveC
Posté par B16F4RV4RD1N . Évalué à 2.
Only wimps use tape backup: real men just upload their important stuff on megaupload, and let the rest of the world ~~mirror~~ link to it
[^] # Re: ObjectiveC
Posté par Nicolas Roard (site web personnel) . Évalué à 2.
- Objective-C met l'accent sur les décisions au temps de l'execution, alors qu'ooc essaie d'attraper les erreurs au temps de la compilation.
Ben uniquement si tu le veux, sinon le compilo t'engueule hein...
- Objective-C n'est pas traduit en C mais compilé directement. Parmi les inconvénients, cela veut dire qu'il faut porter le compilateur sous toutes les plateformes visées. Dans le cas d'ooc, on peut utiliser le compilateur ooc pour traduire .ooc -> .c/.h, puis utiliser gcc pour cross-compiler sur un des 50+ architectures qu'il supporte.
En meme temps vu que le compilo objc le plus utilise c'est gcc, on est a peu pres tranquille concernant la problematique du multi-plateforme ;-)
Plus serieusement, il y a pas mal de trucs interessants fait en ce moment autour de LLVM, et David Chisnall a implemente un frontend Objective-C.
Enfin, ooc est inspiré en partie de Java, lui-meme inspire (entre autres) d'Objective-C, lui-meme inspire de Smalltalk. Concrètement, Objective-C est un langage mature qui apparamment ne changera plus beaucoup. Cela permet une grande stabilité, mais le langage est condamné a rester dans ses habitudes: il est trop tard pour tirer les leçons du passé (par exemple, gcc semble ne pas supporter totalement ObjC 2.0). Par contraste, ooc est un jeune galopin qui essaie d'apprendre de ses grands-parents. Il est largement encore temps de s'impliquer et d'influer sur le design.
J'allait justement souligner ObjC 2.0 -- pour un langage qui ne changera plus beaucoup, c'est un changement assez recent... (bon par contre, c'est en gros Apple qui pousse :-/)
Pour ce qui est du support ObjC 2.0 dans gcc, pas sur a 100% mais il me semble que gcc supporte tout ce qu'il faut... mais libobjc non. ObjC est dynamique et utilise un runtime, i.e. libobjc sous linux, et le runtime NeXT sur OSX, qui lui supporte ce qu'il faut.
[^] # Re: ObjectiveC
Posté par Sebastien . Évalué à 1.
# Vala
Posté par Sytoka Modon (site web personnel) . Évalué à 9.
[^] # Re: Vala
Posté par Amos Wenger . Évalué à 6.
Par contraste, ooc se base uniquement sur la librairie standard C. Cela est avantageux tant en terme de taille que de déploiement sur des plateformes disons.. exotiques (je pense en particulier a Haiku, réécriture libre du défunt BeOS).
Ceci dit, Vala est un excellent langage que je recommande également de tester. Il est sans aucun doute l'avenir du développement des applications Gnome/GTK, vu son fort degré d'intégration avec ces librairies.
[^] # Re: Vala
Posté par Kangs . Évalué à 2.
[^] # Re: Vala
Posté par Amos Wenger . Évalué à 2.
Pour les maps & compagnie, il va falloir attendre la 0.3, qui ne saurait tarder =) Je rappelle au passage que tous ceux qui ont une âme charitable et souhaitent contribuer du code sont plus que les bienvenus. Tout le monde en profite.
[^] # Re: Vala
Posté par Kangs . Évalué à 2.
"Array is a fixed-size type. To store a variable number of elements, see the ArrayList and SparseList classes."
J'ai ouvert tous les chapitres et fait une recherche sur ArrayList, et je n'ai trouvé qu'une brève allusion qu'au chapitre 4.
Elles ne sont pas encore documentées tes class ? (ou vraiment je suis lourd )
Sinon je suis comptent qui tu en prévois d'autres ;)
[^] # Re: Vala
Posté par Amos Wenger . Évalué à 4.
Donc oui ma foi tu as fort raison, le SDK pourrait être un peu plus documenté. En l'occurence, j'utilise une notation a la javadoc dans les sources, donc par ici tu devrais trouver ton bonheur: [http://github.com/amoswenger/ooc/tree/4a977fe092e18bd9cdaffe663b1519905deb0d23/sdk/structs]
1000 fois désolé pour le manque de doc, j'ai déjà passé 2 nuits de suite a écrire le language reference guide, donc le reste viendra en son temps =)
# Et Vala ?
Posté par pix (site web personnel) . Évalué à -1.
# Version 0.2
Posté par Thierry Thomas (site web personnel, Mastodon) . Évalué à 1.
[^] # Re: Version 0.2
Posté par Amos Wenger . Évalué à 2.
# lan_GA_ge
Posté par totof2000 . Évalué à 6.
[^] # Re: lan_GA_ge
Posté par Amos Wenger . Évalué à 2.
[^] # Re: lan_GA_ge
Posté par Amos Wenger . Évalué à 1.
hum.
# hello world?
Posté par case42 (site web personnel) . Évalué à 3.
[^] # Re: hello world?
Posté par Amos Wenger . Évalué à 1.
Sinon, la meilleure ressource pour les exemples reste le dépôt git: [http://github.com/amoswenger/ooc/tree/4a977fe092e18bd9cdaffe(...)]
Et pour la route, un petit hello world fait maison:
func main {
printf("Hello, Linuxfr world =)\n");
}
[^] # Re: hello world?
Posté par windu.2b . Évalué à 4.
:-p
[^] # Re: hello world?
Posté par Amos Wenger . Évalué à 3.
[^] # Re: hello world?
Posté par Amos Wenger . Évalué à 2.
[^] # Re: hello world?
Posté par アントニ ドミ . Évalué à 3.
/** The world must be getting tired of being said hello */
func main {
printf("Goodbye, world !\n");
new Bomb.start;
}
class Bomb {
func start {
for(Int i: reverse 1..11) {
printf("%d...", i);
fflush(stdout);
Time.sleepSec(1);
}
printf("BOOM!\n");
}
}
# Ooc !
Posté par Pierre Bourdon . Évalué à 6.
[^] # Re: Ooc !
Posté par Amos Wenger . Évalué à 0.
[^] # Re: Ooc !
Posté par LupusMic (site web personnel, Mastodon) . Évalué à 4.
[^] # Re: Ooc !
Posté par Amos Wenger . Évalué à 1.
# Succès du langage
Posté par letsyl . Évalué à 6.
[^] # Re: Succès du langage
Posté par Kangs . Évalué à 1.
[^] # Re: Succès du langage
Posté par Amos Wenger . Évalué à 3.
Mais de toute façon, Bjarne fait son rebelle, il se rase, lui!
# Rapidité du C ... et ramasse-miettes ?
Posté par Benoit Jacob (site web personnel) . Évalué à 1.
Or ça c'est une contradiction: un ramasse-miettes ça a un coût en termes de performances et d'utilisation de la mémoire. Ce n'est pas sans raison que les langages orientés performance, ayant une philophie "aucun surcoût par rapport à l'assembleur", tels que le C et le C++, n'utilisent pas de ramasse-miettes.
http://en.wikipedia.org/wiki/Garbage_collection_(computer_sc(...)
[^] # Re: Rapidité du C ... et ramasse-miettes ?
Posté par Pierre Bourdon . Évalué à 3.
Mais c'est bien entendu uniquement « dans certains cas ». Dans d'autres, ça ralentira effectivement le programme un peu, mais ça simplifie énormément la programmation (et ça évite de leaker à cause d'un free oublié quelque part).
[^] # Re: Rapidité du C ... et ramasse-miettes ?
Posté par Benoit Jacob (site web personnel) . Évalué à 2.
Pour ce qui est des fuites mémoire, le problème a largement disparu depuis l'apparition d'outils tels que valgrind. Franchement, tu fais "valgrind ./mon_programme", et bloum, tu vois toutes les fuites avec référence vers la ligne de code source fautive. C'est même beaucoup plus puissant que tout ce qu'un GC intégré à un langage peut espérer couvrir, parce que ça couvre non seulement ton programme mais aussi les librairies qu'il utilise, or une certaine partie des fuites mémoire ont lieu à cause d'un malentendu avec une librairie utilisée.
[^] # Re: Rapidité du C ... et ramasse-miettes ?
Posté par Amos Wenger . Évalué à 5.
Et puis comme je me lasse de me répéter, je vais citer Wikipédia pour changer, a propos des GC: "Many consider the penalty very small compared to the benefits it brings." [http://en.wikipedia.org/wiki/Garbage_collection_(computer_sc(...)]
Pour les fuites mémoires, heu, moui, moyen, je ne sais pas quelle est la complexité des structures de données des programmes que tu as du écrire en C, m'enfin il me semblait que même de très bon programmeurs devaient réfléchir a deux fois avant de gérer tout correctement.
Quant a Valgrind, excellent outil, je l'utilise régulièrement pour résoudre des problèmes plus sérieux que des fuites (violation d'accès mémoire).
J'ai rien contre ajouter l'option de désactiver le GC dans ooc, mais ca servirait strictement a rien, tout le SDK est codé dans l'esprit "on s'occupe pas de libérer la mémoire", donc dans ce cas là autant coder en C.
Faut savoir choisir son langage, pour la tache qu'on a à accomplir. Qu'est-ce que tu penserais de quelqu'un qui se mettrait a utiliser du Java sur des téléphones mobiles ? (Oh, mais.. attendez.. ils le font.. Bizarre. Vraiment.)
[^] # Re: Rapidité du C ... et ramasse-miettes ?
Posté par JoeltheLion (site web personnel) . Évalué à -2.
En théorie, oui. En pratique, je le croirai quand je verai un programme non écrit en C ou en C++ s'executer aussi vite. Pour l'instant, ça existe surtout dans les livres.
[^] # Re: Rapidité du C ... et ramasse-miettes ?
Posté par Amos Wenger . Évalué à 2.
Déjà, tu pars du principe que C et C++ sont les deux langages les plus rapides. Notre cher LupusMic objecterait que tu confond langage et implémentation, et il aurait raison.
Mais.. désolé de te décevoir. Comme example, les programmes écrits en Fortran sont généralement plus rapides (je laisse Google te rassurer sur ce point.)
Ensuite, il y a des benchmark réels (je lis pas de bouquins sur les performances moi, je télécharge et compile les benchmarks existant) qui confirment ce que Pierre Bourdon dit.
Pour pypy, c'est par ici: [http://morepypy.blogspot.com/2008/01/rpython-can-be-faster-t(...)]
Pour Java, c'est par la: [http://kano.net/javabench/]
Et pour ooc, un peu plus bas dans cette page (mais c'est un microbench assez insignifiant dans la discussion,)
A noter que, comme ooc est traduit en C, ça n'a pas beaucoup de sens de "comparer les performances d'ooc a C", mais plutôt de "comparer malloc/free au Boehm GC".
[^] # Re: Rapidité du C ... et ramasse-miettes ?
Posté par Benoit Jacob (site web personnel) . Évalué à 3.
Non: indépendamment du compilateur utilisé, il reste vrai que le C et le C++ ne forcent pas le compilateur à rajouter du code en plus de ce que le programmeur a écrit. Contrairement aux langages à ramasse-miettes.
Il y a une toute petite exception avec certaines fonctionnalités du C++ (classes virtuelles etc) mais ces fonctionnalités ne sont pas obligatoires, on ne les utilise que si on en a l'usage, et même alors ça reste minimaliste de sorte qu'on ne pourrait pas obtenir la fonctionnalité équivalente à moins de frais.
[^] # Re: Rapidité du C ... et ramasse-miettes ?
Posté par Amos Wenger . Évalué à 1.
[^] # Re: Rapidité du C ... et ramasse-miettes ?
Posté par Pierre Bourdon . Évalué à 1.
[^] # Re: Rapidité du C ... et ramasse-miettes ?
Posté par Amos Wenger . Évalué à 2.
[^] # Re: Rapidité du C ... et ramasse-miettes ?
Posté par rhizome . Évalué à 2.
[^] # Re: Rapidité du C ... et ramasse-miettes ?
Posté par pasBill pasGates . Évalué à 6.
Le mot cle const, la notion de private/public/protected , etc... ne coutent pas un centime non plus.
[^] # Re: Rapidité du C ... et ramasse-miettes ?
Posté par Amos Wenger . Évalué à 2.
[^] # Re: Rapidité du C ... et ramasse-miettes ?
Posté par Amos Wenger . Évalué à 2.
Sur un test réalisé par curiosité, la création de 1'000'000+ petits objets dans une boucle est environ 2x plus rapide en ooc qu'en C++ (qui n'utilise pas de GC, donc). Ces résultats, bien que peu fiables, confirment les études faites sur la performance des garbage collectors.
En pratique, une application qui alloue beaucoup de petits objets souvent tournera bien plus vite avec un garbage collector. En contraste, une application qui alloue peu de très gros objets tournera mieux en gestion de mémoire manuelle.
Pour de plus amples informations sur ce sujet, des diapos et documents expliquant les avantages/désavantages, je ne peux que vous référer a la page du GC utilisé par ooc: [http://www.hpl.hp.com/personal/Hans_Boehm/gc/]
[^] # Re: Rapidité du C ... et ramasse-miettes ?
Posté par Amos Wenger . Évalué à 2.
Resultats:
tsubaka tmp # time ./newbench_cxx
real 0m8.048s
user 0m7.859s
sys 0m0.011s
tsubaka tmp # time ./newbench
real 0m3.322s
user 0m3.279s
sys 0m0.011s
tsubaka tmp #
Makefile:
all:
g++ newbench.cxx -o newbench_cxx
ooc newbench
C++:
class Dummy {
private:
int i;
public:
Dummy();
void increment();
};
Dummy::Dummy() {
this->i = 0;
}
void Dummy::increment() {
this->i++;
}
int main() {
for(int i = 0; i < 100000000; i++) {
Dummy* d = new Dummy();
d->increment();
delete d;
}
}
ooc:
class Dummy {
Int i = 0;
func increment { i++; }
}
func main {
for(Int i: 0..100_000_000) {
new Dummy.increment;
}
}
Comme tous les benchmarks, a prendre avec des pincettes.
[^] # Re: Rapidité du C ... et ramasse-miettes ?
Posté par Benoit Jacob (site web personnel) . Évalué à -1.
Donc ton makefile devrait dire à g++ d'optimiser:
g++ -O2 newbench.cxx -o newbench_cxx
Maintenant si tu te renseignais sur le C++ tu verrais que question performances il est strictement à égalité avec le C, donc le résultat de ton benchmark aurait pu te mettre la puce à l'oreille !
[^] # Re: Rapidité du C ... et ramasse-miettes ?
Posté par Amos Wenger . Évalué à 2.
Malheureusement, tu aurais pu le constater par toi-même si tu avais fait l'effort de télécharger ooc et de compiler le benchmark.
Voici donc les résultats avec -O2, dans les deux cas.
Résultats:
tsubaka tmp # time ./newbench_cxx_O1
real 0m8.439s
user 0m8.354s
sys 0m0.004s
tsubaka tmp # time ./newbench_O1
real 0m3.402s
user 0m3.301s
sys 0m0.012s
tsubaka tmp # time ./newbench_cxx_O2
real 0m6.911s
user 0m6.790s
sys 0m0.007s
tsubaka tmp # time ./newbench_O2
real 0m2.813s
user 0m2.767s
sys 0m0.005s
tsubaka tmp #
Makefile:
all:
g++ newbench.cxx -o newbench_cxx_O1
ooc newbench
mv newbench newbench_O1
g++ newbench.cxx -O2 -o newbench_cxx_O2
ooc newbench -backend=gcc,-O2
mv newbench newbench_O2
[^] # Re: Rapidité du C ... et ramasse-miettes ?
Posté par Benoit Jacob (site web personnel) . Évalué à 0.
Maintenant tout s'explique: c'est le bench dont tu parlais plus haut, qui crée et détruit un million de petits objets.
Comme je te l'ai déjà dit, oui, bien sûr que sur un benchmark comme ça le GC permet d'aller plus vite. Je pensais que tu avais compris que dans toute situation on peut toujours trouver le benchmark sur mesure qui prouve ce qu'on veut. C/C++ restent plus rapides que n'importe quel langage à GC, parce qu'avec eux on peut utiliser un GC si l'on veut tout en pouvant aussi de _pas_ en utiliser un si ce n'est pas utile.
[^] # Re: Rapidité du C ... et ramasse-miettes ?
Posté par Amos Wenger . Évalué à 1.
Et maintenant?
[^] # Re: Rapidité du C ... et ramasse-miettes ?
Posté par Benoit Jacob (site web personnel) . Évalué à 1.
Bon bref il faut vraiment concocter un benchmark pas réaliste comme celui-là pour voir apparaître une différence! Pas réaliste, parce que de toute façon, même avec un GC, créer et détruire des millions de petits objets ça n'est pas efficace donc lorsque la vitesse est importante, on évite (par exemple en allouant un millier d'objets d'un coup).
[^] # Re: Rapidité du C ... et ramasse-miettes ?
Posté par Amos Wenger . Évalué à 1.
Et puis bon, heu, écart resserré... 12% plus rapide quand meme, c'est pas rien il me semble.
Allez, rajoutons un sac de pierres sur le dos d'ooc: [http://ooc.pastebin.com/m512a5d78]
Et pourtant il ne bronche pas:
tsubaka ooc_tmp_nogc_if # time ../../withgc/newbench_cxx_O1
real 0m8.014s
user 0m7.907s
sys 0m0.006s
tsubaka ooc_tmp_nogc_if # time ./newbench_O1_nogc_if
real 0m7.376s
user 0m7.228s
sys 0m0.006s
tsubaka ooc_tmp_nogc_if # time ../../withgc/newbench_cxx_O2
real 0m6.842s
user 0m6.738s
sys 0m0.005s
tsubaka ooc_tmp_nogc_if # time ./newbench_O2_nogc_if
real 0m5.943s
user 0m5.890s
sys 0m0.005s
Brave bête, ooc, brave bête.
[^] # Re: Rapidité du C ... et ramasse-miettes ?
Posté par Benoit Jacob (site web personnel) . Évalué à 2.
[^] # Re: Rapidité du C ... et ramasse-miettes ?
Posté par Amos Wenger . Évalué à 1.
Si tu as les sources de benchmarks plus réalistes écrits en C++ je me ferais une joie de les porter en ooc pour poster les résultats comparatifs (avec en sans GC).
[^] # Re: Rapidité du C ... et ramasse-miettes ?
Posté par Sytoka Modon (site web personnel) . Évalué à 3.
[^] # Re: Rapidité du C ... et ramasse-miettes ?
Posté par Amos Wenger . Évalué à 2.
[^] # Re: Rapidité du C ... et ramasse-miettes ?
Posté par JoeltheLion (site web personnel) . Évalué à 5.
[^] # Re: Rapidité du C ... et ramasse-miettes ?
Posté par Amos Wenger . Évalué à 1.
[^] # Re: Rapidité du C ... et ramasse-miettes ?
Posté par vg . Évalué à 3.
'If ptr is NULL, no operation is performed.'
Je serais curieux de voir aussi ce que ca pourrais donner avec d'autres implémentations de malloc, notamment celle de google (TCmalloc) :
http://goog-perftools.sourceforge.net/doc/tcmalloc.html
[^] # Re: Rapidité du C ... et ramasse-miettes ?
Posté par Amos Wenger . Évalué à 2.
Je tiens a faire remarquer que le Boehm GC reste plus performant pour ce micro-bench que TCMalloc/C++, mais c'est bien normal.
Je vais essayer avec l'allocateur Hoard aussi.
tsubaka ooc_tmp_nogc # time ./newbench_cxx_O1
real 0m4.628s
user 0m4.492s
sys 0m0.003s
tsubaka ooc_tmp_nogc # time ./newbench_O1
real 0m5.557s
user 0m5.413s
sys 0m0.005s
tsubaka ooc_tmp_nogc # time ./newbench_cxx_O2
real 0m3.949s
user 0m3.926s
sys 0m0.003s
tsubaka ooc_tmp_nogc # time ./newbench_O2
real 0m5.196s
user 0m5.147s
sys 0m0.005s
tsubaka ooc_tmp_nogc # time ../../withgc/newbench_O1
real 0m3.456s
user 0m3.245s
sys 0m0.006s
tsubaka ooc_tmp_nogc # time ../../withgc/newbench_O2
real 0m2.804s
user 0m2.707s
sys 0m0.013s
[^] # Re: Rapidité du C ... et ramasse-miettes ?
Posté par Amos Wenger . Évalué à 1.
Ici pas de gain de performance par rapport a dlmalloc (l'allocateur par défaut dans la glibc), au contraire. Par contre l'avantage est de nouveau légèrement au C++.
Je suis bien curieux de ce qui provoque ces différences!
tsubaka ooc_tmp_nogc # time LD_PRELOAD=/blue/opt/heaplayers-351/allocators/hoard/libhoard.so ./newbench_cxx_O1
real 0m7.449s
user 0m7.338s
sys 0m0.007s
tsubaka ooc_tmp_nogc # time LD_PRELOAD=/blue/opt/heaplayers-351/allocators/hoard/libhoard.so ./newbench_cxx_O2
real 0m6.678s
user 0m6.570s
sys 0m0.006s
tsubaka ooc_tmp_nogc # time LD_PRELOAD=/blue/opt/heaplayers-351/allocators/hoard/libhoard.so ./newbench_O1
real 0m7.496s
user 0m7.354s
sys 0m0.006s
tsubaka ooc_tmp_nogc # time LD_PRELOAD=/blue/opt/heaplayers-351/allocators/hoard/libhoard.so ./newbench_O2
real 0m7.443s
user 0m7.372s
sys 0m0.011s
[^] # Re: Rapidité du C ... et ramasse-miettes ?
Posté par Amos Wenger . Évalué à 2.
> Maintenant si tu te renseignais sur le C++ tu verrais que question performances il est strictement à égalité avec le C
Ce n'est pas honnete. Si on utilise C++ exactement comme le C, alors, oui, comme le C++ est presque un superset du C, alors on a les memes performances.
Ce qui m'interesse dans les comparaisons c'est la performance qu'on a en faisant les choses comme le langage les recommande. Et si, en C++ on utilise la STL, et qu'en C on utilise des pointeurs a tout va, je suis désolé mais on a pas du tout les mêmes performances. Voir la première partie du benchmark sur cette page: [http://unthought.net/c++/c_vs_c++.html]
[^] # Re: Rapidité du C ... et ramasse-miettes ?
Posté par beagf (site web personnel) . Évalué à 2.
Il n'y a aucun interet au programme que tu montre et même pire, c'est une des plus mauvaise manière de faire cete chose sans interet. Lorsque un objet doit être alloué et libéré très rapidement et en très grande quantité, la bonne manière de faire est d'utiliser un pool d'objet, tout comme en C quand tu dois allouer et libérer un très grand nombre de petites zones mémoire, tu en alloue un gros paquet d'un coup que tu libère aussi en une fois à la fin.
Tu pourras dire ce que tu veux, ce benchmark ne veut absolument rien dire. La seule bonne manière de faire un benchmark, indépendament du test lui même, c'est déjà de bien connaître les deux langages, et d'écrire un bon code pour chacun d'eux.
Il suffit de regarder les résultats du shoutout pour s'en rendre compte, certains langages se retrouvent à la traine, non pas car ils sont réellement moins bon, mais uniquement car les benchs ont étés codés n'importe comment.
Les benchs c'est super pratique, quand tu veux prouver quelque chose, en cherchant bien tu finis toujours par en trouver un qui approte la preuve que tu veux. Par contre dans la réalité, trouve moi un seul code qui fait quelque chose d'aussi stupide que ton bench.
Dans la réalité, tu ne fait pas juste un ++ sur variable de ton objet mais tu fais un traîtement qui justifie la création de cet objet, donc l'allocation/libération à beaucoup moin d'impact sur les perfs et l'écart ce réduit.
Ensuite dans la réalité, tu fais un profile de ton code et tu t'apperçois que cette gestion mémoire continue d'avoir un impact sur les perf, donc tu utilises un pool, et là, la version OOC n'a plus rien pour elle.
Sur un exemple comme le tien, l'utilisation d'un pool permet d'exploser les perfs de OOC très simplement. Le nombre d'objets est connu à la base donc un seul malloc/free est nécessaire dans toutes la durée du programme.
Moralité, même le programme OOC me semble écrit avec les pieds, lui aussi méritrait l'utilisation d'un pool ;-)
[^] # Re: Rapidité du C ... et ramasse-miettes ?
Posté par Antoine . Évalué à 9.
Il est incohérent de critiquer un microbenchmark « non réaliste » et d'expliquer ensuite que le C(++) permet des tas de micro-optimisations coûteuses en développement et en maintenance, comme si c'était « réaliste » de faire ce genre de micro-optimisations sur des applications de la vraie vie.
On peut tout faire en C(++), certes, le truc c'est que pendant que tu passeras ton temps à écrire des tas de micro-optimisations (allocateurs spécialisés, pools d'objets pré-alloués...) et à traquer les inévitables fuites mémoire liées à une complication croissante des schémas d'allocation, le développeur utilisant un langage plus haut niveau aura écrit un logiciel à la couverture fonctionnelle trois fois plus grande, et qui apporte plus aux utilisateurs.
D'autant, évidemment, que rien n'empêche ooc d'intégrer ce genre de micro-optimisations de façon transparente sans que le programmeur ait à lever le petit doigt ; c'est ce que fait Python avec beaucoup de petits objets par exemple.
[^] # Re: Rapidité du C ... et ramasse-miettes ?
Posté par beagf (site web personnel) . Évalué à 4.
Ta critique ne tient (et encore que vaguement) que dans le cadre de ce micro-bench. Dans le cadre d'une vrai application ce genre d'«optimisation» n'est pas couteux en dévelopement et en maintenance.
Tout d'abord, tu trouvera de nombreuse classe sur le net, déjà testées intensivement, qui implémentent ce genre de pool. Donc le cout de dévellopement à ce niveau est quasiment nul. Tu commence par créer un pool en lui donnant éventuellement une indication du nombre d'élément que tu pense créer, et ensuite tu lui demande et et éventuellement redonne les objets de la même manière que les allouerais/libererais de manière classique. Avec l'avantage que tu as un netoyage global à la fin en libérant le pool.
Donc tu peut même gagner du temps dans certains cas, en éliminant la nécéssitée de libéré les objets au fur et à mesure.
Ensuite, un objet qui doit être créer à suffisament d'exemplaire pour qu'utiliser un pool soit vraiment intéressant c'est pas forcément tous les jours que tu en rencontre. Donc de base c'est le genre de chose auquel on a tendance à penser au moment ou l'on prévoit le design de l'application, pas en dernière minute.
De manière plus générale, l'utilisation d'un pool n'est pas, comme tu le dis, une «micro-optimisation» mais un point de design et dans des programme réaliste, les cas ou tu dois le mettre en oeuvre ne sont pas si fréquents, sont bien prévu, et au final ne complexifie pas le code mais on tendance à le simplifier beaucoup quand c'est bien fait.
Avec quelque classes génériques, tu obtient les avantage de la gestion manuelle et des GC. Dans les zones qui n'ont pas être rapide, tu peux utiliser la libération automatique, les auto pointer... Et dans les zones critiques tu utilises une gestion manuelle et des pool automatique quand c'est nécéssaire.
Le développeur utilisant un langage plus haut niveau aura écrit un logiciel à la couverture fonctionnelle trois fois plus grande, et qui apporte plus aux utilisateurs.
C'est un joli mythe mais dans la réalitée c'est loin d'être toujours le cas. Il y a énormément de chose qui jouent dans ta capacité à produire du code et le niveau d'abstraction ou de fonctionalité du langage n'est pas la plus importante.
De manière générale il faut être capable de choisir le langage adapté à la tache et à l'environement. Je n'utilserais pas du C pour faire un programme qui fait des manipulations complexe de chaine de caractère sur un petit volume de donnée une fois par mois, tout comme je n'utilserais du bash pour faire un calcul scientifque complexe qui tournera sur un gros serveur de calcul.
Pour revenir au sujet de base : le garbage collector, J'ai eu un soucis il y a de cela quelque temps :
Un petit programme pas extrèmement compliqué qui lisait un fichier ligne par ligne. Il découpait la lignes, faisait quelques traitement et reassemblait une nouvelle ligne pour la sortie.
J'ai fait une première version de ce programme en Lua, ce fut rapide à programmer, mais le programme devenait vite lent à mourir des que le fichier grossisait un peu.Sur le moment je n'avais ps le temps de chercher plus loin, j'ai donc recoder le truc en C en au final c'est les disque qui ne suivait plus le rythme. (ce qui dans mon cas n'était pas génant puisque la sortie du programme était traiter par un autre programme qui prenait le reste du temps CPU)
Quelques temps plus tard, je me repenche sur le problème pour en déterminer la cause. J'aime beaucoup utiliser des langages de scripts pour prototyper des programmes ou pour des petits dévellopement qui n'on pas à être particulièrement rapide. Lua est un langage que j'apprécie beaucoup et donc j'avais envie de savoir d'ou venait vraiment le problème. Après investigation, le problème venait à la fois du GC et du fait que les chaine sont imutables dans lua : chaque ligne représentait un objet, mais aussi chaque morceau de la ligne découpée, chaque étape de transformation de ces morceaux ainsi que la ligne finale. Ce qui fait que pour chaque ligne traité, de nombreux petits objets était créés et le GC se déclenchait sans arret et libérait tous ceux des lignes précédentes. Bref pas mal de boulot inutile.
La version en C utilisait juste deux buffer alloués statiquement.
Cet exemple est, en partie, lié à la gestion des chaines imutable de lua, mais surtout met en avant le problème de ces langages de haut niveaux : Il y a beaucoup de choses qui sont cachées et que l'on ne peut pas forcément prédir et dont on ne connait pas forcément les conséquences. Et l'utilisation d'un GC peut cacher certains problèmes qui serait explicite sans eux.
C'est quand tous les outils, il font utiliser le bon au bon moment, c'est tout.
Donc, pour en revenir au bench, je maintient que celon moi il est stupide et ne prouve qu'une chose, quand on demande à C++ de faire quelque chose de stupide et qu'on lui demande mal, il est plus lent que OOC.
Ce qui ne donne aucune information sur les perfs réelles de OOC.
[^] # Re: Rapidité du C ... et ramasse-miettes ?
Posté par Amos Wenger . Évalué à 3.
> Ton benchmark ne prouve qu'une chose
Ah bon ca prouve qqch, les micro-benchs? Je croyais que ça voulait rien dire.
> Il n'y a aucun interet au programme que tu montre
Ma foi je vois pas pourquoi tu prends la peine de le critiquer alors.
> ce benchmark ne veut absolument rien dire
C'est pas ce que j'ai répété dans presque tous mes posts en haut? La seule chose que j'ai suggérée, c'est que pour une tâche très précise (et codée naivement) mais finalement pas si irréaliste, les résultats du microbench semblaient montrer qu'ooc implémentait les classes de manière plus légère, c'est tout. Les tests suggérés par bbfok avec l'allocateur TCMalloc montre qu'à conditions égales, le C++ peut outperformer ooc si on prive ce dernier de son GC activé par défaut. Il me semble pas avoir posté "HOLY SCHMOLY, OOC 0.2 BLOWS C++ AWAY"
> les benchs c'est pratique quand tu veux prouver qqch
ou quand tu veux juste avoir une idée vague des performances d'une implémentation d'un langage sous certaines conditions.
> en réalité tu ne fais pas un ++ sur variable
c'est marrant parce que j'ai écrit plein de programmes dans ma vie et j'ai souvent utilisé ++. Plus sérieusement, tu crois pas que si je faisais rien ave l'objet, je courrais le risque que g++/gcc se sente fou et me vire carrément ma boucle? Mieux vaux etre doublement sûr.
> Dans le cadre d'une vrai application ce genre d'«optimisation» n'est pas couteux en dévelopement et en maintenance.
il a raison! tout le monde sait par exemple que Firefox gère parfaitement sa mémoire, et n'a jamais eu historiquement de grosses fuites mémoires et qu'il n'ont pas du tout passé des mois a essayer d'optimiser leurs routines d'allocations mémoire (comme ne le confirme pas le lien posté plus haut par son-nom-m'échappe)
> Avec quelque classes génériques, tu obtient les avantage de la gestion manuelle et des GC. Dans les zones qui n'ont pas être rapide, tu peux utiliser la libération automatique, les auto pointer... Et dans les zones critiques tu utilises une gestion manuelle et des pool automatique quand c'est nécéssaire.
Bon eh bien voilà une suggestion intéressante. A la réflexion, je ne vois pas de bonne raison de "forcer la main" des programmeurs ooc et de leur imposer le gc. J'entrevois la possibilité de pouvoir spécifier dans le code quel type d'allocation on préfère a l'instanciation: GC, pool, ou manuel. Tout ça intégré dans le langage, comme Antoine le suggère.
> il faut être capable de choisir le langage adapté à la tache et à l'environement.
eeeeeeeh copieur c'est moi qui l'ai dit en premier ça. (et pas qu'une fois en plus). Si y'a triche, moi je joue plus hein.
> C'est un joli mythe mais dans la réalité c'est loin d'être toujours le cas.
A cette différence près c'est que quand tu codes dans un langage bien établi comme le C++ tu regarde tristement la réalité en face, tu soupires, et tu remets a coder de manière fastidieuse parce que c'est trop tard pour changer (oui je connais le standard C++0x, et j'avoue que ça m'impressione: ils ont réussi à rendre le langage encore plus complexe et error-prone qu'avant. Je pensais pas que c'était possible.)
> strings immutables (oh oui), et cacher des choses dans les langages de haut niveau.
J'ai toujours été dubitatif quant a l'intérêt de l'immutabilité des Strings en Java (puisque c'est le langage avec lequel j'ai travaillé le plus), à part pour ceux qui ne savent pas ou ils passent leur Strings (auquel cas il faudrait penser sérieusement a arrêter la biosson, mon vieux). En résumé, ooc n'impose pas l'immutabilité d'une String.
Quant a cacher des choses dans les langages de haut niveau ben à ce moment là.. C++ par exemple. Cf. [http://yosefk.com/c++fqa/] mais aussi [http://www.johndeacon.net/Cpp/trapsAndPitfalls.asp]
Pour ooc, rien n'est caché: l'implémentation du langage est simple, et tout ce qu'on a besoin de savoir sur comment c'est fait en dessous est dans le language reference guide (et si ça n'y est pas, c'est que ça manque, prévenez-moi et je complèterais.) L'avantage? Travailler avec un langage qu'on peut facilement maîtriser, se rendre compte qu'on a fait la même chose en C à la main depuis longtemps, et être même capable de faire des contributions valables au langage.
[^] # Re: Rapidité du C ... et ramasse-miettes ?
Posté par beagf (site web personnel) . Évalué à 3.
Ah bon ca prouve qqch, les micro-benchs? Je croyais que ça voulait rien dire.
Pour entrer dans le jeu, ça prouve juste que ça ne prouve rien ;-)
> Il n'y a aucun interet au programme que tu montre
Ma foi je vois pas pourquoi tu prends la peine de le critiquer alors.
Je critique le bench qui utilise un programme sans interet pour monter on ne sais pas trop quoi...
> ce benchmark ne veut absolument rien dire
C'est pas ce que j'ai répété dans presque tous mes posts en haut?
Bah non ce n'est pas ce que tu as répété come tu le dis si bien juste après :
La seule chose que j'ai suggérée, c'est que pour une tâche très précise (et codée naivement) mais finalement pas si irréaliste, les résultats du microbench semblaient montrer qu'ooc implémentait les classes de manière plus légère, c'est tout. Les tests suggérés par bbfok avec l'allocateur TCMalloc montre qu'à conditions égales, le C++ peut outperformer ooc si on prive ce dernier de son GC activé par défaut. Il me semble pas avoir posté "HOLY SCHMOLY, OOC 0.2 BLOWS C++ AWAY"
Une tâche très précise qui ne se produit jamais en dans un vrai code et en plus mal coder de manière à déformer les résultats du bench ? Ça c'est du bench intéressant...
Tout ce que tu réussit à faire avec ton bench c'est dire «dans un cas que vous ne rencontrerez jamais dans la réalitée OOC fait mieux que C++ (et encore /une/ implémentation de C++), mais pour des cas réaliste je vous laisse deviner.»
Moi quand je vois ce genre de bench, je trouve que ça pue la mauvaise fois et que le dev à chercher un moyen de montrer à tout pris que son langage est meilleur, et pour ça il à chercher le seul code ou c'est le cas. Quel que soit ton objectif, se genre de bench ne peut que te désservir.
Soit tu ne fais pas de bench, soit tu en fais un serrieux, mais avec un comme celui là tu ne fais que décrédibiliser ton langage.
ou quand tu veux juste avoir une idée vague des performances d'une implémentation d'un langage sous certaines conditions.
Tout d'abord ce que tu fais n'est pas un vrai bench dans le sens ou tu biaise un des langages testés en l'utilisant mal. Si je fais un bench entre du C du CAML je peut déjà te dire que CAML sera dix fois plus lent et pourtant certains on montrer qu'il avait des perfs honorables.
Ensuite où est l'interet d'un bench qui mesure des performances même vagues dans des conditions telles qu'elles ne seront jamais rencontrer dans aucun programme ?
> en réalité tu ne fais pas un ++ sur variable
c'est marrant parce que j'ai écrit plein de programmes dans ma vie et j'ai souvent utilisé ++. Plus sérieusement, tu crois pas que si je faisais rien ave l'objet, je courrais le risque que g++/gcc se sente fou et me vire carrément ma boucle? Mieux vaux etre doublement sûr.
Je pense que tu le fais exprès mais au cas ou... Je ne critique pas le fait que tu fasse un ++, ce que je critique c'est que tu ne fasse que ça. Tu as souvent écrit des programme qui créait un million d'objet pour juste faire un ++ sur une variable et ensuite libéré l'objet ?
Tu semble très content que OCC gérèe «plus légerement les objets» que C++, mais c'est à quel prix ? C'est ce point qui est important. Ce qu'il faut te poser comme question c'est, qu'ai je sacrifier pour ça et est-ce que ça vaut le cout ?
C'est la même chose que l'argument classique en faveur des GCs : On perd générallement un petit peu en perf mais on y gagne une facilitée d'utilisation.
Tu gagne par rapport à C++ lors de la création de grande quantitée d'objet sans utilisation de pool, mais dans des condition réelle ou chaque objet réalise un vrai traitement tu ne gagne qu'un pouième de perfs, est-ce que c'est valable ? est-ce que C++ en acceptant d'utiliser un pool n'est pas au final meilleur ?
(vrai question puisque je ne sais pas comment marche OOC)
> Dans le cadre d'une vrai application ce genre d'«optimisation» n'est pas couteux en dévelopement et en maintenance.
il a raison! tout le monde sait par exemple que Firefox gère parfaitement sa mémoire, et n'a jamais eu historiquement de grosses fuites mémoires et qu'il n'ont pas du tout passé des mois a essayer d'optimiser leurs routines d'allocations mémoire (comme ne le confirme pas le lien posté plus haut par son-nom-m'échappe)
Là j'ai du mal à voir le rapport avec Firefox. Si j'écrit une appli en OOC qui à plein de fuite mémoire ça veut dire que OOC est une merde ?
Le gros problème de Firefox c'est que la gestion mémoire à été conçue progressivement en rajoutant des couches petit à petit. Le lien que tu indiques montre que la mémoire se fragmente et donc qu'elle ne peut être récupéré par le système. Ce problème n'est pas lié au C++ ou à des pool ou n'importe quoi d'autre, un GC aurra éxactement le même.
Si tu allous un million de petits objets et que tu en libère un sur deux, quel que soit le système que tu utilises tu ne pourra pas libéré la mémoire. A moin d'utiliser un GC compacteur mais là ça pose d'énorme problème puisque tout les pointeur doivent être indirects.
Bien au contraire, un système de pool peut même améliorer la situation car il t'assure que les objets de même types sont regroupés au même endroit, donc il facilite la gestion.
Bon eh bien voilà une suggestion intéressante. A la réflexion, je ne vois pas de bonne raison de "forcer la main" des programmeurs ooc et de leur imposer le gc. J'entrevois la possibilité de pouvoir spécifier dans le code quel type d'allocation on préfère a l'instanciation: GC, pool, ou manuel. Tout ça intégré dans le langage, comme Antoine le suggère.
Ça c'est déjà mieux. Intégrer dans le langage ce que l'on fait de manière plus crade en C++ serait pas mal à condition que ce soit fait proprement ;-)
> il faut être capable de choisir le langage adapté à la tache et à l'environement.
eeeeeeeh copieur c'est moi qui l'ai dit en premier ça. (et pas qu'une fois en plus). Si y'a triche, moi je joue plus hein.
D'un autre côté, ça fait des années que je le dis, et je suis sûr que d'autres l'on dis avant nous. Heureusement qu'il n'y a pas encore de brevets sur les opinions....
> C'est un joli mythe mais dans la réalité c'est loin d'être toujours le cas.
A cette différence près c'est que quand tu codes dans un langage bien établi comme le C++ tu regarde tristement la réalité en face, tu soupires, et tu remets a coder de manière fastidieuse parce que c'est trop tard pour changer (oui je connais le standard C++0x, et j'avoue que ça m'impressione: ils ont réussi à rendre le langage encore plus complexe et error-prone qu'avant. Je pensais pas que c'était possible.)
Pour le C++, j'ai un ensemble classes et de templates que je réutilise à chaque fois que j'en ai besoin et qui me font ce genre de merde toutes seules. Ensuite, c'est pas parce qu'il y a des coins bouseux dans le C++ que tu es obligé de les explorer...
Et pour retourner le compliment, j'ai vu des programmeur (paix à leurs âmes) qui, obligé de programmer dans un langage qui pensait savoir mieux qu'eux comment gérer la mémoire était obliger de passer par de grand tableaux d'objets pour émuler les pool si simple à coder en C ou en C++. Bien sûr c'est pas des cas courrant, et c'est loin d'être systématiquement valable, mais ça arrive à mon avis plus souvent que créer un million do'bjets juste pour faire un ++....
> strings immutables (oh oui), et cacher des choses dans les langages de haut niveau.
J'ai toujours été dubitatif quant a l'intérêt de l'immutabilité des Strings en Java (puisque c'est le langage avec lequel j'ai travaillé le plus), à part pour ceux qui ne savent pas ou ils passent leur Strings (auquel cas il faudrait penser sérieusement a arrêter la biosson, mon vieux). En résumé, ooc n'impose pas l'immutabilité d'une String.
Je ne lance pas le débat sur l'immutabilité des string mais sur le fait qu'il est dangeureux de cacher des chose, surtout dans les éléments de base d'un langage. Je voulais surtout montrer les effets pervers que peuvent avoir dans certains cas le GC et bien expliquer que ce n'est pas la solution ultime et que la gestion manuelle de la mémoire n'est pas le mal absolu.
Quant a cacher des choses dans les langages de haut niveau ben à ce moment là.. C++ par exemple. Cf. [http://yosefk.com/c++fqa/] mais aussi [http://www.johndeacon.net/Cpp/trapsAndPitfalls.asp]
Pour ooc, rien n'est caché: l'implémentation du langage est simple, et tout ce qu'on a besoin de savoir sur comment c'est fait en dessous est dans le language reference guide (et si ça n'y est pas, c'est que ça manque, prévenez-moi et je complèterais.) L'avantage? Travailler avec un langage qu'on peut facilement maîtriser, se rendre compte qu'on a fait la même chose en C à la main depuis longtemps, et être même capable de faire des contributions valables au langage.
Et le jour ou un programmeur stockera un poiteur vers un objet de manière un peu cryptée ou utilisera une variable entière dont la valeure est la même que l'adresse d'un objet qui traine quelque part, le Bohem GC va se planter et l programmeur aurra une surprise...
J'admet que le premier cas relève d'une connerie de la part du programmeur, mais le deuxième est tout à fait réaliste.
[^] # Re: Rapidité du C ... et ramasse-miettes ?
Posté par Amos Wenger . Évalué à 2.
> ça prouve juste que ça ne prouve rien ;-)
+1
> Je critique le bench qui utilise un programme sans interet pour monter on ne sais pas trop quoi...
si tu vois pas l'intérêt d'un micro-bench, alors n'en parle même pas. Critiquer quelque-chose est utile uniquement si tu penses que ça peut l'améliorer. Penses-tu sérieusement t'impliquer dans le développement d'ooc?
> Bah non ce n'est pas ce que tu as répété
bizarrement, on dirait qu'on peut répéter 2 choses a la fois, dont "Ces résultats, bien que peu fiables [,,,]", "J'ai déjà moi-même dit et répété qu'un micro-benchmark ne voulait pas dire grand-chose", "Comme tous les benchmarks, a prendre avec des pincettes.", "Si tu as les sources de benchmarks plus réalistes écrits"
Donc non seulement tu prêches a un converti mais en plus tu pars du principe que c'est un mauvais programmeur. Je te suggère d'imaginer la situation suivante: un programme divisé en 10 sous-systèmes, qui exécutent tous 100 tâches en "parallèle" pour chacun de leurs 100 clients (ou requêtes). Chacune des tâches a besoin d'allouer environ 1000 objets, de types et de taille différentes (aucun intérêt de pooler, donc). Qu'obtient-on? entre autres choses (calcul, entrées/sorties, etc.), 100 millions d'allocation d'objets en quelques secondes, à savoir le micro-benchmark ci-dessus. Sauf que ce programme que je te demande d'imaginer (mais qui ressemble bien a plusieurs programmes réels et en production) n'est pas si facilement optimisable qu'un micro-benchmark, précisément parce que les allocations sont de tous types et disséminées partout dans le code. D'où l'intérêt de tester la vitesse pure d'allocation. Avec tout le côté hasardeux, imprécis, et générateur de troll que ça a.
> Moi quand je vois ce genre de bench, je trouve que ça pue la mauvaise fois et que le dev à chercher un moyen de montrer à tout pris que son langage est meilleur, et pour ça il à chercher le seul code ou c'est le cas. Quel que soit ton objectif, se genre de bench ne peut que te désservir. Soit tu ne fais pas de bench, soit tu en fais un serrieux, mais avec un comme celui là tu ne fais que décrédibiliser ton langage.
Bah. Ce que tu dis serait valable si j'en avais fait tout un fromage en clamant a tout va qu'ooc est plus rapide que C++ de manière générale et si j'en avais fait une raison d'adopter ooc, dans mon argumentation. Or ce n'est pas le cas.
Pour ce qui est d'un benchmark sérieux, je n'ai pas le temps dans la semaine qui vient, mais par simple curiosité (non, je ne suis pas si obsédé que ça par les performances) j'essayerais d'en trouver un potable (qui teste plusieurs aspects). Je pensais porter alioth shootout, a un moment. Mais bon "premature optimization is the root of all evil" donc je vais plutot me concentrer sur une langage plus propre et syntaxiquement bien plus sympathique que le C++ (enfin c'est mon avis..)
> Tu semble très content que OCC gérèe «plus légerement les objets» que C++, mais c'est à quel prix ?
Je ne comprend pas la question. Je ne vois pas de prix a être plus léger, sinon éventuellement en facilité d'utilisation, ce qui n'est clairement pas le cas, de plus ta remarque qui suit présent l'argument exactement inverse.
> est-ce que C++ en acceptant d'utiliser un pool n'est pas au final meilleur ?
Ben c't'a dire que non puisque la performance n'était pas du tout ma raison principael de faire/d'utiliser ooc. Ce qui me chagrinait en principal dans le C++ était la syntaxe, et l'absence d'une ABI standard.
> j'ai du mal a voir le rapport avec Firefox
Ton argumentation : "gérer la mémoire correctement sans GC est trivial"
Ma réponse : "va dire ça aux devs de grosses applications."
> c'est pas parce qu'il y a des coins bouseux dans le C++ que tu es obligé de les explorer...
Pour info, C++0x est le futur du C++. Si son futur est bouseux (d'après toi) c'est pas vraiment ma faute.
> j'ai vu des programmeurs obligés de se mettre au jiu jitsu pour faire des pools dans le langage X
Je comprend que tu as cette discussions uniquement par fierté, par fanatisme du C++&co, et pour afficher ton grand savoir, mais tu pourrais faire l'effort de lire ce que je raconte sur l'avenir d'ooc. Résumons, à l'avenir: 3 options intégrées dans le langage: GC, pool, et malloc/free manuel. Et pour les allocations par blocs, une syntaxe comme "Object o = 300 new Object()" devrait faire l'affaire.
> mais le deuxième est tout à fait réaliste.
Absolument, c'est un des défauts connus des GC conservatifs. D'où le fait que je considère l'éventualité, comme ooc est fortement typé, d'en réécrire un précis pour les prochaines versions.
[^] # Re: Rapidité du C ... et ramasse-miettes ?
Posté par beagf (site web personnel) . Évalué à 2.
- Tu peut mettre tous les avertissement sur le fait que ce que tu vas dire est une grosse connerie, il y aura toujours des personnes pour reprendre tes chiffres et les utiliser comme une parole d'évangile. Les gens aiment les chiffres même lorsqu'ils sont faux, il suffit de regarder les débats sur les perfs de java ou autres langage de haut-niveau ;
- Pour quelqu'un qui regarde le bench d'un peu plus près, tu donne l'impression d'avoir chercher un cas à tout pris où tes perfs sont meilleur que celle du langage auquel tu te compare (même si ce n'est pas forcément le cas) donc tu perd toute crédibilité. Donc même si ton langage est bon, tu pousse les gens que cela pourrait intéresser à passer leur chemin.
Ce que je critique dans mes message c'est principalement le fait de publier un bench tels que celui que tu donne. Les chiffres que tu donne ne veulent strictement rien dire à l'exception d'un cas très particulier qui n'apparait pas jamais dans la vraie vie. Le programme auquel tu l'oppose est trivialement mal programmé pour quelqu'un qui connait le C++, alors que l'on peut supposer que celui en OCC est bien codé puisque c'est ton langage, on peut donc en déduire que tu est de mauvaise foie.
Bref, même si cela part d'une bonne intention, je pense que ton bench fait plus de mal qu'autre chose, et c'est général pour les mauvais benchs. Après, c'est peut-être moi qui suit tordu et qui voit le mal partout, mais au niveau bench j'ai vu le meilleur comme le pire, et j'ai pris l'habitude de me méfier de chiffre donnée sur la base des micro-bench.
Mais de ce que j'ai pus voir les gens gobent ces chiffre aveuglément et globalement c'est plus facile de ce battre contre les mauvais bench que contre les idées qu'ils ont répendues.
[...]exemple avec plein de systeme qui créent des objets dans tous les sens[..]
Ton exemple illustre tout à fait ce que je critique, même si la création/libération des objets est un facteur important : dans le cas que tu illustres, il y a beaucoup de chose qui ce passe en plus de ces opérations. Notament, et c'est souvnt très important les objets sont rarement libérés dans le même ordre qu'ils sont créés, certains ont une durée de vie bien plus longue que les autres, beaucoup de paramètres entrent en jeu. Au final on est très loin de la situtation idéale du micro-bench que tu présente.
Résultat : dans ce cas réaliste les perfs du GC doivent chuter dramatiquement et au final les perfs sont surement au mieux similaires à celle du C++.
Ton argumentation : "gérer la mémoire correctement sans GC est trivial"
Ma réponse : "va dire ça aux devs de grosses applications."
Ne me fais pas dire ce que je n'ai pas dit. Nulle part je ne dit que gérer la mémoire sans GC est trivial. Ce que je dis c'est que,dans un cas comme celui de ton micro bench, l'utilisation d'un pool est très simple : un grand nombre d'objet tous de même taille à allouer et libérer dans une portion réduite du code.
De manière générale, l'utilisation de pool reste relativement simple tant que tu restes sur l'allocation d'un grand nombre d'objets identiques et dans ces cas là, c'est à ma connaissance toujours plus éfficace d'utiliser un pool qu'un GC.
Si tes objets sont de tailles variable et contiennent des références les un aux autres, je suis d'accord qu'un GC deviens intéressant et qu'un pool n'est plus adapté.
Je comprend que tu as cette discussions uniquement par fierté, par fanatisme du C++&co, et pour afficher ton grand savoir, mais tu pourrais faire l'effort de lire ce que je raconte sur l'avenir d'ooc. Résumons, à l'avenir: 3 options intégrées dans le langage: GC, pool, et malloc/free manuel. Et pour les allocations par blocs, une syntaxe comme "Object o = 300 new Object()" devrait faire l'affaire.
Je suis loin d'être un fan du C++ contrairement à ce que tu dis, j'ai parlé du C++ car ton bench comparait OCC à C++ uniquement. Donc si tu veut délirer sur ma fierté et mon grand savoir libre à toi, mais fais comme pour le bench qui ne veulent rien dire, s'il te plait, ne les publies pas.
Pour ton information et pour t'éviter de me relire, je suis pour le choix de la solution adaptée à chaque problèmes, et donc dans le cadre de ton micro bench pour la version en C++ c'est un pool et pas une gestion basique qu'il faut utiliser.
L'avenir de OOC et le fait de pouvoir utiliser plusieurs modèles d'allocation mémoire c'est au dernier message que tu as commencé à en parler, je t'ai même répodu que ce serait bien de le faire, donc depuis que tu en parle, je pense l'avoir lut et en avoir tenu compte...
[^] # Re: Rapidité du C ... et ramasse-miettes ?
Posté par Amos Wenger . Évalué à 1.
Je résume donc ma position
le but d'ooc n'est pas d'être le langage le plus rapide, mais plutôt de réduire le temps de développement, d'être portable, sans machine virtuelle, et libre.
effectivement, le micro-benchmark présent dans les discussions ne prouve rien, et de plus il n'est pas du tout un bon exemple de programmation (comme tous les micro-benchs)
un résultat plus significatif est la taille du code source ^^ 2x plus court en ooc
à l'avenir, je prévois de laisser plus de flexibilité quant a la gestion de mémoire en ooc
toutes mes excuses aux gens que j'ai froissé au passage
(ah et pour "c'est au dernier message que tu as commencé à en parler", en fait c'est a un autre endroit du thread de commentaires que j'en parlais)
Ah et sinon, quelqu'un sur reddit m'a conseillé d'implémenter un alorithme de "escape analysis", ce qui permet d'avoir un modèle déterministe de gestion de mémoire, sans GC, sans pool, et automatique. Voir la discussion avec les liens ici: [http://www.reddit.com/r/programming/comments/8vsgh/ooc_progr(...)]
[^] # Re: Rapidité du C ... et ramasse-miettes ?
Posté par LupusMic (site web personnel, Mastodon) . Évalué à -2.
Et pour le garbage collector, on a bien std::auto_ptr<> (ainsi que boos::scoped_ptr<> et boost::shared_ptr<>) qui peut faire le travail.
De toute façon, je préfère automatiser la libération de la mémoire, parce qu'il est humainement impossible de gérer correctement ces ressources de manière parfaite.
[^] # Re: Rapidité du C ... et ramasse-miettes ?
Posté par Pierre Bourdon . Évalué à 1.
Car l'implémentation par défaut de std::allocator chez moi se base sur new, ça serait un peu le serpent qui se mord la queue si ce que tu dis se confirme.
[^] # Re: Rapidité du C ... et ramasse-miettes ?
Posté par LupusMic (site web personnel, Mastodon) . Évalué à 1.
Faut que je fouille pour comprendre le mécanisme exact de ce qui se passe.
[^] # Re: Rapidité du C ... et ramasse-miettes ?
Posté par Amos Wenger . Évalué à 1.
Je suis d'accord pour me faire démonter mon microbench, mais seulement si le démontage est techniquement correct.
En l'occurence... quelqu'un pourrait-il m'expliquer en quoi auto_ptr, shared_ptr, et autres joyeusetés du genre ont de commun avec un vrai garbage collector tel qu'on peut trouver dans Java (et oui c'est une référence, voir le nouveau collector G1 dans le JRE 1.6u14), python, etc. ou dans n'importe quel langage un tant soit peu haut niveau?
Si par gestion automatique de mémoire tu entends "libérer la mémoire quand on sort du scope", alors oui forcément, a ce compte la, le C++ est garbage collecté...
Quant a std::allocator, je cherche, mais je ne vois vraiment pas ce qu'il vient faire la. A ma connaissance, non, new n'utilise pas std::allocator, et on ne peut pas reimplementer new comme on veut en C++ (dites-moi si je me trompe).
Quand a dire que mon microbench n'a aucun valeur eh bien.. il a aussi peu de valeur que n'importe quel microbench: il teste effectivement l'implementation GNU g++ 4.3 du C++ contre GNU gcc 4.3 du ooc/C avec le Boehm GC v7.1 sous Gentoo Linux en ce qui concerne l'allocation d'objets et leur destruction. Cependant, c'est représentatif des performances qu'obtiendront les utilisateurs d'un de ces langages "out-of-the-box". Je pense qu'il est donc tout de même digne d'intérêt.
[^] # Re: Rapidité du C ... et ramasse-miettes ?
Posté par Amos Wenger . Évalué à 0.
Voir: [http://www.bearcave.com/software/c++_mem.html]
En revanche, je vous met au défi d'implémenter un memory allocator meilleur que celui de votre implémentation C++ par défaut.
[^] # Re: Rapidité du C ... et ramasse-miettes ?
Posté par Benoit Jacob (site web personnel) . Évalué à 2.
L' "operator new" fourni par C++ n'est qu'une enveloppe autour de la routine malloc() fournie par le système d'exploitation. C'est exactement la même chose que malloc().
Alors ensuite oui on peut surcharger "operator new", oui l'une des utilisations est d'avoir un allocateur de mémoire spécialisé, quoique c'est loin d'être la seule utilisation. Moi par exemple je l'utilise surtout pour avoir un "new" qui renvoie des pointeurs alignés sur 128 bits pour des données traitées par des instructions SIMD.
[^] # Re: Rapidité du C ... et ramasse-miettes ?
Posté par Amos Wenger . Évalué à 2.
Et comme on pouvait s'y attendre.... ooc est quand meme plus rapide que C++.
Je suppose qu'on peut en déduire qu'ooc implémente les classes de manière plus légère que le C++, mais je vous laisse vous faire votre propre conclusion.
Résultats:
tsubaka ooc_tmp # time ../../withgc/newbench_cxx_O1
real 0m7.903s
user 0m7.829s
sys 0m0.008s
tsubaka ooc_tmp # time ./newbench_O1_nogc
real 0m6.427s
user 0m6.309s
sys 0m0.008s
tsubaka ooc_tmp # time ../../withgc/newbench_cxx_O2
real 0m6.847s
user 0m6.737s
sys 0m0.004s
tsubaka ooc_tmp # time ./newbench_O2_nogc
real 0m5.976s
user 0m5.855s
sys 0m0.002s
Code C généré par ooc avant modification (utilise le GC): http://ooc.pastebin.com/m1a579233
Code C généré par ooc après modification (utilise malloc/free): http://ooc.pastebin.com/m48d21e05
[^] # Re: Rapidité du C ... et ramasse-miettes ?
Posté par Pierre Bourdon . Évalué à 2.
[^] # Re: Rapidité du C ... et ramasse-miettes ?
Posté par Amos Wenger . Évalué à 1.
tsubaka ooc_tmp_nogc # time ../../withgc/newbench_cxx_O1_nono
real 0m8.151s
user 0m8.134s
sys 0m0.011s
tsubaka ooc_tmp_nogc # time ./newbench_O1_nogc
real 0m7.125s
user 0m6.999s
sys 0m0.005s
tsubaka ooc_tmp_nogc # time ../../withgc/newbench_cxx_O2_nono
real 0m6.684s
user 0m6.609s
sys 0m0.046s
tsubaka ooc_tmp_nogc # time ./newbench_O2_nogc
real 0m5.954s
user 0m5.823s
sys 0m0.042s
En passant, si d'autres personnes pouvaient faire tourner ces benchmarks sur leur machine, histoire de confirmer/infirmer les résultats, ça serait vraiment sympa.
[^] # Re: Rapidité du C ... et ramasse-miettes ?
Posté par pasBill pasGates . Évalué à 3.
Une fois que tu auras fait cela et aura montre les resultats, je commencerai peut-etre a prendre tes dire sur les perfs d'ooc au serieux...
Les micro-benchmarks ne montrent rien du tout, car il y a tout un tas d'elements qui entrent en compte (granularite de la heap utilisee, gestion des alignements, etc...) qui font qu'ils ne signifient absolument rien dans le monde reel.
[^] # Re: Rapidité du C ... et ramasse-miettes ?
Posté par Amos Wenger . Évalué à 1.
J'ai déjà moi-même dit et répété qu'un micro-benchmark ne voulait pas dire grand-chose. En revanche, celui-la est intéressant, puisque (en tout cas dans ses dernieres incarnations) il mesure juste la différence de surpoids (overhead) entre ooc et C++ dans l'implémentation des classes.
Ensuite, en ce qui concerne la granularité de la heap et la gestion des alignement, je ne suis pas du tout spécialiste dans ce domaine, mais il me semble que GNU G++ et GNU GCC ne devraient pas gérer les choses trop différemment, non? (même backend..)
Je rappelle au grand public que le compilateur ooc génère du C ensuite compilé par GCC. Je pense qu'on peut donc considérer ces derniers micro-benchmarks comme des combats "à la loyale".
[^] # Re: Rapidité du C ... et ramasse-miettes ?
Posté par LupusMic (site web personnel, Mastodon) . Évalué à 1.
[^] # Re: Rapidité du C ... et ramasse-miettes ?
Posté par Amos Wenger . Évalué à 1.
"As as last resort, we could replace malloc and new entirely with something more generally better. I don’t think we should do this until we've done as much of the other things as possible."
[^] # Re: Rapidité du C ... et ramasse-miettes ?
Posté par Benoit Jacob (site web personnel) . Évalué à 1.
Bien sûr que l'on peut trouver des cas où avoir un GC améliore les performances. Dans ces cas-là on peut aussi utiliser un GC en C ou en C++: c'est quelque chose qui peut être fourni par une librarie, quoique bien entendu l'utilisation d'un GC fourni par une librarie ne soit pas aussi transparente que si le GC est fourni par le langage lui-même.
En revanche, si l'on utilise un langage qui utilise automatiquement un GC, alors on est coincé: pour certaines utilisations, il peut n'y avoir aucun moyen d'obtenir un niveau optimal de performances et d'utilisation de la mémoire.
Plus généralement il y a une différence de fond entre d'une part les langages qui laissent le programmeur coder "octet par octet de code machine", sans que le compilateur se permette de rajouter des opcodes à droite à gauche --- c'est le cas de l'assembleur, du C, et de l'essentiel du C++ --- et d'autre part les langages qui vont rajouter leur sauce pour simplifier la vie du programmeur dans "99% des cas" tout en rendant sous-optimal le 1% restant.
[^] # Re: Rapidité du C ... et ramasse-miettes ?
Posté par Amos Wenger . Évalué à 1.
En revanche, plusieurs parmi les gourous du développement s'accordent pour dire que le temps de développement requis pour un programme dans un certain programme est plus significatif qu'une faible différence de performance. Voir: [http://www.paulgraham.com/langdes.html] (en particulier la section "Speed comes from profilers", mais tout l'essai est tres intéressant)
[^] # Re: Rapidité du C ... et ramasse-miettes ?
Posté par GeneralZod . Évalué à 2.
ça montre surtout que l'allocateur mémoire par défaut de ton implémentation de C++ est une bouse pour allouer des petits objets. C'est normal, l'allocateur par défaut doit répondre à diverses problèmatiques sans (trop) sacrifier au niveau des performances.
Le ramasse-miette, la plupart du temps, alloue un pool mémoire au démarrage, il ne rend pas toujours la mémoire libéré par le programme, il peut utiliser différentes politiques, etc.
Certes, ça abaisse le niveau d'entrée pour les développeurs : c'est plus simple, plus efficace et surtout plus sûr que si ils géraient manuellement la mémoire mais ça a un surcoût parfois non négligeable (ie: machine limitée en mémoire)
Après, rien n'empêche le développeur C++ de programmer son propre allocateur mémoire (ce qui arrive très souvent en embarqué ou en programmation temps réel) pour améliorer les performances d'allocation mémoire. Mais pour le côté sûreté et simplicité des garbages collector, les dialectes C++ modernes offre des alternatives tout aussi bien sans surcoût: RAII, pointeurs intelligents avec ou sans comptage de référence, conteneurs etc ...
On n'est pas obligé de choisir entre la gestion manuelle ou automatique de la mémoire, on peut s'orienter vers une gestion semi-automatique comme en C++ ou en Objective-C qui constitue un excellent compromis.
Intrinsèquement, un ramasse miette n'est ni plus lent ni plus rapide qu'une gestion manuelle de la mémoire, ça dépends de la configuration (bcp d'allocations, petits/gros objets, ressources disponibles), ça dépends du développeur (niveau, envie de gérer la mémoire ou pas), du temps alloué au projet, du public visé etc ...
[^] # Re: Rapidité du C ... et ramasse-miettes ?
Posté par Damien (site web personnel) . Évalué à 1.
[^] # Re: Rapidité du C ... et ramasse-miettes ?
Posté par GeneralZod . Évalué à 4.
Boehm GC est utilisé par bon nombre de projets (GCJ, Mono, Mozilla, LLVM etc ...) qui garantit que le code a été intensivement testé et déverminé et sur un nombre important de plateformes.
Un nouveau ramasse-miette signifierait moins de temps pour faire avancer un langage encore très jeune, essuyer pas mal de platre. Un ramasse-miette à la fois portable, performant et bien déverminé, ça demande du temps. Plus encore, si il doit être plus complexe.
Laissons le projet avancer à son rythme, si le Boehm GC pose problème à l'évolution du langage, ce sera toujours le moment de se poser la question.
[^] # Re: Rapidité du C ... et ramasse-miettes ?
Posté par briaeros007 . Évalué à 1.
Ahahaha la bonne blague. Ca garantie juste qu'il est utilisé, ni plus, ni moins.
J'avais fait un test tout con :
tu prend boehm gc, tu t'amuse a créer n threads, chacun créant m objets.
pour n et m relativement grand (style n=1000 , m=100) , en 2005, ca segfaulter.
même test en allocation "a la mano"
ca passait sans problème.
[^] # Re: Rapidité du C ... et ramasse-miettes ?
Posté par PachaFonk . Évalué à 2.
Parti comme ça, tu vas aussi dire que le père Noël n'existe pas !
A d'autres !!!!
[^] # Re: Rapidité du C ... et ramasse-miettes ?
Posté par Amos Wenger . Évalué à 1.
As-tu testé avec la version parallelisée du Boehm GC [http://www.hpl.hp.com/personal/Hans_Boehm/gc/#multiprocessor(...)]
Pour ma part je n'ai jamais eu de segfault que j'ai pu incriminer au GC. Au pire, il affiche des warnings quand on alloue beaucoup d'objets énormes souvent. C'est un comportement assez acceptable, je trouve.
[^] # Re: Rapidité du C ... et ramasse-miettes ?
Posté par briaeros007 . Évalué à 2.
j'ai fait un test très simple ou il n'y avait que du C, et gc, donc c'était soit le compilo, soit gc ;)
[^] # Re: Rapidité du C ... et ramasse-miettes ?
Posté par GeneralZod . Évalué à 4.
Si il est très utilisé, statistiquement plus de bogues sont corrigés, et vu que Mono/GCJ/Mozilla/LLVM sont pas des branquignols, ils ont faits des rapports de bogues et même fait le patch qui va avec.
Quant au côté multiplateforme, prenons le cas de Mono. Mono compile sur de multiples plateformes matérielles x86, ppc (wii, ps3 y compris), sparc, alpha, arm (iPhone), et autant d'OS: linux, BSD, Solaris, HP-UX, OS X, merdows et partout, ils utilisent Boehm GC. Si ce n'est pas une belle preuve de portabilité, etc ...
> tu prend boehm gc, tu t'amuse a créer n threads, chacun créant m objets.
Boehm GC par défaut n'est pas thread-safe, tu ne nous apprends rien de nouveau.
http://www.hpl.hp.com/personal/Hans_Boehm/gc/scale.html
[^] # Re: Rapidité du C ... et ramasse-miettes ?
Posté par briaeros007 . Évalué à 2.
Ce qui n'a rien a voir avec "intensivement testé".
Ils ont été fortement testé dans un contexte bien particulier.
Tu sors de ce contexte, et pouf, un monde incroyable de nouveau bug s'ouvre a toi.
Quant au côté multiplateforme, prenons le cas de Mono. Mono compile sur de multiples plateformes matérielles x86, ppc (wii, ps3 y compris), sparc, alpha, arm (iPhone), et autant d'OS: linux, BSD, Solaris, HP-UX, OS X, merdows et partout, ils utilisent Boehm GC. Si ce n'est pas une belle preuve de portabilité, etc ...
Je parlais du fait qu'il ait été intensivement testé.
Ensuite la portabilité ... ben suffit de pas utilisé des librairies spécifiques (winsock par ex) et c'est d'un coup plus simple.
Boehm GC par défaut n'est pas thread-safe, tu ne nous apprends rien de nouveau.
Pour un truc "intensivement testé" et donc "deverminé", c'est un peu opposé a "supporte meme pas les threads".
Pourquoi il n'est pas thread safe avec les options de compilation de base ? Il faut se taper l'ensemble de la doc sur le ternet pour trouver quelque chose ?
quant a ton boehm "thread safe" , de base:
1. It causes the garbage collector to stop all other threads when it needs to see a consistent memory state.
2. It causes the collector to acquire a lock around essentially all allocation and garbage collection activity.
Trop génial : un lock global.
Ah non, y'a pas a dire, trop top génial gc... completement testé.
Le coup du lock global d'un coup c'est plus simple, mais c'est pas ce que j'appelle quelque chose de finalisé, ni efficace
Quant aux autres options indiqués, tu m'excusera, elle semble d'un coup vachement moins "intensivement testé" ...
Ah il est peut etre genial, j'ai vu qu'il avait un gc 7.0 ...
C'est bien, et c'est quoi la différence avec gc 6.0 ? 6.7 ?
Gc est peut etre génial, avec une tonne d'option de compilation, de define qui font même le café, mais tu m'excusera, avec une doc comme ça...
[^] # Re: Rapidité du C ... et ramasse-miettes ?
Posté par Amos Wenger . Évalué à 1.
"être thread-safe" détériore la performance dans un environnement monoprocessus. D'où l'intérêt de ne pas l'être.
> la portabilité.. suffit de pas utiliser de libraries comme winsock
Hum. Voilà une remarque de quelqu'un qui n'a pas vu assez de #ifdef dans sa vie.
Sérieusement, faire une librairie C bas-niveau portable c'est juste un exploit sans cesse renouvelé.
Mais bon si c'est si facile hein vas-y code un meilleur GC, je serais le premier utilisateur.
[^] # Re: Rapidité du C ... et ramasse-miettes ?
Posté par imalip . Évalué à 3.
Ou alors de quelqu'un qui en a deja vu beaucoup trop...
[^] # Re: Rapidité du C ... et ramasse-miettes ?
Posté par briaeros007 . Évalué à 1.
Si tu estime que les race conditions ne sont pas des bugs...
"être thread-safe" détériore la performance dans un environnement monoprocessus. D'où l'intérêt de ne pas l'être.
1°) ce n'est pas toujours vrai
2°) y'a des méthodes pour faire en sorte que la détérioration soit minimale
3°) la vérification des codes de retour et la gestion des erreurs détériore aussi la performance, d'où l'intérêt de ne pas faire de gestion d'erreur ?
Marrant j'ai pas la même conception.
Sérieusement, faire une librairie C bas-niveau portable c'est juste un exploit sans cesse renouvelé.
Un exploit rien que ça.
Si on vire un certain os qui est infoutu de respecter la moindre norme, c'est d'un coup plus facile. :P
Mais bon si c'est si facile hein vas-y code un meilleur GC, je serais le premier utilisateur.
Alors tu sors "il est super G, super testé super stable toussa".
J'ose dire "euh non, pas super g, et si on teste franchement les threads alors ca merde".
Et ta réponse "non mais tu as qu'a la coder".
Mais j'en ai RIEN A FOUTRE de coder un gc, moi je l'utilise pas!
Et puis j'ai jamais dis que c'était facile. J'ai juste osé dire que tout n'était pas parfait au pays des gc.
Si tu n'es pas foutu d'accepter ça....
[^] # Re: Rapidité du C ... et ramasse-miettes ?
Posté par Amos Wenger . Évalué à 1.
Et par contre personne ici n'a jamais dit que tout était parfait au pays des GC. Pour ma part, c'est juste un des compromis existants qui me satisfait.
Pour ce qui est d'être thread safe, je persiste et signe, non, pour une application/librairie clairement designée pour tourner en monoprocessus seulement, ne pas être thread-safe "is not a bug, it's a feature".
Pour le parallèle, il y a d'autres projets, voir le lien de Sébastien Binet ci-dessous.
[^] # Re: Rapidité du C ... et ramasse-miettes ?
Posté par Sebastien . Évalué à 2.
http://code.google.com/p/scarcity/
il devrait être utilise a terme par python (unladen-swallow)
[^] # Re: Rapidité du C ... et ramasse-miettes ?
Posté par GeneralZod . Évalué à 2.
Effectivement, scarcity devrait être utilisé comme GC pour unladen-swallow mais étant écrit en C++, il est improbable qu'il soit inclut dans CPython.
PS: d'après Google, unladen-swallow est plus un fork "temporaire" de CPython qu'une implémentation distincte, en outre, unladen-swallow vise la compatibilité source avec CPython et ses extensions.
http://code.google.com/p/unladen-swallow/wiki/ProjectPlan
[^] # Re: Rapidité du C ... et ramasse-miettes ?
Posté par djano . Évalué à 0.
Sérieusement, Boehm gc a commencé comme étant not thread safe et il l'est encore. La belle affaire! Ta critique n'est pas bien utile. Critiquer un gc sur le fait qu'il n'est pas thread safe alors que cela est connu n'apporte rien.
Si il est très utilisé, statistiquement plus de bogues sont corrigés, et vu que Mono/GCJ/Mozilla/LLVM sont pas des branquignols, ils ont faits des rapports de bogues et même fait le patch qui va avec.
Ce qui n'a rien a voir avec «intensivement testé».
Les tests ne testent que ce pour quoi on les écrit si on dit que le GC est pas thread-safe pourquoi écrire des tests pour montrer qu'il ne l'est pas? hmm?
Boehm GC par défaut n'est pas thread-safe, tu ne nous apprends rien de nouveau.
Pour un truc «intensivement testé» et donc «deverminé», c'est un peu opposé a «supporte meme pas les threads».
Je vois pas le rapport.
Trop génial : un lock global.
Ah non, y'a pas a dire, trop top génial gc... completement testé.
Le coup du lock global d'un coup c'est plus simple, mais c'est pas ce que j'appelle quelque chose de finalisé, ni efficace
Ahem Python a aussi un lock global. Linux, FreeBSD avaient un lock global jusqu'à récemment. Pourtant ils étaient déjà utilisé en production mais pas finalisés selon toi? Il faut croire que tout le monde ne voit pas les choses de la même manière que toi.
M'enfin si ça t'amuse continue a critiquer dans le vent.
[^] # Re: Rapidité du C ... et ramasse-miettes ?
Posté par briaeros007 . Évalué à 1.
Ah le fameux "si tu code pas, tu peux pas critiquer", histoire de bien se cacher les yeux et expliquer ensuite ce que l'utilisateur veux.
Alors je le redis JE RECODERAIS PAS GC, ET JE CONTINUERAIS A DIRE QU'IL A DES MERDES tant qu'il en auras.
Et si tu n'es pas content, ben c'est ton problème.
Sérieusement, Boehm gc a commencé comme étant not thread safe et il l'est encore. La belle affaire! Ta critique n'est pas bien utile.
Comme 30 poste pour dire "you want it you code it. You're juste a looser. Developer of gc are god".
Critiquer un gc sur le fait qu'il n'est pas thread safe alors que cela est connu n'apporte rien.
1°) si : indiquer qu'il n'est pas thread-safe
2°) l'information qu'il n'est pas thread-safe, contrairement a ce que tu affirme, n'est pas si "connu que ça".
De toute façon, tu as vu la page de gc ? Et tu ose me tenir rigueur du fait que leurs trucs sont mal expliqué ?
J'ai vu des sources de la version 7, et les tests et ajouts que j'ai vu sur le site officiel concernait la version 6...
faut faire quoi ? écumer google
Les tests ne testent que ce pour quoi on les écrit si on dit que le GC est pas thread-safe pourquoi écrire des tests pour montrer qu'il ne l'est pas? hmm?
Ne pas dire qu'il est super stable si il n'est pas thread-safe.
Je vois pas le rapport.
Moi si.
Ahem Python a aussi un lock global.
On parlait de gc ou de python ?
Linux, FreeBSD avaient un lock global jusqu'à récemment.
On parlait de gc ou de linux ?
et atha , le "jusqu'à récemment" ... pourquoi l'ont ils enlevé ? Parce que c'était la meilleure solution le lock globale.
Sans compter que comparer un gc a un noyau est relativement comique.
Il faut croire que tout le monde ne voit pas les choses de la même manière que toi.
Voui c'est clair. D'ailleurs sous linux ils comptent mettre un autre gros lock global une fois qu'ils auront réussi a enlever le précédent, parce que c'est une solution technique tellement elegante et efficiente....
M'enfin si ça t'amuse continue a critiquer dans le vent.
Quant tu devra coder des applis parallèles, performantes, avec un framework qui utilise gc, on verras si tu estimeras encore que c'est "dans le vent" quant tu auras un bon gros bug au milieu, et que tu est obligé de perdre une semaine a trouver que c'est le gc qui merde.
[^] # Re: Rapidité du C ... et ramasse-miettes ?
Posté par Amos Wenger . Évalué à 1.
# Ramasse-miette conservatif..
Posté par reno . Évalué à 2.
Ce n'est pas qu'un probleme théorique: j'ai vu plusieurs message sur le newsgroup de D d'utilisateurs qui se plaignaient d'une consommation excessive de mémoire qui était tombé dans ce cas la (D utilise aussi le Boehm GC).
L'avantage du ramasse miette Boehm est qu'il est mature et fonctionne avec du C (enfin si le C n'est pas trop crade: pointeur XOR-és: aucun GC ne peut traiter cela pourtant c'est possible en C) mais cela n'en fait pas (et de loin) le top au niveau ramasse-miette..
Je pense notamment qu'il ne doit pas etre tres temps reels (meme s'il est incrémental d'après wikipedia).
[^] # Re: Ramasse-miette conservatif..
Posté par Amos Wenger . Évalué à 1.
Pour ce qui est de l'usage d'un gc (peu importe lequel) en temps réel, je n'ai jamais entendu/vu ça. URL, please.
[^] # Re: Ramasse-miette conservatif..
Posté par reno . Évalué à 3.
http://lambda-the-ultimate.org/node/2034
Le seul language avec une implementation libre que je connais avec un GC temps reel est SuperCollider:
http://supercollider.sourceforge.net//
Comme autre ammélioration possible: un GC qui 'interagit' avec le systeme de mémoire virtuel d'un OS (nécéssite qu'il soit modifié en conséquence donc pas utilisé a l'heure actuel) pour reduire les conséquence qu'une fuite mémoire a avec un GC classique:
http://lambda-the-ultimate.org/node/2391
[^] # Re: Ramasse-miette conservatif..
Posté par Amos Wenger . Évalué à 1.
Malheureusement, de ce que je peux voir, il n'y a pas grand chose d'utilisable "out-of-the-box". On va dire que pour l'instant, comme GC, le Boehm me va assez bien je trouve.
[^] # Re: Ramasse-miette conservatif..
Posté par reno . Évalué à 1.
Et pour le GC qui coopère avec la mémoire virtuelle j'ignore si l'auteur en a fait une implémentation libre mais de toute manière ses patches pour le noyau Linux ont été rejeté, ce GC n'est donc pas utilisable actuellement en effet.
# Compatibilité avec les lib C++ ?
Posté par 0xFF . Évalué à 2.
Est-ce que c'est impossible de marier les deux ?
[^] # Re: Compatibilité avec les lib C++ ?
Posté par Pierre Bourdon . Évalué à 1.
[^] # Re: Compatibilité avec les lib C++ ?
Posté par Amos Wenger . Évalué à 2.
J'ai moi-meme eu ce probleme, puisque pour le projet pour lequel j'ai ecrit ooc, l'enonce encourageait a utiliser GLUI (librairie graphique d'interface utilisateur en C++). J'ai donc du me lancer dans les joies de la compilation jointe de code C et C++ (sans avoir son main dans un .cxx), et c'est horrible. Et j'ai du écrire toutes les méthodes à la main.
En revanche, en pratique, rien n'empêche d'améliorer le compilateur ooc pour qu'il comprenne les headers C++ et permette l'utilisation de leurs classes/fonctions. Moi c'est plus la compatibilité binaire qui m'inquiète (entre le C et le C++), parce que oui, le C++ n'a pas d'ABI standard, bien sur...
Si assez de personnes sont intéressées par l'utilisation transparente de librairies C++ en ooc, je me pencherais volontiers sur le problème, même si je préfèrerais voir fleurir des ports en ooc de librairies C++ ;)
[^] # Re: Compatibilité avec les lib C++ ?
Posté par Cédric Chevalier (site web personnel) . Évalué à 2.
Faut arrêter quand même c'est pas du FORTRAN... Les codes mixtes C/C++ sont fréquents et cela se passe plutôt bien.
[^] # Re: Compatibilité avec les lib C++ ?
Posté par LupusMic (site web personnel, Mastodon) . Évalué à 1.
Mais je ne vois pas le problème d'avoir un main dans un .c et d'utiliser une API C++. Il y a des méthodes qui permettent de facilement jongler entre les différentes unités de compilation.
[^] # Re: Compatibilité avec les lib C++ ?
Posté par Amos Wenger . Évalué à 1.
Ah bon ? Faudra penser a mettre a jour Wikipédia, dans ce cas:
"The C++ standard therefore does not attempt to standardise name mangling. On the contrary, the Annotated C++ Reference Manual (also known as ARM, ISBN 0-201-51459-1, section 7.2.1c) actively encourages the use of different mangling schemes to prevent linking when other aspects of the ABI, such as exception handling and virtual table layout, are incompatible."
Source: [http://en.wikipedia.org/wiki/Name_mangling#Standardised_name(...)]
> Mais je ne vois pas le problème d'avoir un main dans un .c et d'utiliser une API C++. Il y a des méthodes qui permettent de facilement jongler entre les différentes unités de compilation.
Ma foi c'est bien possible qu'à l'époque je m'y sois mal pris. De toute façon j'ai vite abandonné GLUI (beurk) pour faire mon appli en GTK+/gtkglarea.
[^] # Re: Compatibilité avec les lib C++ ?
Posté par LupusMic (site web personnel, Mastodon) . Évalué à 1.
Il y a donc un effort de standardisation entre les différents compilateurs, sans avoir de norme établie. Cela me rend perplexe quand au fonctionnement de programmes compilés avec gcc sous MS Windows, utilisant des bibliothèques compilées avec le compilateur C++ de Microsoft. Il doit bien y avoir une compatibilité binaire.
[^] # Re: Compatibilité avec les lib C++ ?
Posté par Amos Wenger . Évalué à 1.
[^] # Re: Compatibilité avec les lib C++ ?
Posté par Zenitram (site web personnel) . Évalué à 2.
C'est standardisé en C, pas en C++.
En C, tu peux faire communiquer une appli et une DLL quelque soit le compilo de chacun en forçant le typage par le langage
En C++, le mangling merde, et donc il faut le même compilo (la même marque).
Quand aux libs statiques, effectivement c'est encore plus la merde!
[^] # Re: Compatibilité avec les lib C++ ?
Posté par Amos Wenger . Évalué à 1.
Cela me rend perplexe quand au fonctionnement de programmes compilés avec gcc sous MS Windows, utilisant des bibliothèques compilées avec le compilateur C++ de Microsoft.
[^] # Re: Compatibilité avec les lib C++ ?
Posté par Zenitram (site web personnel) . Évalué à 3.
Et la plupart des DLL proposent une API en C (quitte à faire un binding C vers C++ en interne, ce que je fais par exemple).
[^] # Re: Compatibilité avec les lib C++ ?
Posté par Amos Wenger . Évalué à 1.
Puisqu'on finit toujours par en revenir au C, pourquoi ne pas partir du C tout court..
[^] # Re: Compatibilité avec les lib C++ ?
Posté par Troy McClure (site web personnel) . Évalué à 2.
[^] # Re: Compatibilité avec les lib C++ ?
Posté par 0xFF . Évalué à 1.
Je pense que la possibilité d'instancier et d'utiliser des objets C++ dans ooc serait suffisante. Hériter des classes C++ en ooc ne me semble pas du tout indispensable (d'ailleurs ça me semble même dangereux). Ne parlons même pas des templates qui n'ont rien à faire en dehors du code C++ :)
Après, je ne sais pas dans quel mesure cela est faisable. Mais je serais attentif aux évolutions de ooc.
[^] # Re: Compatibilité avec les lib C++ ?
Posté par Amos Wenger . Évalué à 1.
Je donnerais donc des nouvelles a propos du support des librairies C++ sur le blog, probablement.
[^] # Re: Compatibilité avec les lib C++ ?
Posté par mosfet . Évalué à 1.
Ceci dit une citation pour me contredire :
Ils ne savaient pas que c'etait impossible. Alors ils l'ont fait
[^] # Re: Compatibilité avec les lib C++ ?
Posté par Amos Wenger . Évalué à 1.
Et puis bon, moi avec une page comme ça, je suis comblé et j'suis assez grand pour implémenter tous leur algorithmes de Name mangling incompatibles pourris : http://en.wikipedia.org/wiki/Name_mangling#How_different_com(...)
Et si ça suffit pas, eh ben le reste des différences est ajustable aussi (oui ça va créer du code C spécifique à un compilateur C++, mais personne a dit que tout ce qui était pratique était nécessairement propre). Ce qui est très fastidieux (voir impossible) à faire quand on a à le faire à la main, peut devenir au moins possible, voire même très accessible, quand on a tous les éléments en main pour l'automatiser (=qu'on modifie son propre compilateur.)
En l'occurence pour parser les headers C++ (qui ne sont tout de meme pas une partie de plaisir), j'avais pensé a Elsa: [http://www.eecs.berkeley.edu/~smcpeak/elkhound/sources/elsa/] Et puis finalement je pense réécrire le front-end du compilateur ooc + un parser de headers C/C++ avec ASF+SDF [http://www.meta-environment.org/] et ça, ça a l'air sacrément puissant et ça génère des APIs en Java et C (donc utilisable aussi pour rock, réécriture du compilateur ooc en ooc lui-même.)
Bref, ne crions pas défaite trop vite non plus. (Et pis si c'était pas impossible, y'aurait aucun fun, non?)
[^] # Re: Compatibilité avec les lib C++ ?
Posté par 0xFF . Évalué à 1.
Je m'excuse par avance dans le cas ou j'aurais dit une grosse bêtise...
[^] # Re: Compatibilité avec les lib C++ ?
Posté par Amos Wenger . Évalué à 1.
Le seul problème potentiel avec ça que je voyais c'est que les compilateurs C++ sont méchamment plus stricts au niveau des casts que les compilateurs C. (Donc non, le C++ n'est pas un superset du C compatible), donc il faudrait que je modifie le générateur de code pour qu'il rajoute des casts partout ou il faut, afin que les compialteurs C++ ne pleurent plus.
Alors qu'avec l'approche que je propose, ooc ferait un petit bout du boulot qu'un compilateur C++ ferait (principalement le name mangling) et enverrait tout ça au compilateur C, qui serait très content puisqu'il trouverait les bons symboles (ex. noms de fonctions) dans les librairies C++ avec lesquelles on lui demande de linker.
(puristes: oui le compilateur ne linke pas, mais je prend des raccourcis pour être plus compréhensible)
# Critique du langage.
Posté par LupusMic (site web personnel, Mastodon) . Évalué à 2.
Pour l'ensemble de mes remarques, je vais suivre et commenter le ninja language reference http://ooc-lang.org/doc/langref/book1.htm (tu devrais rajouter dans la FAQ pourquoi c'est une référence Ninja).
http://ooc-lang.org/doc/langref/c31.htm
« All types should be in CamelCase, all variables and functions in camelCase. [...] The justification for that is consistency. »
Je ne vois pas en quoi le nomage des « types » en Java est incohérent. Les POD ont une minuscule parce qu'ils ne sont pas des objets. Si ton système est cohérent, alors on peut dériver depuis un Int. Dans le cas contraîre, c'est OOC qui est incohérent et non Java. À noter qu'ici Java est cohérent, raison de l'existence des classes Integer, Float, etc.
Quand au C++, la tradition est de ne jamais utiliser de majuscules. Que ce soit pour les noms de classe ou des fonctions. Seules exeptions, les noms de constantes ou les nom des paramètres de templates. Par exemple : void std::map<template T>::push(T &) ;
« You can declare several variables on the same line »
Mauvaise habitude. En plus tu montre que tu ne sais pas que le type pointeur n'existe pas en C/C++ (c'est un qualificatif).
« Correspondance with C and Java types »
En Java, je crois bien qu'on peu utiliser le mot-clé « self » dans la liste des paramètres et le type de retour des fonctions membre. En C++, je déclare souvent typedef Myclass self.
Je ne comprends pas cette prolifération de types numérique. Pourquoi ne pas proposer un type générique qui gère les opérations sur les nombres avec une précision arbitraire ? Ça permettrait de totalement abstraire l'usage des nombres, ce qui manque avec C++ et Java (il faut toujours faire attention aux limites, ce qui est rarement testé correctement, voir ignoré le plus souvent).
Le nom Octet est franchement maladroit, quant on sait qu'un byte ne fait pas forcément un octet. D'ailleurs, quelle est la taille de tes int (parce qu'en C, c'est dépendant de l'architecture, tout comme char) ?
« printf("A moins que vous n'epousiez la %s?\n", name); »
Pourquoi pas :
console.print "A moins que vous n'epousiez la %s?\n".format name ;
Je n'arrive pas à entrevoir l'intérêt des Covers sur la dérivation de la classe.
http://ooc-lang.org/doc/langref/x209.htm
Une critique qu'on peut faire au C++, c'est d'avoir conserver les tableaux à la mode C. Pourquoi faire la même erreur ? L'encapsulation des tableaux permet d'éviter la duplication des tests de contrôle, et surtout t'éviter tout problème de sécurité relatif au débordement de tampon (et de centraliser la correction d'un éventuel bogue). Ton langage impose déjà plusieurs paradigme : tu devrais aller au bout de ton idée. Sinon, autant faire du C ou du C++.
« A function is declared with the func keyword. »
Pourquoi un mot-clé ?
« func add(Int arg1, Int arg2) -> Int { } »
Argh... Je n'ai jamais compris cette logique que de noyer le type de retour après la list de paramètres (Pascal, Basic, etc).
« The main function: entry point »
Mais pourquoi une fonction ? :D
« SDL_Quit(); // We must use parenthesis, cause it's a C function »
On pourrait te reprocher une certaine incohérence à ce niveau là. Mais je comprends la limitation technique.
« Instanciation »
Je ne comprends pas l'intérêt du mot-clé new. En plus, de ce que j'en comprends, tes types ne sont jamais créé sur la pile ? Dans ce cas, tu devrais reprendre ton benchmark sur l'instantiation, et faire la création sur la pile. Tu verras que la différence de performances est... non-négligeable (l'instantiation sur la pile est 7× plus rapide que dans le tas, chez moi).
Un objet peut-il être utilisé comme un functor ?
Les objets sont polymorphiques ?
Quelle est la portée par défaut des membres d'une classe ? Public ? N'est-ce pas là une violation du principe d'encapsulation ?
« for in ranges »
C'est pratique, indubitablement. Une bonne idée serait de rajouter un type Range. Pour éviter de déclarer des ensemble en dur dans les boucles. En embarquant le pas dans le Range, évidemment.
Tu aurais pu virer switch ;)
Pas de do..while ?
« The package of a source unit is relative to the sourcepath. »
Je ne penses pas que ce soit une bonne idée. Pour tout un tas de raisons, allant de la relativité du chemin au caractère dur du chemin. Bien que le mot-clé super permette de contourner partiellement ce défaut.
Voilà pour mes quelques remarques. J'espère que ça t'aidera dans ta réflexion.
[^] # Re: Critique du langage.
Posté par Amos Wenger . Évalué à 1.
> ninja language reference
ninja est le nom de code de la version 0.2. Je devrais peut-etre mettre entre parenthese le nom complet de la version pour éviter les problèmes de priorité d'opérateurs ;)
> types primitifs en minuscule/majuscule
ca dépend de ta définition de "cohérence", en fait. comme dit dans le guide, ooc privilégie la cohérence syntaxique. Cela permet une lecture du code très facile. Tout ce qui a une majuscule en premier = un type. Tout ce qui n'en a pas = une variable ou une fonction
Pour la "tradition C++", le problème c'est que comme il n'y a aucun standard qui est forcé, tout le monde le fait a sa sauce, et a utiliser c'est un joyeux mélange.
Quant aux classes Integer/Float en Java, ce sont a mon humble avis des abominations.
> several variables on the same line
Je ne vois pas ou est-ce que j'ai dis que "pointeur" etait un type. De plus, sans les pièges du C/C++ concernant justement ce point de grammaire, la déclaration de plusieurs variables lignes n'est *plus* une mauvaise habitude, puisqu'elle est sans danger.
> correspondance with C and Java types
Le mot-clé self? Jamais entendu parler en Java. url?
pour les types numériques, il y en a peut-etre en effet plus que nécessaire.. personellement j'utilise quasiment uniquement des Int et des Float, mais c'était surtout pour ne pas décevoir les programmeurs C qui aiment avoir des types petits pour pouvoir stocker érnomément de nombres en mémoire.
Pour Octet, et bien précisément non il n'est pas maladroit ;) Le guide ne l'explicite pas assez, mais c'est un typedef vers un uint8_t qui a une taille fixe de.. 8 bits. Si "unsigned char" est aussi dans la colonne "C" a la meme ligne, c'est parce qu'il est généralement utilisé à sa place, par erreur de compréhension (donc que ceux qui utilisent des unsigned char a la place d'uint8_t devraient utiliser des Octet et non des Char en ooc.)
Les Int en revanche sont des typedefs vers int, donc ils sont également de taille variables. Je vais réfléchir a l'utilisation d'un type numérique de précision arbitraire, mais j'ai l'impression que ce serait très couteux au niveau performance, non?
> pourquoi pas console.print "A moins que vous n'epousiez la %s?\n".format name ;
la vraie question est "quand" et non "pourquoi pas" ^^ l'appel de fonctions ayant des arguments sans parentheses est prévu, et la méthode format de String aussi, cependant ça, ça attendra que je trouve une bonne manière d'implémenter/d'écrire (syntaxe) les fonctions variadiques.
> covers
ce qui a pu t'échapper, c'est qu'une Cover, c'est d'un type primitif, pas d'une classe. Rajouter des fonctions a un type primitif, et donc pouvoir l'utiliser (syntaxiquement) comme un objet, c'est l'utilité principale des covers.
> tableaux
c'est vrai que je n'y ai pas réfléchi beaucoup. Dans l'application qui m'a poussé a développer ooc, j'utilisais des structures plus avancées comme des ArrayList/SparseList, donc des routines de bas niveau encapsulées dans des classes donc avec bound checking et tout le bazar. Je ne vois aucune objection a encapsuler tous les tableaux dans des objets, de plus le cout est rellement minime (1 pointeur vers la structure de meta-classe).
> mot-clé func
1) lisibilité, 2) facilité de parsing (moins d'ambiguites dans la grammaire). Et si tu as des doutes sur la nécessité de résoudres des ambiguités qui apparamment n'existent pas, considère que j'ai prévu en ooc la possibilité de faire des fonctions imbriquées (nested functions), et des closures. Le mot-clé func permet donc d'être très lisible et clair dans tous les cas.
> type de retour après la liste des paramètres
parce que 1) en C, void ne sert a rien (sinon a faire des pointeurs sur n'importe quoi). C'est un mot parasite qui encombre la syntaxe. Avec une syntaxe comme ooc 0.2, quand tu as une liste de fonction tu vois les choses de gauche a droite dans l'ordre qui t'intéresse le plus (en général) a savoir 1) le nom de la fonction 2) les arguments qu'elle prend et 3) le type de retour s'il y en a un.
> pourquoi une fonction main?
heuuuuuuuuuuuuuu eh ben parce qu'on a toujours fait comme ça? ;) non sans rigoler, merci de me rappeler ce que je voulais faire depuis longtemps, en fait. je note.
> SDL_Quit()
en effet c'est une incohérence ET une limitation technique temporaire. La note de bas de page explique la difficulté à parser correctement certains headers C. Des améliorations sont à attendre dans les prochaines versions, of course.
> Instanciation & mot-clé new
le mot-clé new est principalement une affaire de lisibilité
Pour l'allocation sur la pile/le tas, eh bien.. pour etre franc, je me suis dit "Java alloue tout sur le tas, et les performaces sont acceptables dans la plupart des cas, donc ça ne devrait pas poser problème."
Et, après benchmarks, eh ben effectivement:
newbench_O1 6.522s
newbench_O1_stack: 1.004s
newbench_O2: 5.890
newbench_O2_stack: 0.867s
Je viens de me dire.. je pourrais faire en sorte, dans le compilateur, que le compilateur détecte ce qui peut etre alloué sur la pile ou le tas, suivant si la variable reste locale ou si son adresse est envoyée ailleurs pour être stockée (ex. appel de fonction avec une assignation de pointeur) ou si elle reste locale, auquel cas elle peut etre allouée sur la pile.
> functor
si tu demandes si on peut appeler un objet avec une méthode call a une fonction qui s'attend a un pointeur sur une fonction en espérant très fort que ca appelle "call" tout seul, eh bien non. Pour l'instant, ooc gère les pointeurs sur les fonctions de la même manière que le C pur, mais cela pourrait bien changer (pour permettre le passage de fonctions membres en tant que callback.) J'ai déjà testé une solution basée sur GNU lightning, qui assemble en temps réel une fonction qui appelle la fonction member sur le bon objet. Je n'ai pas fait de benchmarks de performance, par contre.
> les objets sont-ils polymorphiques ?
bien sur =) ooc n'aurait que peu d'intérêt s'ils ne l'étaient pas.
> portée par défaut et encapsulation
absolument, ooc ne gère actuellement pas les différentes portées, et c'est très très vilain de ma part (je devrais être puni). Mais de nouveau, c'est par manque de temps pour l'instant: implémenter correctement les règles d'encapsulation n'est pas du tout simple, vous pouvez trouver facilement des exemples contre-intuitifs en Java par exemple.
> for in ranges
le type range, c'est prévu ^^ de nouveau, manque de temps jusqu'ici.
> virer switch
tiens donc? pourquoi cela? je pensais juste inverser le comportement par défaut du C/C++/Java, plus précisément introduire un mot-clé fallthrough et gicler le mot-clé break pour les switch.
> do while
Tiens donc, petit oubli de ma part. Bien que je ne l'aies pas du tout prévu dans le compilateur ooc, ca compile quand meme (je viens de tester) car cela ne provoque pas d'erreur de syntaxe.
> relative to the sourcepath
eh bien c'est un point controversé en effet, je n'ai pas fini d'y réfléchir, mais j'attends encore qu'on me donne une très bonne raison pour devoir rajouter des lignes "package blah.truc.machin;" a toutes mes classes, autre que "ouais mais si c'est pas le bon sourcepath, ca va tout foirer". C'est pas des manchots, les programmeurs quand meme, ils savent encore quel sourcepath ils mettent, non?
en tout cas merci pour toutes les remarques, c'est assez curieux: pour la moitié j'ai l'impression que tu voudrais transformer ooc en python, et l'autre moitié que tu voudrais le transformer en C++! on va tenter de trouver un juste milieu =)
[^] # Re: Critique du langage.
Posté par 0xFF . Évalué à 2.
Je sais que l'héritage multiple de classes peut s'avérer très dangereux quand il n'est pas utilisé correctement, mais dans certaines situations c'est tellement pratique.
[^] # Re: Critique du langage.
Posté par Amos Wenger . Évalué à 1.
Pourquoi maintenir la différence entre classe et interface? Parce que dans l'implémentation courante, les casts entre sous-classes et super-classes sont quasiment gratuits, ce sont de bêtes casts C;
abstract class Parent {
abstract func call;
}
class Child from Parent {
implement call {
// blablablah.
}
}
func doThing(Parent p) {
p.call;
}
func main {
// le fait de passer un Child au lieu d'un Parent
// n'induit quasiment aucune pénalité
doThing(new Child);
}
puisque les champs et les fonctions, dans leurs structures respectives, sont ordonnés dans l'ordre d'héritage (un enfant a les champs/fonctions de ses parents dans le même ordre, puis les siens, voir l'ABI "standard" ooc dans le language reference guide).
Dans le cas d'une interface, voila comment je pensais l'implémenter:
- Une "map" (concrètement un tableau de pointeurs de fonction), donc les clés sont des identifiants qui correspondent a un nom pleinement qualifié d'interface (codés par je ne sais quel algorithme miracle qui prend avantage du fait que seuls les caractères alpha-numériques sont autorisés dans les noms de paquetages), et dont les valeurs sont des pointeurs vers des structures qui contiennent un tableau de pointeurs sur les implémentation par la classe des fonctions de l'interface et ce dans le bon ordre de déclaration.
En bref, une fois de plus, pour implémenter le polymorphisme j'utilise des structures avec des pointeurs sur fonction qui sont assignés aux bonnes implémentations a l'initialisation, et retournées suivant vers quoi on cast. Retourner le parent est "straight-forward", mais retourner une interface, pas, puisqu'une classe peut potentiellement implémenter un nombre infini d'interfaces et ce dans n'importe quel ordre.
interface Callable {
abstract func call;
}
// pas de différence de mot-clé entre super-classe/interface. bien? mal? c'est en réflexion.
class Concrete from Callable {
implement call {
// blablablah.
}
}
func doThing(Callable c) {
c.call;
}
func main {
// le fait de passer un Concrete au lieu d'un Callable
// implique un cast implicite vers une interface
doThing(new Concrete);
}
En résumé donc; il y aurait une pénalité pour caster vers une interface, mais une fois casté, l'appel de fonctions est aussi peu cher que l'appel de fonctions d'une classe/super-classe directement.
Note: s'il y a une implémentation évidente, plus simple et plus performante à la fois, je suis tout à fait preneur. Sinon, je pense aller par cette voie.
# Super un nouveau langage
Posté par mosfet . Évalué à 1.
En effet je travaille sur un projet du nom de gynoid(clin d'oeil a android) qui consiste a wrapper en C les api des teléphones portables (wince, symbian, iPhone et peut etre un jour android si google l'autorise).
A l'heure actuelle l'acces a l'adressbook est en train d'etre finalisé et j'avais adopté pour ce framework une approche orientée objet afin de simplifier le wrapping objet plus tard.
Par exemple pour acceder aux contacts de l'adressbook on écrit :
// Desolé pour l'indentation c pas très lisible
ErrorCode err = 0;
int iCount = 0;
GDAddrBook* pAddrBook = NULL;
GDAbItem* pAbItem = NULL;
if (!GDAddrBook_Alloc(&pAddrBook) &&
!GDAddrBook_Init(pAddrBook, 0) )
{
GDAddrBook_GetCount(pAddrBook, &iCount);
for (int i = 0; i < iCount; i++)
{
if (GDAddrBook_GetItem(pAddrBook, i, &pAbItem) == 0)
{
GDCTSTR lpFirstName = (GDCTSTR) GDAbItem_GetProperty(pAbItem, eAbFirstName);
//GDConsole_Writeln(_T("FirstName %s\nLastName %s\n", ...);
_tprintf( _T("[%d] %s %s %s\n"), i, lpFirstName, lpLastName, lpMobTel);
GDObject_Release(pAbItem);
}
}
}
Chacun de mes "objets" GDxxxx derive d'une structure avec une variable pour les références comptées.
Problème c'est que les developpeurs aujourd'hui ne sont plus vraiment intéréssés par le C et ce d'autant plus qi'on developpe des interfaces graphiques, c'est pourquoi je cherchais un langage qui me permettrait d'offrir un langage plus haut niveau et rellement objet.
Je me suis tourné des le départ vers le langage D car il concu par des grands noms du C++(A. Alexandrrescu) et des experts en compilation (Walter Bright) mais le problème est que le compilateur n'est ps disponible sur plateforme arm et que le compilo gnu GDC n'est meme plus maintenu.
Par consqéquent ooc est une alternative sérieuse au D dans mon cas précis.
Je pense par contre que ce serait pas mal de lancer un projet pour implémenter un frontend au sein de gcc ou mieux au sein de llvm car cela permettrait par la suite de pouvoir générer u narbre syntaxique ou un truc du genre pour prendre en charge la complétion dans un IDE par exemple.
Bon d'abord je vais étudier un peu plus le langage et j'essaierais de donner un retour.
[^] # Re: Super un nouveau langage
Posté par mosfet . Évalué à 1.
[^] # Re: Super un nouveau langage
Posté par mosfet . Évalué à 2.
C'est pour ca que pour le moment j'utilise une macro qui me permet de compiler en fonction de la platforme soit en ansi soit en unicode.
Ca serait pas mal de pouvoir faire la meme chose avec ooc
Ca veut dire qu'au moment de la compilation on pourrait faire :
func main
{
_tprintf( _T( "Hello world ))\n" );
}
avec _tprintf qui serait résolu en printf pour les systemes unix-like et en wprintf pour les systemes windows et symbian.
Bon tout ca pour dire que j'aimerais que pour une fois un langage prenne en compte les spécificités des os mobiles.
En ce qui concerne les delegates et les pointeurs de fonctions membres, on est limité par le C et ne pourrait on pas envisager a terme une version de ooc-++ mais ceci dit cela viendrait a perdre tout l'interet et dans ce cas la autant faire un nouveau langage dérive du C (tiens ca existe deja et ca s'appelle le D) qui ne se contente pas de wrapper un autre.
Bref j'attends de voir comment va évoluer cette partie callbacks/delegates/pointeurs de fonctions.
[^] # Re: Super un nouveau langage
Posté par Amos Wenger . Évalué à 3.
Pour répondre à tes questions une par une:
* Oui, ooc est une alternative sérieuse au D dans ton cas, et je suis absolument motivé de corriger le générateur de code si le C produit ne compile pas pour un target ARM (j'ai l'habitude des plateformes *très comfortables*, e.g. Gentoo Linux sur un x86, donc j'ai des fois tendance à oublier que dans le monde réel il y a plus de contraintes.)
* En effet, le D est un langage très bien conçu (à mon avis) et par des gens sérieux, mais les implémentations libres laggent méchamment derrière DMD, tout ça à cause de leur état d'esprit semi-propriétaire et c'est vraiment dommage.
* Les delegates sont prévus, c'est de plus très rapide a implémenter, donc pas de souci de ce côté là.
* Pour les chaines ASCII/UTF-16, etc. je te propose une solution que j'envisageais depuis longtemps: annoter les fonctions C, pour dire à quel type de String elles s'attendent, et permettre de surcharger le cast, pour passer par des fonctions de conversions. Qu'en penses-tu ?
* Pour les pointeurs de fonction membres, je n'ai que survolé le sujet dans le language reference guide, mais mes plans sont assez précis. Peux-tu vérifier que les créateurs de LibJIT disent vrai quand ils prétendent supporter la plateforme ARM? (exemple essayer de compiler leurs exemples dessus). C'est par ici que ça se passe: [http://code.google.com/p/libjit-linear-scan-register-allocat(...)] Pourquoi un Just-In-Time assembler, me direz-vous? Pour faire du currying en ooc [http://en.wikipedia.org/wiki/Currying] c'est à dire "créer en temps réel une fonction avec qq arguments fixés" et je pense bien sur au premier argument, c'est a dire le pointeur vers la structure de l'objet duquel on appelle la fonction. Bien sur il faudrait benchmarker l'utilisation CPU/Mémoire additionelle que cela implique, mais ça serait *tellement* pratique que je pense que c'est intéressant tout de même. L'implémentation de la même méthode avec GNU lightning marchait a merveille =)
Si tout ce que je raconte la haut semble te convenir, je te conseille de prendre le chemin du bug tracker d'ooc [http://bugs.launchpad.net/ooc-language] et de faire un rapport de bug par feature manquante (delegates, strings UTF-16, pointeurs de fonctions membres). Cela permettra de suivre l'évolution des discussions et de l'implémentation plus facilement.
[^] # Re: Super un nouveau langage
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
"La première sécurité est la liberté"
[^] # Re: Super un nouveau langage
Posté par Amos Wenger . Évalué à 1.
[^] # Re: Super un nouveau langage
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
"La première sécurité est la liberté"
# Sympa
Posté par Emeric . Évalué à 1.
Il semble que que le programme généré ne soit pas entièrement portable suivant l'architecture cible.
Les Float sont des float donc dépendant de ce pourquoi on compile.
en tout cas bravo
[^] # Re: Sympa
Posté par Amos Wenger . Évalué à 1.
J'aimerais avoir quelques détails sur en quoi les floats ne sont pas portables ? Si ce n'est que quelques architectures n'ont pas de registres flottants (mais là on peut pas vraiment incriminer le compilateur), vois-tu une autre manière évidente d'implémenter ça de manière portable ?
# contribution
Posté par collinm (site web personnel) . Évalué à 1.
je code en java et C... ça fait un petit moment que j'ai pas touché au C... et je serais sûrement intéressé à participer.... s'il y aurait plus d'info sur ce qu'un volataire peut faire...
www.solutions-norenda.com
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.