grim7reaper a écrit 132 commentaires

tableaux de bateaux Hollandais (le pays, pas le président :))

La Hollande n’est pas un pays.

Uniquement en mode HC.
Le mode « standard » est plus rapide que LZO

Cerise sur le gâteau, le serveur est GPL et fonctionne très bien sous linux… jusqu'à ce que la version de PERL dans la plupart des distribs devienne la 5.16, alors que le serveur est écrit en perl et ne fonctionne que sur la 5.14 au maximum. Sans le serveur, les platines hardware sont inutilisables.

Étant donné que le code est sous GPL, si le truc intéresse vraiment quelqu‘un il est possible de faire le portage (ou de lever des fonds pour financer ce portage) pour le rendre compatible Perl 5.16.
Il ne doit pas y avoir un gap énorme avec Perl 5.14, donc le boulot ne doit pas être titanesque je suppose.
Donc tout espoir n‘est pas perdu.

Ils ne sont pas du tout en concurrence, l'un est un outil pour utiliser plus facilement le second

Non.
Jusqu’à preuve du contraire, la SFML n‘est pas basée sur la SDL.

Mouais, argument bancal.
Si j’en juge au nombre de morts provoqués par les combats directs, on dirait que ça n’empêche pas trop de tuer non plus hein…

All your chocolates belongs to us!

All your chocolates are belong to us
:capello:
N’oublie pas les fautes, scélérat !

la capacite de voir et provoquer la mort a distance, ca facilite psychologiquement la capacite de la donner.

Pas si simple à ce qu’il semblerait.

En même temps tu compares des choux et des carottes.
OpenGL n’est pas comparable à DirectX.
À Direct3D oui.

Et je ne pense pas que, jeux vidéos mis à part, DirectX ai jamais été considéré comme supérieur à OpenGL dans le monde du graphisme. J’ai même l’impression contraire…

A part l'embarqué et le temps réel on ne l'utilise pas / peu ?

Bah disons que je l’ai très rarement vu ailleurs (pas jamais, mais très rarement). Mais bon ça ne reste que mon expérience personnelle.

Pourtant le langage pourrait vraiment être intéressant pour aider a faire de meilleurs softs, non ?

En théorie oui (bien que je ne pense pas que ça soit le langage miracle qui peut s’utiliser partout, mais dans un certain nombres de cas oui clairement).
Mais bon, entre ce qui est très bien théoriquement et ce qui est très utilisé réellement, il y a un gouffre en général…

(et après faut pas croire mais en java on peut aussi faire des gros trucs sympa, genre basé sur hadoop, du distribué, etc)

Oui, je me doute.
Ma remarque ne sous-entendais pas que ceux qui font du dev’ web/JS/Java sont des sous-dev et qu’ils font uniquement des trucs simples.
Je voulais juste dire que les contraintes, exigences et problématiques rencontrées sont vraiment très différente.

où faire de l'ada (professionnellement j'entends) ? Une transition depuis du web/js/java ça se fait facilement ?

Il me semble que de manière générale, Ada est quand même pas mal cantonné à l’informatique embarquée.
Ça risque de faire un sacré gap par rapport à Web/JS/Java.

Java permet de faire du vrai multi-threading, pas Python.

Le langage Python en lui-même permet tout à fait de faire du vrai multithreading (Jython et IronPython en sont la preuve).
Il est vrai que l‘implémentation la plus répandu (CPython) ne le permet pas (à cause du GIL, Ruby est d’ailleurs logé à la même enseigne).
Mais c’est un détail, non négligeable certes, d‘implémentation. Le langage en lui-même en est tout à fait capable.

Pas de libc sur un Android (sauf hack bien sûr).

Mouais, j’ai rarement vu un système tourner sans libc, même en embarqué ce n’est pas le cas le plus courant (il y a souvent une libc minimale).
Bien sûr qu’Android à une libc >_<, elle s’appelle même Bionic.
Par contre, oui, il n’y a pas la glibc.

Pour le moment, ni l’un ni l’autre : il est à Changsha.
À la fin de l’année il va bouger à Guangzhou

The TH-2 is undergoing assembly and testing at NUDT and will be moved to its permanent home at the National Supercomputer Center in Guangzhou (NSCC-GZ) by the end of the year.

Source.

Yep, je confirme que c’est toujours le cas.
L‘INRA a encore des partenariats avec le LSCE/CEA pour y faire tourner des simulations diverses.
Pour ne citer qu’un exemple, deux modèles participant à ce projet européen ont tournés sur ces machines.

Si je comprend bien, -O0 n'a vraiment d’intérêt que lorsqu'il est couplé avec -g.

Oui, je ne vois pas trop un autre intérêt à utiliser -O0.
Ha si, si tu veux regarder la sortie assembleur : ça sera peut-être un poil plus lisible qu‘un truc optimisé à mort.

Dans ce cas, j'ai du mal a comprendre pourquoi autoriser a coupler du -O2 voire -O3 avec -g? Les performances vont être meilleures, mais le debugging va être beaucoup plus compliqué. Il me semble que si l'on utilise -g, c'est le debugging qui prime. Non?

Bah y’a des fois tu as des bugs qui ne se produisent qu‘en version optimisé.
Ou encore, sans optimisation c’est vraiment trop lent à tourner et le débogage devient laborieux (ou alors tu fais des timeout sur certains trucs).
Donc oui, c’est plutôt rare de mixer les deux mais parfois on en a besoin.

Oui, le débogage va être un peu plus difficile pour les raisons cité (changement de comportement pas endroits). D’ailleurs le man de gcc en parle :

GCC allows you to use -g with -O. The shortcuts taken by optimized code may occasionally produce surprising results: some variables you declared may not exist at all; flow of control may briefly move where you did not expect it; some statements may not be executed because they compute constant results or their values were already at hand; some statements may execute in different places because they were moved out of loops.
Nevertheless it proves possible to debug optimized output. This makes it reasonable to use the optimizer for programs that might have bugs.

Mais bon, au moins tu auras les symboles et d‘autres petites choses appréciables.
D’ailleurs à ce sujet, si tu sais que tu va déboguer avec gdb il y a une option bien meilleur que -g, c‘est -ggdb

Je ne suis pas développeur C ou C++ et n'utilise pas gcc, mais peux-tu debugger un programme sans émettre les infos de debug avec -g?

Dans l’absolu, oui tu peux.
Mais ça va être vachement moins sympa vu que tu n’auras pas le lien avec le code source, il va manquer un bon paquet de symboles, etc.

Si non, alors comment comprends-tu la phrase suivante?
"-O0 réduit le temps de compilation et fais en sorte que le debugging produise les résultats attendus."

Comme je l’ai dit dans mon message précédent : gcc va désactiver les optimisations qui risquent de modifier le comportement visible de ton code (du genre un appel de fonction qui disparaît car la fonction est inliné, une variable supprimé car finalement reconnu inutile par le compilateur, …)

Si tu veux voir le détails des différences entre les niveaux -O0, -O1, -O2 et -O3, tu peux t’amuser à comparer les sorties de :

gcc -O0 -Q --help=optimizers | grep enabled
gcc -O1 -Q --help=optimizers | grep enabled
gcc -O2 -Q --help=optimizers | grep enabled
gcc -O3 -Q --help=optimizers | grep enabled

Donc par défaut GCC génère les infos de debuggage alors que TCC ne le fais pas (c'est ce que j'ai déduit de leur documentation).

Mauvaise déduction.
Il faut passer, à minima, l’option -g à gcc pour obtenir les info’ de débogage.
Compiler en -O0 n’apporte aucune info, mais il désactive les optimisations un peu trop agressives de gcc. Du genre des trucs qui donnes ça quand tu débogues :

(gdb) p ma_var
$1 = <value optimized out>

Le bench en faveur de Python est à foireux.

Le code Java est pourri au possible (suffit de voir que pour l’écriture il n‘utilise même pas des I/O bufferisé, alors que script Python le fait).
Pour info, chez moi ça donne :
Time to write: 0.466531038284 (Python)
Time to write: 3.083743529 (Java foireux du bench)
Time to write: 0.437884799 (Java bufferisé, ~équivalent au code Python donc)

Résultat : bah y’a pas grande différence.
De toutes façons, niveau I/O c’est rarement là que les langages se distingue (s’ils sont pas trop mal foutu…) les uns des autres, vu que ça fini souvent en appels de l’API C du système sous-jacent.

Idem pour la lecture, Scanner est réputé pour être lent donc c'est clairement pas ça qu’un programmeur Java va utiliser pour lire une grosse liste de double dans un fichier.

Ha ouais ?
Moi, ton lien me dit ça :

Sorry, I am unable to validate this document because on line 461 it contained one or more bytes that I cannot interpret as utf-8 (in other words, the bytes found are not valid values in the specified Character Encoding). Please check both the content of the file and the character encoding indication.
The error was: utf8 "\xE9" does not map to Unicode

Quelques autres ici aussi.

Bon écoute, je crois qu’il faut que tu revoies la définition d’un front-end de débogueur parce que sinon on est pas sortie du sable -___-"
Un front-end de débogueur ne détecte pas de bugs, c’est pas son taff (c’est le taff du débogueur en back-end + programmeur).
Un front-end de débogueur ne se contente pas de lancer le débogueur.

Un front-end de débogueur ça propose une interface, graphique (genre Eclipse) ou pas (genre M-x gdb-many-windows sous Emacs), qui permet d’interagir avec le débogueur et d’afficher diverses infos (par exemple : pile d’appel, contenue des variables et registres, liste des breakpoints, position dans le code source, listing asm, …)

Maintenant, il va falloir que tu m’expliques en quoi memcheck est un front-end de gdb, parce que là je ne vois toujours pas (où alors on a pas la dernière version de memcheck)…

Non.
Un front-end de débugger ça ne se contente pas de lancer le débugger uniquement, et après tu joues directement avec le débugger lui-même sans rien entre toi et lui.
À ce compte là, je fais un script shell qui attache gdb à un process et j’appelle ça un front-end…

Tu n’as jamais étudié les systèmes distribués (ne serait-ce qu’une intro) ?
C’est un des premiers trucs que l’on voit.
Ce topic (première réponse + commentaires) de stackoverflow explique la différence ordre total/ordre partiel, si jamais ça peut t’éclairer un peu :)

D’ailleurs Valgrind en lui-même ce n’est pas un débogueur mais un framework d'instrumentation binaire qui permet de créer des outils d’analyses dynamiques.
Après, certains de ces outils d’analyses sont effectivement utiles pour du débogage (mais ce ne sont toujours pas des débogueurs !), d’autres non (plutôt orienté profilage).

Ça dépends des constructeurs je suppose.
J’avais bossé sur une carte de traitement vidéo, de Texas, et le compilo’ le supportait sans problème.