• [^] # Re: mine is better

    Posté par (site web personnel, Mastodon) . En réponse au lien Nothing better than C. Évalué à 5.

    C non plus ne remplit plus ces critères pour les ordinateurs modernes: https://queue.acm.org/detail.cfm?id=3212479

    Il est construit sur un modèle qui n'existe plus: un seul fil d'exécution, pas de mémoire cache, des instructions qui s'exécutent dans l'ordre ou elles sont présentes dans le programme, un ensemble de registres fixes. Aujourd'hui, un ordinateur ne fonctionne plus comme ça. Il y a plusieurs CPUs qui chacun peuvent exécuter plusieurs threads en parallèle, plusieurs niveaux de mémoire cache et de mémoire virtuelle, les instructions sont exécutées dans le désordre et même parfois exécutées avant d'être finalement annulées, et les registres visibles en assembleur n'existent pas vraiment, le processeur assigne ses registres internes dynamiquement en fonction des dépendances qu'il détecte entre les instructions.

    Donc, non, le C n'est pas vraiment proche du comportement du matériel actuel. Il est proche du fonctionnement d'un ordinateur des années 70-80. Ça permet d'avoir un modèle simple à comprendre (mais approximatif) de ce qu'il se passe. Mais on pourrait prendre un autre modèle moins proche du PDP-11 et ça fonctionnerait bien aussi. Par exemple quand on programme en Smalltalk, on réfléchit en terme d'objets qui s'envoient des messages, et on peut très bien parler de performances dans ce contexte (combien d'objets sont créés/supprimés, combien de messages sont envoyés, etc). Ou par exemple si on fait du Haskell, on réfléchit en terme de fonctions, et les optimisations se font à un autre niveau (qu'est-ce qui peut être précalculé à la compilation?).

    La difficulté de C++ (je prend cet exemple parce que je le connaît bien), c'est surtout qu'il y a plusieurs façons de penser qui sont mélangées dans un seul langage. À la fois c'est intéressant, parce que ça permet d'écrire du code à différent niveaux d'abstraction sans trop s'embêter. À la fois, on a vite fait de tomber dans un piège parce qu'on saute sans cesse d'une façon de penser à une autre (de la programmation objet, impérative, procédurale, ou même fonctionnelle).