Est-il courant de prototyper dans un langage de niveau supérieur? [fermé]

18

Je suis en train de jouer avec l'idée de me lancer dans un projet qui dépasse de loin mes capacités de programmation actuelles dans un langage dans lequel j'ai très peu d'expérience du monde réel en (C). Serait-il utile de créer un prototype dans un langage de niveau supérieur que je connais mieux (comme Perl / Python / Ruby / C #) pour que je puisse lancer la conception globale?

En fin de compte, le produit final est sensible aux performances (c'est un moteur de base de données), d'où le choix de C, mais je crains de ne pas bien connaître C me fera perdre la forêt pour les arbres.

En cherchant des questions similaires, j'ai remarqué un collègue mentionner que les programmeurs avaient l'habitude de prototyper dans Prolog, puis de le lancer dans l'assembleur.

Mark Canlas
la source
4
J'ai entendu parler de gens qui écriraient l'assembleur en codant d'abord ce qu'ils voulaient en C, puis en le désassemblant et en ajustant manuellement l'assemblage résultant.
user16764
9
N'oubliez pas que le plus souvent, les performances se résument à la sélection et à la mise en œuvre d'algorithmes corrects, à l'écriture de code parallèle pour des problèmes parallèles embarrassants et à de bonnes représentations des données. Ne vous inquiétez pas pour C jusqu'à ce que vous obteniez le bon design.
Peter Smith
1
@ user16764: A fait ça. Sauf que la langue était le Fortran. Mais nous avons modifié à la main la sortie du compilateur exactement comme vous le décrivez.
S.Lott
C n'est pas nécessairement plus rapide. Surtout si les performances sont liées aux E / S. Même pour les performances liées au processeur, si vous n'êtes pas un expert C, une machine virtuelle optimisée peut probablement surpasser tout ce que vous écrivez vous-même.
jiggy
J'utilise souvent cette technique de prototypage: un problème s'exprime dans son langage le plus naturel, qui finit par être implémenté en DSL. Ensuite, lorsque le prototype est terminé, au lieu de recoder une partie DSL dans un langage de niveau inférieur, j'améliore l'implémentation de ce compilateur DSL, jusqu'à ce que les performances soient acceptables.
SK-logic

Réponses:

27

L'utilisation de C ne rend pas automatiquement votre application plus rapide. Lorsque vous avez la possibilité de choisir un langage de programmation différent pour votre plate-forme, je le recommande vivement.

Comme Bill Harlan l'a déclaré :

Il est plus facile d'optimiser le code correct que de corriger le code optimisé . L'optimisation prématurée entrave réellement l'optimisation à long terme. Une optimisation inutile déforme les conceptions, détruit la modularité et la dissimulation d'informations et rend le code beaucoup plus difficile à modifier. Les bogues latents prennent plus de temps à trouver. Nous découvrons souvent par profilage, ou en changeant de machines ou de compilateurs, que nous avons mal évalué l'effort de calcul de notre code. Devine quoi? Maintenant, l'optimisation est beaucoup plus difficile qu'elle ne devait l'être.

Si vous pouvez vraiment prédire les problèmes de performances, envisagez d'utiliser C ++. cprogramming.com le dit très bien :

On peut se demander, cependant, si cela vaut la peine d' abandonner la réutilisabilité de C ++ pour obtenir la faible augmentation des performances avec C, en particulier lorsque C ++ peut, le cas échéant, être écrit dans un style de programmation C .


Pour mieux répondre à votre question réelle: j'écrirais du code dans un langage de niveau supérieur, pas seulement un prototype, et j'optimiserais uniquement dans des langages de niveau inférieur lorsque vous rencontrez des problèmes de performances.

Steven Jeuris
la source
25
+1: En outre, Perl, Python et Ruby peuvent appeler des fonctions C, vous pouvez donc écrire les parties sensibles aux performances en C si nécessaire.
Larry Coleman
J'ai prototypé du code de vision industrielle en Java; ce qui s'est avéré en fait assez rapide. Le recodage en C aurait été assez facile (vous l'écrivez simplement comme C; en utilisant l'
anti-motif de
J'ai écrit du code en temps réel en Java. Dans ce projet particulier, l'accès aux fichiers a été fait avec C ++, et le code en temps réel était en Java - fou! Cependant, le code en temps réel était incroyablement rapide. Ce n'était pas très compliqué, mais il a traité des quantités incroyables de données en un rien de temps. Je dirais donc que vous pouvez certainement utiliser des langages de haut niveau pour les applications sensibles aux performances.
configurateur
@ Tim Williscroft: Il me semble que cette page ne s'affiche que lorsque je recherche "anti-motif de fixation primitive". Qu'est-ce que c'est?
SingleNegationElimination
@TokenMacGuy: l'obsession primitive a plus de hits (même contre-modèle)
Tim Williscroft
7

Il ne serait pas utile de le faire, car a) les parties de ces langages qui traduisent directement en C ne seraient pas plus simples, et b) les parties qui ne traduisent pas directement en C seraient plus difficiles à réécrire en C que si vous les aviez écrites en C en premier lieu.

user16764
la source
+1 - D'autant plus qu'il serait difficile de déplacer le code OO en C si vous n'êtes pas familier avec le langage, ou que l'utilisation du langage de haut niveau serait plus gênante si vous écrivez de manière procédurale.
Jetti
Oui, exactement. Je crains de penser encore à des concepts supérieurs qui ne sont pas facilement traduits en C, comme si j'utilise trop de magie ou de sucre.
Mark Canlas
4

Ce n'est pas une question avec une réponse catégorique oui ou non. Permettez-moi de revenir sur une anecdote.

Exemple 1

J'ai été chargé de porter un jeu écrit en Java dans Flash, AS3. En surface, cela peut se dérouler de manière relativement fluide. Après tout, vous pourriez considérer qu'un tel travail est plus clair que votre travail client moyen, car vous avez déjà une spécification fonctionnelle entièrement construite sous la forme du jeu source. Java et AS 3 sont tous deux des langages de haut niveau, et AS3 partage de nombreux traits communs avec Java, tels que les structures de packages, l'héritage unique / les interfaces multiples, le typage fort (opt-in) et les notions de variable publique / protégée / privée et déclarations de fonctions. À l'époque, j'étais encore très vert à Java et complètement nouveau dans la base de code source d'origine. J'ai donc plongé pour voir ce que je pouvais trouver en espérant que ce serait rapide et facile.

Il s'est avéré que l'auteur du code avait tenté de créer un moteur abstrait qui pourrait être porté loin de Java dans un autre environnement non défini. Cela m'a donné l'espoir qu'il serait simple de mettre en communication. Malheureusement, ce que j'ai découvert à la place, c'est que j'envisageais la possibilité de réinventer Flash lui-même au-dessus de Flash, sans l'avantage de Threads. Il s'est avéré qu'un port littéral aurait simplement été une mauvaise idée ... un cauchemar de performance. En plus de cela, le jeu a implémenté son propre langage de script externe personnalisé, ce qui aurait signifié la création d'un analyseur et d'un lexeur pour cette langue si j'espérais utiliser tous les fichiers de données source d'origine.

En fin de compte, compte tenu des contraintes de temps et de budget, le code source d'origine n'a pas vraiment aidé beaucoup. La partie la plus utile pour l'avoir était que je savais comment imiter avec précision le flux de contrôle de la logique du jeu ... mais avais-je vraiment besoin de la source d'origine pour cela? Probablement pas.

Mais cet exemple n'est peut-être pas aussi pertinent car c'est en quelque sorte l'inverse de votre situation. J'espérais utiliser une base de code que je n'avais pas écrite, dans un langage que je ne connaissais pas à l'époque pour accélérer le développement dans un environnement que je connaissais très bien. Voici donc un exemple différent

Exemple 2

Notant ce que le développeur Java faisait en essayant de créer une base de code portable, je me suis mis à faire quelque chose de similaire pour moi dans mon travail Flash ... écrire du code qui ne reposait pas tellement sur l'extension des classes flash.display. * Par exemple, et utiliser la composition pour créer des vues. Ne pas trop compter sur flash.event. * Et plutôt écrire un système de transmission de messages léger, qui n'est pas lié en particulier à une langue ou à une plate-forme. J'ai récemment terminé un jeu en utilisant ledit framework et je voulais voir s'il serait facile de le porter en C # (un langage que je connais dans la mesure où il est similaire à Java et AS3) en tant que projet Unity 3D. En fait, cela a été beaucoup plus réussi! Parce que je pense plus couramment en AS3 qu'en C #, avoir les algorithmes déjà écrits a sauvé une tonne de temps. Tout ce que j'avais à faire était simplement de changer la syntaxe, ce qui n'est pas

Donc, juste dans ma propre expérience personnelle, je ne peux pas dire que la réponse sera toujours oui ou non. Vous devez prendre en compte à quel point vous dépendez d'idiomes linguistiques particuliers dans la langue de votre choix, et si les recréer sera facile ou difficile en C.

scriptocalypse
la source
Votre deuxième histoire illustre ce que je ressens. J'essaierais de garder l'implémentation du prototype générique et libre de magie / tromperie, de sorte que la plupart, sinon toutes les idées, puissent être traduites en C. Plus facile à dire qu'à faire, mais je pense qu'à un niveau suffisamment élevé, cela porte toujours. Évidemment, le diable est dans les détails.
Mark Canlas
@Mark Canlas "le diable est dans les détails". Absolument. Je pense qu'il est possible que votre première tentative tourne mal si vous n'avez jamais porté de code entre des langages ou des environnements auparavant simplement parce qu'il est difficile de prévoir tous les problèmes potentiels jusqu'à ce que vous les ayez rencontrés.
scriptocalypse
2

Je pense qu'il serait utile de commencer par le pseudocode. Écrire un prototype dans une autre langue semble être une perte de temps potentielle, car votre langage de niveau supérieur ne se traduira probablement pas aussi bien par un «C» que par un pseudocode.

De plus, en utilisant le pseudocode, vous développerez une meilleure compréhension du fonctionnement réel de votre système.

Pendant la même période que vous travaillez sur le pseudocode, vous devriez étudier C. Ensuite, au moment où vous avez terminé votre planification, vous pourriez être prêt à réellement mettre en œuvre la chose.

Étant donné que la raison que vous avez proposée pour l'écrire dans une autre langue était d'aider à faire avancer la conception, vous pouvez plutôt utiliser des diagrammes UML ou quelque chose de ce genre pour vous aider à démarrer.

Casey Patton
la source
2

Vous pouvez prototyper l'algorithme - aplanir les erreurs de conception de la logique de base, en utilisant définitivement un langage de "très haut niveau" (disons Matlab, peut-être Ruby). Utilisez-le pour prouver que votre algorithme fonctionne et fonctionne correctement, puis implémentez-le à partir de zéro dans un langage "bas niveau".

Vous ne gagnerez pas grand-chose si vous choisissez C ++ ou même Java ou C # comme "haut niveau" et C comme "bas niveau" car le gain en lisibilité ne sera pas significatif et la "traduction" sera toujours assez douloureuse et assez bug- enclin. L'idée est l'essence, le moteur de votre projet dans une mise en œuvre de haut niveau ne doit pas occuper plus d'un écran ou deux, être facile à saisir, facile à lire et toutes les mises en garde doivent être douloureusement évidentes - essentiellement, un bloc fonctionnel et exécutable diagramme.

SF.
la source
2

Un moteur de base de données consiste principalement à gérer les E / S de bas niveau de manière optimale et à gérer efficacement les structures complexes telles que l'arborescence b et les listes liées.

Donc, c'est définitivement un problème C / C ++, bien qu'il existe de très bonnes implémentations Java.

Développer des algorithmes corrects qui fonctionnent bien est beaucoup plus facile dans un langage de niveau supérieur. Il s'agit généralement d'essayer plusieurs variantes et de comparer les résultats. Vous pouvez ensuite traduire l'algorithme "gagnant" en C.

Une solution de compromis pourrait être d'écrire l'implémentation initiale dans l'un des langages JVM de niveau supérieur (Jython, Groovy me vient à l'esprit), puis de déplacer classe par classe vers Java lorsque l'implémentation se stabilise.

James Anderson
la source
2

Je ne pense pas que ce soit commun, mais c'est fait. L'un des architectes les plus pointus avec qui j'ai jamais travaillé avait l'habitude de faire sa modélisation en Python puis d'implémenter ce code en C ++.

En général, pour que cela en vaille la peine, je pense que vous devez vraiment exécuter des algorithmes complexes et hautement optimisables qui ne sont pas facilement exprimés de manière simple dans la langue cible. Pour la plupart des situations «monde réel / entreprise», il est relativement facile d'exprimer l'intention de haut niveau dans le même langage que nous ciblons, et une implémentation dans ce langage répond à nos exigences de performance, il n'y a donc pas besoin / désir de modéliser dans un niveau supérieur langue de niveau.

Compte tenu de votre situation, où vous avez une meilleure connaissance d'une langue de niveau supérieur, j'ai pu voir cette méthodologie bien fonctionner à court terme. Non seulement il vous fournira une feuille de route pour garder les choses sur la bonne voie, mais si vous avez des questions, vous pourrez les poser avec plus de précision.

user29776
la source
1

Actuellement, je travaille sur un projet qui est écrit en C "à cause des performances" (c'était la motivation d'origine), mais en effet s'il est profilé, il révèle qu'il passe la plupart de son temps à attendre d'autres systèmes (une base de données, d'autres applications écrites en Java, "événements" sur un socket).

Si vous utilisez le mauvais algorithme, vous obtenez également de mauvaises performances en C (par exemple, si vous effectuez une recherche linéaire pour une clé, "puisque C n'a pas de tables de hachage et que nous ne voulons pas utiliser d'autres bibliothèques", vous allez plus lentement que si vous faites-le avec un langage qui a des tables de hachage ou similaire comme C ++, Java, C #, Python ... et ainsi de suite).

Si vous êtes obligé de le faire en C pour une raison quelconque, alors le prototypage dans un autre langage que vous connaissez n'est pas une si mauvaise idée que si vous prototypez en sachant quels "problèmes" vous aurez à faire l'implémentation C réelle, c'est difficile si vous n'êtes pas confiant avec C. (Vous découvrirez bientôt par exemple que les bibliothèques std C / C n'ont pas de conteneurs, juste un tableau "ordinaire"; vous avez besoin de bibliothèques non std). De plus, C n'est pas OO, donc si vous prototypez de façon OO, ce sera plus difficile.

En résumé, la meilleure chose à faire est de faire l'implémentation réelle dans votre langage de "prototypage", puis, si vraiment nécessaire, d'écrire des fonctions gourmandes en CPU en C, mais si seul C est acceptable, apprenez-le mieux avant de faire un prototype dans d'autres langues et bien sûr avant d'écrire l'implémentation.

ShinTakezou
la source
1

Il existe de nombreuses applications essentielles aux performances écrites dans un langage de niveau supérieur.

J'ai programmé dans Assembler et C dans le passé, et même si c'est un peu cool de se sentir si proche du métal, leur utilisation est très limitée de nos jours.

Il y a tellement de choses qui entravent les performances, que je doute que vous atteindrez jamais la partie où la langue elle-même est le facteur limitant. Cela considère qu'il s'agit de C vs C #.

Supposons que vous obtenez une augmentation de 10 à 15% des performances de la langue. Ce n'est rien comparé à l'augmentation de l'ordre de grandeur de la mise en œuvre du bon algorithme.

Lorsque vous programmez en C #, vous aurez beaucoup plus de temps pour vous concentrer sur l'architecture et la mise en œuvre d'algorithmes / structures de données conduisant ainsi à de meilleures optimisations de plus haut niveau.

Dans le monde réel, vous êtes toujours limité dans le temps, alors passez votre temps sur la bonne partie du projet.

Boris Yankov
la source
0

Je suis curieux de savoir quel est votre plan pour le créer en C? Allez-vous créer un prototype, puis apprendre le C, puis le recoder en C? Pour moi, cela ressemble un peu aux proverbiales "les yeux étant plus gros que l'estomac" dans lesquels je pense que beaucoup de programmeurs se font prendre tout en apprenant les nouvelles technologies (je sais que je l'ai). Ce que je veux dire, c'est que vous essayez de concevoir quelque chose qui est clairement sensible aux performances sans même connaître les tenants et aboutissants du langage dans lequel vous pensez qu'il devra éventuellement être écrit, fondamentalement, vous voulez déjà commencer à concevoir une application C avant vous sachez C quand il est préférable de passer du temps à apprendre le C, puis vous pourrez mieux comprendre comment écrire l'application que vous souhaitez. Peut-être que je me suis trompé la question et vous avez l'intention de remettre cela à un autre programmeur pour construire le programme en C,

programmx10
la source
Parfois "ne fais pas ça." est la bonne réponse à "Comment faire X?"
Larry Coleman
0

Le prototypage est parfois effectué pour mieux comprendre le problème que vous essayez de résoudre. Et parfois, pour connaître les technologies sous-jacentes si vous ne les connaissez pas déjà.

Pour le cas mentionné, vous envisagez de créer un prototype dans un langage de script, par exemple, python et de créer le code réel en C.

Évaluer certaines possibilités:

1 . Vous prototypez en python et écrivez le logiciel en C.

Le prototypage dans un langage de script peut vous aider à vérifier rapidement la sortie par rapport à l'entrée . Ceci est utile si vous devez principalement tester votre logique pour résoudre un problème. Aussi, utile si vous souhaitez créer rapidement une démo pour d'autres personnes.

Le code que vous avez écrit en python ne sera pas utilisé dans le logiciel final. Mais, cela peut être utile si vous transmettez votre prototype à quelqu'un qui peut lire python et écrire en C. Ici, le prototypage peut aider à communiquer une idée .

Cette méthode est appropriée pour tester la faisabilité logique de la solution.

2 . Vous prototypez en C et écrivez le logiciel en C.

Le prototypage en C, nouveau pour vous, présente deux avantages. Un, pendant que vous écrivez le prototype, vous apprenez à comprendre les parties pertinentes du langage , de la bibliothèque, de l'API, des pièges, etc. Deux, pendant que vous construisez le logiciel final, vous pouvez commencer à partir du prototype lui-même, ce qui vous fait gagner du temps et réutilise le code .

Cette méthode convient pour tester à la fois la faisabilité logique et technologique de la solution.

3 . Vous pouvez envisager des méthodes non codantes de prototypage en fonction du problème rencontré.

Si c'est un morceau de logique et d'idées que vous voulez prototyper; le pseudo-code , les organigrammes et les diagrammes sur papier sont également bons.

S'il s'agit d'un prototype d'interface utilisateur, envisagez un outil de maquette d'interface utilisateur ou encore du papier.

Amol
la source
0

Je pense que vous devriez prototyper dans un langage que vous connaissez (Pytho / Ruby / C # quoi pas) pour que:

  1. Vous tirez le meilleur parti des installations / bibliothèques fournies par la langue.
  2. Vous passez votre temps à décider des choix de conception plutôt que des limitations linguistiques.

Plus tard, vous pouvez utiliser un outil de profilage pour trouver des zones de col de bouteille. Réimplémenter en C / C ++. Répétez l'étape ci-dessus plusieurs fois, qui sait que votre prototype pourrait être «assez rapide»!

KGA
la source
0

Je ne pense pas que vous gagniez quoi que ce soit par l'approche que vous avez décrite, et plusieurs personnes ont expliqué pourquoi en détail.

Un projet auquel j'ai participé a utilisé ce type d'approche: le développement d'une bibliothèque mathématique pour les architectures Cell / BE et Power7. Les fonctions ont été modélisées dans Haskell (en utilisant CoCoNUT), et les fonctions de sortie étaient en assemblage optimisé pour une architecture cible particulière.

Dans ce cas, les objectifs étaient des performances élevées avec des instructions d'assemblage optimisées et la possibilité de cibler plusieurs architectures.

Pour la nourriture, j'espère que vous ne mourrez pas de faim :)

Stephen
la source
0

Pour un moteur de base de données hautes performances, vous aurez probablement besoin de:

  • multi-threading,
  • gestion explicite de la mémoire,
  • notifications asynchrones,
  • sémaphores ou primitives de synchronisation,
  • accès facile aux fonctions du système de fichiers de bas niveau.

Les algorithmes que vous choisissez sont essentiels aux performances.

Le conseil général est de commencer par un langage de haut niveau, puis de migrer uniquement les bits qui doivent être optimisés dans un langage de niveau inférieur.

pourtant , le langage de haut niveau que vous choisissez doit être en mesure de prendre en charge les algorithmes dont vous avez besoin pour écrire: et les algorithmes efficaces ici peuvent finalement être dominés par le contrôle du threading, l'utilisation efficace de la mémoire et l'utilisation des meilleures opérations de systèmes de fichiers de bas niveau disponible. Donc, si l'objectif final est la performance, vous ne pouvez pas créer de prototype dans des langages qui ne prennent pas en charge les primitives que vous devez utiliser.

Si vous devez tester votre prototype (ou que d'autres personnes doivent développer un logiciel par rapport à ses interfaces), vous devez également travailler dans un langage prenant en charge les API prévues. Vous pouvez ensuite autoriser d'autres personnes à tester leur code et effectuer vos propres tests de régression tout en optimisant.

Ces considérations excluent probablement de nombreux langages de prototypage de haut niveau dans ce cas - et probablement tous ceux que vous avez mentionnés (sauf éventuellement C #). Mais vous pouvez, bien sûr, pseudo-code dans n'importe quelle langue (y compris l'anglais) et, si nécessaire, vous pouvez prototyper des parties du projet (fonctions de tri, par exemple) dans votre langue préférée.

La relation étroite entre C ++ et C (et les différences de performances négligeables) signifient qu'il y a très peu de raisons de ne pas préférer C ++ à C dans le produit final.

(Je réponds en supposant que vous avez besoin d'un moteur de base de données hautes performances dans un but particulier: si vos intentions sont plus modestes, vous devriez probablement prendre un moteur existant sur étagère).

MZB
la source
-2

Je pense que la renommée de C est bien méritée, car le magnifique produit Unix a été écrit en C. Cependant, par rapport aux personnes qui connaissent le mieux C, je suis assez sceptique quant à la raison pour laquelle il devrait être utilisé. On dit que Ken Thompson (après avoir écrit une première version d'Unix en langage assembleur) a commencé à écrire Unix dans Fortran, mais a abandonné après une semaine ou un mois, et a commencé à utiliser C qui était développé par son collègue Ken Ritchie à le même temps.

J'ai été stupéfait de lire récemment que Fortran est plus rapide que C et C ++.

Richard Mullins

richard mullinsq
la source
1
comment cela répond-il à la question posée?
moucher