Tu veux dire que l'UE est contre le TAFTA? Mince, elle devrait le dire plus fort pasque j'ai pas entendu :)
Je déteste me répeter. Encore une fois, l'UE est pour ou contre ce que veulent ces états membres. Ça n'a rien d'une entité diabolique qui décide par elle même, désolé de te casser tes rêves.
Par ailleurs, il y a un (gros) souci de logique dans ton heu raisonnement : Sans l'UE, ce "ministre bien national" (ça, pareil, je sais pas vraiment de quoi tu parles, on a des ministres au service de la France ? Qui ?)
Tu ne m'as pas l'air de connaitre grand chose au fonctionnement de l'UE et de ses insitutions toi.
Mais comme beaucoup, tu ne sais pas comment ça marche mais tu permets de critiquer quand meme
Le conseil des ministres, ou conseil de l'Union Européenne est un conseil avec l'integralités des ministres de chaque pays pour un topic donné ( Ministres de l'Economie pour le TAFTA mais pas seulement ).
Un texte comme le TAFTA ne peut passer sans leur approbation à la majorité qualifié.
Ainsi qu'avec l'approbation du parlement au passage.
Maintenant imaginons un monde sans l'Union Euopénne. A l’échelle de la France, ça se ferait juste à coup de 49.3 en fait.
Donc ton "Le problème avec l'UE et la France, c'est qu'il ya encore trop de France et pas assez d'UE" ce genre de discours de téléspectateur, je suis pas assez bien payé pour l'écouter en ricanant :)
N'invente pas ce que je n'ai pas dit, car là c'est toi qui a un petit air de téléspectateur de BFM tv.
C'est pas très clair. La France a trahi, et c'est une habitude?
De petites connaissances en histoires te ferait certainement savoir que, oui, la France sur la scène internationale retourne assez régulièrement sa veste.
Posté par Firwen (site web personnel) .
En réponse au journal TAFTA.
Évalué à 10.
Dernière modification le 28 juin 2016 à 14:04.
Ce truc, le TAFTA, est une démonstration tonitruante de l'ampleur du foutage de gueule de Bruxelles.
L'UE et Bruxelles ont bon dos comme d'habitude.
Aucun texte, et spécialement pas de cette envergure, ne peut être adopté par l'UE sans un passage au conseil des ministres.
En claire, c'est NOTRE ministre bien national qui approuve et sponsor ce genre de connerie. Commencez donc par taper sur notre gouvernement bien Français et national avant de taper sur l'UE.
L'UE est ce que les états membres en font. C'est à dire ce que la France et l'Allemagne en font…
C'est principalement la France et le Royaume Uni qui poussent pour le TAFTA ( et non un démon illuminati-nazi-antidemocratic sournoisement nommé "UE" pour tromper les peuples… )
Au passage, l'Allemagne et une bonne partie du parlement de L'UE ont déjà invalidé par le passé une bonne partie des versions précédentes de cette saloperie.
Le Royaume Uni est dehors.
Et la France vient de retourner sa veste ( Je dirais comme d'habitude si c'était vendredi )
J'ai utilisé pendant suffisamment de temps pour me faire une expérience valable (selon mes propres critères) les trois principaux OS desktop, et aucun ne me convient à 100%. Celui qui m'offre le meilleur compromis est actuellement OS X, et nul doute que chacun aura une réponse différente à cette problématique précise ;)
Répondre
Ben, je suis heureux pour toi que tu ais trouver chaussure à ton pied, mais ta parole n'est pas évangile.
Personnellement j'ai essayer aussi les "trois principaux OS", et celui qui m'offre ce que je recherche est Linux et non OSX.
OSX peut être résumé à un dérivé UNIX batard ( moins pire que Windows certes ) où l'ont a caché la misère derrière une pseudo interface léchée.
Si il est un peu plus socialement acceptable que Windows pour le développement (POSIX) et l'usabilité, il n'en reste pas moins qu'un jouet tout juste acceptable pour une utilisation Desktop et rien d'autre.
Preuve s'il en faut avec le filesystem d'OSX en première ligne….
Ça c'est un problème de scalabilité de ta base, c'est encore autre chose :)
Je dirai plutot c'est un problème de scalabilité des RDBMS tout court :)
Un RDBMS par design, te donne de fortes garanties en terme de consistante et de faible possibilités en terme de partionning.
Au mieux un RDBMS te donne une réplication maitre-esclave, là ou un KV/Object store pourra aisément te donné une scalabilité linéaire.
Et c'est normal, là où un distributed file system se contente de te donner une consistence par fichier pour les données, et par dossier pour les méta-données, ta DB te donne l'atomicité des transactions par cellule, par ligne et par table.
```
Les bases en elle-même savent faire des choses là dessus (comme séparer les blobs sur un espace différent et te les présenter comme une même table (comme une vue) et ne charger les blob que si tu l'a vraiment demandé). Mais rien autour ne permet d'en tirer vraiment parti, tu parlais d'hibernate, je ne suis même pas sûr que JDBC puisse correctement gérer ça (ne pas s'attendre à recevoir toute la ligne en une seule fois par exemple).
Même si tu considères ça, elles ne sont pas faites pour stocker des gros blobs à tailles variables, sans schemas.
La plupart des scientifiques avec lesquels je travaille ont facilement 2-3 TB sur leur espace personnel sur dropbox… A
Multiplie ça par les ~2000 personnes de mon organisation, et imagine la tête qu'aurait une pauvre DB relationnel derrière ça.
Histoire de pouvoir en discuter, tu peux dire ce qui te choque ?
Personnellement le choix de stocker sur disque ou dans une base de données dépend vraiment des cas. Je trouve cool de pouvoir récupérer tout le contenu d'owncloud (quand je m'en servais) grâce à un rsync.
Stocker un grand nombre de fichiers, ou des fichiers larges, dans une DB relationnelle est une très mauvaises idée, ça n'a jamais été désigné pour ça.
Une DB est orientée pour du stockage de données typées et structurée row ( ou colonne ). Mettre des fichiers dans une DB revient plus ou moins a serializer chaque fichier dans un gros blob binaire géant avant de le mettre lui même dans un fichier. C'est une terrible idée.
Certaines DB comme oracle ou SQL server stocke les fichiers comme fichiers externes, sur disque et les références depuis le namespace de la DB, histoire d’éviter le problème. Mais là ça revient a perdre tous les avantages d'utiliser une DB ….
Mais en pro j'ai déjà stocké des fichiers en base (ou dans des choses bizarres comme S3) pour avoir des machines immuables et stateless. Je sais qu'iCloud stocke tout dans une base cassandra.
S3 est un distributed KV store. Stocker des objets de grande taille n'est pas un problème, il a été désigné pour ça. Dropbox mettait l'intégralité de ses fichiers sur amazon S3 jusqu'a recemment.
Sincèrement, je doute qu'on trouve un meilleur nom de protocole que B.A.T.M.A.N un jour. J'ai un profond respect pour l'auteur originel qui a reussi à pondre un accronyme pareil.
Peut-être que je n'ai pas assez fait de C++ pour voir à quel point c'est génial, mais j'ai l'impression que le code assembleur que tu présentes est plus simple que le code C++.
Parce que le code assembleur que tu vois en bas n'est pas représentatif du code templated que tu vois plus haut, ni même comparable.
Le code C++ templated que tu vois plus haut est valide pour une infinité de combinaison de mul / add et pour une infinité d'expressions différente.
Alors que le code assembler que tu vois plus bas est valide uniquement pour la simple expression "auto expr = add(cst(12), mul(ref(a), ref(b)));" avec des paramètres donnés.
Si tu gardes ça à l'esprit, alors non le code C++ n'est pas verbeux, il est même extrêmement concis.
Ce que tu as écris en C++ se rapproche au final d'un un "micro-compiler" d'expressions mathématiques. Alors que ce que tu as en assembler est juste une simple opération mathématique sur une range.
C'est là toute la magie de la méta-programmation en C++, faire tout ce que tu peux faire à compile time à compile time pour générer un runtime aussi léger que possible ( en théorie du moins ).
```
Il doit y en avoir. Peut être est-ce la simplicité de l'exemple qui ne me permet pas de le voir. Eventuellement du lazy loading (l'expression n'est évaluée que lorsqu'elle est nécessaire) ?
Imagine 5 secondes que a, b et c sont trois matrix de trés grande tailles et que tu enchaînes des opérations beaucoup plus complexe qu'une simple multiplication et soustraction.
L'ordre dans lequel tu appliques tes opérations (suivant la taille de chacune de tes matrix) peut avoir un impact énorme sur le temps de calcul nécessaire.
De même pour la nécessité à copier la mémoire ou non, sur des matrix trés grande, ou lorsque tu as besoin de transposition.
Ce sont des optimisations que presque l’intégralité des bibliothèques désignés pour faire de l'algèbre linéaire mettre en oeuvre en C++: Eigen, Armadillo, blaze, etc, etc.
Tu peux ajouter aussi Hong Kong, Shanghai, Guangzhou et Stockholm.
Le systeme de Hong Kong est idéal, plus simple, plus économique et plus efficace que le navigo au passage.
Tu peux acheter ta carte anonyme, RFID dans n'importe quel magasin de proximité ( ou bureau de tabac ) à prix Fixe. Pas besoin de piece d'identité, pas besoin de formulaire a remplir ou de quoi que ce soit, l'operation se fait en 30 secondes.
La carte est rechargeable dans toutes les bornes présente en station, et peut servir de moyen de paiement "a la moneo" un peu prés partout dans la ville, sans frais supplémentaires.
Ce n'est pas si vrai que ça. C'est surtout un bench du sous système IO de la lib du langage. Et cela peut être très mal fait.
C'est vrai. Mais c'est quelque chose d'assez dure à mesurer, les I/O font toujours parti des aspects les plus dure à benchmarker d'un programme car elles sont très sensibles au effets de bords ( cache du kernel, utilisation de la mémoire, block size, … )
Si tu rajoutes à ça le fait que la plupart des langages te donne à la fois leur propre librairie et un accés direct à l'API POSIX open/read/write de l'OS.
Tu obtiens une situation où ce que tu mesures est bien souvent l'efficacité d'un pattern d'accés plutot que la performance de ta lib en question :)
. Devoir lire une grande quantité de fichier (10 000 ?) de taille moyenne (1 Mo ?) dans une arborescence, et d'écrire autant de fichiers (avec un checksum bidon dedans par exemple).
Ça pourrait être trés interessant en effet. Peut être un benchmark à leur proposer.
La même chose concernant le taux de request par seconde sur un seul et même socket: le classique C10K problem.
https://www.techempower.com/benchmarks/#section=data-r12&hw=peak&test=query -> sur cet exemple, le C++ est loin derrière Java et Dart (!!?). Pourtant, il devrait être plus près de l'OS en termes d'appels systèmes et avec la gestion manuelle de la mémoire, il devrait être bien devant selon tes dires. Comme quoi, ce n'est pas si simple.
Sincèrement… Tu critiques le manque d'I/O dans le bench de Debian et son manque de règle.
Et tu links un bench compare des frameworks Webs qui ont des implémentations différentes pour des objectifs différents associé à des Database différentes derrière des serveurs web différents sur la seule métrique du request/sec.
Il y a plus de variable à prendre en compte sur un Bench comme ça que d'ours polaire en Alaska.
Si je vois l’intérêt du bench pour le choix d'un framework Web. Tout ça n'a rien n'a voir avec l' I/O, ni même avec les perfs d'un langage d'ailleurs.
Rust a repris plein de concepts existants/éprouvés dans d'autres langages (C++, Haskell, Erlang, Python…), mais pour le coup sa gestion des références est réellement unique, et va plus loin que du simple RAII habituel (c'est sûrement inspiré du RAII, mais c'est bien plus que du RAII obligatoire)
Enfin une vrai remarque construite ! merci sincèrement.
C'est vrai que le borrow checker fait de Rust un langage assez unique en soit.
Il utilise l'analyse statique au moment de la compilation pour détecter des problèmes qui passerait inaperçu dans une RAII classique "à la C++".
C'est une innovation propre à Rust, c'est vrai et c'est une innovation importante en terme de sûreté.
Le borrow checker n'a pas d'équivalent (à ma connaissance) ailleurs
Il n'en a pas directement c'est vrai.
Dans un cas similaire, Il y a un talk d'Herb Shutter à la dernière CppCon qui introduit un système similaire en C++ associé au unique_ptr de C++ (probablement inspiré de Rust au passage )
Leur système fait de l'analyse static sur du code C++ et détecte à la compilation les utilisations invalide de pointeur en traçant les utilisations invalide potentiels de unique_ptr aprés un "move".
Mais ça reste un plugin d'analyse statique là, et ce n'est probablement pas fiable à 100% où Rust l'a mis directement dans le design du langage.
Leur objectif, clairement affiché (« we are porofoundly unintersted »), n'est pas de se servir des résultats comme base pour determiner les performances relatives des différents langages.
Je déteste me répéter. Encore une fois, ce qu'ils annoncent c'est que ces benchmarks ne sont pas représentatifs des performances d'un langage dans son ensemble mais pour un problème donné justement défini par le toy benchmark lui même.
Je te conseil sincèrement de te renseigner plus sur le concept de "mini-app" et ce que ça implique dans le domaine du Calcul à haute performance (HPC). Ça t'evitera de sortir ce genre d'anerie à l'avenir.
Ensuite, passons à l'analyse d'un des tests, celui qui semble te préoccuper le plus : la gestion de la mémoire. Pour mettre à l'épreuve les GC, il y a le test binary trees
Toute les mini-app à base binary tree montrent principalement l'impact du trashing du cache du processeur.
Si tu veux un benchmark qui pousse un GC à ses limites dans un context des calculs mathématiques plus intensif. Le mini-app sur sur mandelbrot est beaucoup plus intéressant.
Tiens, on se rapproche déjà plus des performances de OCaml et Haskell ! Mais que ce passe-t-il donc dans ce code C par rapport au super code de la mort qui tue en 3.26 secondes ? Tout simplement il optimise bien moins le parallélisme. Il utilise pthread là où le plus rapide utilise apr-1.0.
Tu ne sais pas lire du code C j'ai juste ?
apr n'a rien à voir avec pthread ni même avec le threading. gcc#3 utilise openMP et gcc#5 pthread.
La différence de performance provient trés probablement du fait que gcc#3 utilise une gestion manuel de la mémoire avec une memory pool ( utilisant apr ).
Ironiquement, tu as selectionner un bench qui valide ce que je disais précédemment sur les memory pool.
vu que c'est lui qui a soumis le code le plus lent (enfin, il a apporté des modifications sur le code d'un autre) : il sait pertinemment optimiser du calcul parallèle en OCaml
Ou peut-être que OCaml a un global interpreter lock qui l'empeche d'utiliser proprement du multi-threading, et que même le meilleur programmeur du monde ne peut pas changer ça ?
C'est d'ailleurs pour cela que le benchmark OCaml#2 fork() / join() et multi-process pour pouvoir compenser.
Les benchmarks, c'est bien, encore faut-il en analyser correctement les résultats. ;-)
Assez ironique en soit quand on réalise que ton analyse est presque fausse du début à la fin.
Ceci dit, je déteste perdre mon temps avec des personnes dont l'argumentation n'étaye sur aucun fait mais juste sur leur propre théologie. Je cesserai donc de poster ici.
Je te conseille par contre de t’intéresser un poil plus au langages à bas niveau et pas seulement au calcul formelle. tu risques de voir le monde un peu plus pragmatiquement :)
Déjà les versions dites « optimisées » ne le sont pas toujours. Dans certains langages, il y a eu effectivement pas mal de temps passé pour optimiser le problème. Dans d'autres langages, c'est juste la première version qui a marché qui est testée, personne n'a cherché à optimiser.
Chacun est libre de fournir sa propre implémentation si amélioration.
Les langages n'implémentent pas tous les mêmes problèmes.
Oui, mais c'est clairement stipulé dans les résultats.
Les benchmarks sont très faussés vers une utilisation pure du CPU
C'est un cas d'utilisation qui les mets à l'égalité. Mesurer l'I/O c'est principalement mesurer l'OS, ça a très peu d’intérêt pour un bench qui veut évaluer un langage.
Et seulement 4 cœurs, ça paraît peu de nos jours (mon PC qui a quelques années en a 8).
Ils testent à la fois une execution séquentiel et parallèle, 4, 8, 16 ou 32.. le but ici n'est pas de benchmarké le weak scaling mais simplement la gestion grossière du multi-threading et du parallelisme.
Les règles pour les benchmarks m'ont l'air floues. J'ai l'impression que certains langages profitent de bindings vers un langage plus bas niveau (genre le C++ qui utilisent des trucs en C)
Tu as déja fait du C++ une fois dans ta vie pour sortir des énormités pareilles ? Depuis quand un programme C++ a besoin de bindings pour utiliser du C ?
Même réponse. On s'en fout qu'une partie du backend soit écrit en C/C++, lorsqu'on n'a pas soi-même à écrire du C/C++ ni à gérer la mémoire à la main. Les objets Numpy et Pandas sont bel et bien gérés par la même infrastructure que n'importe quel autre objet Python…
Alors ne viens pas prétendre que "Les domaines où les performances sont suffisamment "primordiales" pour interdire l'utilisation d'un GC fondent comme neige au soleil.". C'est faux et hypocrite.
C'est juste qu'on tend à utiliser ces implémentations en C/C++ dans des langages de plus haut niveau.
En même temps, il y a peut être de la mauvaise foi non assumée chez une personne qui considère le benchmarkgame de chez Debian comme une « référence en terme d'optimisation » pour comparer les langages, là où pour les auteurs du comparatif ce n'est même pas le cas.
Quand on a pas d'argumentation à avancer, on commence les attaques personnelles on dirait.
Le "The Computer Language Benchmarks Game" offrent des versions optimisées dans différents langages à des problèmes donnés. Et pour ces problèmes donnés, je le trouve personnellement trés bons et effectivement une "référence en terme d'optimisation". Mais peut-être ai-je tord ?
Mais étant donné ton apparente intelligence supérieure, je te propose de prouver d'éclairer ces pauvres plébéiens avec ta science de la preuve formelle et tes connaissances pointus des performances des GC en leur envoyant ta propre implémentation de leur benchs. (évidemment supérieur !)
Les domaines où les performances sont suffisamment "primordiales" pour interdire l'utilisation d'un GC fondent comme neige au soleil. Aujourd'hui, de plus en plus de jeux vidéo sont écrits avec un langage à GC (les jeux écrits avec Unity 3D, par exemple). On fait du calcul scientifique en Python. Cassandra, Hadoop sont écrits en Java. Des services critiques tournent sous une VM Erlang. etc.
Ahahahah ( Désolé la fatigue probablement )
On dirait que tu as pris la liste d'exemple parfaite à ne pas prendre:
Le coeur d'Unity est fait en C++. C# est utilisé pour le scripting des games mechanics. Et même avec ça, c'est un engine qui est connu pour ses problèmes de performances et sa mauvaise gestion du multi-coeur ( avant Unity 5 ). Des jeux comme Kerbal Space program ont énormement souffert de ça d'ailleurs. Sinon tous les autres 3D engines majeurs sont en C++.
"On fait du calcul scientifique en Python". Tous (ou presque) les modules scientifiques et les simulateurs pour python sont codé en C/C++ ( cf numpy, pandas, matplotlib, hdf5, etc, etc ,etc ) avec généralement un backend BLAS / SuperLU / LAPACK. Seul l'interface est en python. Ce qui est tout à fait génial en soit, car ça combine les performances natives de C avec la flexibilité de scripting de python ( Encore mieux avec IPython / Jupither ).
"Hadoop". Tu devrais faire part de tes théories à MapR, un des principaux supporteur commercial de Hadoop, qui a recoder son propre MapReduce en C++ également.
"Des services critiques tournent sous une VM Erlang". Je vois pas trop le rapport avec le beefsteak là. Personne ici n'a dit que les langages à GC était moins fiable. Et spécialement pas Erlang.
Typiquement tout ce qui est "safety critical" ne supporte pas l'allocation mémoire, alors un GC … (le SC, c'est pour les avions, les trains, l'industriel, le ferroviaire, la voiture…)
[troll day]
Je vois pas pourquoi.
Par exemple, quand une des fusées de SpaceX se vautre lamentablement sur sa barge en tentant d’atterrir, tu pourrais simplement dire "Le GC faisait une pause, promis ça arrivera plus au prochain lancement".
Et au-delà de la sécurité, c'est un problème plus général de qualité logicielle qui se pose.
La qualité logiciel n'a rien à voir avec le langage ni le memory management. Un mauvais programmeur fera un mauvais programme, quel que soit le langage.
Rust est tellement jeune (et, pour l'instant, peu utilisé) que l'on n'a pas de recul sur les problèmes des applications écrites en Rust.
La gestion mémoire de Rust n'a rien de jeune. Elle vient des techniques de RAII de C++, Ada our Vala qui ont plus de 10 ans.
La seule "nouveauté" de Rust, est de les rendre obligatoire par défaut.
Les problèmes du C ne se limitent certes pas à la gestion manuelle de la mémoire. Mais la gestion manuelle de la mémoire fait cependant partie de ses problèmes, et la complexité de la tâche (sur des applications non-triviales) fait que c'est un facteur important de défauts.
Encore une fois, c'est un problème associé au design du langage, et pas à l'absence de GC. Le C pure rend trés difficile, voir impossible la mise en place de technique de RAII car il ne gère pas la notion de "scope", contrairement à C++, Rust, Ada, Objective-C, Swift, etc….
[^] # Re: Go ?
Posté par Firwen (site web personnel) . En réponse au journal Java (EE) Sapu cépalibre.. Évalué à 5.
Go a déjà un écosystème. Je dirai même qu’il a un écosystème étonnement conséquent compare a la popularité du langage.
La seul différence est que écosystème de go n'est pas centralisé comme EE, mais se base sur une des libraires indépendantes github/got-get.
Tu as déja tout ce qu'il faut en go pour faire du REST, du messaging, du rendu dynamique, de l'ORM, du parsing, etc, etc…
[^] # Re: Courriel
Posté par Firwen (site web personnel) . En réponse au journal TAFTA. Évalué à 1.
Je déteste me répeter. Encore une fois, l'UE est pour ou contre ce que veulent ces états membres. Ça n'a rien d'une entité diabolique qui décide par elle même, désolé de te casser tes rêves.
Tu ne m'as pas l'air de connaitre grand chose au fonctionnement de l'UE et de ses insitutions toi.
Mais comme beaucoup, tu ne sais pas comment ça marche mais tu permets de critiquer quand meme
Le conseil des ministres, ou conseil de l'Union Européenne est un conseil avec l'integralités des ministres de chaque pays pour un topic donné ( Ministres de l'Economie pour le TAFTA mais pas seulement ).
Un texte comme le TAFTA ne peut passer sans leur approbation à la majorité qualifié.
Ainsi qu'avec l'approbation du parlement au passage.
Maintenant imaginons un monde sans l'Union Euopénne. A l’échelle de la France, ça se ferait juste à coup de 49.3 en fait.
N'invente pas ce que je n'ai pas dit, car là c'est toi qui a un petit air de téléspectateur de BFM tv.
De petites connaissances en histoires te ferait certainement savoir que, oui, la France sur la scène internationale retourne assez régulièrement sa veste.
[^] # Re: Courriel
Posté par Firwen (site web personnel) . En réponse au journal TAFTA. Évalué à 10. Dernière modification le 28 juin 2016 à 14:04.
L'UE et Bruxelles ont bon dos comme d'habitude.
Aucun texte, et spécialement pas de cette envergure, ne peut être adopté par l'UE sans un passage au conseil des ministres.
En claire, c'est NOTRE ministre bien national qui approuve et sponsor ce genre de connerie. Commencez donc par taper sur notre gouvernement bien Français et national avant de taper sur l'UE.
L'UE est ce que les états membres en font. C'est à dire ce que la France et l'Allemagne en font…
C'est principalement la France et le Royaume Uni qui poussent pour le TAFTA ( et non un démon illuminati-nazi-antidemocratic sournoisement nommé "UE" pour tromper les peuples… )
Au passage, l'Allemagne et une bonne partie du parlement de L'UE ont déjà invalidé par le passé une bonne partie des versions précédentes de cette saloperie.
Le Royaume Uni est dehors.
Et la France vient de retourner sa veste ( Je dirais comme d'habitude si c'était vendredi )
[^] # Re: Désinformation ?
Posté par Firwen (site web personnel) . En réponse au journal Le malaise.. Évalué à 0.
Ben, je suis heureux pour toi que tu ais trouver chaussure à ton pied, mais ta parole n'est pas évangile.
Personnellement j'ai essayer aussi les "trois principaux OS", et celui qui m'offre ce que je recherche est Linux et non OSX.
OSX peut être résumé à un dérivé UNIX batard ( moins pire que Windows certes ) où l'ont a caché la misère derrière une pseudo interface léchée.
Si il est un peu plus socialement acceptable que Windows pour le développement (POSIX) et l'usabilité, il n'en reste pas moins qu'un jouet tout juste acceptable pour une utilisation Desktop et rien d'autre.
Preuve s'il en faut avec le filesystem d'OSX en première ligne….
[^] # Re: Migration
Posté par Firwen (site web personnel) . En réponse à la dépêche Nextcloud, le fork d'ownCloud. Évalué à 2.
Je dirai plutot c'est un problème de scalabilité des RDBMS tout court :)
Un RDBMS par design, te donne de fortes garanties en terme de consistante et de faible possibilités en terme de partionning.
Au mieux un RDBMS te donne une réplication maitre-esclave, là ou un KV/Object store pourra aisément te donné une scalabilité linéaire.
Et c'est normal, là où un distributed file system se contente de te donner une consistence par fichier pour les données, et par dossier pour les méta-données, ta DB te donne l'atomicité des transactions par cellule, par ligne et par table.
```
[^] # Re: Prérequis trop important pour un auto-hébergement
Posté par Firwen (site web personnel) . En réponse à la dépêche Cozy Cloud lève 4 millions d'euros (pour faire du libre). Évalué à 2.
Par simple cursiosité, qu'est-ce qui cause une conso mémoire si élevé par instance ?
[^] # Re: Migration
Posté par Firwen (site web personnel) . En réponse à la dépêche Nextcloud, le fork d'ownCloud. Évalué à 2.
Même si tu considères ça, elles ne sont pas faites pour stocker des gros blobs à tailles variables, sans schemas.
La plupart des scientifiques avec lesquels je travaille ont facilement 2-3 TB sur leur espace personnel sur dropbox… A
Multiplie ça par les ~2000 personnes de mon organisation, et imagine la tête qu'aurait une pauvre DB relationnel derrière ça.
[^] # Re: Migration
Posté par Firwen (site web personnel) . En réponse à la dépêche Nextcloud, le fork d'ownCloud. Évalué à 3.
Personnellement le choix de stocker sur disque ou dans une base de données dépend vraiment des cas. Je trouve cool de pouvoir récupérer tout le contenu d'owncloud (quand je m'en servais) grâce à un rsync.
Stocker un grand nombre de fichiers, ou des fichiers larges, dans une DB relationnelle est une très mauvaises idée, ça n'a jamais été désigné pour ça.
Une DB est orientée pour du stockage de données typées et structurée row ( ou colonne ). Mettre des fichiers dans une DB revient plus ou moins a serializer chaque fichier dans un gros blob binaire géant avant de le mettre lui même dans un fichier. C'est une terrible idée.
Certaines DB comme oracle ou SQL server stocke les fichiers comme fichiers externes, sur disque et les références depuis le namespace de la DB, histoire d’éviter le problème. Mais là ça revient a perdre tous les avantages d'utiliser une DB ….
S3 est un distributed KV store. Stocker des objets de grande taille n'est pas un problème, il a été désigné pour ça. Dropbox mettait l'intégralité de ses fichiers sur amazon S3 jusqu'a recemment.
# Better Approach To Mobile Adhoc Networking
Posté par Firwen (site web personnel) . En réponse à la dépêche Sortie du noyau Linux 4.6. Évalué à 7. Dernière modification le 06 juin 2016 à 19:24.
Sincèrement, je doute qu'on trouve un meilleur nom de protocole que B.A.T.M.A.N un jour. J'ai un profond respect pour l'auteur originel qui a reussi à pondre un accronyme pareil.
https://www.youtube.com/watch?v=OpWVV8wuM1A
Rien qu'a la lecture du changelog, j'ai déjà le generique en tête.
( Merci pour la dépêche, c'est vraiment un excellent travail )
[^] # Re: C++, où quand le code asm généré est plus lisible
Posté par Firwen (site web personnel) . En réponse au journal [C++14 ] Expressions template pour les nuls. Évalué à 2. Dernière modification le 01 juin 2016 à 10:38.
Parce que le code assembleur que tu vois en bas n'est pas représentatif du code templated que tu vois plus haut, ni même comparable.
Le code C++ templated que tu vois plus haut est valide pour une infinité de combinaison de mul / add et pour une infinité d'expressions différente.
Alors que le code assembler que tu vois plus bas est valide uniquement pour la simple expression "auto expr = add(cst(12), mul(ref(a), ref(b)));" avec des paramètres donnés.
Si tu gardes ça à l'esprit, alors non le code C++ n'est pas verbeux, il est même extrêmement concis.
Ce que tu as écris en C++ se rapproche au final d'un un "micro-compiler" d'expressions mathématiques. Alors que ce que tu as en assembler est juste une simple opération mathématique sur une range.
C'est là toute la magie de la méta-programmation en C++, faire tout ce que tu peux faire à compile time à compile time pour générer un runtime aussi léger que possible ( en théorie du moins ).
```
[^] # Re: Avantage ?
Posté par Firwen (site web personnel) . En réponse au journal [C++14 ] Expressions template pour les nuls. Évalué à 2.
Imagine 5 secondes que a, b et c sont trois matrix de trés grande tailles et que tu enchaînes des opérations beaucoup plus complexe qu'une simple multiplication et soustraction.
L'ordre dans lequel tu appliques tes opérations (suivant la taille de chacune de tes matrix) peut avoir un impact énorme sur le temps de calcul nécessaire.
De même pour la nécessité à copier la mémoire ou non, sur des matrix trés grande, ou lorsque tu as besoin de transposition.
Ce sont des optimisations que presque l’intégralité des bibliothèques désignés pour faire de l'algèbre linéaire mettre en oeuvre en C++: Eigen, Armadillo, blaze, etc, etc.
[^] # Re: Ticket de métro
Posté par Firwen (site web personnel) . En réponse au journal La Suède abandonne les paiements en espèce — ne devrait-on pas s'en inquiéter?. Évalué à 1.
Les tickets 24h/48h se chargent sur la carte. Ils s'activent automatiquement au premier badging.
[^] # Re: Ticket de métro
Posté par Firwen (site web personnel) . En réponse au journal La Suède abandonne les paiements en espèce — ne devrait-on pas s'en inquiéter?. Évalué à 2.
Tu peux ajouter aussi Hong Kong, Shanghai, Guangzhou et Stockholm.
Le systeme de Hong Kong est idéal, plus simple, plus économique et plus efficace que le navigo au passage.
Tu peux acheter ta carte anonyme, RFID dans n'importe quel magasin de proximité ( ou bureau de tabac ) à prix Fixe. Pas besoin de piece d'identité, pas besoin de formulaire a remplir ou de quoi que ce soit, l'operation se fait en 30 secondes.
La carte est rechargeable dans toutes les bornes présente en station, et peut servir de moyen de paiement "a la moneo" un peu prés partout dans la ville, sans frais supplémentaires.
Simple, flexible, efficace.
# BFM TV du net
Posté par Firwen (site web personnel) . En réponse au journal Quand 01net nous explique ce qu’est un hacker. Évalué à 10. Dernière modification le 20 mai 2016 à 18:56.
Je vais sûrement me faire des ennemis en disant ça..
Mais en même temps 01net, c'est un petit peu le BFM TV de l'informatique.
Le pire dans l'histoire, c'est que comme pour BFM TV, il y a des gens qui lisent/suivent ça…. et souvent des décideurs.
Et encore ça s'est amélioré, à l'époque où 01net s'orientait "manager", le contenu était encore plus à vomir que maintenant.
[^] # Re: Destructeurs
Posté par Firwen (site web personnel) . En réponse à la dépêche Crystal, un langage proche de Ruby, en version 0.16. Évalué à 1. Dernière modification le 13 mai 2016 à 14:56.
Yep :) 10K est plus vraiment d'actualité mais le problème l'est toujours :)
Je suis curieux de voir ce que donnerait les différents les différents langage / model de threading de nos jours sur ça.
[^] # Re: Destructeurs
Posté par Firwen (site web personnel) . En réponse à la dépêche Crystal, un langage proche de Ruby, en version 0.16. Évalué à 1.
C'est vrai. Mais c'est quelque chose d'assez dure à mesurer, les I/O font toujours parti des aspects les plus dure à benchmarker d'un programme car elles sont très sensibles au effets de bords ( cache du kernel, utilisation de la mémoire, block size, … )
Si tu rajoutes à ça le fait que la plupart des langages te donne à la fois leur propre librairie et un accés direct à l'API POSIX open/read/write de l'OS.
Tu obtiens une situation où ce que tu mesures est bien souvent l'efficacité d'un pattern d'accés plutot que la performance de ta lib en question :)
Ça pourrait être trés interessant en effet. Peut être un benchmark à leur proposer.
La même chose concernant le taux de request par seconde sur un seul et même socket: le classique C10K problem.
[^] # Re: Destructeurs
Posté par Firwen (site web personnel) . En réponse à la dépêche Crystal, un langage proche de Ruby, en version 0.16. Évalué à 3.
Sincèrement… Tu critiques le manque d'I/O dans le bench de Debian et son manque de règle.
Et tu links un bench compare des frameworks Webs qui ont des implémentations différentes pour des objectifs différents associé à des Database différentes derrière des serveurs web différents sur la seule métrique du request/sec.
Il y a plus de variable à prendre en compte sur un Bench comme ça que d'ours polaire en Alaska.
Si je vois l’intérêt du bench pour le choix d'un framework Web. Tout ça n'a rien n'a voir avec l' I/O, ni même avec les perfs d'un langage d'ailleurs.
[^] # Re: Destructeurs
Posté par Firwen (site web personnel) . En réponse à la dépêche Crystal, un langage proche de Ruby, en version 0.16. Évalué à 2. Dernière modification le 12 mai 2016 à 22:54.
Enfin une vrai remarque construite ! merci sincèrement.
C'est vrai que le borrow checker fait de Rust un langage assez unique en soit.
Il utilise l'analyse statique au moment de la compilation pour détecter des problèmes qui passerait inaperçu dans une RAII classique "à la C++".
C'est une innovation propre à Rust, c'est vrai et c'est une innovation importante en terme de sûreté.
Il n'en a pas directement c'est vrai.
Dans un cas similaire, Il y a un talk d'Herb Shutter à la dernière CppCon qui introduit un système similaire en C++ associé au unique_ptr de C++ (probablement inspiré de Rust au passage )
Leur système fait de l'analyse static sur du code C++ et détecte à la compilation les utilisations invalide de pointeur en traçant les utilisations invalide potentiels de unique_ptr aprés un "move".
Mais ça reste un plugin d'analyse statique là, et ce n'est probablement pas fiable à 100% où Rust l'a mis directement dans le design du langage.
[^] # Re: Destructeurs
Posté par Firwen (site web personnel) . En réponse à la dépêche Crystal, un langage proche de Ruby, en version 0.16. Évalué à 0. Dernière modification le 12 mai 2016 à 21:27.
Je déteste me répéter. Encore une fois, ce qu'ils annoncent c'est que ces benchmarks ne sont pas représentatifs des performances d'un langage dans son ensemble mais pour un problème donné justement défini par le toy benchmark lui même.
Je te conseil sincèrement de te renseigner plus sur le concept de "mini-app" et ce que ça implique dans le domaine du Calcul à haute performance (HPC). Ça t'evitera de sortir ce genre d'anerie à l'avenir.
Toute les mini-app à base binary tree montrent principalement l'impact du trashing du cache du processeur.
Si tu veux un benchmark qui pousse un GC à ses limites dans un context des calculs mathématiques plus intensif. Le mini-app sur sur mandelbrot est beaucoup plus intéressant.
Tu ne sais pas lire du code C j'ai juste ?
apr n'a rien à voir avec pthread ni même avec le threading. gcc#3 utilise openMP et gcc#5 pthread.
La différence de performance provient trés probablement du fait que gcc#3 utilise une gestion manuel de la mémoire avec une memory pool ( utilisant apr ).
Ironiquement, tu as selectionner un bench qui valide ce que je disais précédemment sur les memory pool.
Ou peut-être que OCaml a un global interpreter lock qui l'empeche d'utiliser proprement du multi-threading, et que même le meilleur programmeur du monde ne peut pas changer ça ?
C'est d'ailleurs pour cela que le benchmark OCaml#2 fork() / join() et multi-process pour pouvoir compenser.
Assez ironique en soit quand on réalise que ton analyse est presque fausse du début à la fin.
Ceci dit, je déteste perdre mon temps avec des personnes dont l'argumentation n'étaye sur aucun fait mais juste sur leur propre théologie. Je cesserai donc de poster ici.
Je te conseille par contre de t’intéresser un poil plus au langages à bas niveau et pas seulement au calcul formelle. tu risques de voir le monde un peu plus pragmatiquement :)
[^] # Re: Destructeurs
Posté par Firwen (site web personnel) . En réponse à la dépêche Crystal, un langage proche de Ruby, en version 0.16. Évalué à 1.
Chacun est libre de fournir sa propre implémentation si amélioration.
Oui, mais c'est clairement stipulé dans les résultats.
C'est un cas d'utilisation qui les mets à l'égalité. Mesurer l'I/O c'est principalement mesurer l'OS, ça a très peu d’intérêt pour un bench qui veut évaluer un langage.
Ils testent à la fois une execution séquentiel et parallèle, 4, 8, 16 ou 32.. le but ici n'est pas de benchmarké le weak scaling mais simplement la gestion grossière du multi-threading et du parallelisme.
Tu as déja fait du C++ une fois dans ta vie pour sortir des énormités pareilles ? Depuis quand un programme C++ a besoin de bindings pour utiliser du C ?
[^] # Re: Destructeurs
Posté par Firwen (site web personnel) . En réponse à la dépêche Crystal, un langage proche de Ruby, en version 0.16. Évalué à 2. Dernière modification le 12 mai 2016 à 13:40.
Alors ne viens pas prétendre que "Les domaines où les performances sont suffisamment "primordiales" pour interdire l'utilisation d'un GC fondent comme neige au soleil.". C'est faux et hypocrite.
C'est juste qu'on tend à utiliser ces implémentations en C/C++ dans des langages de plus haut niveau.
[^] # Re: Destructeurs
Posté par Firwen (site web personnel) . En réponse à la dépêche Crystal, un langage proche de Ruby, en version 0.16. Évalué à -2. Dernière modification le 12 mai 2016 à 10:33.
Quand on a pas d'argumentation à avancer, on commence les attaques personnelles on dirait.
Le "The Computer Language Benchmarks Game" offrent des versions optimisées dans différents langages à des problèmes donnés. Et pour ces problèmes donnés, je le trouve personnellement trés bons et effectivement une "référence en terme d'optimisation". Mais peut-être ai-je tord ?
Mais étant donné ton apparente intelligence supérieure, je te propose de prouver d'éclairer ces pauvres plébéiens avec ta science de la preuve formelle et tes connaissances pointus des performances des GC en leur envoyant ta propre implémentation de leur benchs. (évidemment supérieur !)
https://benchmarksgame.alioth.debian.org/play.html
Je suis certain qu'ils se laisseront convaincre aisément si tu leur montrent des faits au lieu d'un beau discours.
[^] # Re: Destructeurs
Posté par Firwen (site web personnel) . En réponse à la dépêche Crystal, un langage proche de Ruby, en version 0.16. Évalué à 3. Dernière modification le 11 mai 2016 à 23:27.
Ahahahah ( Désolé la fatigue probablement )
On dirait que tu as pris la liste d'exemple parfaite à ne pas prendre:
Le coeur d'Unity est fait en C++. C# est utilisé pour le scripting des games mechanics. Et même avec ça, c'est un engine qui est connu pour ses problèmes de performances et sa mauvaise gestion du multi-coeur ( avant Unity 5 ). Des jeux comme Kerbal Space program ont énormement souffert de ça d'ailleurs. Sinon tous les autres 3D engines majeurs sont en C++.
"On fait du calcul scientifique en Python". Tous (ou presque) les modules scientifiques et les simulateurs pour python sont codé en C/C++ ( cf numpy, pandas, matplotlib, hdf5, etc, etc ,etc ) avec généralement un backend BLAS / SuperLU / LAPACK. Seul l'interface est en python. Ce qui est tout à fait génial en soit, car ça combine les performances natives de C avec la flexibilité de scripting de python ( Encore mieux avec IPython / Jupither ).
"Cassandra". Récemment, une société a recoder cassandra en C++ avec des performances qui parlent d'elle même je pense.
"Hadoop". Tu devrais faire part de tes théories à MapR, un des principaux supporteur commercial de Hadoop, qui a recoder son propre MapReduce en C++ également.
"Des services critiques tournent sous une VM Erlang". Je vois pas trop le rapport avec le beefsteak là. Personne ici n'a dit que les langages à GC était moins fiable. Et spécialement pas Erlang.
[^] # Re: Destructeurs
Posté par Firwen (site web personnel) . En réponse à la dépêche Crystal, un langage proche de Ruby, en version 0.16. Évalué à 0.
[troll day]
Je vois pas pourquoi.
Par exemple, quand une des fusées de SpaceX se vautre lamentablement sur sa barge en tentant d’atterrir, tu pourrais simplement dire "Le GC faisait une pause, promis ça arrivera plus au prochain lancement".
[/toll day]
[^] # Re: Destructeurs
Posté par Firwen (site web personnel) . En réponse à la dépêche Crystal, un langage proche de Ruby, en version 0.16. Évalué à 3. Dernière modification le 11 mai 2016 à 10:44.
La qualité logiciel n'a rien à voir avec le langage ni le memory management. Un mauvais programmeur fera un mauvais programme, quel que soit le langage.
La gestion mémoire de Rust n'a rien de jeune. Elle vient des techniques de RAII de C++, Ada our Vala qui ont plus de 10 ans.
La seule "nouveauté" de Rust, est de les rendre obligatoire par défaut.
Encore une fois, c'est un problème associé au design du langage, et pas à l'absence de GC. Le C pure rend trés difficile, voir impossible la mise en place de technique de RAII car il ne gère pas la notion de "scope", contrairement à C++, Rust, Ada, Objective-C, Swift, etc….