Non, c'est dans l'ordre de grandeur de ce qui existe déjà. Le problème est d'être sûr de pouvoir faire 17 mesure toutes les ms. C'est parfois très lent de changer de ligne, par exemple.
Par exemple, pour un seul moteur, il faut mesurer le courant, il faudrait mesurer la tension en entré, mesurer la position du moteur (pour un servomoteur) ou sa vitesse de rotation (pour un truc qui roule), et mesurer la position de l’élément mécanique (roue libre pour un déplacement, position d'un bras) pour mesurer les contraintes mécaniques (glissement, jeu,…). Ensuite, il faut 3 PWM pour un moteur synchrones.
C'est seulement pour un moteur. On peut ensuite ajouter des choses comme des télémètres, des capteurs de couleurs, une central inertiels, …. Il existe des blocs tout fait, mais cela serait bien plus compact et moins couteux d'interfacer la partie analogique directement avec le SoC.
Disons qu'en retro action mécanique, 10 ms est une réactivité basse, 4 ms est assez rapide, et 1 ms gère tous les cas.
Pour la vitesse, on a ce total de 1 ms max, mais ça ne concerne peut-être pas toutes les E/S, il y en a probablement qui ne demanderaient pas à être actualisées à chaque cycle.
Si, tous, c'est bien trop compliqué sinon. Imagine une machine synchrone qui commande un robot humanoïde.
De mémoire, NAO a 25 moteurs. Il est pseudo statique, mais si tu avais besoin de faire l'équilibre du robot, il faudrait une rétro action complète de sa position. Tu as donc besoin de connaitre la position réels des articulations (genre un potentiometre avec un ADC derrière), plus une mesure du courant du moteur pour avoir une idée de la force déployée, une mesure de la vitesse de rotation du moteur ou de sa position (le but est de tenir compte du jeu de l'articulation), puis 3 PWM si tu as un moteur synchrone.
Donc ton programme pour gérer ce genre de chose, tourne entre 100 et 1000Hz, prend en entré tous les capteurs, et calcule ensuite toutes les sorties. Tu peux faire un peu de masquage de latence, avec la lecture au temps n, le calcul des données n-1, et l'écriture des données n-2. Mais dans ce cas, le cpu doit être libre.
Je ne sais pas s'il y a d'autres raisons pour ce choix que le fait du confort et de l'habitude de développer sur une plateforme riche et familière. Ces raisons sont parfaitement compréhensibles mais dans le cas présent, il est possible qu'elles conduisent à une impasse (en l'état des composants et des cartes toutes faites sur le marché).
Il y a des solutions ou un gros µP est maitre, et un PC est esclave. Mais cela reste une architecture un poil compliqué. Un truc sous Linux permet d'avoir le réseau (wifi ou filaire) qui permet de bien connaitre l'état interne du robot. Avec un simple µP, il faut + moins tout écrire : gestion de l'extraction des données vers un hote, affichage, etc… C'est quasi impossible d'avoir des logs à cause de la mémoire trop faible.
Un µP ne permet pas non plus de faire de la cartographie à cause de la taille de la RAM, ou du traitement d'images même léger. On peut aussi imaginer l'usage du Bluetooth.
Quand tu en a codé 1 (ou recopié le code dispo ailleurs), que tu en instancies 2 ou 100, c'est le même travail.
Il y a tout le décodage à faire proprement et être sur que cela rentre. 100 compteurs 16 bits, cela n'est pas petit.
À partir de là, la solution est d'associer les 2, mais tu n'aimes pas.
Il y a beaucoup de raisons à cela : lenteur des communications entre les 2. Mon but est de lire tous les capteurs puis tout écrire pendant un cycle. Un cycle dure entre 1 à 10 ms maximum (retroaction). Et pendant ce temps là le cpu doit être libre, ou presque pour faire des calculs (il existe des ADC sous I2C qui demande beaucoup de temps cpu pour du pulling).
Ensuite, si tu as un lien rapide entre les 2, cela sacrifie beaucoup d'IO, donc cela veut dire des gros package couteux. Lier un µP et µcontroller demande aussi de coder le µcontroller sans quasiement d'aide au debug, c'est bien plus long et complexe que sous un Linux, par exemple.
Après si le boulot difficile est fait par le producteur de la carte pourquoi pas. Mais il faudra montrer que le driver Linux qui permet d’accéder au ADC ou au PWM d'un µcontrolleur à bien 1 ms de latence max, ou plus exactement que toutes les IO peuvent être lu/écrite en moins de 10 ms, sans prendre plus de 10% de cpu.
Tu cherches quelque chose qui (pour ce que j'en connais) n'existe pas ou presque :
puissant comme un SoC pour faire tourner un Linux ;
des E/S analogiques d'un µC ;
un grand nombre d'E/S ;
monolythique.
Les cortexM tourne à 70-100Mhz, j'ai commencé la robotique sous linux avec des Pentium 75. Il faudrait juste utiliser une plateforme de µC et y mettre un Cortex A7 ou lieu d'un M.
les Vybrid VF6xx de Freescale que l'on trouve par exemple sur la carte Cosmic + de Phytec
Il y a 2 ADC sur 4 lignes, c'est très peu. Je n'ai pas vu de PWM. Mais l'idée est là.
J'avais déjà regardé à l'époque et rien n'a changé. Dans ma description, je décris un moyen simple et pas chère de faire de la robotique issue de 10 ans de coupe e=m6 (ou presque) et une formation en ingénieur microélectronique. Et la carte que tu pointes ne répond pas du tout, à ce dont je parles.
Pas de CAN/ADC veut simplement dire pas d'entrée ! C'est ballot pour un robot ! Oui, tu peux rajouter une paquet de merde utilisant des I2C ou des UART, mais jamais tu pourras mettre des dizaines d'entrée lisible en quelques millisecondes sans pomper tout le cpu disponible.
Donc, toutes "IOS" dédié I2C, USB, UART, je m'en fiche complètement. Cela ne répond pas du tout à ce dont je parle au dessus. Tu devrais aussi mieux lire les demandes.
Pour les entrées, tu as bien une centaine d'IO du FPGA en 3.3V, ok. Il ne reste plus qu'à coder la centaine de PWM qui va avec, ce n'est pas le plus simple à faire !
Le bus interne 16 bit pour parler au FPGA semble assez rapide.
Par contre, attention, ça reste un module (auquel tu peux ajouter une carte de dév), pas quelque chose d'immédiatement prêt à l'emploi comme un SBC ou beaucoup de cartes µC.
Regarde des trucs genre intellij ou eclipse, tout en java, pas franchement lent (mais oui, ca met beaucoup de temps a demarrer).
Justement, je code un client RCP, et "rapide" est pas franchement le 1er qualificatif qui me vient à l'esprit.On a pu faire la comparaison de consommation mémoire entre 2 outils, l'un basé sur eclipse, l'autre maison en c++, pour la même quantité d'objet, il y a un facteur 10.
Tu fais du Zenitram. Regardes comment fonctionne openssl ou gpg pour encoder un fichier en AES, et arrêtes de te ridiculiser. PBKDF2 n'est (n'était ?) pas un choix.
Par contre ça n'a sans doute rien à voir avec une quelconque facilitation de brute-force de mots de passe.
Indirectement si. Le 2ième était très bon en soft, mais gros (pas lent) en hardware. Donc, mettre plein d'accélérateur de calcul de hash, aurait pris bien plus de place sur une puce, que pour l'algorithme choisi. Cela complique beaucoup la vie de ceux qui casse des mots de passe avec des paquets de FPGA.
En même temps casser un fichier AES ayant un mot de passe peut être rapide avec des trucs comme hashcat (~1Gkey/s).
Donc, si tu planques des trucs derrière AES contre la NSA, il faut au moins 100 bits d'entropie, cela fait 8 mots du dictionnaires, rare pour un mot de passe…
Il suffit de voir les critères pour l'attribution de sha3, un des algo finaliste a été écarté car il était trop lent en hardware, contrairement à celui choisi.
mouais. Il n'y a pas tellement d'IO, pas de ADC. Et j'imagine que tu dois tout faire tout même (VHDL + drivers), ce qui n'est pas si simple. La connection ARM-FPGA est parfois pas top (pseudo lien série lent).
Je ne peux rien pour toi si tu n'as pas le temps ou pas d'intérêt pour comprendre et suivre les règles du projet auquel tu veux contribuer.
J'ai suivi un MOOC sur les interfaces, donc, j'ai une vision déformé des choses. Mais il n'a jamais été question de changer les règles, simplement de changer l'interface, pour la rendre plus agréable et efficace.
Utiliser des images sous copyright est complexe, mais le cas des logos est très courant dans ce cas complexe. Il est facile de mettre une exception générique pour mettre le logo pour l'objet en question.
Je crois que tu te trompes, la majorité des boites codent maintenant en Java. Je ne sais pas si c'est Java qui est lent ou l’empilement de couche, mais une application java est lente.
Ton problème finale de faux partage n'est rien par rapport au problème de l'écriture sur le registre qui écrase les valeurs autour.
Les champs de bits avec une union sur un registre, j'ai souvent vu ça sur des mini drivers de µcontroller, c'est facile, car le compilo est toujours le même pour une cible donné. Il suffit de regarder ce que génère le compilateur et s'adapter.
Sérieux, tu n'arrives pas à lire quelque chose comme:
J'ai fait un tout petit de R. Mais j'ai du mal à voir comment une fonction replicate() pourrait avoir une utilité sans un "truc qui bouge" dans le membre d'à coté. 1:10000 semble être une liste de nombre que l'on mélange avec des scalaires.
En gros, cela évite d'avoir des objets partout qui bouffent de la place, et tu colles ton entier directement à la place du pointeur. Cela permet aussi d'informer le GC qu'il lit un pointeur et non un entier. L'idée est que la mémoire contient un peu du type de donné réel.
En gros, les champs de bits en C ne garantissent rien du tout sur les champs réellement utilisés au final, si on regarde l'ensemble de la structure (le padding dépend du CPU et du compilo). Pour un driver par exemple, c'est un non sens, d'ou l'usage des macros.
Je n'ai jamais compris pourquoi les langages mélangeaient des informations de haut niveau comme le type de donné, les ranges, et leur implémentation en mémoire ( ce qui n'a rien à voir ou presque).
[^] # Re: embarqué ?
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche L’arrivée du BananaPi. Évalué à 3.
Non, c'est dans l'ordre de grandeur de ce qui existe déjà. Le problème est d'être sûr de pouvoir faire 17 mesure toutes les ms. C'est parfois très lent de changer de ligne, par exemple.
Par exemple, pour un seul moteur, il faut mesurer le courant, il faudrait mesurer la tension en entré, mesurer la position du moteur (pour un servomoteur) ou sa vitesse de rotation (pour un truc qui roule), et mesurer la position de l’élément mécanique (roue libre pour un déplacement, position d'un bras) pour mesurer les contraintes mécaniques (glissement, jeu,…). Ensuite, il faut 3 PWM pour un moteur synchrones.
C'est seulement pour un moteur. On peut ensuite ajouter des choses comme des télémètres, des capteurs de couleurs, une central inertiels, …. Il existe des blocs tout fait, mais cela serait bien plus compact et moins couteux d'interfacer la partie analogique directement avec le SoC.
"La première sécurité est la liberté"
[^] # Re: embarqué ?
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche L’arrivée du BananaPi. Évalué à 3.
Disons qu'en retro action mécanique, 10 ms est une réactivité basse, 4 ms est assez rapide, et 1 ms gère tous les cas.
Si, tous, c'est bien trop compliqué sinon. Imagine une machine synchrone qui commande un robot humanoïde.
De mémoire, NAO a 25 moteurs. Il est pseudo statique, mais si tu avais besoin de faire l'équilibre du robot, il faudrait une rétro action complète de sa position. Tu as donc besoin de connaitre la position réels des articulations (genre un potentiometre avec un ADC derrière), plus une mesure du courant du moteur pour avoir une idée de la force déployée, une mesure de la vitesse de rotation du moteur ou de sa position (le but est de tenir compte du jeu de l'articulation), puis 3 PWM si tu as un moteur synchrone.
Donc ton programme pour gérer ce genre de chose, tourne entre 100 et 1000Hz, prend en entré tous les capteurs, et calcule ensuite toutes les sorties. Tu peux faire un peu de masquage de latence, avec la lecture au temps n, le calcul des données n-1, et l'écriture des données n-2. Mais dans ce cas, le cpu doit être libre.
Il y a des solutions ou un gros µP est maitre, et un PC est esclave. Mais cela reste une architecture un poil compliqué. Un truc sous Linux permet d'avoir le réseau (wifi ou filaire) qui permet de bien connaitre l'état interne du robot. Avec un simple µP, il faut + moins tout écrire : gestion de l'extraction des données vers un hote, affichage, etc… C'est quasi impossible d'avoir des logs à cause de la mémoire trop faible.
Un µP ne permet pas non plus de faire de la cartographie à cause de la taille de la RAM, ou du traitement d'images même léger. On peut aussi imaginer l'usage du Bluetooth.
"La première sécurité est la liberté"
[^] # Re: embarqué ?
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche L’arrivée du BananaPi. Évalué à 3.
Il y a tout le décodage à faire proprement et être sur que cela rentre. 100 compteurs 16 bits, cela n'est pas petit.
Il y a beaucoup de raisons à cela : lenteur des communications entre les 2. Mon but est de lire tous les capteurs puis tout écrire pendant un cycle. Un cycle dure entre 1 à 10 ms maximum (retroaction). Et pendant ce temps là le cpu doit être libre, ou presque pour faire des calculs (il existe des ADC sous I2C qui demande beaucoup de temps cpu pour du pulling).
Ensuite, si tu as un lien rapide entre les 2, cela sacrifie beaucoup d'IO, donc cela veut dire des gros package couteux. Lier un µP et µcontroller demande aussi de coder le µcontroller sans quasiement d'aide au debug, c'est bien plus long et complexe que sous un Linux, par exemple.
Après si le boulot difficile est fait par le producteur de la carte pourquoi pas. Mais il faudra montrer que le driver Linux qui permet d’accéder au ADC ou au PWM d'un µcontrolleur à bien 1 ms de latence max, ou plus exactement que toutes les IO peuvent être lu/écrite en moins de 10 ms, sans prendre plus de 10% de cpu.
Les cortexM tourne à 70-100Mhz, j'ai commencé la robotique sous linux avec des Pentium 75. Il faudrait juste utiliser une plateforme de µC et y mettre un Cortex A7 ou lieu d'un M.
Il y a 2 ADC sur 4 lignes, c'est très peu. Je n'ai pas vu de PWM. Mais l'idée est là.
"La première sécurité est la liberté"
[^] # Re: embarqué ?
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche L’arrivée du BananaPi. Évalué à 5.
J'avais déjà regardé à l'époque et rien n'a changé. Dans ma description, je décris un moyen simple et pas chère de faire de la robotique issue de 10 ans de coupe e=m6 (ou presque) et une formation en ingénieur microélectronique. Et la carte que tu pointes ne répond pas du tout, à ce dont je parles.
Pas de CAN/ADC veut simplement dire pas d'entrée ! C'est ballot pour un robot ! Oui, tu peux rajouter une paquet de merde utilisant des I2C ou des UART, mais jamais tu pourras mettre des dizaines d'entrée lisible en quelques millisecondes sans pomper tout le cpu disponible.
Donc, toutes "IOS" dédié I2C, USB, UART, je m'en fiche complètement. Cela ne répond pas du tout à ce dont je parle au dessus. Tu devrais aussi mieux lire les demandes.
Pour les entrées, tu as bien une centaine d'IO du FPGA en 3.3V, ok. Il ne reste plus qu'à coder la centaine de PWM qui va avec, ce n'est pas le plus simple à faire !
Le bus interne 16 bit pour parler au FPGA semble assez rapide.
Tu remarques enfin ce que je cherche vraiment ?
"La première sécurité est la liberté"
[^] # Re: suckless !! More is less !
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Pourquoi un PC ralentit-il ?. Évalué à 2.
Tu as des sources pour accélérer le lancement d'IDE basé sur eclipse et leur paquet de plugin ?
"La première sécurité est la liberté"
[^] # Re: suckless !! More is less !
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Pourquoi un PC ralentit-il ?. Évalué à 2.
Justement, je code un client RCP, et "rapide" est pas franchement le 1er qualificatif qui me vient à l'esprit.On a pu faire la comparaison de consommation mémoire entre 2 outils, l'un basé sur eclipse, l'autre maison en c++, pour la même quantité d'objet, il y a un facteur 10.
"La première sécurité est la liberté"
[^] # Re: pas forcément
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Qu'un algo de chiffrement soit cassé, est-ce important pour nos PETITS secrets ?. Évalué à 6.
Tu fais du Zenitram. Regardes comment fonctionne openssl ou gpg pour encoder un fichier en AES, et arrêtes de te ridiculiser. PBKDF2 n'est (n'était ?) pas un choix.
"La première sécurité est la liberté"
[^] # Re: pas forcément
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Qu'un algo de chiffrement soit cassé, est-ce important pour nos PETITS secrets ?. Évalué à 2.
Indirectement si. Le 2ième était très bon en soft, mais gros (pas lent) en hardware. Donc, mettre plein d'accélérateur de calcul de hash, aurait pris bien plus de place sur une puce, que pour l'algorithme choisi. Cela complique beaucoup la vie de ceux qui casse des mots de passe avec des paquets de FPGA.
"La première sécurité est la liberté"
[^] # Re: pas forcément
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Qu'un algo de chiffrement soit cassé, est-ce important pour nos PETITS secrets ?. Évalué à 1.
Les clefs sont toujours hashé avant d'être utilisé. Cela détermine la vitesse du brute force.
"La première sécurité est la liberté"
[^] # Re: pas forcément
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Qu'un algo de chiffrement soit cassé, est-ce important pour nos PETITS secrets ?. Évalué à 0.
En même temps casser un fichier AES ayant un mot de passe peut être rapide avec des trucs comme hashcat (~1Gkey/s).
Donc, si tu planques des trucs derrière AES contre la NSA, il faut au moins 100 bits d'entropie, cela fait 8 mots du dictionnaires, rare pour un mot de passe…
Il suffit de voir les critères pour l'attribution de sha3, un des algo finaliste a été écarté car il était trop lent en hardware, contrairement à celui choisi.
"La première sécurité est la liberté"
[^] # Re: embarqué ?
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche L’arrivée du BananaPi. Évalué à 0.
mouais. Il n'y a pas tellement d'IO, pas de ADC. Et j'imagine que tu dois tout faire tout même (VHDL + drivers), ce qui n'est pas si simple. La connection ARM-FPGA est parfois pas top (pseudo lien série lent).
"La première sécurité est la liberté"
[^] # Re: Si, ce sont des images libres !
Posté par Nicolas Boulay (site web personnel) . En réponse au message logo dans wikipedia. Évalué à 2.
J'ai suivi un MOOC sur les interfaces, donc, j'ai une vision déformé des choses. Mais il n'a jamais été question de changer les règles, simplement de changer l'interface, pour la rendre plus agréable et efficace.
Utiliser des images sous copyright est complexe, mais le cas des logos est très courant dans ce cas complexe. Il est facile de mettre une exception générique pour mettre le logo pour l'objet en question.
"La première sécurité est la liberté"
[^] # Re: suckless !! More is less !
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Pourquoi un PC ralentit-il ?. Évalué à 4.
Je crois que tu te trompes, la majorité des boites codent maintenant en Java. Je ne sais pas si c'est Java qui est lent ou l’empilement de couche, mais une application java est lente.
"La première sécurité est la liberté"
[^] # Re: suckless !! More is less !
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Pourquoi un PC ralentit-il ?. Évalué à 2.
Ton problème finale de faux partage n'est rien par rapport au problème de l'écriture sur le registre qui écrase les valeurs autour.
Les champs de bits avec une union sur un registre, j'ai souvent vu ça sur des mini drivers de µcontroller, c'est facile, car le compilo est toujours le même pour une cible donné. Il suffit de regarder ce que génère le compilateur et s'adapter.
"La première sécurité est la liberté"
[^] # Re: Et les nouveaux langages de programmation...
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Pourquoi un PC ralentit-il ?. Évalué à 4.
Il me semble aussi que g++ instanciait une version du code à chaque appel et pas seulement par type. C'est assez récent comme changement.
"La première sécurité est la liberté"
[^] # Re: suckless !! More is less !
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Pourquoi un PC ralentit-il ?. Évalué à 3.
En général, les GC parcourent les zones mémoires à nettoyer avec assez peu d'information.
"La première sécurité est la liberté"
[^] # Re: suckless !! More is less !
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Pourquoi un PC ralentit-il ?. Évalué à 3.
J'ai fait un tout petit de R. Mais j'ai du mal à voir comment une fonction replicate() pourrait avoir une utilité sans un "truc qui bouge" dans le membre d'à coté. 1:10000 semble être une liste de nombre que l'on mélange avec des scalaires.
"La première sécurité est la liberté"
[^] # Re: suckless !! More is less !
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Pourquoi un PC ralentit-il ?. Évalué à 2.
En gros, cela évite d'avoir des objets partout qui bouffent de la place, et tu colles ton entier directement à la place du pointeur. Cela permet aussi d'informer le GC qu'il lit un pointeur et non un entier. L'idée est que la mémoire contient un peu du type de donné réel.
"La première sécurité est la liberté"
[^] # Re: suckless !! More is less !
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Pourquoi un PC ralentit-il ?. Évalué à 3.
Cela sert dans 2 ou 3 cas :
* écriture de drivers et donc dans des registres mémoires
* parseur de fichier binaire
* parseur de message réseau.
C'est tout de même assez courant, en fait.
"La première sécurité est la liberté"
[^] # Re: suckless !! More is less !
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Pourquoi un PC ralentit-il ?. Évalué à 2.
Il y a de grande chance que ton compilateur ai détecté que tu demandes 500x la même chose et ne le fasse pas.
C'est vrai, mais typiquement ton exemple en R est illisible.
"La première sécurité est la liberté"
[^] # Re: suckless !! More is less !
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Pourquoi un PC ralentit-il ?. Évalué à 4.
C'est pas faux, sauf si il y a beaucoup d'aller retour entre le code C et le python (avec recopie en trop, accès fichier mal fichu, etc…).
"La première sécurité est la liberté"
[^] # Re: suckless !! More is less !
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Pourquoi un PC ralentit-il ?. Évalué à 2.
Il ne faut pas exagérer, il y a souvent un facteur 10 entre un script et un langage compilé.
"La première sécurité est la liberté"
[^] # Re: suckless !! More is less !
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Pourquoi un PC ralentit-il ?. Évalué à 3.
En gros, les champs de bits en C ne garantissent rien du tout sur les champs réellement utilisés au final, si on regarde l'ensemble de la structure (le padding dépend du CPU et du compilo). Pour un driver par exemple, c'est un non sens, d'ou l'usage des macros.
"La première sécurité est la liberté"
[^] # Re: suckless !! More is less !
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Pourquoi un PC ralentit-il ?. Évalué à 2.
Je n'ai jamais compris pourquoi les langages mélangeaient des informations de haut niveau comme le type de donné, les ranges, et leur implémentation en mémoire ( ce qui n'a rien à voir ou presque).
"La première sécurité est la liberté"
[^] # Re: suckless !! More is less !
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Pourquoi un PC ralentit-il ?. Évalué à 2.
Ou alors tu fais un langage qui ne fait pas n'importe quoi (Ocaml) et qui marche rapidement même avec un GC.
"La première sécurité est la liberté"