Certes mon ami, mais alors, il ne s'agit plus de virtualisation, mais d'une espèce de portage.
Bah, la virtualisation c'est Virtual PC et Vmware; ce que tu comptais faire c'était de l'émulation comme Bochs (http://bochs.sourceforge.net)
Le principal c'est que ça marche, de toute façon.
Eric
Je vais essayé de faire des recherches sur cette piste, merci pour m'en avoir parlé.
Eric
Renseignez vous auprès de Motorola, mais je pense que ca existe déjà. généralement les outil de dev DSP sont livré avec émulateur PC pour pouvoir debugger plus rapidemment du code...
VB
Je vais essayé de faire des recherches sur cette piste, merci pour m'en
avoir parlé.
Eric
Renseignez vous auprès de Motorola, mais je pense que ca existe déjà.
généralement les outil de dev DSP sont livré avec émulateur PC pour
pouvoir
debugger plus rapidemment du code...
Je vais essayé de faire des recherches sur cette piste, merci pour m'en avoir parlé.
Eric
Renseignez vous auprès de Motorola, mais je pense que ca existe déjà. généralement les outil de dev DSP sont livré avec émulateur PC pour pouvoir debugger plus rapidemment du code...
VB
Eric
Intéressant ton lien. J'aime internet pour ça, il y a toujours des personnes ayant trouvé une adresse internet que nous n'avons pas trouvé nous même.
Eric
"Frederic Bonroy" a écrit dans le message de news: d6s6la$2im4$
AMcD® a écrit :
Certes mon ami, mais alors, il ne s'agit plus de virtualisation, mais d'une espèce de portage.
Bah, la virtualisation c'est Virtual PC et Vmware; ce que tu comptais faire c'était de l'émulation comme Bochs (http://bochs.sourceforge.net)
Le principal c'est que ça marche, de toute façon.
Intéressant ton lien.
J'aime internet pour ça, il y a toujours des personnes ayant trouvé une
adresse internet que nous n'avons pas trouvé nous même.
Eric
"Frederic Bonroy" <bidonavirus@yahoo.fr> a écrit dans le message de news:
d6s6la$2im4$1@ulysses.news.tiscali.de...
AMcD® a écrit :
Certes mon ami, mais alors, il ne s'agit plus de virtualisation, mais
d'une
espèce de portage.
Bah, la virtualisation c'est Virtual PC et Vmware; ce que tu comptais
faire c'était de l'émulation comme Bochs (http://bochs.sourceforge.net)
Intéressant ton lien. J'aime internet pour ça, il y a toujours des personnes ayant trouvé une adresse internet que nous n'avons pas trouvé nous même.
Eric
"Frederic Bonroy" a écrit dans le message de news: d6s6la$2im4$
AMcD® a écrit :
Certes mon ami, mais alors, il ne s'agit plus de virtualisation, mais d'une espèce de portage.
Bah, la virtualisation c'est Virtual PC et Vmware; ce que tu comptais faire c'était de l'émulation comme Bochs (http://bochs.sourceforge.net)
Le principal c'est que ça marche, de toute façon.
Alexandre
"Eric" a écrit dans le message de news: 4290f03a$0$3109$
Si chaque instruction est traduite puis interprétée, on perd un temps fou. On ne peut donc pas tout programmer ainsi ou alors il faut des machines super rapide. J'ai bien compris ?
ben oui, c'est pour ça que c'est lent, java ;-)
Aurais-tu un source d'une petite machine virtuelle, pour voir un peu le fonctionnement.
une petite ???
Eric
"Eric" <ericcity@caramail.com> a écrit dans le message de news:
4290f03a$0$3109$8fcfb975@news.wanadoo.fr...
Si chaque instruction est traduite puis interprétée, on perd un temps fou.
On ne peut donc pas tout programmer ainsi ou alors il faut des machines
super rapide.
J'ai bien compris ?
ben oui, c'est pour ça que c'est lent, java ;-)
Aurais-tu un source d'une petite machine virtuelle, pour voir un peu le
fonctionnement.
"Eric" a écrit dans le message de news: 4290f03a$0$3109$
Si chaque instruction est traduite puis interprétée, on perd un temps fou. On ne peut donc pas tout programmer ainsi ou alors il faut des machines super rapide. J'ai bien compris ?
ben oui, c'est pour ça que c'est lent, java ;-)
Aurais-tu un source d'une petite machine virtuelle, pour voir un peu le fonctionnement.
une petite ???
Eric
Alexandre
> Ben regarde le code .Net, le Java. Ça marche pas trop mal. C'est clair que plus la machine est rapide... Mais bon, ça dépend aussi du type de code intermédiaire généré. C'est évident que si tes instructions intermédiaires sont encodés comme les instructions Intel, t'es pas prêt de gagner un concours de vitesse...
ceci dit sur .Net et Java il y a aussi des compilateurs JIT, donc le code executé est du natif... pas de l'interprété (enfin la plupart du temps)
> Ben regarde le code .Net, le Java. Ça marche pas trop mal. C'est clair que
plus la machine est rapide... Mais bon, ça dépend aussi du type de code
intermédiaire généré. C'est évident que si tes instructions intermédiaires
sont encodés comme les instructions Intel, t'es pas prêt de gagner un
concours de vitesse...
ceci dit sur .Net et Java il y a aussi des compilateurs JIT, donc le code
executé est du natif... pas de l'interprété (enfin la plupart du temps)
> Ben regarde le code .Net, le Java. Ça marche pas trop mal. C'est clair que plus la machine est rapide... Mais bon, ça dépend aussi du type de code intermédiaire généré. C'est évident que si tes instructions intermédiaires sont encodés comme les instructions Intel, t'es pas prêt de gagner un concours de vitesse...
ceci dit sur .Net et Java il y a aussi des compilateurs JIT, donc le code executé est du natif... pas de l'interprété (enfin la plupart du temps)
Cyrille Szymanski
On 2005-05-22, AMcD® wrote:
On ne peut donc pas tout programmer ainsi ou alors il faut des machines super rapide.
Ben regarde le code .Net, le Java. Ça marche pas trop mal. C'est clair que plus la machine est rapide... Mais bon, ça dépend aussi du type de code intermédiaire généré. C'est évident que si tes instructions intermédiaires sont encodés comme les instructions Intel, t'es pas prêt de gagner un concours de vitesse...
Je pense que si Java et .net sont si lents c'est plutôt la faute au ramasse miettes et à tous les autres tests de typage et de sécurité que le fait de JITer le code.
-- Cyrille Szymanski
On 2005-05-22, AMcD® <arnold.mcdonald@free.fr> wrote:
On ne peut donc pas tout programmer ainsi ou alors il faut des
machines super rapide.
Ben regarde le code .Net, le Java. Ça marche pas trop mal. C'est clair que
plus la machine est rapide... Mais bon, ça dépend aussi du type de code
intermédiaire généré. C'est évident que si tes instructions intermédiaires
sont encodés comme les instructions Intel, t'es pas prêt de gagner un
concours de vitesse...
Je pense que si Java et .net sont si lents c'est plutôt la faute au ramasse
miettes et à tous les autres tests de typage et de sécurité que le fait de
JITer le code.
On ne peut donc pas tout programmer ainsi ou alors il faut des machines super rapide.
Ben regarde le code .Net, le Java. Ça marche pas trop mal. C'est clair que plus la machine est rapide... Mais bon, ça dépend aussi du type de code intermédiaire généré. C'est évident que si tes instructions intermédiaires sont encodés comme les instructions Intel, t'es pas prêt de gagner un concours de vitesse...
Je pense que si Java et .net sont si lents c'est plutôt la faute au ramasse miettes et à tous les autres tests de typage et de sécurité que le fait de JITer le code.
-- Cyrille Szymanski
Cyrille Szymanski
On 2005-05-23, Alexandre wrote:
Si chaque instruction est traduite puis interprétée, on perd un temps fou. On ne peut donc pas tout programmer ainsi ou alors il faut des machines super rapide. J'ai bien compris ?
ben oui, c'est pour ça que c'est lent, java ;-)
Bof à mon avis la cause est plutôt à chercher du côté du ramasse miettes, des tests de typage et de sécurité.
-- Cyrille Szymanski
On 2005-05-23, Alexandre <alex.g@netcourrier.com> wrote:
Si chaque instruction est traduite puis interprétée, on perd un temps fou.
On ne peut donc pas tout programmer ainsi ou alors il faut des machines
super rapide.
J'ai bien compris ?
ben oui, c'est pour ça que c'est lent, java ;-)
Bof à mon avis la cause est plutôt à chercher du côté du ramasse miettes,
des tests de typage et de sécurité.
Si chaque instruction est traduite puis interprétée, on perd un temps fou. On ne peut donc pas tout programmer ainsi ou alors il faut des machines super rapide. J'ai bien compris ?
ben oui, c'est pour ça que c'est lent, java ;-)
Bof à mon avis la cause est plutôt à chercher du côté du ramasse miettes, des tests de typage et de sécurité.
-- Cyrille Szymanski
Vincent Burel
"Cyrille Szymanski" wrote in message news:
On 2005-05-23, Alexandre wrote: >> Si chaque instruction est traduite puis interprétée, on perd un temps
fou.
>> On ne peut donc pas tout programmer ainsi ou alors il faut des machines >> super rapide. >> J'ai bien compris ? > > ben oui, c'est pour ça que c'est lent, java ;-)
Bof à mon avis la cause est plutôt à chercher du côté du ramasse miettes, des tests de typage et de sécurité.
Enfin bon, une interprétation de code est toujours plus longue comparée à une exécution d'un code natif directement faite par le processeur.
Dans les machines virtuelles, ou émulateurs, il y'a un intermédiaire entre le processeur et le logiciel (ou le script logiciel). C'est cet intermédiaire qui est la cause d'un ralentissement de l'éxécution, quelque soit ce qu'il fait, ramassage de miette ou pas.
VB
"Cyrille Szymanski" <cns@cns2.invalid> wrote in message
news:slrnd99npv.7id.cns@szymanski4.rez-gif.supelec.fr...
On 2005-05-23, Alexandre <alex.g@netcourrier.com> wrote:
>> Si chaque instruction est traduite puis interprétée, on perd un temps
fou.
>> On ne peut donc pas tout programmer ainsi ou alors il faut des machines
>> super rapide.
>> J'ai bien compris ?
>
> ben oui, c'est pour ça que c'est lent, java ;-)
Bof à mon avis la cause est plutôt à chercher du côté du ramasse miettes,
des tests de typage et de sécurité.
Enfin bon, une interprétation de code est toujours plus longue comparée à
une exécution d'un code natif directement faite par le processeur.
Dans les machines virtuelles, ou émulateurs, il y'a un intermédiaire entre
le processeur et le logiciel (ou le script logiciel). C'est cet
intermédiaire qui est la cause d'un ralentissement de l'éxécution, quelque
soit ce qu'il fait, ramassage de miette ou pas.
On 2005-05-23, Alexandre wrote: >> Si chaque instruction est traduite puis interprétée, on perd un temps
fou.
>> On ne peut donc pas tout programmer ainsi ou alors il faut des machines >> super rapide. >> J'ai bien compris ? > > ben oui, c'est pour ça que c'est lent, java ;-)
Bof à mon avis la cause est plutôt à chercher du côté du ramasse miettes, des tests de typage et de sécurité.
Enfin bon, une interprétation de code est toujours plus longue comparée à une exécution d'un code natif directement faite par le processeur.
Dans les machines virtuelles, ou émulateurs, il y'a un intermédiaire entre le processeur et le logiciel (ou le script logiciel). C'est cet intermédiaire qui est la cause d'un ralentissement de l'éxécution, quelque soit ce qu'il fait, ramassage de miette ou pas.
VB
Cyrille Szymanski
On 2005-05-25, Vincent Burel wrote:
Dans les machines virtuelles, ou émulateurs, il y'a un intermédiaire entre le processeur et le logiciel (ou le script logiciel). C'est cet intermédiaire qui est la cause d'un ralentissement de l'éxécution, quelque soit ce qu'il fait, ramassage de miette ou pas.
Prends le cas d'une jvm récente. Le pseudo-code est compilé (*) et s'exécute quasi-nativement. On n'est pas dans le cas où chaque instruction est interprétée à chaque fois qu'on tombe dessus. Le sur-coût du pseudo code est relativement petit.
Par contre, le code des méthodes est analysé pour vérifier la cohérence de la pile, ce qui correspond d'après les spécialistes à un délai d'environ 1 à 2 fois l'exécution de la méthode sans passer dans les boucles. Le garbage collector c'est sympa, mais gourmand en ressources aussi. Les types des objets sont aussi constamment vérifiés pour s'assurer qu'ils correspondent à ce qui est attendu. Il y a d'autres exemples, surtout des choses liées à l'introspection.
Tout ça pour dire que ce qui rend Java lent, d'après moi, c'est pas le fait qu'ils utilisent du pseudo-code (sinon les compilateurs natifs feraient un tabac) mais le fait que le Java passe son temps à tout vérifier. Ça en fait aussi l'un des langages les plus sûrs.
(*) C'est fait à la volée donc globalement ça ralentit l'exécution du programme, mais ça ne change rien si la jvm compilait au lancement (le délai serait alors ressenti au début au lieu d'être réparti). Les puristes te disent que de JITer le code ça permettrait de faire des optimisations à la volée et que le code serait encore plus performant que du code compilé, mais l'efficacité reste à prouver.
-- Cyrille Szymanski
On 2005-05-25, Vincent Burel <vincent.burel@spam-wanadoo.fr> wrote:
Dans les machines virtuelles, ou émulateurs, il y'a un intermédiaire entre
le processeur et le logiciel (ou le script logiciel). C'est cet
intermédiaire qui est la cause d'un ralentissement de l'éxécution, quelque
soit ce qu'il fait, ramassage de miette ou pas.
Prends le cas d'une jvm récente. Le pseudo-code est compilé (*) et s'exécute
quasi-nativement. On n'est pas dans le cas où chaque instruction est
interprétée à chaque fois qu'on tombe dessus. Le sur-coût du pseudo code est
relativement petit.
Par contre, le code des méthodes est analysé pour vérifier la cohérence de la
pile, ce qui correspond d'après les spécialistes à un délai d'environ 1 à 2
fois l'exécution de la méthode sans passer dans les boucles. Le garbage
collector c'est sympa, mais gourmand en ressources aussi. Les types des objets
sont aussi constamment vérifiés pour s'assurer qu'ils correspondent à ce qui
est attendu. Il y a d'autres exemples, surtout des choses liées à
l'introspection.
Tout ça pour dire que ce qui rend Java lent, d'après moi, c'est pas le fait
qu'ils utilisent du pseudo-code (sinon les compilateurs natifs feraient un
tabac) mais le fait que le Java passe son temps à tout vérifier. Ça en fait
aussi l'un des langages les plus sûrs.
(*) C'est fait à la volée donc globalement ça ralentit l'exécution du
programme, mais ça ne change rien si la jvm compilait au lancement (le délai
serait alors ressenti au début au lieu d'être réparti). Les puristes te disent
que de JITer le code ça permettrait de faire des optimisations à la volée et
que le code serait encore plus performant que du code compilé, mais
l'efficacité reste à prouver.
Dans les machines virtuelles, ou émulateurs, il y'a un intermédiaire entre le processeur et le logiciel (ou le script logiciel). C'est cet intermédiaire qui est la cause d'un ralentissement de l'éxécution, quelque soit ce qu'il fait, ramassage de miette ou pas.
Prends le cas d'une jvm récente. Le pseudo-code est compilé (*) et s'exécute quasi-nativement. On n'est pas dans le cas où chaque instruction est interprétée à chaque fois qu'on tombe dessus. Le sur-coût du pseudo code est relativement petit.
Par contre, le code des méthodes est analysé pour vérifier la cohérence de la pile, ce qui correspond d'après les spécialistes à un délai d'environ 1 à 2 fois l'exécution de la méthode sans passer dans les boucles. Le garbage collector c'est sympa, mais gourmand en ressources aussi. Les types des objets sont aussi constamment vérifiés pour s'assurer qu'ils correspondent à ce qui est attendu. Il y a d'autres exemples, surtout des choses liées à l'introspection.
Tout ça pour dire que ce qui rend Java lent, d'après moi, c'est pas le fait qu'ils utilisent du pseudo-code (sinon les compilateurs natifs feraient un tabac) mais le fait que le Java passe son temps à tout vérifier. Ça en fait aussi l'un des langages les plus sûrs.
(*) C'est fait à la volée donc globalement ça ralentit l'exécution du programme, mais ça ne change rien si la jvm compilait au lancement (le délai serait alors ressenti au début au lieu d'être réparti). Les puristes te disent que de JITer le code ça permettrait de faire des optimisations à la volée et que le code serait encore plus performant que du code compilé, mais l'efficacité reste à prouver.
-- Cyrille Szymanski
Vincent Burel
"Cyrille Szymanski" wrote in message news:
On 2005-05-25, Vincent Burel wrote: > Dans les machines virtuelles, ou émulateurs, il y'a un intermédiaire
entre
> le processeur et le logiciel (ou le script logiciel). C'est cet > intermédiaire qui est la cause d'un ralentissement de l'éxécution,
quelque
> soit ce qu'il fait, ramassage de miette ou pas.
Prends le cas d'une jvm récente. Le pseudo-code est compilé (*) et
s'exécute
quasi-nativement. On n'est pas dans le cas où chaque instruction est interprétée à chaque fois qu'on tombe dessus. Le sur-coût du pseudo code
est
relativement petit.
mouai, petit, sur un P4 3ghz on voit pas la différence de vitesse sur une application disons "usuel", sur un P120 on voit bien que ca va 15 fois moins vite. Non, c'est la puissance des machine qui donne sont de l'intérêt au langages interprétés... et sur du document ou de la gestion, qu'un processus se fasse en 1ms ou en 10ms, on s'en fout. Parions que dans 10 ans, on ne n'évoquera même plus du tout ce problème potentiel de vitesse...
VB
"Cyrille Szymanski" <cns@cns2.invalid> wrote in message
news:slrnd9bqe2.ft1.cns@szymanski4.rez-gif.supelec.fr...
On 2005-05-25, Vincent Burel <vincent.burel@spam-wanadoo.fr> wrote:
> Dans les machines virtuelles, ou émulateurs, il y'a un intermédiaire
entre
> le processeur et le logiciel (ou le script logiciel). C'est cet
> intermédiaire qui est la cause d'un ralentissement de l'éxécution,
quelque
> soit ce qu'il fait, ramassage de miette ou pas.
Prends le cas d'une jvm récente. Le pseudo-code est compilé (*) et
s'exécute
quasi-nativement. On n'est pas dans le cas où chaque instruction est
interprétée à chaque fois qu'on tombe dessus. Le sur-coût du pseudo code
est
relativement petit.
mouai, petit, sur un P4 3ghz on voit pas la différence de vitesse sur une
application disons "usuel", sur un P120 on voit bien que ca va 15 fois moins
vite. Non, c'est la puissance des machine qui donne sont de l'intérêt au
langages interprétés... et sur du document ou de la gestion, qu'un processus
se fasse en 1ms ou en 10ms, on s'en fout. Parions que dans 10 ans, on ne
n'évoquera même plus du tout ce problème potentiel de vitesse...
On 2005-05-25, Vincent Burel wrote: > Dans les machines virtuelles, ou émulateurs, il y'a un intermédiaire
entre
> le processeur et le logiciel (ou le script logiciel). C'est cet > intermédiaire qui est la cause d'un ralentissement de l'éxécution,
quelque
> soit ce qu'il fait, ramassage de miette ou pas.
Prends le cas d'une jvm récente. Le pseudo-code est compilé (*) et
s'exécute
quasi-nativement. On n'est pas dans le cas où chaque instruction est interprétée à chaque fois qu'on tombe dessus. Le sur-coût du pseudo code
est
relativement petit.
mouai, petit, sur un P4 3ghz on voit pas la différence de vitesse sur une application disons "usuel", sur un P120 on voit bien que ca va 15 fois moins vite. Non, c'est la puissance des machine qui donne sont de l'intérêt au langages interprétés... et sur du document ou de la gestion, qu'un processus se fasse en 1ms ou en 10ms, on s'en fout. Parions que dans 10 ans, on ne n'évoquera même plus du tout ce problème potentiel de vitesse...
