For the record, c'est pas moi qui ai dit que Boehm GC était super testé/stable, ce qui est pourtant vrai.
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.
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 ?
"pas thread-safe" n'a jamais été un bug.
"ê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.
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.
Merci pour les éclaircissements, on va pouvoir finir cette conversation sur un ton constructif =)
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(...)]
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.
Bah je suis déçu, t'as compris que la moitié de mon deuxième degré. Je répond court parce que je commence a saturer (et puis, dans la vie, on nourrit les trolls en discutant ou on les tue en codant, hein..)
> ç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.
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)
Merci pour les éclaircissements, mais je suis déçu, j'avais naïvement supposé qu'ils avaient inventé une astuce super duper pratique.
Puisqu'on finit toujours par en revenir au C, pourquoi ne pas partir du C tout court..
> 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.
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.
J'ai pas mal réfléchi à cette question déjà au début de la conception d'ooc, et j'ai décidé de faire un héritage à la Java: une classe parente maximum, et tu implémentes autant d'interfaces que tu veux.
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.
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?)
C'bien ce qui me semblait, mais alors justement d'ou la question plus haut: 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.
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.
A mon humble avis, les interfaces des librairies dynamiques (.dll) sont standardisées, donc pas de souci. Par contre, compiler statiquement un programme sous MinGW/gcc avec des objets binaires provenant de deux compilateurs différents.. eh ben j'ai jamais testé mais ça doit pas être joli :/
Bonbonbon, eh bien voila plein de critiques intéressantes. Je vais reprendre point par point:
> 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 =)
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
Eh bien je m'y attaquerais, alors. Parser du C++, c'est un cauchemar, mais pour pouvoir utiliser une lib C++ il suffit de pouvoir parser ses headers (c'est ce qui se passe avec les librairies C avec ooc pour l'instant).
Je donnerais donc des nouvelles a propos du support des librairies C++ sur le blog, probablement.
Hum il me semble qu'ils en parlent au conditionnel, là, non?
"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."
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."
> 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.
Disons qu'il ne teste qu'une petite partie de deux implémentations de deux langages.
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).
Maintenant, juste pour le "benchmark pas réaliste", ben en y réfléchissant bien, je suis pas si sur que ça. Plein de programmes Java sont over-orientés objets, je pense notamment côté serveur, les frameworks sont à mon sens horrible car remplis d'objets dans tous les sens, et pourtant ce sont des domaines ou la performance (enfin plutot la "scalability") est importante...
[^] # Re: Rapidité du C ... et ramasse-miettes ?
Posté par Amos Wenger . En réponse à la dépêche Le language de programmation ooc sorti en version 0.2. É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: Sympa
Posté par Amos Wenger . En réponse à la dépêche Le language de programmation ooc sorti en version 0.2. É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 ?
[^] # Re: Rapidité du C ... et ramasse-miettes ?
Posté par Amos Wenger . En réponse à la dépêche Le language de programmation ooc sorti en version 0.2. É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 Amos Wenger . En réponse à la dépêche Le language de programmation ooc sorti en version 0.2. É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 Amos Wenger . En réponse à la dépêche Le language de programmation ooc sorti en version 0.2. É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: ObjectiveC
Posté par Amos Wenger . En réponse à la dépêche Le language de programmation ooc sorti en version 0.2. É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: Rapidité du C ... et ramasse-miettes ?
Posté par Amos Wenger . En réponse à la dépêche Le language de programmation ooc sorti en version 0.2. É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: Compatibilité avec les lib C++ ?
Posté par Amos Wenger . En réponse à la dépêche Le language de programmation ooc sorti en version 0.2. É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)
[^] # Re: Compatibilité avec les lib C++ ?
Posté par Amos Wenger . En réponse à la dépêche Le language de programmation ooc sorti en version 0.2. Évalué à 1.
Puisqu'on finit toujours par en revenir au C, pourquoi ne pas partir du C tout court..
[^] # Re: Rapidité du C ... et ramasse-miettes ?
Posté par Amos Wenger . En réponse à la dépêche Le language de programmation ooc sorti en version 0.2. É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: Super un nouveau langage
Posté par Amos Wenger . En réponse à la dépêche Le language de programmation ooc sorti en version 0.2. É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: Critique du langage.
Posté par Amos Wenger . En réponse à la dépêche Le language de programmation ooc sorti en version 0.2. É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.
[^] # Re: Compatibilité avec les lib C++ ?
Posté par Amos Wenger . En réponse à la dépêche Le language de programmation ooc sorti en version 0.2. É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 Amos Wenger . En réponse à la dépêche Le language de programmation ooc sorti en version 0.2. É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: Ramasse-miette conservatif..
Posté par Amos Wenger . En réponse à la dépêche Le language de programmation ooc sorti en version 0.2. É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: Compatibilité avec les lib C++ ?
Posté par Amos Wenger . En réponse à la dépêche Le language de programmation ooc sorti en version 0.2. Évalué à 1.
[^] # Re: Critique du langage.
Posté par Amos Wenger . En réponse à la dépêche Le language de programmation ooc sorti en version 0.2. É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: Rapidité du C ... et ramasse-miettes ?
Posté par Amos Wenger . En réponse à la dépêche Le language de programmation ooc sorti en version 0.2. Évalué à 2.
[^] # Re: Rapidité du C ... et ramasse-miettes ?
Posté par Amos Wenger . En réponse à la dépêche Le language de programmation ooc sorti en version 0.2. É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: Compatibilité avec les lib C++ ?
Posté par Amos Wenger . En réponse à la dépêche Le language de programmation ooc sorti en version 0.2. Évalué à 1.
Je donnerais donc des nouvelles a propos du support des librairies C++ sur le blog, probablement.
[^] # Re: Rapidité du C ... et ramasse-miettes ?
Posté par Amos Wenger . En réponse à la dépêche Le language de programmation ooc sorti en version 0.2. É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 . En réponse à la dépêche Le language de programmation ooc sorti en version 0.2. É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: Compatibilité avec les lib C++ ?
Posté par Amos Wenger . En réponse à la dépêche Le language de programmation ooc sorti en version 0.2. É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: Rapidité du C ... et ramasse-miettes ?
Posté par Amos Wenger . En réponse à la dépêche Le language de programmation ooc sorti en version 0.2. É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 Amos Wenger . En réponse à la dépêche Le language de programmation ooc sorti en version 0.2. Évalué à 1.