Apprendre la programmation en C.

Je n'ai pas trouvé grand chose, sinon les docs imbitables à propos du processeur.

https://software.intel.com/en-us/forums/intel-isa-extensions/topic/299644

There are significant performance advantages to being 32-byte aligned if you have 32-byte loads and stores, even for instructions that do not require alignment to behave correctly.

On va lui faire confiance hein ?
Donc un alignement sur multiples de 32 octets (256 bits).

Endianness:

Stauk a écrit:Sinon si quelqu'un peut me filer un argument sur comment doivent être alignés les datas sur la plateforme X86, je veux bien prendre. 32 bits ? 128, 256, 512 ?

https://en.wikipedia.org/wiki/Data_structure_alignment

Ben, ça dépend pour quelle architecture tu veux programmer (vu que tu veux faire du bas niveau).

Le minimum est bien entendu le mot de ton processeur (donc 64 bits de nos jours).
Je ne suis pas (depuis fort longtemps) au courant de ce genre de détails, mais de ce que j'en comprends en fouillant rapido, ce serait :
- 128 bits pour le jeu d'instructions SSE2+
- 256 bits pour l'AVX
- 512 bits pour l'AVX-512
etc.

@philippe : ouais, l'autre lien date de 2008 ... donc on va dire 64 byte d'alignement (512 bits). Ca devient un peu ridicule, mais bon. Je pense que je vais seulement aligner les tableaux.

message censuré

Roger a écrit:

Commencer par programmer une version optimisée est l'erreur classique du débutant. Il vaut mieux commencer par un programme fonctionnel, modulaire, bref, un programme qui marche. Ensuite seulement on optimise. Il est également important de disposer d'options de compilation désactivant certaines optimisations pour que le programme puisse tourner sur le maximum de machines: si il faut le processeur machin-bidule avec tel jeu d'instruction à la mode, c'est mort. De nos jours, les machines sont tellement rapides et ont tellement de mémoire qu'on ne gagne rien à optimiser. Il y a même des optimisations qui ralentissent les programmes... Dans le temps, on mettait en cache les calculs car la mémoire était chère. Aujourd'hui, une telle stratégie plombe les applis à cause des latences d'accès à la mémoire et les fautes de cache: il est aujourd'hui plus efficace de recalculer au lieu de stocker en mémoire.

J'avoue que c'est toujours bien de le rappeler. D'habitude je le vois présenter comme une erreur classique qui concerne tout le monde, et pas seulement les débutants. Mais il y a des applications où une version non-optimisée peut être rapidement une source de galère. Néanmoins je n'ai jamais trouvé aucun argument pour défendre l'absence de version non optimisée, qui même si elle tourne sur une dimension réduite du problème, permet tout de même de Benchmarquer et vérifier la version qui elle va fonctionner sur des jeux de données un peu plus ambitieux. Combien la version qui va vite fait gagner par rapport à la version qui va lentement (ou économise de mémoire etc) ? La version qui va lentement doit en effet tourner sur un maximum de machines, avec un minimum d'effort, car comme elle n'a pas de contraintes, ça serait dommage autrement. Parfois on se rendra compte que la version qui va lentement est finalement utilisable (mais là peut résider le piège). Parfois on se rendra aussi compte que la version qui va lentement ne permet pas de traiter des jeux de données non triviaux de façon confortable, mais rarement.

Par contre l'homoingénieurus est naturellement enclin à n'avoir aucune envie de réaliser (et maintenir !) plusieurs versions. Et avoir les tests et l'ensemble de l'outillage qui va permettre de comparer les deux versions n'est probablement pas tout à fait trivial non plus. En vrai les logiciels pour être à peu prés au point doivent être réécrit 3 fois, et pouvoir tenir dans un seul cerveau humain. Les gros logiciels doivent être impérativement découpés en éléments simples qui correspondent à cette contrainte, et l'ensemble du système présenté en tant que collection d'éléments simples en interactions doit lui aussi obéir à cette règle (et récursivement s'il est encore plus complexe).

Sinon c'est la merde.

---

Heum. Ouais y a un cas où la question est plus ardue. Si ton composant est simple, mais utilisé par potentiellement l'ensemble de tous tes développements futurs. Là c'est compliqué. Quand la base est modifiée radicalement, ça peut vite demander du travail, voir demander de refaire tout ce qui en dépend. Pour le réécrire trois fois, il faut qu'il soit utilisé ... mais le fait qu'il soit utilisé, va contraindre énormément la possibilité de le re-écrire.

Petite page de publicité
https://alexgaynor.net/2017/nov/20/a-vulnerability-by-any-other-name/

(bien entendu c'est une publicité anti-C mais bon. Ca met un peu d'ambiance, et puis surtout c'est loin d'être faux).

message censuré

Roger a écrit:

Stauk a écrit:Petite page de publicité
https://alexgaynor.net/2017/nov/20/a-vulnerability-by-any-other-name/

(bien entendu c'est une publicité anti-C mais bon. Ca met un peu d'ambiance, et puis surtout c'est loin d'être faux).

Le mec fait de la pub pour Rust. Mais il n'a pas réalisé que la sûreté des accès mémoire est un problème réglé depuis l'apparition du premier langage de programmation ou presque: LISP disposait en natif d'un ramasse-miette dès sa conception, en 1958. L'informatique, c'est le grand bon en arrière permanent, la victoires des incultes incompétents.

T'as fais un peu de sécurité informatique ?

Roger a écrit: ramasse-miette

Les ramasses miettes peinent un peu, encore de nos jours (2017). C'est excellent pour faire du prototypage rapide, mais par contre dans certains environnements, si tu as du temps réel, ou du temps réel CRITIQUE (genre y a un mec qui meurt à chaque fois que tu es en retard de 2 ms, ou une banque qui fait faillite), les ramasses miettes n'offrent pas toujours toutes les garanties qu'on aimerait avoir. Du moins c'est ce qu'il semblait ressortir sur les forums et autres il y a encore quelques mois.

message censuré

Petitagore a écrit:

ortolan a écrit:Voilà, merci Philippe pour les stats. Je parlais bien du "PC des familles" (prolos, Mme Michu, ça me paraît un peu méprisant).

Il se peut. Cela dit, il y a clairement une informatique pour les utilisateurs qui n'y bitent rien, et une informatique pour ceux qui peuvent faire des incursions dans le code -- et ce sont ces derniers qui rédigent les librairies libres, les documentations, les tutoriels. Quand on pond soi-même du code, on a un peu tendance à se désintéresser totalement de la première catégorie, sauf si on veut leur vendre un produit fini. Mais on ne peut pas servir Dieu et Mammon: si on veut faire du bon code, on se fout un peu des machines merdiques, et si on veut vendre au grand public, on se fout un peu de faire du beau code.

Les utilisateurs "qui n'y bitent rien" choisissent Mac ! Parce que c'est vendu (alors que c'est faux) comme un système "simple", "beau" et "stable". Mais quand ma sœur s'est équipée d'une imprimante Wifi, elle m'a appelé à la rescousse pour la faire fonctionner, ce que j'ai réussi à faire en n'y connaissant rien mais en farfouillant sur internet (et en devant patcher un programme en plus !).

Plus précisément, de ce que j'ai vu (plus de vingt ans d'informatique de près ou de loin), on achète Mac soit par fétichisme, soit parce qu'on n'y connaît rien, soit parce que tout le monde le fait et que c'est cher ...
On peut aujourd'hui tout faire avec un PC sous Windows, même ce qui était réservé auparavant aux professionnels de la MAO, de la PAO ou du graphisme (2D, 3D, photo). Mais c'est vrai, on constate que la plupart des professionnels sont en Mac. À mon avis, les habitudes y sont pour beaucoup car le budget n'est pas le même...

Quant à la prééminence de Mac dans le monde professionnel, effectivement c'est loin d'être le cas dans beaucoup de secteurs. Dans les différents services de l'administration que j'ai traversés, c'est Windows qui gagne haut la main. Linux arrive bien sûr dans les environnements techniques et scientifiques (facs de sciences, organismes de recherches, écoles d'ingénieurs), mais on y trouve encore aussi beaucoup de Windows.

Cette guéguerre Windows/Linux/Mac dure depuis que les marques existent. Elle est stérile comme toutes les guerres, en particulier comme celle qui agite ce sujet : "tel logiciel est le seul valable, les autres sont de la merde", et comme tout ce qui est du type "religieux". (Attention, je n'ai pas dit : "religion", hein !) Même combat par exemple pour les guéguerres des différents types d'alimentation. Le problème est toujours le même : une attitude absolutiste est toujours fausse ! On ne peut pas appliquer la même recette à tous, que ce soit en nutrition ou en programmation, pour la simple et bonne raison que les individus sont différents, et même si leurs besoins sont les mêmes en apparence, la façon de les satisfaire sera multiple. Au passage, c'est la clé pour comprendre le monde dans lequel nous vivons. Il existe cinquante mille langages de programmation et cinquante marques de shampoings. Nous vivons dans le monde de la multiplicité !

Mais pour en revenir aux OS ou aux langages de programmation, croire que l'un est meilleur que les autres est une erreur qui trouve sont origine dans la croyance que l'utilité absolue existe. Or, il n'existe qu'une utilité relative. Ce qui est utile à l'un, l'autre s'en fout. Et inversement et réciproquement. J'aime bien l'exemple de l'agriculteur et du bourgeois pour illustrer ce propos. L'agriculteur a un tracteur, et le bourgeois une Ferrari. Qui peut croire que "la Ferrari c'est mieux qu'un tracteur" ? Ce sont deux véhicules, ça roule, ça permet d'aller un point A à un point B, mais l'utilité n'est pas la même. (Certes, une Ferrari, ça doit bien labourer un champ sur quelques mètres, mais niveau solidité... !)

L'utilisateur lambda n'en a donc rien à faire que l'on puisse programmer comme un esthète une architecture Linux avec du Ocaml. Pour regarder Facebook, jouer à Tétris 2018 ou faire ses comptes après avoir regardé ses dernières photos ou un épisode de sa série préférée, il veut ce qui sera le plus simple pour lui. Et pour beaucoup, comme l'habit fait le moine, il veut en plus "un bel objet". "Chéri(e), tu vas être content(e), c'est un Mac !" Pour le gamer, un bon vieux PC sous windows survitaminé sera un must (et même pour ceux qui veulent un compromis entre puissance et prix : mon ordinateur principal est un PC de gamer acheté en 2011 et toujours dans la course niveau performance pour ce que je fais : programmation, MAO, photo, etc. Parfois ça rame, parfois ça plante, mais j'ai connu le même genre de problèmes avec Linux et Mac !). Pour un étudiant en informatique, Linux est souvent le choix parce que pour installer le moindre logiciel, il faut recompiler jusqu'aux entrailles la machine et c'est formateur. Mais aucun choix n'est bon pour tout le monde. Pas en 2017 en tout cas...

Idem pour les langages de programmation : on peut tout programmer en assembleur, mais étrangement, on ne le fait pas. Il y a des langages pour le Web, des langages pour le bas niveau, des langages pour la performance ou les sciences, etc. On ne choisit pas un langage avant de savoir ce que l'on fait, on choisit le langage après avoir décidé ce que l'on veut faire.

Par ailleurs, il ne faut pas se leurrer : apprendre n'importe quel langage, que ce soit le joyau du fonctionnel comme Ocaml ou une "vraie merde" comme PHP, ça peut certes se faire en quelques heures pour avoir les bases, mais avec ce bagage, on bidouille et c'est tout. Maîtriser "l'art de la programmation", ça ne viendra pas comme ça. Et maîtriser n'importe quel langage, fût-ce cette merdouille de PHP ou de Java, ça demande plusieurs années de pratique. Que ça plaise ou non aux esthètes  . Alors le "mon langage, c'est le plus beau et les autres, y sont tous pourris", ça me fait toujours penser à cette citation de je ne sais plus qui (*) que je paraphraserai en : il y a plus de mauvais programmeurs que de mauvais langages (en proportion) .


(*) De mémoire : "Il y a plus de mauvais pianistes que de mauvais pianos"...

Alexandre, ce que tu dis est intéressant, et d'ailleurs je n'ai pas tellement l'impression que cela contredise celui de mes propos auquel tu réponds. Je m'inscris quand même totalement en faux contre ça:

Alexandre a écrit:Pour un étudiant en informatique, Linux est souvent le choix parce que pour installer le moindre logiciel, il faut recompiler jusqu'aux entrailles la machine et c'est formateur.

Ca a pu être assez vrai dans les premiers temps (quand l'Union soviétique était encore debout), mais il y a largement plus d'une dizaine d'années que c'est de la blague, à moins qu'on cherche les ennuis en tenant absolument à faire tourner une distribution exotique mal maintenue. La raison pour laquelle les étudiants en informatique privilégient Linux, c'est que tous les compilateurs libres, toutes les librairies libres, tous les environnements de développement libres, etc... tournent dessus sans difficulté, sans bourse délier et sans demander la permission à personne.

En revanche, je souscris totalement à ça:

Par ailleurs, il ne faut pas se leurrer : apprendre n'importe quel langage, que ce soit le joyau du fonctionnel comme Ocaml ou une "vraie merde" comme PHP, ça peut certes se faire en quelques heures pour avoir les bases, mais avec ce bagage, on bidouille et c'est tout. Maîtriser "l'art de la programmation", ça ne viendra pas comme ça. Et maîtriser n'importe quel langage, fût-ce cette merdouille de PHP ou de Java, ça demande plusieurs années de pratique. Que ça plaise ou non aux esthètes  . Alors le "mon langage, c'est le plus beau et les autres, y sont tous pourris", ça me fait toujours penser à cette citation de je ne sais plus qui (*) que je paraphraserai en : il y a plus de mauvais programmeurs que de mauvais langages (en proportion) .

(*) De mémoire : "Il y a plus de mauvais pianistes que de mauvais pianos"...

Je l'ai même déjà entendu sous la forme (un peu excessive quand même): "il n'y a pas de mauvais pianos, il n'y a que de mauvais pianistes". Il y a des machines pourries, des systèmes d'exploitation pourris, et des langages mal conçus; mais c'est vrai, il y a surtout des gens qui ne savent pas s'en servir.

Ou comme disait ma mère-grand (la vôtre aussi, j'imagine): les mauvais ouvriers ont toujours de mauvais outils.

Roger a écrit:

Il y a toutes sortes de ramasses-miettes: interruptibles ou non, multi-threadés ou non, incrémentaux ou non, optimisants ou non, temps-réel ou non. Pour la programmation usuelle, les ramasses-miettes améliorent les performances: ils ne bloquent pas l'application lors de la libération de grosses structures de données, ils défragmentent la mémoire et relocalise les données, ce qui rend les gros caches des processeurs plus efficaces. Mais surtout, ils font totalement disparaître toutes les fuites mémoires, les déréférencements invalides et les failles comme les débordements de pile. Quand on programme des algorithmes complexes, la gestion mémoire devient vite un cauchemar.

Honnêtement je sais pas encore très bien pourquoi la gestion de la mémoire est un tel cauchemar. Il faudra que je creuse le sujet. Je sais qu'elle PEUT être un cauchemar, en tout cas dans ses effets. Mais quand à savoir s'il existe une manière de programmer qui évite ces écueils, c'est une question que je vais me poser. Pour les ramasses-miettes ça m'étonne un peu. Rust dans ses premières versions utilisait un ramasse miette, et c'est un des arguments qui lui permet d'être si populaire, de justement offrir de bonnes garanties, tout ayant fait le choix de ne pas proposer de ramasse miette dans sa version 1.0. C'est aussi un des trucs que j'ai vu reprocher à Go, son ramasse miette.  Bon j'ai aussi entendu râler à propos de Java, mais on va dire que c'est un sujet tabou. Il faudrait que je fasse un peu le tour de la chose, mais en tout cas pour le peu que j'en perçois sur le plan théorique, ça ne semble pas trivial d'implémenter un bon ramasse miette, qu'on peut laisser gérer à sa guise en toute opacité.

Si tu as un lien à proposer sur un bon ramasse miette avec de supers garanties, je veux bien que tu le poste ici.

message censuré

Roger a écrit:

Stauk a écrit:Les ramasses miettes peinent un peu, encore de nos jours (2017). C'est excellent pour faire du prototypage rapide, mais par contre dans certains environnements, si tu as du temps réel, ou du temps réel CRITIQUE (genre y a un mec qui meurt à chaque fois que tu es en retard de 2 ms, ou une banque qui fait faillite), les ramasses miettes n'offrent pas toujours toutes les garanties qu'on aimerait avoir. Du moins c'est ce qu'il semblait ressortir sur les forums et autres il y a encore quelques mois.

Pour le mec qui meurt, c'est pas de bol. La banque en faillite, en revanche...

Il y a toutes sortes de ramasses-miettes: interruptibles ou non, multi-threadés ou non, incrémentaux ou non, optimisants ou non, temps-réel ou non. Pour la programmation usuelle, les ramasses-miettes améliorent les performances: ils ne bloquent pas l'application lors de la libération de grosses structures de données, ils défragmentent la mémoire et relocalise les données, ce qui rend les gros caches des processeurs plus efficaces. Mais surtout, ils font totalement disparaître toutes les fuites mémoires, les déréférencements invalides et les failles comme les débordements de pile. Quand on programme des algorithmes complexes, la gestion mémoire devient vite un cauchemar.

Un programme temps réel n'est pas un programme qui va vite, mais un programme qui respecte des contraintes de temps strictes. En général, les systèmes d'exploitation temps réels sont plus lents que leurs homologues plus laxistes. Au niveau des structures de données, le temps-réel impose de bonnes complexités dans le pire des cas, alors que par ailleurs on pourrait privilégier une complexité moyenne encore meilleure. Par exemple, une appli temps-réel utilisera des arbres équilibrés au lieu de tables de hachages, pourtant plus rapides en moyenne. La méthode la plus aisée pour faire du temps réel avec un ramasse-miette est de garantir que ce dernier peut être désactivé à tout moment puis réactivé quand les contraintes temporelles sont moins critiques. De toute manière, le temps-réel est une condition qui demande des soins très particuliers et le ramasse-miette n'est pas le plus dramatique des problèmes: il y a des sources de latence bien plus gênantes et souvent liées au système lui-même.

Je vois pas comment un garbage collector peut éviter un stack overflow.
Les buffer overflow, oui, mais il te suffit de faire une récursion infini et tu l'as ton stack overflow, garbage collector ou pas.

@Sarella : il voulait peut être parler des buffer overflow. Mais cela dit, ça ne fait pas automatiquement partie des attributions d'un garbage collector d'éviter les buffer overflow. Ptet un excès d'enthousiasme.

Roger a écrit:Le relativisme n'est pas pertinent. L'informatique, ça n'est pas n'importe quoi. Il est évident que l'arithmétique en chiffres romains est bien moins bonne que celle en chiffres arabes. Il n'y a pas besoin de tergiverser bien longtemps: un niveau scolaire en calcul suffit pour s'en rendre compte. En informatique, c'est pareil. Sauf qu'en informatique, les professionnels sont très mal formés, complètement ignares de leur discipline et par là même incompétents. J'ai croisé des cas graves, du genre le développeur qui croit avoir programmé un logiciel qui trouve les fuites mémoires dans un code ou qui détecte les programmes qui bouclent... sauf que ce sont des problèmes indécidables, on a les preuves mathématiques de leur impossibilité. Ces mêmes ignorants t'expliquent ce qu'est un bon ou un mauvais langage selon qu'il est cool ou pas. Tout se vaut quand on ne sait pas faire la part des choses. Le relativisme est un symptôme d'incompétence, pas un fanal de liberté.

Il ne s'agit pas de philosophie mais de pragmatisme ! L'agriculteur n'a que faire de savoir s'il est relativiste, physicaliste ou scientiste. Une belle voiture n'est pour lui d'aucune utilité au moment-même où il veut labourer son champ. L'utilité dépend de l'individu, de l'environnement, etc., bref est relative à un contexte. C'est un constat. Tant pis si ça heurte nos convictions philosophiques.
Et pour l'informatique, c'est la même chose. Si seuls des informaticiens ultra-compétents devaient programmer et ne programmer que dans des langages "selects", nous ne discuterions pas sur ce forum qui n'aurait jamais été créé (phpBB est en PHP, comme son nom l'indique). Il n'y aurait qu'une poignée de programmeurs sur Terre qui se feraient embaucher à coups de salaire de trader par des industriels qui leur feraient programmer autre chose que des forum pour internet (par exemple des logiciels pour lancer des fusées, piloter des engins, faire fonctionner les IRM, bref ce qui rapporte).

Les systèmes sont aujourd'hui tellement complexes que le zéro-défaut coûte des fortunes et est réservé à des projets ultra-exigents (par exemple, l'aéronautique, l'un des rares domaines où l'on a recruté un jour des spécialistes du Caml ). Beaucoup de logiciels sont donc bugués, mais on s'en fout. On n'a pas les mêmes exigences du zéro défaut dans tout ce qui contient de l'informatique parce qu'il y a un seuil de fiabilité au-delà duquel nous achetons, et l'économie fonctionne ainsi. On peut le regretter, trouver ça "mal", trépigner, ça ne changera rien au fait...

Bon courage pour le C en tout cas !

message censuré

chocolat a écrit:Je ne sais pas si ça va t'intéresser :
http://pubs.opengroup.org/onlinepubs/9699919799/

hello, si si, ça fait partie des choses qui concernent le sujet

Une page de vie informatique, avec aujourd'hui notre invité, Linus Torvald.
Alors, Linus, est ce que vous auriez un truc à partager avec nous ?

N'essayez pas ce mode de communication dans l'open space d'une grande banque:

C'est bien sûr faux, surtout dans l'aéronautique où ils ne veulent pas des langages de haut niveau, ni des méthodes formelles et autres outils de pointe. Ils les connaissent, ils savent qu'avec ces outils, leurs logiciels seraient de meilleur qualité, fonctionneraient mieux et coûteraient moins cher. Mais ils n'en veulent pas. Sont-ils crétins ? Bien sûr que non. Tout simplement, l'adoption de ces outils les forceraient à revoir toutes leurs méthodes et refonder leur chaîne hiérarchique: le chef de projet ne serait plus chef de projet, l'ingénieur ne serait plus ingénieur, etc. Ils veulent conserver leurs privilèges, voilà tout.

Tu n'arriveras pas à me convaincre. Je suis dans la position de celui qui a vu. Je sais ce qu'on apprend aux informaticiens, je sais ce qu'ils font une fois embauchés et je sais qui leur donnent des ordres. Ces gens sont des ignares, ils ne savent rien, ce sont de simples bricoleurs du dimanche bombardés développeurs. Les plus mauvais deviennent managers et font ensuite les choix stratégiques qui coûtent des milliards à la communauté. Les plus mauvais managers deviennent business angels et financent les équipes aux commandes des fondations Mozilla, de Google, ils font du PHP, du Go, de l'AutoIt, toutes ces merdes.

Pour l'utilisation d'Ocaml chez Airbus : L'analyseur statique ASTRÉE. Bien sûr que le Caml n'est pas utilisé dans tout ce qui est logiciel embarqué. On sait pourquoi (et sinon, on cherchera sur Google). Cet exemple était surtout ironique. Le caml n'est pas utilisé (ou de façon si discrète...) dans l'industrie. Seuls des universitaires et des chercheurs l'utilisent. Même dans l'éducation, il cède le pas à... Python (cf. le nombre de livres qui sortent depuis quelques années sur l'informatique en classes prépas : Python toute !). Bref, Caml est réservé aux "esthètes". Ici encore, c'est bien ou c'est mal, à vrai dire je ne sais pas (enfin si, je sais : ce n'est ni l'un ou l'autre, c'est fonction de son objectif, son besoin, son environnement... bref c'est relatif. Eh oui, le relativisme est décidément partout !).

Et pour terminer, je ne cherche à convaincre personne. Ni sur ce fil, ni sur aucun autre. Je ne fais que témoigner moi-aussi, et donner mon point de vue (car il ne s'agit toujours que de cela, relativisme oblige). Je lis l'avis des autres, et leur expérience est intéressante mais ne correspond pas toujours (pas souvent ?) à la mienne. Comme quoi le monde est décidément bien multiple...

Le couplet sur l'incompétence à la Dilbert est assez classique. La perfection n'étant pas de ce monde, il est toujours possible de le produire quels que soient les résultats déjà obtenus et la qualité des intervenants. Ici encore, ce n'est qu'un point de vue : voit-on le verre à moitié vide ou à moitié plein ?
Eh bien je le vois à moitié plein et donc mon point de vue est différent. Je vois d'énormes efforts qui ont été menés pour aboutir à quantité de résultats. Tout ne va pas comme sur des roulettes, et pourtant plein de choses parviennent à rouler tout de même. La preuve, comme je l'ai déjà signalé : ce forum où nous échangeons nos points de vue (mais nous ne débattons pas, il ne faut pas se leurrer non plus !), écrit dans la merdouille PhP qui donne du boulot à beaucoup de gens, même s'ils sont de piètres programmeurs... Et ni toi ni moi je pense (mais on peut se sentir une âme de Don Quichotte) n'y changera goutte...

@alexandre : Toi tu pourrais bien t'entendre avec ma compagne (Touches pas quand même) qui essaie d'expliquer qu'avant d'essayer de concevoir une Ferrari ou un Tracteur, il faut inventer la roue et que tout cela passe par des phases de créations de bouse ou de génie et de comprendre que la petite et la grande roue ont chacune un interêt, q'une surface molle ou dure c'est idem et que c'est un mixte de tout ce bazar qui fera que nous ferons un petit pas pour l'humanité, juste un petit pas. Car le grand pas c'est réservé à très peu d'entre nous.(Merci Alexandre de remettre un peu de bon sens ici bàs)

Moi je vais faire un grand plongeon, j'ai piscine

Alors ... où que j'en suis dans mon projet de faire du C ? Il y a deux points qui se dégagent :

- A/ Même si j'ai choisis le C comme langage, je veux quand même m'assurer une certaine confiance dans les aspects de reproductibilité des programmes que je vais écrire. Donc on est plus dans "je vais faire du C", mais "je vais faire du C de telle sorte que les programmes que j'écris seront sinon reproductibles [mêmes entrées produisent les mêmes sorties] tout au moins dotés d'une forte probabilité de l'être". Donc on est plus dans "avec quoi je programme ?", mais "comment je programme ?". Et c'est un sujet un peu complexe, bien qu' intéressant.

- B/ L'autre point, c'est qu'à force de me perdre dans des considérations théoriques, j'avance d'autant moins vite au niveau des programmes que je voudrais écrire. Sauf si on considère que les aides pour les écrire sont aussi une façon de les écrire, mais je préfère considérer que ce sont des aides. La logique voudrait que j'essaye de trouver ce qui existe comme pratiques (ou frameworks) qui correspondent à mon besoin. D'un autre coté chercher ce qui existe est parfois plus coûteux que de le réinventer, donc c'est toujours un choix difficile. Quand on réinvente, on peut mesurer l'avancement. Quand on cherche un truc qui n'existe pas, mesurer l'avancement est plus délicat.


Si je pousse la logique B jusqu'au bout, invariablement la conclusion est qu'il ne faut pas "utiliser C au mieux", mais "inventer un meilleure C". Sauf que ça prendrait trop de temps pour espérer pouvoir l'utiliser ensuite, à priori. Et c'est d'autant moins pertinent, que le fait de ne pas savoir utiliser C au mieux, laisse peu d'espoir d'être vraiment sagace pour proposer "un meilleur C".

Où commence le C, où commence le hardware, où commence la logique booléenne, où commence un programme, où commence la notion de fonction, et en quoi la notion de "programme" lui fait concurrence et vient la compléter, voici quelques unes des considérations qu'il semblent nécessaire de méditer, mais dont le fait de méditer beaucoup dessus, ne fait pas tellement avancer le schmilblick en tant que construction d'un projet montrable et utilisable.

Je perdrais moins de temps, si les gens mettaient des titres appropriés.

Le mec appelle sont article

Writing Secure Code

https://www.cprogramming.com/tutorial/secure.html

Qu'est ce que l'article contient ? Des trucs et astuces, et des exemples pour écrire du code non sécurisé.



Pareil pour les livres ?
https://resources.sei.cmu.edu/asset_files/BookChapter/2005_009_001_52710.pdf
Au moins dans le livre, y a quand même des éléments susceptible d'aider :

Page 102 :
size_t __builtin_object_size(void *ptr, int type)

http://www.informit.com/articles/article.aspx?p=2036582&seqNum=6


J'imagine que c'est contre les jeunes gens qui veulent mettre en pratique tous ces conseils, que Linus avait ranté (plus haut dans ce fil l'extrait du mail).
Personnellement je ne veux pas me défendre contre les gens malicieux pour le moment, mais plus me défendre contre moi même. Donc bon. De toute façon ça me semble quand même un peu léger tout ça, et on dépend parfois des outils, donc solutions pas très portables .

---

https://books.google.fr/books?id=GL8AeTCu1WAC&pg=PT180&lpg=PT180&dq=secure+array+access+for+c+programs&source=bl&ots=igEmDuIZYi&sig=uqaJUM3RbgOYsddCX2SAk5y7Cv0&hl=en&sa=X&ved=0ahUKEwipk7ixj9LXAhXCUhQKHYjZBOo4ChDoAQguMAE#v=onepage&q=secure%20array%20access%20for%20c%20programs&f=false

Okay, faut payer pour lire
https://link.springer.com/chapter/10.1007/3-540-36532-X_9

Mais comment je sais si ça vaut le coup de payer, si tu me dis pas ce qu'il y a dedans ?

Les protections du Kernel Linux :
https://www.kernel.org/doc/Documentation/security/self-protection.txt
https://eklitzke.org/memory-protection-and-aslr

Suite du roman feuilleton, Linus et ses rants.
https://lkml.org/lkml/2017/11/21/356

J'y vois un peu plus clair au niveau de la nature de l'informatique. J'ai fait quelques expérimentations en C, pour essayer de construire un environnement où programmer en ayant une idée de ce que fait le programme qu'on a créé, et pas seulement une idée de ce que pourrait faire le programme qu'on CROIT avoir créé en C est possible. Ca prend du temps, ça met des bugs dans les dents. Je comprends pourquoi les pointeurs sont réputés difficiles, par contre j'ai du mal à comprendre la manière dont on les utilise en C (dans la littérature pour débutants). C'est n'importe quoi, je dirais en première approximation. Peut être ça s'explique de façon historique, on pour des raisons d'optimisation énergétique. C'est peut être moins coûteux de mal programmer, on pourrait se demander en quoi, mais ça serait entrer dans un débat socio-économico-philosophique de peu d'intérêt pour réaliser des projets personnels.


Un de mes constats, c'est qu'on oublie vite ce qu'on fait, et de quoi on parle. Il y a une chaîne (stack on dirait en english, comme on parle de la stack des protocoles internets) qui va du monde physique, jusqu'au monde du langage et des échanges entre personnes, le monde des spécifications logicielle écrite pour être lues par des humains, et qui passe brièvement par une étape logique objective.


Monde physique <----> monde humain.
Entre les deux, il y a l'information, et notamment les processeurs, le hardware, puis les langages de programmation. Tout ça est un beau bordel, et les différentes strates sont assez mal conçues pour communiquer ensemble.

Il existe des langages de descriptions hardware propriétaires, il existe même des entreprises spécialisées dans la compilation des programmes c vers des langages hardware propriétaires, à destination en particulier de l'industrie financière.



Il existe des gens qui invente de nouveaux langage (Rust par exemple, ou Go, ou Lisp, Haskell), l'ennui c'est qu'ils mettent un coup d'épée dans l'eau, en ceci que leur langage s'intègre dans une stack complètement hétéroclites, et les couches en amont et aval du langage se parlent très très mal, avec des centaines de standards et façon différentes de dire et spécifier qui s'affrontent de manière informelle.


Ptet inventer un langage de programmation, ça serait déjà remettre un peu d'ordre et de cohérence dans la stack de l'informatique. La pile des manières de spécifier.

1. Spécifications physiques (grosso modo comment construire de portes logiques avec un monde physique, que ce soit avec des boules de billards, des automates cellulaires, ou des effets quantiques sur du silicium enrichi soumi à des tensions)
   
   
2. Spécifications logiques et temporelles (le hardware, les microprocesseurs, il existe des langages propriétaires spécialisé, le HDL, et du hardware bien adaptés à l'émulation : le FPGA. Il existe aussi des émulateurs logiciels assez lents). Comme vous le savez sans doute, Intel à racheté Xilinx, un vendeur de FPGA. A la fois pour intégrer la technologie à ses processeurs, mais aussi probablement du fait qu'il était un énorme consomateurs de FPGA pour mettre au point la partie logique de ses processeurs.
   
   
3. Programmation impérative (assembleurs). Là c'est l'explosion. On notera au passage que la force des assembleurs, c'est leur coté séquentiel. Tu fais ça, puis ça ... sauf que le monde réel est revenu à la charge, et que les processeurs sont de plus en plus plongé dans des environnements multiprocesseurs.
   
   
4. Programmation impérative / fonctionnelle (langages). On arrive aux langages traditionnels, C, Java, Go, Rust, Haskell, Lisp, Scala, Lua, .....
   
   
5. Programmation (autres) : prolog, mathematica, coq, .. langages de "haut niveau"
   
   
6. CAO : logiciels d'architectures (architecture des prorammes, des processeurs, ou des maisons, suivant le logiciel), Assistants à la création - simulations de flux sur des coques, simulateurs, design automatisé ou assisté, logiciels de modélisation 3D, Raytracing ....
   

Trouver LA (the) bonne abstraction pour parler de tout ça à la fois, de façon unifiée, et adaptée aux réalités de 2017 (ou 2018 notez, chui ouvert d'esprit)



Sources :
https://www.quora.com/Why-did-Intel-choose-to-acquire-Altera-and-not-Xilinx
http://fortune.com/2015/08/27/why-intel-altera/

Pour le fait que Intel utilisait des murs couvert de FPGA pour tester ses designs, j'ai l'impression que c'est un gars qui m'a dit ça. Aucune idée du contexte.
https://en.wikipedia.org/wiki/Hardware_emulation

Une page d'ingénierie.

It feels a little weird to put 100 hours into something that won't be noticed by its absence.

https://forums.tigsource.com/index.php?topic=40832.msg1363742#msg1363742

L'objectif du jour, c'est de me renseigner un peu sur les systèmes d'exploitation. Avoir au moins une vague idée de ce que c'est. Amusament dans la spécification du Multiboot loader, ils fournissent un exemple d'OS.
https://www.gnu.org/software/grub/manual/multiboot/multiboot.html

Sinon je vais lire un blog je crois, ptet celui là :
https://os.phil-opp.com/

notes de lecture:

(How to Write a (Lisp) Interpreter (in Python))

So, ironically, Tony wrote a Lisp program (with one small routine in C) because he was a C programmer, and I wrote a C program because I was a Lisp programmer.

http://norvig.com/lispy.html

Roger a écrit:

Code:


type instruction =
| SetReg of int * int
| Load of int * int
| Store of int * int
| Jump of int
| JumpZ of int * int
| Add of int * int
| Sub of int * int
| Print of int

let rec eval prog mem reg ptr =
  if ptr >= Array.length prog then (
    mem
  ) else (
    let nextPtr =
      match prog.(ptr) with
      | SetReg (r, cst) -> reg.(r) <- cst ; ptr + 1
      | Load (r, ra) -> reg.(r) <- mem.(reg.(ra)) ; ptr + 1
      | Store (r, ra) -> mem.(reg.(ra)) <- reg.(r) ; ptr + 1
      | Jump p -> p
      | JumpZ (r, p) -> if reg.(r) == 0 then p else ptr + 1
      | Add (r1, r2) -> reg.(r1) <- reg.(r1) + reg.(r2) ; ptr + 1
      | Sub (r1, r2) -> reg.(r1) <- reg.(r1) - reg.(r2) ; ptr + 1
      | Print r -> Printf.printf "%d\n" reg.(r) ; ptr + 1 in
    eval prog mem reg nextPtr
  )

let exec memSize regSize prog =
  let mem = Array.make memSize 0 in
  let reg = Array.make regSize 0 in
  eval prog mem reg 0

let _ = exec 100 4 [|
  SetReg (0, 10);
  SetReg (1, 50);
  SetReg (2, 1);
  SetReg (3, 0);
  Store (3, 1);
  Sub (0, 2);
  Add (1, 2);
  Add (3, 2);
  JumpZ (0, 10);
  Jump 4 ;
  SetReg (0, 10);
  SetReg (1, 50);
  SetReg (2, 1);
  Load (3, 1);
  Print 3;
  Sub (0, 2);
  Add (1, 2);
  JumpZ (0, 19);
  Jump 13
|]


Le code en OCaml fait appel à des concepts simples: des entiers, des tableaux et une récursion terminale. Il introduit simplement la notion de pointeur comme étant l'adresse d'une case mémoire, un indice dans un tableau. On a en prime la notion d'interpréteur, d'assembleur, de registres, etc.

Je me sens quand même intrigué par cette affaire. Même si clairement c'est encore un hors sujet qui va me conduire à investiguer des pistes et perdre de vue mes objectifs plus immédiats.

the grammar of Scheme generates a sublanguage of the language used for data. An important consequence of this simple, uniform representation is the susceptibility of Scheme programs and data to uniform treatment by other Scheme programs. For example, the eval procedure evaluates a Scheme program expressed as data.

Historiquement ça nous donne :
http://schemers.org/Documents/Standards/R5RS/r5rs.pdf
vs
https://en.wikipedia.org/wiki/ALGOL

Je ne suis pas un fan de l'aspect "recursif" vs "for loop". J'aime assez la notation "for i =0 to 125 do" (et toutes ses variantes). Il n'y a pas de version récursive aussi satisfaisante. A contrario on vante beaucoup l'aspect minimaliste de lisp, et son "élégance". Je me sens intrigué. J'ai déjà écrit vite fait des programmes dans des dialectes, et ça ne m'a pas marqué comme étant très agréable ou pratique. Mais peut être que je n'ai pas abordé les choses sous le bon angle. J'aimerais consacrer un peu de temps à me faire idée des forces et faiblesses du paradigme lisp.  Une faiblesse qui me semble évidente, est le coté trop générique de la forme simple [for i=0 to 125 do] car cette expression offre des garanties intéressante, et c'est d'ailleurs quelque chose que je n'aime pas du tout dans le langage C non plus que de fusionner cette forme très fortement garantie, avec un truc plus (trop) général : le while. (ou le tail recursion).

---

The JSON crowd is re-inventing LISP. Originally, JSON was a subset of what you could pass to "eval()".

https://news.ycombinator.com/item?id=13097872

---

What follows is largely a discussion of how to sum the first ten integers

http://wiki.c2.com/?WhyWeHateLisp

Ca prend une épouvantable quantité de temps (plus de 2h) de se faire même une vague idée de ce qui existe ou de ce qui a été tenté.

http://www.paulgraham.com/thist.html
http://mumble.net/~jar/tproject/
http://web.archive.org/web/20060925104715/http://mumble.net/~campbell/t/tman.pdf

Ce que je retiens pour le moment c'est que les lisps sont des langages naturellement faciles à implémenter, tant au niveau de l’interpréteur que du compilateur. Par contre à l'usage c'est pas forcément terriblement pratique, dans le sens que ça ne respecte pas trop les habitudes qu'on nous inculque (et peut être c'est juste merdique tout court). Mais du coup pour écrire un langage customisé pour une certaine tâche, il est tentant de s'intéresser à Lisp. Par exemple si on veut rapidement fournir un langage de script, on peut avoir envie de s'intéresser à Lisp.

Le projet T semble(ait) avoir pour objectif de transformer la syntaxe Lisp en un langage macro-assembleur (donc utilisable en programmation systeme). C'est assez intriguant, et néanmoins ça demande quand même de se pencher un peu sur l'ensemble pour se faire une idée de ce qui est possible, et de ce qui a été tenté.

https://swizec.com/blog/the-birth-of-lisp-a-summary-of-john-mccarthys-original-paper/swizec/5075

I tried to learn LISP (clojure really), I really did. But the syntax was just too jarring.

Le problème du jour : le mutlithread. Dis tonton, ça marche comment ?

- Quelles instructions sont disponibles sur les processeurs ?
- Combien ça coûte ?
- Quels sont les patterns (de haut niveau) les plus courants, avantages/inconvénients ?
- Est ce qu'il existe un moyen de se passer de synchronisation, et d'avoir un bidule qui fonctionne à la fin ?



Un premier lien pour se cultiver :
https://stackoverflow.com/questions/2538070/atomic-operation-cost

D'autres en vrac
https://en.wikipedia.org/wiki/Synchronization_(computer_science)#The_need_for_synchronization
https://en.wikipedia.org/wiki/Readers%E2%80%93writer_lock
http://moodycamel.com/blog/2013/a-fast-lock-free-queue-for-c++

https://carld.github.io/2017/06/20/lisp-in-less-than-200-lines-of-c.html

---

Stack languages ("Lisp without the parentheses") :
http://www.drdobbs.com/architecture-and-design/cat-a-functional-stack-based-little-lang/207200779
https://en.wikipedia.org/wiki/Joy_(programming_language)

Introduction to concatenative (aka stack based, aka lisp without parenthesis) language
http://ncreep.github.io/language_perils/blog/2013-03-18-the-joy-of-joy.html

Une autre publicité pour rust (english) et pour le nouveau mozilla.
http://bholley.net/blog/2017/stylo.html

Vocabulaire (game of life)
http://conwaylife.com/wiki/Lidka
http://conwaylife.com/wiki/List_of_long-lived_methuselahs

Une (en fait plusieurs) implementation présumée rapide de game of life (sur les CPU intel)
https://gitlab.com/apgoucher/lifelib
http://www.perlmonks.org/?node_id=1197250

Stauk a écrit:Vocabulaire (game of life)
http://conwaylife.com/wiki/Lidka
http://conwaylife.com/wiki/List_of_long-lived_methuselahs

Une (en fait plusieurs) implementation présumée rapide de game of life (sur les CPU intel)
https://gitlab.com/apgoucher/lifelib

Je ne sais pas pourquoi tu nous parles de tout ça, mais c'est quand même fascinant...

@Petitagore ... bah ... pour apprendre le C.

Y a aussi BBBEEAUCOUP de choses dont je ne parle pas; Grosso modo tout ce qu'il y a d'original dans mon approche. Vu que déjà c'est difficile d'en parler, et puis c'est con, mais on sait jamais, dans le tas y a peut être un truc utile.  Je crois que j'ai mal digéré le jour ou ayant la flemme de tester (plus avant ) des idées j'ai expliqué un truc sur une mailing list. Et puis quelques mois après y avait un papier qui testait la pertinence de mon idée (qui fonctionnait correctement, mais sans plus, ça n'a jamais été une révolution, juste une bonne idée à tester, puis à oublier). Mais rien qui relie le papier à ma contribution, c'est à dire de poser l'idée elle même. Ca m'a laissé l'impression qu'une idée qui n'est pas ancrée dans la réalité par une implémentation solide appartient à l’éther commun. Alors qu'une idée qui est implémentée concrètement appartient à celui qui l'a ainsi mis en valeur. Tout ça reste très subjectif bien entendu.


Pour ce qui est de ce que je mets ici, ce sont des ressources qui me semblent pertinentes pour apprendre le C, néanmoins ce qui est vraiment pertinent, c'est d'implémenter des trucs. Et ça reste le point faible de mon approche, je me sens mal à l'aise avec le hardware, je suis terriblement frustré de ne pas trouver un moyen de poser les choses à plat qui me convienne. Je gratte la surface, en espérant un miracle.

Pour faire simple, je suis extrêmement angoissé par ce monde, ces choix qui sont faits pour moi, et sur lesquels j'ai peu de pouvoir. Bien que ce ne soit pas la priorité immédiate, j'ai envie de pouvoir partager un minimum mes (éventuelles) réalisations, de montrer ce que j'implémente, à un moment, ne serait-ce qu'à mes proches, mais aussi pourquoi pas, un jour partager d'une façon ou d'une autre.

Réaliser des trucs sur FPGA (ou asic) n'est clairement pas pertinent, sauf si justement c'est pour offrir quelque chose qui est vraiment bas niveau (robot ou autre). D'ailleurs même les FPGA sont frustrants dans les choix qu'ils imposent. Je ne comprends pas tout ces choix, mais si je veux bien comprendre ce que j'estime être incompréhensible, il y a un moment où il va falloir plus qu'un gut-feeling. Et du coup le C est un moyen d'exploration de ces univers (les automates de façon générale, dont les CPUs sont des instances particulières).

---

Bah pour faire simple, après tout à défaut de parler des mes idées, je peux toujours parler de mes difficultés : j'ai choisis le C car c'est un langage qui demande peu d'investissement. Si je veux apprendre le rust, ou le C++, il va me falloir des années, et je n'ai pas envie d'être marié à ces langages qui me semblent défaillants (ou à défaut très angoissant dans le manque de contact qu'ils offrent avec le monde qui m'intéresse). Le C est en fait une manière de prototyper pour explorer le monde des automates (au sens général du terme, grosso modo pour explorer la programmation, dont malheureusement les instances actuelles sont finalement très contraintes et peu générique. Y a comme un manque généralisé d'élégance). Dans les envies concrètes, il y a les agents qui apprennent automatiquement (aka deep learning et assimilable) et également les interactions [graphique/souris/dream/clavier] (aka les jeux vidéos, en particulier les simulations du style Dwarf Forteress, même si je ne connais absolument pas Dwarf Fortress, j'ai lu des choses à propos de ce jeu, et ça représente bien l'esprit de ce qui me fascine : le monde des simulations).

Je dis que je veux apprendre à Programmer en C, et le reflexe d'un lecteur semble être "tiens, il n'a jamais programmé de sa vie". Ce qui n'est pas tout à fait exact. Je dis que je ne sais pas programmer, car je n'ai pas les idées claires sur pleins de choses. Mais plus mes idées se précisent, plus c'est difficile de programmer, car je suis angoissé par toutes les contraintes que l'environnement nous propose. D'un autre coté, sans cet environnement, je n'aurais jamais eu accès à un pc (qui est quand même pas évident à construire à partir du bush australien), donc je peux pas non plus cracher dans la soupe de la main qui me nourrit en sciant la branche sur laquelle je suis assis. Mais des fois j'ai envie quand même.


Références :

Optimisation automatique ( = learning)


https://github.com/wassname/viz_torch_optim



https://www.sfu.ca/~ssurjano/camel6.html

sur ce lien et cette animation

https://github.com/wassname/viz_torch_optim

on capte bien que l'optimisation est paradoxalement la meilleure quand l'itération "explore" une plus grande étendue de possibles

le learning en fait dépend fondamentalement des erreurs !

et si on injecte les écarts par rapport aux attentes, on apprend plus vite, c'est le principe de la régulation des lasers ceci dit si j'ai souvenir

le chaos du flux lumineux en sortie est rebalancé en entrée de telle manière que le flux soit tout dans tout relativement corrigé et vaguement constant

la prévision adaptative en stat fait la même chose

on a donc forcément une réduction progressive des écarts et une convergence

je suppose qu'en programmation en c on pourrait aussi coder une injection d'écart en quelque sorte mais ce serait surement pas très propre comme code

et évolutif, le code , ou l'auto code d'une ia permets ans doute cette liberté de reprogrammation

cela montre aussi accessoirement une faiblesse majeure des machines learning, elles ne peuvent proposer une solution que sur les entrées

cela implique que si les entrées sont partielles ou de mauvaises qualité, le learning ne sera pas bon

je le constate souvent en amazon par exemple

je suppose qu'ils ont le même problème à la nsa et c'est très bien ainsi :-)

Quelques informations sur les processeurs.    la notion de Pile fait partie de tous les processeurs que je connais. Et de toute façon la RAM aussi. Une RAM + un pointeur = une pile.

Stack based processor :
http://www.excamera.com/files/j1.pdf

Multi core processor (pas eu le temps de trouver ce que je cherche : comment ils synchronisent les procs)
https://upcommons.upc.edu/bitstream/handle/2099.1/7460/59395.pdf

---

Je cherche des benchmarks sur les instructions de shift des BigIntegers.
https://stackoverflow.com/questions/35001722/global-bitwise-shift-of-128-256-512-bit-registry-using-intrinsics

Hello Stauk,

Pour comprendre le C et avant d'aller trop loin dans des "détails" techniques, il est intéressant de comprendre la réelle puissance des concepts même du C et des instructions basiques. Je crains que sans cela, tu te perdes dans les normes et dans les méandres des architectures qui nécessitent pas mal de recul pour en comprendre les tenants et les aboutissements.

Si tu veux un exemple d'un exercice de style simple mais délicat c'est de programmer un simple algo de tri d'un fichier de données tabulaire dont tu ne connais ni structure ni la longueur avant l'appel de la fonction.
La structure des colonnes peut être donnée par un fichier tiers du type
Col_1 Integer
Col_2 String25
...
Col_n Bizarre

Le but du jeu est d'avoir un temps de réponse "presque" linéaire que tu traites 1 millions de ligne ou 1 milliards.

C'est très basique mais une base sûre pour faire pas mal d'erreur, de comprendre ses erreurs et de rentrer dans ce qu'est le traitement de l'information sans passer par les couches de haut niveaux.


Si tu veux t'initier à la programmation système, tu peux créer un driver Windows pour la gestion de joystick virtuel. Mais là c'est coûteux en investissement car il va falloir éplucher des tonnes de docs pour voir comment Windaube exploite les périphériques. Mais c'est amusant et éducatif  car sans trop de risque.

Bon jeu

Unefois a écrit:
Le but du jeu est d'avoir un temps de réponse "presque" linéaire que tu traites 1 millions de ligne ou 1 milliards.
C'est très basique mais une base sûre pour faire pas mal d'erreur, de comprendre ses erreurs et de rentrer dans ce qu'est le traitement de l'information sans passer par les couches de haut niveaux.

>on Oct 28 2015 AliCloud sorted 100 terabytes of data within 377 seconds, breaking the previous world record of 1,406 seconds set by Apache Spark. In the two most technically demanding contests GraySort and MinuteSort, AliCloud set four new world records in both the Daytona category for general-purpose sorting systems and the Indy category for specifics-customized systems for the task of sorting.

The news stunned the technical sphere, especially the Internet and computer fields that pay close attention to cloud computing. AliCloud’s record-breaking performance in the contest rekindled people’s interest in distributed computing. Discussions are going on in the big data and cloud computing circles about how difficult the task is, how AliCloud made it, what its significance is for the general public etc.<


https://www.alibabacloud.com/forum/read-71



>The concept changed in 1998 and distributed computing started to predominate. The focus of work turned to how to effectively dispatch the physical resources of hundreds or even tens of thousands of machines such as CPUs, memory, networks and disk IOs to complete data sorting within the shortest time.<

---

Si tu veux t'initier à la programmation système, tu peux créer un driver Windows pour la gestion de joystick virtuel. Mais là c'est coûteux en investissement car il va falloir éplucher des tonnes de docs pour voir comment Windaube exploite les périphériques. Mais c'est amusant et éducatif  car sans trop de risque.
Bon jeu

Je n'ai pas windows, et je n'ai pas de Joystick.




https://www.codingame.com/start

C + SDL 2 --> Web.

https://lyceum-allotments.github.io/2016/06/emscripten-and-sdl2-tutorial-part-4-look-owl/
https://github.com/emscripten-ports/SDL2

Bon j'ai choisis le C comme langage (de programmation), mais finalement l'informatique ce n'est pas juste la programmation. Il faut d'autres langages complémentaires.


Le C sert juste à manager la boite la plus en bas. J'ai choisis le C car c'est simple. Maintenant faut voir comment je gère les autres boîtes, avec quels langages ? Des langages simples, pratiques, faciles à apprendre, qui permettent de réutiliser ... etc etc.

Stauk a écrit:J'ai choisis le C car c'est simple.

Ben non, justement, c'est ce que plusieurs personnes ont expliqué : le C n'est pas simple. (Ça veut dire quoi, d'ailleurs, "simple" ? C'est comme l'utilité dont il a été question plus haut...)
Aucun langage n'est simple, ni les vraies langues parlées dans le monde, ni les langages du monde informatique. Parce qu'un langage ce n'est pas simplement des mots et une syntaxe pauvre, c'est une utilisation, une grammaire, des exceptions, des variations, beaucoup de pièges aussi, et surtout à la fin... un style !
Mais bon, si tu veux continuer de penser que le C est simple, tu le pourras et tu en seras convaincu tant que tu n'auras pas mené de "vrais" projets en C. (On peut bien sûr remplacer "C" par n'importe quel autre langage ;-)...)

Bon courage en tout cas !

Alexandre a écrit:
Aucun langage n'est simple, ni les vraies langues parlées dans le monde, ni les langages du monde informatique.

J'utilise "simple" par opposition à "complexe". Est ce que tu affirmerais qu'aucun langage n'est plus >non-simple< qu'un autre ? S'il existe des langages plus >non-simple<, alors il existe aussi des langage moins >non-simple<, et alors on peut designer l'un de ces langages par ce label qui représente bien une propriété. Après je suis d'accord que le mot "simple" n'est pas très parlant, en général une personne qui lit ce qu'on écrit ne se demandera pas ce qu'on essaye de dire, et même si elle le fait, elle n'aura pas nécessairement envie d'essayer de répondre en utilisant cette compréhension : comprendre ce que quelqu'un d'autre écrit (ou dit, ou veux dire) est complexe, sauf si le contenu n'est pas important, et que c'est l'échange qui prime.

Malheureusement j'aimerais échanger au niveau du contenu. Peut être le langage n'est pas approprié pour ça, et du coup le mot "simple" non plus. Le C est simple au niveau de sa structure, au niveau de ses compilateurs (au moins les minimalistes), il est impératif, et répond aux syntaxes intuitives dans lesquelles tout le monde baigne. Si tu donnes à un jeune de quatorze an quelques exemples, en quelques lignes il devrait comprendre la majorité de la syntaxe, excepté peut être les pointeurs, qui sont spécifiques aux langages assembleurs. Le C est aussi simple en ceci qu'on peut se faire une idée à priori du code généré, en ayant à l'esprit un modèle simple(encore). Le langage est aussi à considéré dans la pile des outils/langages/hardware dans lequel il s'inscrit. Le C est simple là encore, les outils sont (ou peuvent être) très simples, et le lien avec le hardware sans être immédiat, est accessible.

J'oppose donc le C au C++, à Rust, Javascript, Java, aux Lisps etc. Aucun n'est aussi "simple" que le C. Et donc le C est "simple".


Le fait que je considère que je ne sache pas programmer en C, ne signifie pas que je n'ai jamais écrit de programme en C.  Ni que je n'ai jamais écrit de programme en assembleur d'ailleurs, ou en Java, ou en Clojure, en Bash, en Rust etc. Le C est simple en ceci qu'on peut l'avoir en tête et même l'expliquer en quelques minutes, ou quelques heures, à une personne qui est compatible intellectuellement. A contrario le C++ ne peut pas être expliqué en quelques heure, même à une personne très compatible. D'ailleurs je ne sais honnêtement pas si le C++ peut être expliqué, dans le sens que peut être l'ensemble ne fait tout simplement pas sens. Ce qui ne signifie pas qu'il ne soit jamais "simple" pour personne d'utiliser du C++. Le C++ n'est pas >simple<, et le C est >simple<.


J'ai choisis le C, car il n'a pas de spécificités particulières, comparés à un langage assembleur c'est dans une large mesure un équivalent, avec une syntaxe plus intuitive et structurée, et doté d'un langage macro. Par ailleurs, si on prend la plateforme i686 comme référence, le C est un langage assembleur simplifié. Un certain nombre de détails sont masqués, et la prolifération des opérations est simplifiée. Dans la nomenclature que j'utilise, les langages assembleurs (même le i686 qui est particulièrement alambiqué) sont >simple<, essentiellement du fait qu'ils sont un moyen immédiat d'affecter la réalité physique sous-jacente. Avoir à l'esprit la place qu'ils occupe dans la pile des constructions qui rendent possible "la programmation" est simple. Par ailleurs les principes de bases sont peu nombreux également. Le système de typage est minimaliste (essentiellement la taille des entiers / flotants / pointeurs). Par contre il est clair qu'il y a des langages assembleurs plus simple que d'autres. Donc si j'écrivais que le langage assembleur bidule [exemple : https://github.com/cslarsen/stack-machine] est "simple", la réaction ici serait : mais non le langage assembleur n'est pas simple, fait donc du visual basic plutot. Bah, ouais. Enfin c'est pas idiot pris dans le référentiel de la personne qui me donne ce conseil, mais j'ai mes propres contraintes, qui font que de réaliser un logiciel qui trie le dataset des courses de chevaux [exemple de data set à prendre en input : https://www.kaggle.com/lukebyrne/horses-for-courses] en VisualBasic n'est pas ma priorité, même si c'est par ailleurs sans doute un excellent moyen d'apprendre pleins de choses intéressantes.

---

Bref ce que je cherche en fait, ce sont des interlocuteurs, et des contradicteurs. Finalement celui qui a le plus challengé mes conceptions, c'était Roger. Je n'ai pas aimé la manière dont il a présenté ses arguments, mais je suis bien obligé d'admettre qu'il y avait derrière l'expression de son dégoût, un contenu réfléchi et travaillé, et finalement une compréhension du sujet du fil.  Après si on lit en surface ce qu'il a écrit était "Le C c'est nul, fait plutôt du Forth ou du Lisp (enfin CamelObjet bidule, mais j'imagine que ça doit pas être très loin)". Mais la différence, c'est qu'il a essayé de fournir des liens vers des articles, et des arguments. Et il a également lu les arguments et les articles que je lui opposais, en dépit du fait qu'il semblait partir du principe que j'étais sois un gros con, soit un criminel. Enfin de compte c'était stimulant, et c'est ça que j'espérais tirer d'un fil avec pour titre "tiens j'aimerais bien apprendre le C".

Assez rapidement lire ce qu'écris une personne dans mon genre, un peu destructurée et qui manque d'organisation, sur un fil qui est disponible au quotidien, devient à peu près impossible en soi. Lire les référence demanderait encore plus d'investissement. Le format du fil n'est pas très adapté à l'interaction avec les gens qui veulent interagir.  Je vous propose donc qu'on ferme ce fil, et qu'on en ouvre un nouveau, avec des règles plus claires au niveau de ce qui est attendu.

https://www.cl.cam.ac.uk/~srk31/research/papers/kell17some-preprint.pdf

This essay is a
C programmer’s reaction to the call to abandon ship. It questions
several properties commonly held to define the experience
of using C; these include unsafety, undefined behaviour,
and the motivation of performance. It argues all these are
in fact inessential; rather, it traces C’s ultimate strength to a
communicative design which does not fit easily within the
usual conception of “a programming language”, but can be
seen as a counterpoint to so-called “managed languages”.
This communicativity is what facilitates the essential aspect
of system-building: creating parts which interact with other,
remote parts—being “alongside” not “within”.

La conclusion ...

C is far from sacred, and I look forward
to its replacements—but they must not forget the importance
of communicating with aliens.