Donc je bosse dans un collège, et la saison des subvention permet
d'acheter des poste. Et ceux de PS étant intéressant niveau prix/config,
ce sont ceux qu'on a acheté.
Résultat : Le Mandrake linux Discovery annoncé est en fait un Linpus
Linux, distribution basée Mdk, sur laquelle je n'ai pas réussit à faire
un chti urpmi, ni même à trouver un outil graphique pour maj.
Bref, moi qui espérait un peu là-dessus pour convaincre de faire migrer
la salle info sous linux, pas de pot avec cette config à 2 sous...
Ouais, je sais, on en a pour son argent. Mais quand même...
La fin de l'aventure, totalement HS ici, mais bon, c'est que j'ai tout
viré pour refoutre win98 dessus (et ouais, je sais :-(). Ai pour ça
utilisé une knoppix, et QTParted, en 2 fois (obligation de redémarrer au
milieu), pour pouvoir supprimer les partitions et préparer/formater en
fat32. Et le fin du fin, aucun pilote fourni. Heureusement qu'il y a un
site.
En bref, le prix, 350 l'UC pour 80Go, Celeron D et 512 Mo Ram se justifie.
Moi sur d'autres exemples, j'ai moins de 10% d'écart entre tous ces compilateurs. J'espère aussi que ta différence ne s'explique pas un meilleur support du processeur (du genre utilisation de sse2) de la part du compilateur d'Intel, sinon ça ne prouverais rien sur le compilateur mais tout sur le processeur.
Non, l'utilisation de sse sur ce programme ne fait absolument rien gagner.
J'espère que tu ne crois pas qu'un processeur dual core, ou même un biproc calcule 2 fois plus vite qu'un monoproc sur un problème donné.
Si. Sur un exemple donné il va même 120% plus vite, le test CPU righmark représenté ici : http://www.pcinpact.com/articles/a/127/0.htm?pge
Oui, et j'ai des programmes python multithreadés (et des programmes Java itou) qui tournent jusqu'à 5 fois moins vite (tu as bien lu 5) quand on active le HTT sur mon Pentium 4. J'attends de voir un seul exemple autre que purement académique où le biprocesseur fait gagner quelque chose sur un calcul précis (je ne parle pas évidemment d'un ensemble de processus s'exécutant simultanément, ou de la réactivité d'une machine à la console). Même pour une charge de travail à priori plus favorable, genre serveur web avec des pages dynamiques, j'ai entendu plusieurs fois des gens dire qu'ils avaient un meilleur débit sur un monoproc sous FreeBSD-4 que ur un biproc sous Linux 2.6. (je prends exprés deux systèmes optimisés pour le monoproc et le multiproc). S'il faut aller chercher des machines à 8 procs pour commencer à sentir le bénéfice, ça fait un peu chérot.
Il y a au contraire toute probabilité qu'il calcule *beaucoup* moins vite, à cause de tous les verrous qu'il faut si on multithreade le programme. On a essayé ici la vectorisation automatique du compilateur Intel sur de vrais biprocs, avec des résultats désastreux (sous Linux). Pour obtenir un gain, il faut, soit qu'on ait des processus trés indépendants, soit que le multithreading ait été énormément bien étudié.
Tout est dans le "bien étudié" et c'est sur ce point qu'insiste la présentation que j'avais citée précédemment. Les compilateurs apportent bien peu par rapport à ce que peut faire le programmeur en choisissant les bons algorithmes.
Autrement dit il faut passer des semaines à optimiser la vectorisation du programme. Ca me fait penser aux vieilles machines Cray d'autrefois qui soit disant avaient des performances formidables, mais en pratique, sur un programme non optimisé à mort touranaient moins vite qu'un bête PC.
Tes Athlons 64 tournent royalement à 2 Ghz et les Pentium à 3Ghz et on ne voit pas ces chiffres augmenter fortement dans les années à venir, en tout cas certainement pas doubler tous les deux ans.
Ce n'est pas la fréquence qui double, mais le nombre de transistors...
Et ça sert à quoi?
--
Michel TALON
Richard Delorme <abulmo@nospam.fr> wrote:
Moi sur d'autres exemples, j'ai moins de 10% d'écart entre tous ces
compilateurs. J'espère aussi que ta différence ne s'explique pas un
meilleur support du processeur (du genre utilisation de sse2) de la part
du compilateur d'Intel, sinon ça ne prouverais rien sur le compilateur
mais tout sur le processeur.
Non, l'utilisation de sse sur ce programme ne fait absolument rien gagner.
J'espère que tu ne crois pas qu'un processeur dual core, ou même un biproc
calcule 2 fois plus vite qu'un monoproc sur un problème donné.
Si. Sur un exemple donné il va même 120% plus vite, le test CPU righmark
représenté ici :
http://www.pcinpact.com/articles/a/127/0.htm?pge
Oui, et j'ai des programmes python multithreadés (et des programmes Java itou)
qui tournent jusqu'à 5 fois moins vite (tu as bien lu 5) quand on active le
HTT sur mon Pentium 4. J'attends de voir un seul exemple autre que purement
académique où le biprocesseur fait gagner quelque chose sur un calcul précis
(je ne parle pas évidemment d'un ensemble de processus s'exécutant
simultanément, ou de la réactivité d'une machine à la console). Même pour
une charge de travail à priori plus favorable, genre serveur web avec des
pages dynamiques, j'ai entendu plusieurs fois des gens dire qu'ils avaient un
meilleur débit sur un monoproc sous FreeBSD-4 que ur un biproc sous Linux 2.6.
(je prends exprés deux systèmes optimisés pour le monoproc et le multiproc).
S'il faut aller chercher des machines à 8 procs pour commencer à sentir le
bénéfice, ça fait un peu chérot.
Il y a au
contraire toute probabilité qu'il calcule *beaucoup* moins vite, à
cause de tous les verrous qu'il faut si on multithreade le programme.
On a essayé ici la vectorisation automatique du compilateur Intel sur de vrais
biprocs, avec des résultats désastreux (sous Linux). Pour obtenir un gain,
il faut, soit qu'on ait des processus trés indépendants, soit que le
multithreading ait été énormément bien étudié.
Tout est dans le "bien étudié" et c'est sur ce point qu'insiste la
présentation que j'avais citée précédemment. Les compilateurs apportent
bien peu par rapport à ce que peut faire le programmeur en choisissant
les bons algorithmes.
Autrement dit il faut passer des semaines à optimiser la vectorisation du
programme. Ca me fait penser aux vieilles machines Cray d'autrefois qui
soit disant avaient des performances formidables, mais en pratique, sur un
programme non optimisé à mort touranaient moins vite qu'un bête PC.
Tes Athlons 64
tournent royalement à 2 Ghz et les Pentium à 3Ghz et on ne voit pas ces
chiffres augmenter fortement dans les années à venir, en tout cas certainement
pas doubler tous les deux ans.
Ce n'est pas la fréquence qui double, mais le nombre de transistors...
Moi sur d'autres exemples, j'ai moins de 10% d'écart entre tous ces compilateurs. J'espère aussi que ta différence ne s'explique pas un meilleur support du processeur (du genre utilisation de sse2) de la part du compilateur d'Intel, sinon ça ne prouverais rien sur le compilateur mais tout sur le processeur.
Non, l'utilisation de sse sur ce programme ne fait absolument rien gagner.
J'espère que tu ne crois pas qu'un processeur dual core, ou même un biproc calcule 2 fois plus vite qu'un monoproc sur un problème donné.
Si. Sur un exemple donné il va même 120% plus vite, le test CPU righmark représenté ici : http://www.pcinpact.com/articles/a/127/0.htm?pge
Oui, et j'ai des programmes python multithreadés (et des programmes Java itou) qui tournent jusqu'à 5 fois moins vite (tu as bien lu 5) quand on active le HTT sur mon Pentium 4. J'attends de voir un seul exemple autre que purement académique où le biprocesseur fait gagner quelque chose sur un calcul précis (je ne parle pas évidemment d'un ensemble de processus s'exécutant simultanément, ou de la réactivité d'une machine à la console). Même pour une charge de travail à priori plus favorable, genre serveur web avec des pages dynamiques, j'ai entendu plusieurs fois des gens dire qu'ils avaient un meilleur débit sur un monoproc sous FreeBSD-4 que ur un biproc sous Linux 2.6. (je prends exprés deux systèmes optimisés pour le monoproc et le multiproc). S'il faut aller chercher des machines à 8 procs pour commencer à sentir le bénéfice, ça fait un peu chérot.
Il y a au contraire toute probabilité qu'il calcule *beaucoup* moins vite, à cause de tous les verrous qu'il faut si on multithreade le programme. On a essayé ici la vectorisation automatique du compilateur Intel sur de vrais biprocs, avec des résultats désastreux (sous Linux). Pour obtenir un gain, il faut, soit qu'on ait des processus trés indépendants, soit que le multithreading ait été énormément bien étudié.
Tout est dans le "bien étudié" et c'est sur ce point qu'insiste la présentation que j'avais citée précédemment. Les compilateurs apportent bien peu par rapport à ce que peut faire le programmeur en choisissant les bons algorithmes.
Autrement dit il faut passer des semaines à optimiser la vectorisation du programme. Ca me fait penser aux vieilles machines Cray d'autrefois qui soit disant avaient des performances formidables, mais en pratique, sur un programme non optimisé à mort touranaient moins vite qu'un bête PC.
Tes Athlons 64 tournent royalement à 2 Ghz et les Pentium à 3Ghz et on ne voit pas ces chiffres augmenter fortement dans les années à venir, en tout cas certainement pas doubler tous les deux ans.
Ce n'est pas la fréquence qui double, mais le nombre de transistors...
Et ça sert à quoi?
--
Michel TALON
l'indien
On Mon, 23 May 2005 16:39:44 +0200, Richard Delorme wrote:
C'est grâce à des raisonements comme celà que Microsoft propose des plates formes multi-média "qui nécéssitent un CPU à au moins 2 Ghz" et coute 2000 euros alors qu'on sait fait des cartes embedded qui coutent moins de 300 euros, avec des CPU < 500 Mhz (voire < 300 Mhz) qui font la même chose... Par contre, les compilations (et le code) doivent être légèrement optimisés... Mais ça n'a, bien sur, aucun intérêt...
1) Microsoft propose un des meilleurs compilateur C/C++ du marché, entre autre en terme de performance du code compilé.
Hum. Tu aurais dit Intel, ça aurait été vrai, du moins pour x86... (dommage, d'ailleurs, que leur compilo ne sache rien faire d'autre). Mauvaise pioche pour cette fois, tu peux rejouer.
2) Une carte mère avec un CPU à 2 GHz, ça ne vaut pas 100 Euros.
Je ne parle pas d'une carte mère mais des plate-forme multimédia (je n'ai plus le nom commercial en tête) dont Microsoft essaye de faire la promo partout. Regarde bien, les prix sont bien de l'ordre de 2000 euros.
3) 300 Euros pour une carte embarqué avec un CPU à 300 Mhz, c'est du vol.
Je n'ai pas parlé d'une carte mère, j'ai parlé d'un système embarqué complet, avec du soft permettant de faire la même chose que la plate-forme Microsoft sus-nommée. Il y a un effort d'investissement technologique d'ailleurs souvent bien plus impressionnant que dans le PC recarossé de Redmond.
4) Les compilateurs optimisant pour les cartes embarquées... ça n'existe pas.
Merci de me sugérer que je ne connais rien à mon métier et que je n'ai jamais pu constater la différence entre un programme embarqué bien compilé et un programme passé dans n'importe quelle moulinette. J'aurais donc revé quand je m'applique à faire aller un soft 2, 3 ou 5 fois plus vite (voire du x100 dans les cas extrèmes... s'il sont particulièrement mal compilés par défaut) en regardant de quelle façon le compilo génère son code et lui passant les options optimales.
5) Tu trolles mal.
Je parle de ce qui existe vraiment, dans la vrai vie industrielle, pas de ce que je ne connais pas, au moins pour cette fois... Ma la vie n'est qu'un troll immense, en fait ;-)
On Mon, 23 May 2005 16:39:44 +0200, Richard Delorme wrote:
C'est grâce à des raisonements comme celà que Microsoft propose des
plates formes multi-média "qui nécéssitent un CPU à au moins 2 Ghz" et
coute 2000 euros alors qu'on sait fait des cartes embedded qui coutent
moins de 300 euros, avec des CPU < 500 Mhz (voire < 300 Mhz) qui font la
même chose... Par contre, les compilations (et le code) doivent être
légèrement optimisés...
Mais ça n'a, bien sur, aucun intérêt...
1) Microsoft propose un des meilleurs compilateur C/C++ du marché, entre
autre en terme de performance du code compilé.
Hum. Tu aurais dit Intel, ça aurait été vrai, du moins pour x86...
(dommage, d'ailleurs, que leur compilo ne sache rien faire d'autre).
Mauvaise pioche pour cette fois, tu peux rejouer.
2) Une carte mère avec un CPU à 2 GHz, ça ne vaut pas 100 Euros.
Je ne parle pas d'une carte mère mais des plate-forme multimédia (je
n'ai plus le nom commercial en tête) dont Microsoft essaye de faire la
promo partout. Regarde bien, les prix sont bien de l'ordre de 2000 euros.
3) 300 Euros pour une carte embarqué avec un CPU à 300 Mhz, c'est du vol.
Je n'ai pas parlé d'une carte mère, j'ai parlé d'un système embarqué
complet, avec du soft permettant de faire la même chose que la
plate-forme Microsoft sus-nommée. Il y a un effort d'investissement
technologique d'ailleurs souvent bien plus impressionnant que dans le PC
recarossé de Redmond.
4) Les compilateurs optimisant pour les cartes embarquées... ça n'existe
pas.
Merci de me sugérer que je ne connais rien à mon métier et que je n'ai
jamais pu constater la différence entre un programme embarqué bien
compilé et un programme passé dans n'importe quelle moulinette. J'aurais
donc revé quand je m'applique à faire aller un soft 2, 3 ou 5 fois plus
vite (voire du x100 dans les cas extrèmes... s'il sont particulièrement
mal compilés par défaut) en regardant de quelle façon le compilo
génère son code et lui passant les options optimales.
5) Tu trolles mal.
Je parle de ce qui existe vraiment, dans la vrai vie industrielle, pas de
ce que je ne connais pas, au moins pour cette fois... Ma la vie n'est
qu'un troll immense, en fait ;-)
On Mon, 23 May 2005 16:39:44 +0200, Richard Delorme wrote:
C'est grâce à des raisonements comme celà que Microsoft propose des plates formes multi-média "qui nécéssitent un CPU à au moins 2 Ghz" et coute 2000 euros alors qu'on sait fait des cartes embedded qui coutent moins de 300 euros, avec des CPU < 500 Mhz (voire < 300 Mhz) qui font la même chose... Par contre, les compilations (et le code) doivent être légèrement optimisés... Mais ça n'a, bien sur, aucun intérêt...
1) Microsoft propose un des meilleurs compilateur C/C++ du marché, entre autre en terme de performance du code compilé.
Hum. Tu aurais dit Intel, ça aurait été vrai, du moins pour x86... (dommage, d'ailleurs, que leur compilo ne sache rien faire d'autre). Mauvaise pioche pour cette fois, tu peux rejouer.
2) Une carte mère avec un CPU à 2 GHz, ça ne vaut pas 100 Euros.
Je ne parle pas d'une carte mère mais des plate-forme multimédia (je n'ai plus le nom commercial en tête) dont Microsoft essaye de faire la promo partout. Regarde bien, les prix sont bien de l'ordre de 2000 euros.
3) 300 Euros pour une carte embarqué avec un CPU à 300 Mhz, c'est du vol.
Je n'ai pas parlé d'une carte mère, j'ai parlé d'un système embarqué complet, avec du soft permettant de faire la même chose que la plate-forme Microsoft sus-nommée. Il y a un effort d'investissement technologique d'ailleurs souvent bien plus impressionnant que dans le PC recarossé de Redmond.
4) Les compilateurs optimisant pour les cartes embarquées... ça n'existe pas.
Merci de me sugérer que je ne connais rien à mon métier et que je n'ai jamais pu constater la différence entre un programme embarqué bien compilé et un programme passé dans n'importe quelle moulinette. J'aurais donc revé quand je m'applique à faire aller un soft 2, 3 ou 5 fois plus vite (voire du x100 dans les cas extrèmes... s'il sont particulièrement mal compilés par défaut) en regardant de quelle façon le compilo génère son code et lui passant les options optimales.
5) Tu trolles mal.
Je parle de ce qui existe vraiment, dans la vrai vie industrielle, pas de ce que je ne connais pas, au moins pour cette fois... Ma la vie n'est qu'un troll immense, en fait ;-)
lhabert
Nicolas George :
En revanche, il semblerait que ce soit une bouze pour ce qui est de l'implémentation des fonctionnalités avancées du c++.
(Source : différents membres d'un gros projet de bibal de géométrie algorithmique.)
(Je tombe là-dessus par hasard...)
Euh, à vrai dire, je ne l'ai jamais testé, moi, je n'ai fait que répéter bêtement ce qu'a dit un autre membre. D'ailleurs, je vois mal comment on pourrait faire pire que g++ pour ce qui est gestion des templates (le premier programme C++ avec des templates que j'ai écrit a trouvé moyen de le faire segfaulter). Enfin bon, je ne cherche pas à lancer un troll, oubliez ce post...
-- Un des membre du gros projet en question.
Nicolas George :
En revanche, il semblerait que ce soit une bouze pour ce qui est de
l'implémentation des fonctionnalités avancées du c++.
(Source : différents membres d'un gros projet de bibal de géométrie
algorithmique.)
(Je tombe là-dessus par hasard...)
Euh, à vrai dire, je ne l'ai jamais testé, moi, je n'ai fait que répéter
bêtement ce qu'a dit un autre membre. D'ailleurs, je vois mal comment on
pourrait faire pire que g++ pour ce qui est gestion des templates (le
premier programme C++ avec des templates que j'ai écrit a trouvé moyen de le
faire segfaulter). Enfin bon, je ne cherche pas à lancer un troll, oubliez
ce post...
En revanche, il semblerait que ce soit une bouze pour ce qui est de l'implémentation des fonctionnalités avancées du c++.
(Source : différents membres d'un gros projet de bibal de géométrie algorithmique.)
(Je tombe là-dessus par hasard...)
Euh, à vrai dire, je ne l'ai jamais testé, moi, je n'ai fait que répéter bêtement ce qu'a dit un autre membre. D'ailleurs, je vois mal comment on pourrait faire pire que g++ pour ce qui est gestion des templates (le premier programme C++ avec des templates que j'ai écrit a trouvé moyen de le faire segfaulter). Enfin bon, je ne cherche pas à lancer un troll, oubliez ce post...
-- Un des membre du gros projet en question.
remy
Oui, et j'ai des programmes python multithreadés (et des programmes Java itou)
qui tournent jusqu'à 5 fois moins vite (tu as bien lu 5) quand on active le
HTT sur mon Pentium 4.
bizarre tu as toujours ton cache
J'attends de voir un seul exemple autre que purement académique où le biprocesseur fait gagner quelque chose sur un calcul précis
(je ne parle pas évidemment d'un ensemble de processus s'exécutant simultanément, ou de la réactivité d'une machine à la console).
de la 3d sur plusieurs obj dans une meme scene mais la vectorisation ne peut pas s'appliquer a tous les pbs de memoire et je viens peut etre de dire une connerie tout bien reflechi
Tes Athlons 64 tournent royalement à 2 Ghz et les Pentium à 3Ghz et on ne voit pas ces
chiffres augmenter fortement dans les années à venir, en tout cas certainement
pas doubler tous les deux ans.
faire tourner du code 32 sur un 64 tu ne vas pas avoir des gros ecarts les ecarts seront dûs a la difference de vitesse des bus et a la taille des caches 1,2,...
Ce n'est pas la fréquence qui double, mais le nombre de transistors...
Et ça sert à quoi?
8,16,32,64 bit avec plus de micro code cable une instruction asm 3 instruction "micro code cable" une instruction asm 1 instruction "micro code cable" un exemple super simple registre a decalage soft ou tu croise le flis
-- des conneries j'en ai dites oui oui je vous assure... mais elles n'engagent que votre perception remy
Oui, et j'ai des programmes python multithreadés (et des programmes Java
itou)
qui tournent jusqu'à 5 fois moins vite (tu as bien lu 5) quand on active
le
HTT sur mon Pentium 4.
bizarre tu as toujours ton cache
J'attends de voir un seul exemple autre que purement
académique où le biprocesseur fait gagner quelque chose sur un calcul
précis
(je ne parle pas évidemment d'un ensemble de processus s'exécutant
simultanément, ou de la réactivité d'une machine à la console).
de la 3d sur plusieurs obj dans une meme scene
mais la vectorisation ne peut pas s'appliquer a tous les pbs
de memoire et je viens peut etre de dire une connerie
tout bien reflechi
Tes Athlons 64
tournent royalement à 2 Ghz et les Pentium à 3Ghz et on ne voit pas
ces
chiffres augmenter fortement dans les années à venir, en tout cas
certainement
pas doubler tous les deux ans.
faire tourner du code 32 sur un 64 tu ne vas pas avoir des gros ecarts
les ecarts seront dûs a la difference de vitesse des bus et a la taille des
caches 1,2,...
Ce n'est pas la fréquence qui double, mais le nombre de transistors...
Et ça sert à quoi?
8,16,32,64 bit avec plus de micro code cable
une instruction asm 3 instruction "micro code cable"
une instruction asm 1 instruction "micro code cable"
un exemple super simple registre a decalage
soft ou tu croise le flis
--
des conneries j'en ai dites oui oui je vous assure...
mais elles n'engagent que votre perception
remy
Oui, et j'ai des programmes python multithreadés (et des programmes Java itou)
qui tournent jusqu'à 5 fois moins vite (tu as bien lu 5) quand on active le
HTT sur mon Pentium 4.
bizarre tu as toujours ton cache
J'attends de voir un seul exemple autre que purement académique où le biprocesseur fait gagner quelque chose sur un calcul précis
(je ne parle pas évidemment d'un ensemble de processus s'exécutant simultanément, ou de la réactivité d'une machine à la console).
de la 3d sur plusieurs obj dans une meme scene mais la vectorisation ne peut pas s'appliquer a tous les pbs de memoire et je viens peut etre de dire une connerie tout bien reflechi
Tes Athlons 64 tournent royalement à 2 Ghz et les Pentium à 3Ghz et on ne voit pas ces
chiffres augmenter fortement dans les années à venir, en tout cas certainement
pas doubler tous les deux ans.
faire tourner du code 32 sur un 64 tu ne vas pas avoir des gros ecarts les ecarts seront dûs a la difference de vitesse des bus et a la taille des caches 1,2,...
Ce n'est pas la fréquence qui double, mais le nombre de transistors...
Et ça sert à quoi?
8,16,32,64 bit avec plus de micro code cable une instruction asm 3 instruction "micro code cable" une instruction asm 1 instruction "micro code cable" un exemple super simple registre a decalage soft ou tu croise le flis
-- des conneries j'en ai dites oui oui je vous assure... mais elles n'engagent que votre perception remy
Izaho Ihany
scripsit nicolas vigier :
[...]
L'informatique industrielle c'est comme le COBOL, on fait ça pour manger, pas pour la beauté de la chose.
Ah que si:
[...] SUBSTRACT BASIC AND COBOL FROM PROGRAMMATION GIVING NOTHINGLEFT. ADD BASIC TO COBOL GIVING LABEAUTÉDELACHOSE. [...] -- Né (approx) 553.737.600 secondes avant É.J.
scripsit nicolas vigier :
[...]
L'informatique industrielle c'est comme le COBOL, on fait ça pour manger,
pas pour la beauté de la chose.
Ah que si:
[...]
SUBSTRACT BASIC AND COBOL FROM PROGRAMMATION GIVING NOTHINGLEFT.
ADD BASIC TO COBOL GIVING LABEAUTÉDELACHOSE.
[...]
--
Né (approx) 553.737.600 secondes avant É.J.
L'informatique industrielle c'est comme le COBOL, on fait ça pour manger, pas pour la beauté de la chose.
Ah que si:
[...] SUBSTRACT BASIC AND COBOL FROM PROGRAMMATION GIVING NOTHINGLEFT. ADD BASIC TO COBOL GIVING LABEAUTÉDELACHOSE. [...] -- Né (approx) 553.737.600 secondes avant É.J.
Izaho Ihany
nicolas vigier écrivait :
[...] Ah, ça tombe bien. Je cherchais justement quelqu'un qui connaît bien les langages de programmation, vous allez sûrement pouvoir me répondre :
Je me demandais quel serait le meilleur langage à utiliser pour une initiation à la programmation disons en une trentaine d'heure pour des jeunes de 15 ans,
l' ENA-PL
quels sont les concepts qu'on peut raisonnablement faire passer, et quels types d'exercices donner.
doom, pinball, ... ???
-- Né (approx) 553.737.600 secondes avant É.J.
nicolas vigier écrivait :
[...]
Ah, ça tombe bien. Je cherchais justement quelqu'un qui connaît bien les
langages de programmation, vous allez sûrement pouvoir me répondre :
Je me demandais quel serait le meilleur langage à utiliser pour une initiation
à la programmation disons en une trentaine d'heure pour des jeunes de 15 ans,
l' ENA-PL
quels sont les concepts qu'on peut raisonnablement faire passer, et quels types
d'exercices donner.
[...] Ah, ça tombe bien. Je cherchais justement quelqu'un qui connaît bien les langages de programmation, vous allez sûrement pouvoir me répondre :
Je me demandais quel serait le meilleur langage à utiliser pour une initiation à la programmation disons en une trentaine d'heure pour des jeunes de 15 ans,
l' ENA-PL
quels sont les concepts qu'on peut raisonnablement faire passer, et quels types d'exercices donner.
