Processeur et langage
Fermé
jemd
-
19 avril 2005 à 21:38
Luffy =) Messages postés 365 Date d'inscription mercredi 20 avril 2005 Statut Membre Dernière intervention 19 mai 2006 - 6 mai 2005 à 20:49
Luffy =) Messages postés 365 Date d'inscription mercredi 20 avril 2005 Statut Membre Dernière intervention 19 mai 2006 - 6 mai 2005 à 20:49
A voir également:
- Processeur et langage
- Temperature processeur - Guide
- Fréquence du processeur - Guide
- Langage ascii - Guide
- Génération processeur amd - Guide
- Planification de processeur graphique à accélération matérielle - Guide
3 réponses
A moins que la modification d'adaptation du langage au processeur passe par un changement du compilateur...!!
Tout à fait.
Historiquement, le C / UNIX à été inventé pour ça, qu'un même programme puisse être porté sur différentes stations, assez hétérogène (plus que nos PC actuels) et n'avoir besoin QUE d'être recompilé.
Ca a été une sacrée révolution.
Néanmoins, tout celà est possible car les µprocesseur et les ordis en général sont tous conçus sur des concept plus ou moins identique, du moins équivalant.
Et quand une fonctionalité n'est pas présente de façon matérielle, on peut la rajouter, l'émuler, de façon logicielle.
exemple : à l'époque des 386/486, antécédents du pentium (que, pour des raison de standard, intel n'a pas pu déposer sous le nom d'i80586, d'où le nom PENTium...) à l'époque donc, certain PC intégraient des co-processeur mathématique pour les 386, d'autres non (à l'époque, ce composant valais cher, il était abscent des stations purement bureautique qui ne font pas de calcul sur des nombles rééls, ou très peu), alors que 486, pour une large partie de la gamme, embarquait le-dit "FPU" (le co-proce) sur le puce, directement.
A l'époque les compilateurs proposaient donc une option qui permettait de compiler avec utilisation du FPU, ou bien avec une émulation logicielle, plus lente mais aussi précise, c'est à dire des sous-programmes qui effectuaient les calculs au lieu d'une puce.
Plus récemment, c'est les bibliothèque 3D (openGL, direct X) qui proposaient d'utiliser soit la carte 3D, soit, si elle était abscente, une émulation logicielle. Encore une fois, c'est plus lent, mais ça marche.
Pour ce qui est du traitement parallèle. Deux choses :
-soit tu parle du traitement multi-processeurs, c'est parceque les programmes sont architecturés en plusieurs modules indépendants.
On peut toujours réduire le nombre de processeurs jusqu'à 1 seul : pour simuler le parallélisme, le seul µ-proce va éxécuter les différents modules (les défférents processus, tâches, ou threads) les uns après les autres. C'est un peu comme au cinéma, vu que le changement est rapide, on a l'impression que tout se passe en même temps.
Mais ça reste évidemment plus rapide d'utiliser plusieurs processeurs.
Si on parle du parallélisme à l'intéreur du processeur...
Il faut voir que l'éxécution d'une instruction en language binaire nécessite plusieurs étapes :
- La lecture l'instruction en mémoire
- Le décodage de l'instruction
- La lecture (éventuelle) des arguments
- L'éxécution
- L'enregistrement (éventuel) du résultat en mémoire centrale
Mais si, pendant que tu effectue le décodage, tu lis l'instruction suivante, que pendant que tu lit les agruments de la 1iere, tu décode la 2ième, etc...
Tu gagne beaucoup de temps. Or matériellement, c'est tout à fait possible.
Il y a quand même des cas où la progression est bloquée : quand une instruction à besoin du résultat de celle immédiatement précédente.
Voilà, pour conclure à ta question, ta supposition est correcte : le compilateur sert à traduire un programme en language standard, portable, en assembleur puis en code machine spécifique à un microprocesseur.
Les bibliothèques et les drivers servent à adapter un matériel spécifique à une interface de programmation standard (exemple openGL marche sur toutes les cartes 3D).
Encore une fois, on rejoint la notion d'abstraction : on rajoute des couches entre le programme final et le matériel pour masquer ses spécificités.
Ca répond à ta question ?
Tout à fait.
Historiquement, le C / UNIX à été inventé pour ça, qu'un même programme puisse être porté sur différentes stations, assez hétérogène (plus que nos PC actuels) et n'avoir besoin QUE d'être recompilé.
Ca a été une sacrée révolution.
Néanmoins, tout celà est possible car les µprocesseur et les ordis en général sont tous conçus sur des concept plus ou moins identique, du moins équivalant.
Et quand une fonctionalité n'est pas présente de façon matérielle, on peut la rajouter, l'émuler, de façon logicielle.
exemple : à l'époque des 386/486, antécédents du pentium (que, pour des raison de standard, intel n'a pas pu déposer sous le nom d'i80586, d'où le nom PENTium...) à l'époque donc, certain PC intégraient des co-processeur mathématique pour les 386, d'autres non (à l'époque, ce composant valais cher, il était abscent des stations purement bureautique qui ne font pas de calcul sur des nombles rééls, ou très peu), alors que 486, pour une large partie de la gamme, embarquait le-dit "FPU" (le co-proce) sur le puce, directement.
A l'époque les compilateurs proposaient donc une option qui permettait de compiler avec utilisation du FPU, ou bien avec une émulation logicielle, plus lente mais aussi précise, c'est à dire des sous-programmes qui effectuaient les calculs au lieu d'une puce.
Plus récemment, c'est les bibliothèque 3D (openGL, direct X) qui proposaient d'utiliser soit la carte 3D, soit, si elle était abscente, une émulation logicielle. Encore une fois, c'est plus lent, mais ça marche.
Pour ce qui est du traitement parallèle. Deux choses :
-soit tu parle du traitement multi-processeurs, c'est parceque les programmes sont architecturés en plusieurs modules indépendants.
On peut toujours réduire le nombre de processeurs jusqu'à 1 seul : pour simuler le parallélisme, le seul µ-proce va éxécuter les différents modules (les défférents processus, tâches, ou threads) les uns après les autres. C'est un peu comme au cinéma, vu que le changement est rapide, on a l'impression que tout se passe en même temps.
Mais ça reste évidemment plus rapide d'utiliser plusieurs processeurs.
Si on parle du parallélisme à l'intéreur du processeur...
Il faut voir que l'éxécution d'une instruction en language binaire nécessite plusieurs étapes :
- La lecture l'instruction en mémoire
- Le décodage de l'instruction
- La lecture (éventuelle) des arguments
- L'éxécution
- L'enregistrement (éventuel) du résultat en mémoire centrale
Mais si, pendant que tu effectue le décodage, tu lis l'instruction suivante, que pendant que tu lit les agruments de la 1iere, tu décode la 2ième, etc...
Tu gagne beaucoup de temps. Or matériellement, c'est tout à fait possible.
Il y a quand même des cas où la progression est bloquée : quand une instruction à besoin du résultat de celle immédiatement précédente.
Voilà, pour conclure à ta question, ta supposition est correcte : le compilateur sert à traduire un programme en language standard, portable, en assembleur puis en code machine spécifique à un microprocesseur.
Les bibliothèques et les drivers servent à adapter un matériel spécifique à une interface de programmation standard (exemple openGL marche sur toutes les cartes 3D).
Encore une fois, on rejoint la notion d'abstraction : on rajoute des couches entre le programme final et le matériel pour masquer ses spécificités.
Ca répond à ta question ?
franchement ??
Non. C'est que des blagues. :-P
Non. C'est que des blagues. :-P
bonjour
y avait longtemps...que je n'étais passé par là...
j'ai attaqué les bases de données et j'ai du mal à saisir ce qu'on entend par "moteur de la base" ??
et l'intégration d'un langage de programmation pour l'utiliser avec des fonctionnalités... quel rôle alors pour le sgbdr ??
une question subsidiaire : peut-on utiliser plusieurs langages de programmation sur un pc ??
y avait longtemps...que je n'étais passé par là...
j'ai attaqué les bases de données et j'ai du mal à saisir ce qu'on entend par "moteur de la base" ??
et l'intégration d'un langage de programmation pour l'utiliser avec des fonctionnalités... quel rôle alors pour le sgbdr ??
une question subsidiaire : peut-on utiliser plusieurs langages de programmation sur un pc ??
Les bases de données interprète des commandes, écrit dans un language standard (SQL est devenu LA référence du domaine).
Une BDD n'est pas forcément sur un ordinateur local et isolé.
L'intéret de ces truc est par exemple d'avoir une base qui centralise, je ne sais pas, les sorties et entrées dans les stocks de différents intermarchés, ce qui permet un calcul "en temps réél" des achat que doit réaliser, non pas individuellement chaque magasin, mais le groupe tout entier !!!
Une BDD c'est un espace de stockage. Le format dans lequel les données sont écrite, la manière exacte dont elle sont organisées sur le support matériel, est la responsabilitée de la BDD.
Moi mon problème c'est de taper une commande, et qu'elle sache retrouver les info dont j'ai besoin.
Par exemple le nombre de choux disponible en stock dans l'ensemble des magasins de la Picardie.
Pour me donner cette info, la BDD va etre obliger de :
- sélectionner l'ensembles des magasin de Picardie (mais pas les autres)
- y extraire le nombre de choux dispos pour chaque.
- Eventuellement, les additionner
Ces trois opérations seront effectuée par le "moteur" de la BDD, qui se charge : d'interpréter la commande, d'en déduire les actions à effectuer, de les éxécuter, et de renvoyer, enfin, la réponse à la requete.
Il s'agit de la partie réactive de la BDD, alors que la partie "stockage d'informations", elle, est en soit inerte.
Etant donné les nombreux travaux en IA qui ont profités aux BDD, ces moteurs sont parfois capables de propriété d'induction très puissantes (car on ne demande pas forcément la réstitution des données telles quelles, mais parfois avec beaucoup de traitements).
Pour répondre à la question sur l'applicatif que tu a posée ailleurs, je ne suis pas sur du tout. Je pense qu'il s'agit effectivement du programme qui exploite la BDD, donc je rejoint ta réponse, mais a vérifier.
Une BDD n'est pas forcément sur un ordinateur local et isolé.
L'intéret de ces truc est par exemple d'avoir une base qui centralise, je ne sais pas, les sorties et entrées dans les stocks de différents intermarchés, ce qui permet un calcul "en temps réél" des achat que doit réaliser, non pas individuellement chaque magasin, mais le groupe tout entier !!!
Une BDD c'est un espace de stockage. Le format dans lequel les données sont écrite, la manière exacte dont elle sont organisées sur le support matériel, est la responsabilitée de la BDD.
Moi mon problème c'est de taper une commande, et qu'elle sache retrouver les info dont j'ai besoin.
Par exemple le nombre de choux disponible en stock dans l'ensemble des magasins de la Picardie.
Pour me donner cette info, la BDD va etre obliger de :
- sélectionner l'ensembles des magasin de Picardie (mais pas les autres)
- y extraire le nombre de choux dispos pour chaque.
- Eventuellement, les additionner
Ces trois opérations seront effectuée par le "moteur" de la BDD, qui se charge : d'interpréter la commande, d'en déduire les actions à effectuer, de les éxécuter, et de renvoyer, enfin, la réponse à la requete.
Il s'agit de la partie réactive de la BDD, alors que la partie "stockage d'informations", elle, est en soit inerte.
Etant donné les nombreux travaux en IA qui ont profités aux BDD, ces moteurs sont parfois capables de propriété d'induction très puissantes (car on ne demande pas forcément la réstitution des données telles quelles, mais parfois avec beaucoup de traitements).
Pour répondre à la question sur l'applicatif que tu a posée ailleurs, je ne suis pas sur du tout. Je pense qu'il s'agit effectivement du programme qui exploite la BDD, donc je rejoint ta réponse, mais a vérifier.
et donc le moteur se différencie du sgbdr ou bien c'est la même chose ??
il n'y a pas d'un coté une partie logicielle et de l'autre une partie matèrielle...on est dans le logiciel en plein...
ce qui veut dire qu à un niveau conceptuel, une fois le modèle de la base crée, ce modèle va être géré d'une façon logicielle...organisation des données en tables, etc; ensuite c'est le sgbdr qui sera chargé d'aller gérer l'info (donc la base est "construite" en étroite relation avec un sgbdr...non? mais alors toutes les bases ont la même organisation excéptée les relations entre les tables... c'est ca ou je dis n'importe quoi ?)
il n'y a pas d'un coté une partie logicielle et de l'autre une partie matèrielle...on est dans le logiciel en plein...
ce qui veut dire qu à un niveau conceptuel, une fois le modèle de la base crée, ce modèle va être géré d'une façon logicielle...organisation des données en tables, etc; ensuite c'est le sgbdr qui sera chargé d'aller gérer l'info (donc la base est "construite" en étroite relation avec un sgbdr...non? mais alors toutes les bases ont la même organisation excéptée les relations entre les tables... c'est ca ou je dis n'importe quoi ?)
Luffy =)
Messages postés
365
Date d'inscription
mercredi 20 avril 2005
Statut
Membre
Dernière intervention
19 mai 2006
109
>
SKZ
6 mai 2005 à 20:49
6 mai 2005 à 20:49
le moteur se différencie du sgbdr
on va dire que le moteur fait partie du sgbdr. Car il gère également les accès concurrents à la base, l'intégrité des données, les transactions, etc...
mais alors toutes les bases ont la même organisation
là on peut dire ça, dans le sens où toutes les bases sont construites sur le modéle Table->Champ->Enregistrement
Après tu mets le nombre de tables et de champs que tu veux, ainsi que de stypes de valeurs qui correspondent à ce que tu veux.
on va dire que le moteur fait partie du sgbdr. Car il gère également les accès concurrents à la base, l'intégrité des données, les transactions, etc...
mais alors toutes les bases ont la même organisation
là on peut dire ça, dans le sens où toutes les bases sont construites sur le modéle Table->Champ->Enregistrement
Après tu mets le nombre de tables et de champs que tu veux, ainsi que de stypes de valeurs qui correspondent à ce que tu veux.
sam3000
Messages postés
1225
Date d'inscription
mercredi 22 décembre 2004
Statut
Membre
Dernière intervention
13 juin 2005
144
5 mai 2005 à 16:54
5 mai 2005 à 16:54
oui
19 avril 2005 à 22:44
plus que je ne pouvais espérer !
merci beaucoup
je vais me pencher sur la question des drivers et des dll...
6 mai 2005 à 19:29
cela veut dire que lorsque on installe un langage, son environnement est constitué en fait de librairies (programmes) lui permettant de fonctionner avec un matèriel et d'une interface pour lire écrire le programme ??