Où ça en général ? quelqu'un l'a montré vérifié quelque part ? avec des data sérieux à l'appui ? Je ne parle pas des stats commerciales bidon, mais des data de tests sérieux faites par des gens sérieux.
Disons que quand on connait l'architecture et le développement Palm Os, on peut formuler des opinions éclairées.
Disons que lorsqu'on fait de l'optimisation et la caractérisation de performances sur un tas d'applications, systèles et d'archi depuis 10 ans, on a encore une meilleure opinion.
Il faut qu'elle soit particulièrement mal programmée, et ça ne sera pas un problème d'émulation.
Si l'émulation gère mal les appels systèmes pour libérer/allouer de la mémoire, ou si l'émulation a besoin d'ouvrir ou de fermer un environnement particulier pour chaque application, cela se sentirait au niveau de l'utilisateur (latence de basculement entre appli).
L'émulation 68k de Garnet est tout sauf peu performante...
qui l'a démontré mis à part les affirmations ?
Ce n'est pas le tri qui va prendre du temps, surtout avec le petit nombre d'applications. C'est de récupérer les informations sur les applications, en particulier les icônes. C'est particulièrement visible avec le Lifedrive, par exemple. Si tu as une carte SD, enlève-là, pour voir ce que ça donne.
ce que vous citez est relatif aux performances du système d'entrée/sortie. Mes applications ainsi que mes icônes sont toutes sur le Treo pas sur une SD.
Possible, mais pas en permanence. Attention aussi à la stack Bluetooth qui a tendance à boucler sur le Treo.
le BT est désactivé par défaut chez moi (pour préserver la batterie). Mes pbs de performances ne sont pas permanents (plusieurs secondes de latence quelque fois). Le pire est lorsque je suis en communication et que je bascule vers une autre appli (agenda, contact, etc). Ceci renforce les doutes sur la couche téléphonie.
Exemple d'application qui met 10-30 secondes pour se lancer: tomtom. Vive l'émulation :)
Je persiste à dire que l'émulation binaire et les techniques de virtualisation sont de la daube: p de performances et de consommation. Les études expérimentales qui démontrent le contraire sont bidon. Je n'ai jamais mordu aux arguments pseudo techniques des partisans de cette machine à vapeur. Cependant, j'accorde le bénéfice principal: l'émulation et la virtualisation permettent de se déconnecter commercialement des fournisseurs des processeurs, améliorant ainsi la compétitivité et la course à la réduction des coûts unitaires. Si on veut pousser, on dit aussi que cela permet de figer une application binaire qui fonctionne (plus besoin de recompiler au risque de découvrir des cochonneries dans le code).
Le 17.06.2009 13:48, Patrick V a écrit :
Ceci (le cas général) est tout à fait vérifié.
Où ça en général ? quelqu'un l'a montré vérifié quelque part ? avec des
data sérieux à l'appui ? Je ne parle pas des stats commerciales bidon,
mais des data de tests sérieux faites par des gens sérieux.
Disons que quand on connait l'architecture et le développement Palm Os,
on peut formuler des opinions éclairées.
Disons que lorsqu'on fait de l'optimisation et la caractérisation de
performances sur un tas d'applications, systèles et d'archi depuis 10
ans, on a encore une meilleure opinion.
Il faut qu'elle soit particulièrement mal programmée, et ça ne sera pas
un problème d'émulation.
Si l'émulation gère mal les appels systèmes pour libérer/allouer de la
mémoire, ou si l'émulation a besoin d'ouvrir ou de fermer un
environnement particulier pour chaque application, cela se sentirait au
niveau de l'utilisateur (latence de basculement entre appli).
L'émulation 68k de Garnet est tout sauf peu performante...
qui l'a démontré mis à part les affirmations ?
Ce n'est pas le tri qui va prendre du temps, surtout avec le petit
nombre d'applications. C'est de récupérer les informations sur les
applications, en particulier les icônes. C'est particulièrement visible
avec le Lifedrive, par exemple. Si tu as une carte SD, enlève-là, pour
voir ce que ça donne.
ce que vous citez est relatif aux performances du système
d'entrée/sortie. Mes applications ainsi que mes icônes sont toutes sur
le Treo pas sur une SD.
Possible, mais pas en permanence. Attention aussi à la stack Bluetooth
qui a tendance à boucler sur le Treo.
le BT est désactivé par défaut chez moi (pour préserver la batterie).
Mes pbs de performances ne sont pas permanents (plusieurs secondes de
latence quelque fois). Le pire est lorsque je suis en communication et
que je bascule vers une autre appli (agenda, contact, etc).
Ceci renforce les doutes sur la couche téléphonie.
Exemple d'application qui met 10-30 secondes pour se lancer: tomtom.
Vive l'émulation :)
Je persiste à dire que l'émulation binaire et les techniques de
virtualisation sont de la daube: p de performances et de consommation.
Les études expérimentales qui démontrent le contraire sont bidon. Je
n'ai jamais mordu aux arguments pseudo techniques des partisans de cette
machine à vapeur. Cependant, j'accorde le bénéfice principal:
l'émulation et la virtualisation permettent de se déconnecter
commercialement des fournisseurs des processeurs, améliorant ainsi la
compétitivité et la course à la réduction des coûts unitaires. Si on
veut pousser, on dit aussi que cela permet de figer une application
binaire qui fonctionne (plus besoin de recompiler au risque de découvrir
des cochonneries dans le code).
Où ça en général ? quelqu'un l'a montré vérifié quelque part ? avec des data sérieux à l'appui ? Je ne parle pas des stats commerciales bidon, mais des data de tests sérieux faites par des gens sérieux.
Disons que quand on connait l'architecture et le développement Palm Os, on peut formuler des opinions éclairées.
Disons que lorsqu'on fait de l'optimisation et la caractérisation de performances sur un tas d'applications, systèles et d'archi depuis 10 ans, on a encore une meilleure opinion.
Il faut qu'elle soit particulièrement mal programmée, et ça ne sera pas un problème d'émulation.
Si l'émulation gère mal les appels systèmes pour libérer/allouer de la mémoire, ou si l'émulation a besoin d'ouvrir ou de fermer un environnement particulier pour chaque application, cela se sentirait au niveau de l'utilisateur (latence de basculement entre appli).
L'émulation 68k de Garnet est tout sauf peu performante...
qui l'a démontré mis à part les affirmations ?
Ce n'est pas le tri qui va prendre du temps, surtout avec le petit nombre d'applications. C'est de récupérer les informations sur les applications, en particulier les icônes. C'est particulièrement visible avec le Lifedrive, par exemple. Si tu as une carte SD, enlève-là, pour voir ce que ça donne.
ce que vous citez est relatif aux performances du système d'entrée/sortie. Mes applications ainsi que mes icônes sont toutes sur le Treo pas sur une SD.
Possible, mais pas en permanence. Attention aussi à la stack Bluetooth qui a tendance à boucler sur le Treo.
le BT est désactivé par défaut chez moi (pour préserver la batterie). Mes pbs de performances ne sont pas permanents (plusieurs secondes de latence quelque fois). Le pire est lorsque je suis en communication et que je bascule vers une autre appli (agenda, contact, etc). Ceci renforce les doutes sur la couche téléphonie.
Exemple d'application qui met 10-30 secondes pour se lancer: tomtom. Vive l'émulation :)
Je persiste à dire que l'émulation binaire et les techniques de virtualisation sont de la daube: p de performances et de consommation. Les études expérimentales qui démontrent le contraire sont bidon. Je n'ai jamais mordu aux arguments pseudo techniques des partisans de cette machine à vapeur. Cependant, j'accorde le bénéfice principal: l'émulation et la virtualisation permettent de se déconnecter commercialement des fournisseurs des processeurs, améliorant ainsi la compétitivité et la course à la réduction des coûts unitaires. Si on veut pousser, on dit aussi que cela permet de figer une application binaire qui fonctionne (plus besoin de recompiler au risque de découvrir des cochonneries dans le code).
Patrick V
anon a écrit :
Ceci (le cas général) est tout à fait vérifié.
Où ça en général ? quelqu'un l'a montré vérifié quelque part ? avec des data sérieux à l'appui ? Je ne parle pas des stats commerciales bidon, mais des data de tests sérieux faites par des gens sérieux.
Tous les développeurs Palm OS peuvent le confirmer.
Disons que quand on connait l'architecture et le développement Palm Os, on peut formuler des opinions éclairées.
Disons que lorsqu'on fait de l'optimisation et la caractérisation de performances sur un tas d'applications, systèles et d'archi depuis 10 ans, on a encore une meilleure opinion.
On va peut-être arrêter là le concours de bites ?
Il faut qu'elle soit particulièrement mal programmée, et ça ne sera pas un problème d'émulation.
Si l'émulation gère mal les appels systèmes pour libérer/allouer de la mémoire, ou si l'émulation a besoin d'ouvrir ou de fermer un environnement particulier pour chaque application, cela se sentirait au niveau de l'utilisateur (latence de basculement entre appli).
Si c'était le cas, en effet. Mais heureusement, il n'y a pas ce type de problème : je l'ai déjà dit, les APIs sont quasiment natives.
L'émulation 68k de Garnet est tout sauf peu performante...
qui l'a démontré mis à part les affirmations ?
Toi, en ne t'apercevant pas avant que j'en parle que c'était émulé ;-)
le BT est désactivé par défaut chez moi (pour préserver la batterie). Mes pbs de performances ne sont pas permanents (plusieurs secondes de latence quelque fois).
Le pire est lorsque je suis en communication et que je bascule vers une autre appli (agenda, contact, etc). Ceci renforce les doutes sur la couche téléphonie.
Oui, ça me semble une bonne piste. Mais normalement, toutes les applications de base devraient être en natif, sans passage par l'émulation. "Normalement" parce que Palm a laissé certaines parties hors standard Palm OS en émulé, et je ne peux pas vérifier pour l'instant.
Exemple d'application qui met 10-30 secondes pour se lancer: tomtom. Vive l'émulation :)
Houla, attention avec ce genre d'applications : elles font des trucs que la morale réprouve, pour contourner les limites de l'OS, donc leur comportement n'est pas vraiment représentatif. Et ce n'est pas une question d'émulation. Sans compter qu'elles peuvent chercher à se connecter au GPS avant même d'être en navigation, ce qui peut générer une attente inutile : c'est le cas avec ViaMichelin en Bluetooth si le GPS n'est pas allumé, par exemple. Par contre, on peut noter que Tomtom utilise un port série (réel ou virtuel pour Bluetooth), comme la téléphonie, on peut donc imaginer des interférences entre des threads qui gèrent des ressources similaires.
Je persiste à dire que l'émulation binaire et les techniques de virtualisation sont de la daube: p
L'émulation 68k de Palm OS n'est pas une bête émulation binaire, puisque les APIs sont natives. Par contre, on ne sait pas comment est faite l'émulation sur le Pre mais comme ce n'est pas intégré à l'OS et que les APIs Palm OS ne doivent pas exister en Palm WebOS, ça ne peut pas être aussi efficace.
Enfin bon, comme il s'agit d'émuler un 68k à 16MHz, ça ne doit pas présenter de difficultés. Mais ça reste un pis-aller, d'autant que les applications utilisant du code natif ARM (comme Tomtom justement, ou un certain nombre de jeux) ne vont probablement pas fonctionner.
Cependant, j'accorde le bénéfice principal:
Dans le cas de Palm OS, il y a un bénéfice secondaire mais indispensable qui est que ça existe et ça marche, même si ça fait un peu usine à gaz, alors que si on avait attendu l'OS6, ben en fait on attendrait encore :-(
anon a écrit :
Ceci (le cas général) est tout à fait vérifié.
Où ça en général ? quelqu'un l'a montré vérifié quelque part ? avec des
data sérieux à l'appui ? Je ne parle pas des stats commerciales bidon,
mais des data de tests sérieux faites par des gens sérieux.
Tous les développeurs Palm OS peuvent le confirmer.
Disons que quand on connait l'architecture et le développement Palm Os,
on peut formuler des opinions éclairées.
Disons que lorsqu'on fait de l'optimisation et la caractérisation de
performances sur un tas d'applications, systèles et d'archi depuis 10
ans, on a encore une meilleure opinion.
On va peut-être arrêter là le concours de bites ?
Il faut qu'elle soit particulièrement mal programmée, et ça ne sera pas
un problème d'émulation.
Si l'émulation gère mal les appels systèmes pour libérer/allouer de la
mémoire, ou si l'émulation a besoin d'ouvrir ou de fermer un
environnement particulier pour chaque application, cela se sentirait au
niveau de l'utilisateur (latence de basculement entre appli).
Si c'était le cas, en effet. Mais heureusement, il n'y a pas ce type de
problème : je l'ai déjà dit, les APIs sont quasiment natives.
L'émulation 68k de Garnet est tout sauf peu performante...
qui l'a démontré mis à part les affirmations ?
Toi, en ne t'apercevant pas avant que j'en parle que c'était émulé ;-)
le BT est désactivé par défaut chez moi (pour préserver la batterie).
Mes pbs de performances ne sont pas permanents (plusieurs secondes de
latence quelque fois).
Le pire est lorsque je suis en communication et
que je bascule vers une autre appli (agenda, contact, etc).
Ceci renforce les doutes sur la couche téléphonie.
Oui, ça me semble une bonne piste. Mais normalement, toutes les
applications de base devraient être en natif, sans passage par
l'émulation. "Normalement" parce que Palm a laissé certaines parties
hors standard Palm OS en émulé, et je ne peux pas vérifier pour l'instant.
Exemple d'application qui met 10-30 secondes pour se lancer: tomtom.
Vive l'émulation :)
Houla, attention avec ce genre d'applications : elles font des trucs que
la morale réprouve, pour contourner les limites de l'OS, donc leur
comportement n'est pas vraiment représentatif. Et ce n'est pas une
question d'émulation. Sans compter qu'elles peuvent chercher à se
connecter au GPS avant même d'être en navigation, ce qui peut générer
une attente inutile : c'est le cas avec ViaMichelin en Bluetooth si le
GPS n'est pas allumé, par exemple. Par contre, on peut noter que Tomtom
utilise un port série (réel ou virtuel pour Bluetooth), comme la
téléphonie, on peut donc imaginer des interférences entre des threads
qui gèrent des ressources similaires.
Je persiste à dire que l'émulation binaire et les techniques de
virtualisation sont de la daube: p
L'émulation 68k de Palm OS n'est pas une bête émulation binaire, puisque
les APIs sont natives. Par contre, on ne sait pas comment est faite
l'émulation sur le Pre mais comme ce n'est pas intégré à l'OS et que les
APIs Palm OS ne doivent pas exister en Palm WebOS, ça ne peut pas être
aussi efficace.
Enfin bon, comme il s'agit d'émuler un 68k à 16MHz, ça ne doit pas
présenter de difficultés. Mais ça reste un pis-aller, d'autant que les
applications utilisant du code natif ARM (comme Tomtom justement, ou un
certain nombre de jeux) ne vont probablement pas fonctionner.
Cependant, j'accorde le bénéfice principal:
Dans le cas de Palm OS, il y a un bénéfice secondaire mais indispensable
qui est que ça existe et ça marche, même si ça fait un peu usine à gaz,
alors que si on avait attendu l'OS6, ben en fait on attendrait encore :-(
Où ça en général ? quelqu'un l'a montré vérifié quelque part ? avec des data sérieux à l'appui ? Je ne parle pas des stats commerciales bidon, mais des data de tests sérieux faites par des gens sérieux.
Tous les développeurs Palm OS peuvent le confirmer.
Disons que quand on connait l'architecture et le développement Palm Os, on peut formuler des opinions éclairées.
Disons que lorsqu'on fait de l'optimisation et la caractérisation de performances sur un tas d'applications, systèles et d'archi depuis 10 ans, on a encore une meilleure opinion.
On va peut-être arrêter là le concours de bites ?
Il faut qu'elle soit particulièrement mal programmée, et ça ne sera pas un problème d'émulation.
Si l'émulation gère mal les appels systèmes pour libérer/allouer de la mémoire, ou si l'émulation a besoin d'ouvrir ou de fermer un environnement particulier pour chaque application, cela se sentirait au niveau de l'utilisateur (latence de basculement entre appli).
Si c'était le cas, en effet. Mais heureusement, il n'y a pas ce type de problème : je l'ai déjà dit, les APIs sont quasiment natives.
L'émulation 68k de Garnet est tout sauf peu performante...
qui l'a démontré mis à part les affirmations ?
Toi, en ne t'apercevant pas avant que j'en parle que c'était émulé ;-)
le BT est désactivé par défaut chez moi (pour préserver la batterie). Mes pbs de performances ne sont pas permanents (plusieurs secondes de latence quelque fois).
Le pire est lorsque je suis en communication et que je bascule vers une autre appli (agenda, contact, etc). Ceci renforce les doutes sur la couche téléphonie.
Oui, ça me semble une bonne piste. Mais normalement, toutes les applications de base devraient être en natif, sans passage par l'émulation. "Normalement" parce que Palm a laissé certaines parties hors standard Palm OS en émulé, et je ne peux pas vérifier pour l'instant.
Exemple d'application qui met 10-30 secondes pour se lancer: tomtom. Vive l'émulation :)
Houla, attention avec ce genre d'applications : elles font des trucs que la morale réprouve, pour contourner les limites de l'OS, donc leur comportement n'est pas vraiment représentatif. Et ce n'est pas une question d'émulation. Sans compter qu'elles peuvent chercher à se connecter au GPS avant même d'être en navigation, ce qui peut générer une attente inutile : c'est le cas avec ViaMichelin en Bluetooth si le GPS n'est pas allumé, par exemple. Par contre, on peut noter que Tomtom utilise un port série (réel ou virtuel pour Bluetooth), comme la téléphonie, on peut donc imaginer des interférences entre des threads qui gèrent des ressources similaires.
Je persiste à dire que l'émulation binaire et les techniques de virtualisation sont de la daube: p
L'émulation 68k de Palm OS n'est pas une bête émulation binaire, puisque les APIs sont natives. Par contre, on ne sait pas comment est faite l'émulation sur le Pre mais comme ce n'est pas intégré à l'OS et que les APIs Palm OS ne doivent pas exister en Palm WebOS, ça ne peut pas être aussi efficace.
Enfin bon, comme il s'agit d'émuler un 68k à 16MHz, ça ne doit pas présenter de difficultés. Mais ça reste un pis-aller, d'autant que les applications utilisant du code natif ARM (comme Tomtom justement, ou un certain nombre de jeux) ne vont probablement pas fonctionner.
Cependant, j'accorde le bénéfice principal:
Dans le cas de Palm OS, il y a un bénéfice secondaire mais indispensable qui est que ça existe et ça marche, même si ça fait un peu usine à gaz, alors que si on avait attendu l'OS6, ben en fait on attendrait encore :-(
Cornelia Schneider
Patrick V wrote in news:4a3901af $0$437$:
On va peut-être arrêter là le concours de bites ?
Et le troll aussi, tant qu'à faire... Z'avez pas de killfile, les gars ? Un peu marre de continuer de lire ce clampin dans vos citations.
Cornelia
-- Be out and be proud - today is the first day of the rest of your life Support Transgenre Strasbourg : www.sts67.org Creative stuff : www.bownbend.com GPG key ID 83FF7452
Patrick V <Patrick.V.u.i.c.h.a.r.d@mitgard.invalid> wrote in news:4a3901af
$0$437$426a74cc@news.free.fr:
On va peut-être arrêter là le concours de bites ?
Et le troll aussi, tant qu'à faire... Z'avez pas de killfile, les gars ? Un
peu marre de continuer de lire ce clampin dans vos citations.
Cornelia
--
Be out and be proud - today is the first day of the rest of your life
Support Transgenre Strasbourg : www.sts67.org
Creative stuff : www.bownbend.com
GPG key ID 83FF7452
Et le troll aussi, tant qu'à faire... Z'avez pas de killfile, les gars ? Un peu marre de continuer de lire ce clampin dans vos citations.
Cornelia
-- Be out and be proud - today is the first day of the rest of your life Support Transgenre Strasbourg : www.sts67.org Creative stuff : www.bownbend.com GPG key ID 83FF7452
anonymous
Le 17/06/2009 16:46, Patrick V a écrit :
Tous les développeurs Palm OS peuvent le confirmer.
Tous ? pas sûr. A mon avis, y a pas eu un vote sur le sujet, ni un congrès, ni une étude sérieuse.
On va peut-être arrêter là le concours de bites ?
oui, mais faut pas lancer un combat avant de s'assurer qu'on a une chance de l'emporter.
Toi, en ne t'apercevant pas avant que j'en parle que c'était émulé ;-)
L'impression d'un utilisateur est subjective. Vous connaissez la situation de la grenouille qui ne s'aperçoit que l'eau qui l'entoure est en train de bouillir ?
Le 17/06/2009 16:46, Patrick V a écrit :
Tous les développeurs Palm OS peuvent le confirmer.
Tous ? pas sûr. A mon avis, y a pas eu un vote sur le sujet, ni un
congrès, ni une étude sérieuse.
On va peut-être arrêter là le concours de bites ?
oui, mais faut pas lancer un combat avant de s'assurer qu'on a une
chance de l'emporter.
Toi, en ne t'apercevant pas avant que j'en parle que c'était émulé ;-)
L'impression d'un utilisateur est subjective. Vous connaissez la
situation de la grenouille qui ne s'aperçoit que l'eau qui l'entoure est
en train de bouillir ?
Tous les développeurs Palm OS peuvent le confirmer.
Tous ? pas sûr. A mon avis, y a pas eu un vote sur le sujet, ni un congrès, ni une étude sérieuse.
On va peut-être arrêter là le concours de bites ?
oui, mais faut pas lancer un combat avant de s'assurer qu'on a une chance de l'emporter.
Toi, en ne t'apercevant pas avant que j'en parle que c'était émulé ;-)
L'impression d'un utilisateur est subjective. Vous connaissez la situation de la grenouille qui ne s'aperçoit que l'eau qui l'entoure est en train de bouillir ?
Patrick V
anonymous a écrit :
On va peut-être arrêter là le concours de bites ?
oui, mais faut pas lancer un combat avant de s'assurer qu'on a une chance de l'emporter.
Ah ok, tu veux continuer... Bon, ben je te laisse, alors.
anonymous a écrit :
On va peut-être arrêter là le concours de bites ?
oui, mais faut pas lancer un combat avant de s'assurer qu'on a une
chance de l'emporter.
Ah ok, tu veux continuer... Bon, ben je te laisse, alors.
