Nous devons utiliser C & # 8220; pour des raisons de performance & # 8221; [fermé]

StackOverflow https://stackoverflow.com/questions/1223710

Question

À l'ère de nombreuses langues, il semble exister une langue géniale pour presque toutes les tâches et je me trouve professionnellement en train de lutter contre un mantra de " rien mais C est rapide ", où "rapide" signifie vraiment "assez rapide". Je travaille avec des personnes très rationnelles, ouvertes d'esprit, qui aiment comparer les chiffres. Tout ce que j'ai, ce sont des pensées et des opinions. Pourriez-vous m'aider à me frayer un chemin à travers les opinions subjectives et dans le "monde réel"?

Pourriez-vous m'aider à trouver des recherches pour savoir si d'autres langages pourraient être utilisés pour la programmation de systèmes intégrés et (Linux)? Je pourrais très bien avancer une fausse hypothèse et j'apprécierais énormément les recherches qui me le montreraient. Pourriez-vous, s'il vous plaît, associer ou inclure de bons chiffres afin de vous aider à conserver le "qui n'est que son opinion" commentaires au minimum.

Voilà donc mes exigences particulières

  • la mémoire n'est pas une contrainte sérieuse
  • la portabilité n’est pas un problème sérieux
  • ce n'est pas un système temps réel
Était-ce utile?

La solution

"Rien que C ne soit rapide [assez]" est une optimisation précoce et fausse pour toutes les raisons pour lesquelles les optimisations initiales sont fausses. Si votre système a suffisamment de complexité pour que quelque chose d'autre que C soit souhaitable, certaines parties du système doivent être "suffisamment rapides". et des pièces avec des contraintes plus légères. Si vous écrivez votre code, par exemple, en Python, le projet sera fini plus rapidement, avec moins de bogues, alors vous pouvez faire un suivi avec du code en C ou en assembleur pour accélérer les parties critiques.

Même s'il s'avère que tout le code doit être écrit en C ou en assemblage pour répondre aux exigences de performance, le prototypage dans un langage tel que Python peut avoir de réels avantages. Vous pouvez utiliser votre prototype Python en fonctionnement et remplacer progressivement les pièces par du code C jusqu'à atteindre les performances requises.

Alors, utilisez les outils qui vous permettent d’effectuer le travail de développement le plus correctement et le plus rapidement possible, puis utilisez des données réelles pour déterminer où vous souhaitez optimiser. C est peut-être l’outil le plus approprié pour commencer, parfois, mais certainement pas toujours, même dans les systèmes embarqués.

Autres conseils

Selon mon expérience, l’utilisation de C pour la programmation intégrée et systémique n’est pas nécessairement un problème de performances, c’est souvent un problème de portabilité. C tend à être le langage le plus portable et le mieux supporté sur à peu près toutes les plateformes, en particulier les plates-formes de systèmes intégrés.

Si vous souhaitez utiliser quelque chose d'autre dans un système embarqué, il vous suffit souvent de déterminer les options disponibles, puis de déterminer si les performances, la consommation de mémoire, la prise en charge de bibliothèques, etc. sont "suffisamment bonnes". pour votre situation.

L'utilisation de C pour les systèmes embarqués a de très bonnes raisons, parmi lesquelles "performances". est seulement l'un des mineurs. Embedded étant très proche du matériel, vous avez besoin d'adressage manuel en mémoire pour communiquer avec le matériel. Toutes les API et les kits de développement logiciel (SDK) sont disponibles principalement pour le langage C.

Seules quelques plates-formes peuvent exécuter une machine virtuelle pour Java ou Mono, ce qui s'explique en partie par les conséquences en termes de performances, mais également par les coûts de mise en œuvre élevés.

Outre les performances, il existe un autre facteur à prendre en compte: vous aurez probablement affaire à des API de bas niveau conçues pour être utilisées en C ou C ++ .

Si vous ne pouvez pas utiliser certains SDK, vous aurez uniquement des problèmes au lieu de gagner du temps avec le développement en utilisant un langage de niveau supérieur. À tout le moins, vous finirez par refaire un tas de déclarations de fonctions et de définitions constantes.

Pour C:

  • C est souvent le seul langage pris en charge par les compilateurs pour un processeur.
  • La plupart des bibliothèques et des exemples de code ont également une probabilité en C.
  • La plupart des développeurs intégrés ont des années d’expérience C mais très peu d’expérience.
  • Permet l’interfaçage matériel direct et la gestion manuelle de la mémoire.
  • Intégration facile avec le langage d'assemblage.

C sera dans les années à venir. Dans le développement intégré, c'est un monopole qui étouffe toute tentative de changement. Un langage nécessitant une machine virtuelle, telle que Java ou Lua, ne se généralisera jamais dans l'environnement embarqué. Un langage compilé pourrait avoir une chance s'il offre de nouvelles fonctionnalités convaincantes par rapport à C.

Il existe plusieurs points de repère sur le Web entre différentes langues. Dans la plupart des cas, vous trouverez une implémentation C ou C ++ en haut, car ils vous donnent plus de contrôle pour optimiser les choses.

Exemple: Le jeu de tests de langage informatique .

Il est difficile de s’opposer à C (ou à d’autres langages de procédures tels que Pascal, Modula-2, Ada) et à l’assemblage pour systèmes intégrés. Il y a une longue histoire de succès avec ces langues. En règle générale, vous souhaitez supprimer le risque de l'inconnu. Essayer d'utiliser autre chose que le C ou l'assemblage, à mon avis, est un inconnu. Cela dit, il n’ya rien de mal avec un modèle mixte dans lequel vous utilisez l’un des schémas allant en C, ou Python ou Lua ou JavaScript comme langage de script.

Ce que vous voulez, c’est la possibilité d’aller rapidement et facilement en C quand il le faut.

Si vous convaincez l’équipe d’agir avec quelque chose qui n’a pas fait ses preuves, le projet est votre cookie. Si elle s'effrite, cela sera probablement considéré comme votre faute.

Cet article (de Michael Barr) parle de l’utilisation de C, C ++, de l’assembleur et d’autres langages dans les systèmes embarqués, et comprend un graphique illustrant l’utilisation relative de chacun.

Et voici un autre article, intitulé à juste titre, Mauvaises raisons de rejeter C ++ .

Il existe des situations dans lesquelles vous avez besoin de performances en temps réel, en particulier dans les systèmes embarqués. Vous avez également des contraintes de mémoire sévères. Un langage comme le C vous permet de mieux contrôler le temps et l’espace d’exécution.

Donc, selon ce que vous faites, C peut très bien être "meilleur" ou plus approprié.

Découvrez les articles suivants

Ada est un langage de programmation de haut niveau conçu pour les systèmes embarqués et les systèmes stratégiques.

C’est un langage rapide et sécurisé qui intègre la vérification des données partout. C’est ce que sont programmés les pilotes automatiques dans les avions.

sur ce lien une comparaison entre Ada et C.

Vous pouvez également consulter le langage de programmation D . Il pourrait utiliser certains réglages de performances, car Python peut surpasser certains domaines. Je ne peux pas vraiment vous indiquer de comparaison comparative car vous n’avez pas gardé de liste, mais comme Peter Olsson l’a souligné, Benchmarks & amp; Les implémentations linguistiques ont D Mars numérique.

Vous voudrez probablement également examiner ces belles questions:

C est omniprésent, disponible pour presque toutes les architectures, généralement dès le premier jour de la disponibilité du processeur. C ++ est une seconde proche. Si votre système peut prendre en charge C ++ et que vous disposez de l’expertise nécessaire, utilisez-le plutôt que C, c’est tout ce que C est et bien d’autres, c’est pourquoi il ya peu de raisons de ne pas l’utiliser.

C ++ est un langage plus vaste, et certaines constructions et techniques prises en charge peuvent consommer des ressources ou se comporter de manière inacceptable dans un système intégré, mais ce n'est pas une raison pour ne pas utiliser le langage, mais plutôt comment l'utiliser de manière appropriée.

Java et C # (sur Micro.Net ou WinCE) peuvent constituer des alternatives viables en temps non réel.

Je ne suis pas vraiment un programmeur systèmes / embarqué, mais il me semble que les programmes embarqués ont généralement besoin de performances déterministes - ce qui exclut immédiatement de nombreux langages ramassés, car ils ne sont pas déterministes en général. . Toutefois, des travaux ont été menés sur la collecte de déchets déterministe (par exemple, Metronome for Java: http://www.ibm.com/developerworks/java/library/j-rtj4/index.html )

Le problème est lié à des contraintes: les langages / exécutions répondent-ils aux exigences déterministes, d’utilisation de la mémoire, etc.

C est vraiment votre meilleur choix.

Il y a une différence entre écrire du code C portable et entrer trop profondément dans le ghee whiz des fonctionnalités d'un compilateur spécifique ou des cas particuliers du langage (ce qui devrait être évité). Mais la portabilité entre les compilateurs et les versions de compilateur. Le nombre d'employés qui seront capables de développer ou de maintenir le code. Les compilateurs auront plus de facilité avec cela et produiront un code meilleur, plus propre et plus fiable.

C ne va nulle part, avec toutes les nouvelles langues conçues pour corriger les défauts de toutes les langues précédentes. C, avec toutes les failles que ces nouvelles langues tentent de corriger, reste solide.

Voici quelques articles qui comparent C # à C ++:

http://systematicgaming.wordpress.com/ 2009/01/03 / performance-c-vs-c /

http: //journal.stuffwithstuff. com / 2009/01/03 / debunking-c-vs-c-performance /

Ce n’est pas exactement ce que vous avez demandé, car il n’est pas axé sur la programmation C intégrée. Mais c'est quand même intéressant. Le premier illustre les performances du C ++ et les avantages de l’utilisation de "unsafe" " code pour les tâches intensives du processeur. Le second déballe quelque peu le premier et montre que si vous écrivez le code C # un peu différemment, les performances sont quasiment identiques.

Je dirai donc que C ou C ++ peut être le grand gagnant en termes de performances dans de nombreux cas. Mais souvent, la marge est mince. Utiliser C ou non est un autre sujet. À mon avis, cela devrait dépendre de la tâche à accomplir. Mais dans les systèmes embarqués, vous n'avez souvent pas beaucoup de choix.

Quelques personnes ont mentionné Lua. Les personnes que je connais qui ont travaillé avec des systèmes embarqués ont déclaré que Lua était utile, mais que ce n'était pas vraiment son propre langage, mais plutôt une bibliothèque pouvant être incorporée en C. appeler le code Lua depuis C. Mais le pur C permet une maintenance plus simple (bien que pas nécessairement plus facile), puisque tout le monde le sait.

En fonction de la plate-forme intégrée, en cas de problème de mémoire, vous devrez probablement utiliser un langage de programmation non corrompu.

C à cet égard est probablement le plus connu de l’équipe et le plus largement pris en charge avec les bibliothèques et les outils disponibles.

La vérité est - pas toujours.

Il semble que le runtime .NET (mais tout autre runtime peut être pris comme exemple) impose plusieurs Mo au temps d’exécution. Si c'est tout ce que vous avez (en RAM), alors vous n'avez pas de chance. JavaME semble plus compact, mais tout dépend des ressources dont vous disposez.

Les compilateurs C sont beaucoup plus rapides, même sur les systèmes de bureau, en raison du nombre peu élevé de fonctions de langage comparées au C ++. J'imagine donc que la différence n'est pas triviale sur les systèmes embarqués. Cela se traduit par des temps d’itération plus rapides, bien qu’OTTOH ne vous permette pas de bénéficier des fonctionnalités de C ++ (telles que les collections), ce qui peut vous ralentir à long terme.

Licencié sous: CC-BY-SA avec attribution
Non affilié à StackOverflow
scroll top