Articles précédents : Logiciel
- [157] OpenOffice 2.0
- [70] MySQL 5.0 est sorti
- [12] Gnumeric 1.6 disponible
- [86] Galeon fusionne avec Epiphany
- [48] Faire entrer les logiciels libres à l'école
- [5] Apache Geronimo est certifié J2EE 1.4
- [14] Sortie de Deskzilla 1.0
- [173] La version 3 de Nessus sera propriétaire
- [37] Internet, le 2 octobre 2005 - Wesnoth 1.0
- [48] Quake IV et Serious Sam 2 sous GNU/Linux
Liens connexes
- WineHQ (2206 hits)
- Annonce de la 0.9 (615 hits)
- Codeweavers (338 hits)
- Qemu (550 hits)
- ReactOS (691 hits)
Dépêche modérée par
Dépêche éditée par
Pour rappel, Wine (Wine is not an emulator) est un lot de bibliothèques compatibles Win32 dont le but est de pouvoir faire tourner nativement des applications Win32 sous Linux, FreeBSD et autres Unix-like en version x86. Il est aussi maintenant possible de les faire tourner sur d'autres architectures via Qemu.
NdM : merci à inico pour avoir également proposé une dépêche à ce sujet.
WineHQ (2206 hits)
Annonce de la 0.9 (615 hits)
Codeweavers (338 hits)
Qemu (550 hits)
ReactOS (691 hits)
> Lire la suite (86 commentaires, moyenne: 3,1). [dépêche : 1007 caractères]
- disparition du fichier .wine/config au profit d'une application winecfg
- un grand nombre de DLL disponibles nativement, supprimant ainsi la majorité des besoins de DLL natives Microsoft.
À noter aussi que Crossover Office, version commerciale de Wine, vient également de sortir en version 5, qui apporte - entre autre - le support de MS Office 2003 et les nouvelles fonctionnalités de Wine 0.9.
De mon point de vue, Wine 0.9 est la version la plus stable de Wine qu'il m'ait été donné de tester : elle permet de faire tourner la majeure partie des logiciels Windows pour mes besoins professionnels : Office XP, IE 6, etc. sans avoir besoin de Crossover pour le faire.
À noter aussi que Wine travaille en collaboration avec ReactOS (système d'exploitation se voulant un clone de Windows NT, compatible aussi bien au niveau kernel que applicatif) ; la version 0.9 devrait leur permettre une compatibilité accrue avec les logiciels prévus pour l'OS de la firme de Redmond.
Super !
Bonne nouvelle !!!
Mais je n arrive pas a trouver la version wine pour windows sur le site ?!
..
==> [ ]
-
[^]Re: Super !
Posté par Ulrich VANDENHEKKE (Jabber id, page perso, ) le 27/10/2005 à 17:24. (lien). Évalué à 2.C'est vrai que c'est pratique pour faire tourner les programmes Windows sous Windows ;)
-
[^]Re: Super !
-
-
[^]Re: Super !
Posté par smorico (page perso, ) le 27/10/2005 à 17:39. (lien). Évalué à 10.Oui, c'est normal il faut utiliser cygwin :p
-
[^]Re: Super !
Posté par Mildred (Jabber id, page perso, ) le 27/10/2005 à 18:08. (lien). Évalué à 6.Et c'est ici: http://www.winehq.com/site/fun_projects
Titre : Virtualization Projects
Wine under Cygwin in Windows (In Progress)-
[^]Re: Super !
-
-
[^]moule inside
Posté par Infernal Quack (Jabber id, page perso, ) le 27/10/2005 à 18:56. (lien). Évalué à 9.C'est pas un peu beaucoup ? Une seule ne suffit pas ? /o\
-
[^]Re: moule inside
Posté par nayco (page perso, ) le 27/10/2005 à 21:22. (lien). Évalué à 4.Non, six sont nécessaires, pour une sombre question de liaisons dynamiques...
-
[^]Re: moule inside
-
-
Re: quel travail de titans !
J'allais justement proposer une dépêche à ce sujet. Wine est vraiment un projet d'envergure, actif, dynamique. En plus, il en est vraiment à un stade avancé. Rendez-vous compte, faire fonctionner des applications comme MS Office en ayant réécrit la plus grande partie de l'API win32 !
Enfin bon. Toujours est-il que pour ma part, je ne me sers de wine que pour faire tourner une seule application win32 : emu48 (c'est un émulateur de calculatrice hp48/49 sous license GPL). Il est dommage que ce programme ne fonctionne pas correctement avec wine en ce qui concerne la ROM de la hp49 :-/ Je suis obligé d'utiliser un autre émulateur, mais moins riche en fonctionnalités.
-
[^]Re: quel travail de titans !
Posté par baud123 (Jabber id, page perso, ) le 27/10/2005 à 17:47. (lien). Évalué à 4.ah t'avais une dépêche, donc peut-être encore plus de matière à proposer / des retours d'expérience plus détaillés sur le sujet alors ? non ?
Ben
Je veux pas faire ma mauvaise langue, mais on aura un Wine 1.0 pour la sortie de Windows Vista. En clair, quand Wine aura fini par implémenter les bibliothèques de Windows, ce dernier passera à des choses totalement nouvelles.
Après, on peut espérer que Windows Vista soit un flop(trop de changements font fuire les utilisateurs) et que ReactOs domine le monde :)
-
[^]Re: Ben
Posté par serge_kara () le 27/10/2005 à 18:38. (lien). Évalué à 10.c'est le probleme commun a tous les projets libres tentant d'emuler (oui, oui, je sais, Wine Is Not an Emulator) des projets de mastodontes du proprio : moins de ressources humaines car infiniment moins de pognon, donc toujours en retard et donc grosse baffe dans la gueule a chaque changement de version majeur.
Cela dit, ca devrait deja depanner pas mal de monde d'avoir un win32 complet, donc l'effort n'es pas vain non plus.
-
[^]Re: Ben
Posté par Mathieu Acher (page perso, ) le 27/10/2005 à 19:00. (lien). Évalué à 6.Si les programmes faits pour tourner sous windows XP (par exemple) marcheront sous Windows Vista, pourquoi Wine ne suivrait pas ?
-
[^]Re: Ben
Posté par serge_kara () le 27/10/2005 à 19:35. (lien). Évalué à 4.le probleme c'est pas tant de faire marcher les programmes XP qui devraient a priori tourner dans une certaine mesure, c'est plutot de faire tourner les porgrammes Vista, qui eux profiteront d'une nouvelle api et donc totalement pas compatible du tout avec celle de wine.
-
[^]Sauf que ...
Posté par Ludovic Danigo () le 27/10/2005 à 19:53. (lien). Évalué à 4.... pour ça existe Mono.
Donc je vois pas où est le problème. Wine pour la compatibilité API Win32 et Mono pour la compatibilité API .Net.
C'est donc un faux problème.-
[^]Re: Sauf que ...
Posté par gnumdk (page perso, ) le 27/10/2005 à 20:27. (lien). Évalué à 4.Euh, faudrait un peu te renseigner sur Vista avant de parler ;)
Quand y'aura Winfs(apres la sortie de vista) + Aero(interface) + Indigo(ipc), ben t'auras beau avoir Wine win32, ca marchera pas !
Et je te rappelle que Mono permet de compiler(avec adaptation) un programme .Net, pas de faire tourner les executable créer avec les outils microsoft. Donc, pour ce qui interesse la majorité des utilisateurs de Wine, c'est à dire les logiciels proprio, ca t'avancera pas à grand chose Mono.-
[^]Re: Sauf que ...
Posté par pasBill pasGates () le 27/10/2005 à 22:08. (lien). Évalué à 4.Et je te rappelle que Mono permet de compiler(avec adaptation) un programme .Net, pas de faire tourner les executable créer avec les outils microsoft. Donc, pour ce qui interesse la majorité des utilisateurs de Wine, c'est à dire les logiciels proprio, ca t'avancera pas à grand chose Mono.
Ah bon ? Il m'avait pourtant semble que Mono avait une CLR, qui permettrait des lors de faire tourner les softs sans recompilation tant que les assemblies sont presentes.-
[^]Re: Sauf que ...
Posté par stephwww () le 27/10/2005 à 22:28. (lien). Évalué à 2.[...]
>>Ah bon ? Il m'avait pourtant semble que Mono avait une CLR, [..]
Pour les incultes comme moi et peut être d'autre cest quoi CLR ?-
[^]Re: Sauf que ...
Posté par pasBill pasGates () le 27/10/2005 à 23:53. (lien). Évalué à 4.C'est en gros la machine virtuelle qui traduit le MSIL (equivalent du byte code Java) en code executable.
Bref, c'est similaire a une machine virtuelle Java-
[+] [^]Re: Sauf que ...
Posté par Mr F (page perso, ) le 28/10/2005 à 09:04. (lien). Évalué à -3.Bref, c'est similaire a une machine virtuelle Java
Y comprit sur les points de lourdeur et de lenteur ?-
[^]Re: Sauf que ...
Posté par serge_kara () le 28/10/2005 à 09:26. (lien). Évalué à 4.pour la millieme fois une jvm n'est pas lente!!!
gourmande en ram, oui, ca c'est avere.
Mais ca n'est pas lent!!!
Java se traine cette legende urbaine qui remonte a ya plusieurs annees, mais ca n'est plus le cas!!!
un peu comme si on disait que le c/c++ est lent parce qu'en 89 les compilos ne suivaient pas...-
[^]Re: Sauf que ...
Posté par Mildred (Jabber id, page perso, ) le 28/10/2005 à 10:00. (lien). Évalué à 3.Sauf que lorsque onb a déja une grande partie de la ram occupée, je suppose que ca ralentit car ca swappe et tout ... non ?
-
[^]Re: Sauf que ...
Posté par serge_kara () le 28/10/2005 à 10:21. (lien). Évalué à 3.Si ta question est :
Quand le systeme swap, est ce que le systeme swap?
La reponse est :
Oui, quand le systeme swap, le systeme swap.
Ce a quoi j'ai envie d'ajouter :
Pas de pierres... pas de palais!
Pas de palais... pas de palais!
Apres on va me dire :
Oui mais c'est de la merde, c'est pas utilisable sur une vieille machine.
Ce a quoi je reponds :
Il ne me parait pas anormal qu'une techno recente tourne mal sur une machine ancienne.
-
[^]Re: Sauf que ...
Posté par Kévin FERRARE (page perso, ) le 29/10/2005 à 00:03. (lien). Évalué à 3.Eclipse sur un ordi avec 256Mo de ram est inutilisable sous linux à cause de ca ...
Sous windows je sais pas pourquoi, mais ca passe très bien par contre
probablement la JVM de sun qui est à la traine sous linux ...-
[^]Re: Sauf que ...
Posté par lasher () le 29/10/2005 à 10:21. (lien). Évalué à 0.Euh, non. J'ai développé des applis J2EE sur un duron 650 avec 512Mo de RAM, et je t'assure que ça ne se passe pas très bien. En gros, voilà comment se déroulaient les choses :
Eclipse + JBoss + plugins Eclipse : tourne bien au début. Après plusieurs heures de dév, de démarrage/arrêt du serveur, de chargement de diverses webapps de test, etc... La machine est inutilisable, et met parfois une bonne minute (voire plus) avant de prendre en compte un quelconque élément en entrée (clavier, souris).
Deux solutions pour ça : trifouiller la JVM (allocation de +/- de RAM, etc.), et ... rajouter 512Mo de RAM. Grâce à ça, on peut avoir plus de temps avant que la machine ne se mette à rammer. Et donc, je pouvais faire mes heures de bureau sans accroc. Evidemment, ce genre de "solution" n'est pas viable pour un serveur en production. Mais dans ce cas, il vaudrait mieux avoir un vrai admin, qui sache comment on configure correctement une JVM.
Bref. Java n'est pas lent, mais bouffe effectivement de la mémoire, et Windows semble mal gérer celle-ci, ce qui ralentit le système au final.
Sous linux, Eclipse est moins bien, mais au moins je n'ai jamais eu les problèmes constatés ci-dessus.-
[^]Re: Sauf que ...
Posté par CrEv (page perso, ) le 29/10/2005 à 11:57. (lien). Évalué à 1.Je ne sais pas si certains ont essayés mais il existe sous win des programmes qui permettent de "nettoyer" la ram et de la libérer (rambooster par exemple). Peut-être simplement que ça permettrait de faire tourner plus simplement.
Sinon, quand tu dis que ecplise est moins bien sous linux ça veut dire quoi ?
Je fais pas trop de java mais je n'ai jamais trop ressenti de problème avec ecplise...-
[^]Re: Sauf que ...
Posté par pasBill pasGates () le 02/11/2005 à 01:27. (lien). Évalué à 3.Je ne sais pas si certains ont essayés mais il existe sous win des programmes qui permettent de "nettoyer" la ram et de la libérer (rambooster par exemple). Peut-être simplement que ça permettrait de faire tourner plus simplement.
Ces softs sont une escroquerie, aucun de ces softs n'est capable de liberer de la RAM sur W2k/XP/WS03-
[^]Re: Sauf que ...
Posté par CrEv (page perso, ) le 03/11/2005 à 15:31. (lien). Évalué à 2.ok, domage.
donc il ne reste qu'une solution :
monter des nouvelles barettes à chaud :-D
-
-
-
-
[^]Re: Sauf que ...
Posté par serge_kara () le 29/10/2005 à 18:42. (lien). Évalué à 1.eclipse utilisable avec 256 sur windows?
Je suis sceptique quand meme..
512 ca roule, je me tape generalement un freeze de 10-15 secondes juste apres le demarrage, apres ca tourne toute la journee sans aucun probleme.-
[^]Re: Sauf que ...
Posté par Alexandre LISSY (Jabber id, ) le 29/10/2005 à 21:08. (lien). Évalué à 0.Sous FreeBSD en tout cas je l'ai fait cet été. Et en laissant Eclipse d'un jour sur l'autre!
Certes, c'était pas comme mon desktop à la maison avec 1Go de ram ...
-
-
-
-
[^]Re: Sauf que ...
Posté par Guillaume Knispel () le 28/10/2005 à 14:00. (lien). Évalué à 5.lol, la bonne blague :)
En fait si je te lis au pied de la lettre ce que tu dis est vrai : la JVM n'a rien de lent (ce qui tourne dedans si par contre ;)
C'est pas parce qu'une machine de base actuelle (du genre PIV à 2GHz avec 1 Go de RAM) peut faire tourner une petit IHM en Java sans que le tout rame que ça veut dire que Java est rapide. La lenteur (toute relative donc selon le contexte), n'en est pas une tare pour autant, l'interet de Java est ailleurs. Le jour ou Java servira à écrire des codes de calculs je voudrais bien croire qu'"il est rapide" (si tant est que "il est rapide" à un sens, vu que tout dépend bien evidemment du contexte etc...)
Bon ceci étant si on compare aujourd'hui un soft en Java bien codé et un bloatware à la Gnome, KDE, OOo, ou FF, effectivement Java peu sembler carrement très rapide (voir même économe en mémoire :))
De toute façon le débat n'a pas de sens tant qu'on compare des tomates et des carottes. Il faudrait écrire de gros soft de calcul en Java et en Whatever (avec la même architecture, les mêmes algorithmes, etc) pour pouvoir comparer "la vitesse", ça risque fort de ne jamais se faire, donc on en restera à des trolls (comme le mien, j'avoue) et des approximations, ainsi que des incompréhension mutuelle dues à un contexte différent dans la tête des interlocuteurs.-
[^]Re: Sauf que ...
Posté par CrEv (page perso, ) le 28/10/2005 à 14:53. (lien). Évalué à 1.je crois que ce qu'il voulait dire (et qu'il a dit dans un autre commentaire, ou en tout cas je l'ai lu il y a pas longtemps...) c'est que java en tant que langage n'est pas beaucoup plus lent qu'un langage compilé, essentiellement grace au JIT.
Par contre ce qui est très lent et très mal fait sont les interfaces, SWING est horrible, SWT un poil mieux mais associé à une jvm moins bonne sous linux que sous windows on arrive à une horreur.
Donc en gros si on avait un toolkit graphique digne de ce nom sous java, l'impression de lenteur serait beaucoup moins présente.
Enfin, c'est ce que j'ai pu comprendre, allez voire dans la news OOo ça doit êter là le débat je crois... ;-)-
[^]Re: Sauf que ...
Posté par Guillaume Knispel () le 28/10/2005 à 15:37. (lien). Évalué à 3.Mwai enfin dès que tu lis les manuels d'intel tu as de très gros doutes sûr la capacité d'un JIT quel qu'il soit à produire le summum de l'efficacité. Des perfs pas trop nulles, voilà ce à quoi on peut s'attendre, et c'est déjà pas mal finalement. Mais de là à concurrencer du code produit par ICC avec les sections critiques parrallélisé et vectorialisées, du prefechting et conseil de branchement conditionel produit par profiling et autre, j'ai un léger doute.... Sans même compter de l'hyperthreading dont l'interet peut énormement varier selon l'archi générale (pouvant même aller jusqu'à la diminution des perfs dans des cas patologiques)
Pendant que les VM ont fait des progrès non négligeable, les compilo classiques aussi. Et les processeurs sont devenus d'une grande complexitée. Et ce n'est pas parce que "c = a+b" Java va être traduit en "add %eax, %ebx" par du JIT à un moment donné que l'ensemble va atteindre ce qu'on sait faire de mieux en terme de performance.-
[^]Re: Sauf que ...
Posté par lasher () le 29/10/2005 à 14:48. (lien). Évalué à 1.« Pendant que les VM ont fait des progrès non négligeable, les compilo classiques aussi »
Bouais. Beaucoup moins. Et le JIT de Java permet clairement bien plus d'optimisations que ce que tu sembles dire. Attention, je ne dis pas qu'on obtiendra au final quelque chose d'optimal, mais certainement pas aussi "mauvais" que ce que tu sembles croire (même si tu rappelles bien que les perfs obtenues sont déjà pas mal ;-) ).
Je ne suis pas un fan absolu de Java, mais les JVM avec JIT sont très bien pensées, et le langage permet vraiment beaucoup de choses au niveau optimisations... Ah, si seulement il était libre ...-
[^]Re: Sauf que ...
Posté par benp () le 29/10/2005 à 22:08. (lien). Évalué à 1.le JIT de Java permet clairement bien plus d'optimisations que ce que tu sembles dire.
C'est juste qu'il manque encore un "-Os"
et le langage permet vraiment beaucoup de choses au niveau optimisations
c'est la première fois que je l'entend celle-là !
-
-
-
[^]Re: Sauf que ...
Posté par serge_kara () le 29/10/2005 à 18:53. (lien). Évalué à 2.voila, c'est exactement ca.
SWT tourne tres bien sous windows, en etant reactif. Mais la lib n'est pas encore mure, ils y sont presque, je pense qu'on aura un SWT parfaitement mur pour la version 5 (estimation pyfometre total).
SWING peut tourner a peu pres decemment, mais ca reste un gros bouzin immonde.
Et pour ce qui est du calcul pur, j'ai fait un bench (rapide) fortran/java 1.4 de code de calcul scientifique (simulation numerique pour l'armee), java etait 1.3 fois plus lent que le code fortran.
Je suis pas sur que le C++ aurait ete tellement plus rapide.
Le code a ete porte a l'arrache de chez arrache, en utilisant systematiquement des objets au lieu des types de bases.
Et en utilisant java5, on devrait pouvoir encore diminuer cet ecart, et plus encore en adaptant le code au langage.
Ce qui fait perdre du temps, c'est le lancement de la jvm, ca s'est grandement ameliore avec java5, faut que la transition se fasse quoi.
Regarde une appli comme eclipse, c'est un truc monstrueux qui fait enormement de choses en meme temps et reste pourtant tres reactif et pas si gourmand que ca au vu de tout ce qu'il fait (je tourne generalement dans les 100-150Mo d'occupation, avec 4 projets ouvert, lomboz/tomcat en plugin, 20 a 30 jars de dependances par projet et quelques dizaines de milliers de lignes de code en tout)
Regarde tomcat qui supporte de grosse charges sans broncher, et pourtant c'est pas les I/O qui manquent sur un serveur d'appli (entre les logs, les IO reseau, les connections DB etc..)-
[^]Re: Sauf que ...
Posté par Morreale Jean Roc () le 29/10/2005 à 21:06. (lien). Évalué à 3.jette un oeil ici pour voir ce que le bousin immonde peut donner quand on sait y faire : http://jroller.com/page/gfx
-
-
-
[^]Re: Sauf que ...
Posté par Krunch (Jabber id, page perso, ) le 28/10/2005 à 15:36. (lien). Évalué à 3.l faudrait écrire de gros soft de calcul en Java et en Whatever (avec la même architecture, les mêmes algorithmes, etc) pour pouvoir comparer "la vitesse"
Comme ça ? http://shootout.alioth.debian.org/
J'ai l'impression que la lenteur de Java est surtout due au temps que met la JVM à se lancer. Ce qui semble provenir du fait qu'elle doit allouer plein de mémoire. Pour une application serveur c'est pas forcément grave mais pour des "petites" applications qu'on lance/arrète souvent et quand on doit développer sur une "petite" machine c'est l'enfer.
Tiens tant qu'on est dans les trolls sur Java, quelqu'un peut m'expliquer l'intérêt de générer des .class ? Ca serait pas plus pratique que la JVM utilise directement les .java ? Les .class sont quand même parsés et vérifiés de toute façon. Ou bien j'ai rien compris.--
Free Softwares Users Group Arlon (Sud Luxembourg, Belgique)
pertinent, e adj. Approprié ; qui se rapporte exactement à ce dont il est question.-
[^]Re: Sauf que ...
Posté par Sylvain Sauvage () le 28/10/2005 à 19:10. (lien). Évalué à 5.Ça te fera de la peine si je te réponds que t'as rien compris ?
C'est tout l'intérêt d'une machine virtuelle : le .class est un code machine, il suffit de l'exécuter (= le traduire en code machine réelle), le .java est à interpréter (= à « comprendre », analyser...).-
[^]Re: Sauf que ...
Posté par serge_kara () le 29/10/2005 à 18:40. (lien). Évalué à 2.sans compter que le .class est compilé, donc syntaxiquement et semantiquement correct, optimise et legerement preprocesse (genre l'autoboxing de java5)
-
-
-
[^]Re: Sauf que ...
Posté par lasher () le 29/10/2005 à 14:37. (lien). Évalué à 2.Euh, tu sais qu'il existe des softs de calcul en Java hein ? :-) Je veux dire, de vrais softs. Avec des multiplications de matrices, tout ça. Et ils s'en sortent plutôt bien. Attends, je vais te retrouver ça...
Voilà :
« Java Signal Processing : FFTs with bytecodes » (John Glossner, Jesse Thilo, Stamatis Vassiliadis). Le papier date de 98, et depuis Java a fait pas mal de progrès dans le domaine de l'optimisation en temps (en espace - donc en mémoire - c'est autre chose). Pour te résumer l'article, faire des transformées de Fourier rapides avec Java, c'est faisable. L'expérience avait été faite sur des Ultra-Sparc II avec 128Mo de RAM, avec Java 1.1.4 (sur diverses JVM) et comparé avec gcc 2.7. Au final, Java est en moyenne 2 à 3 fois plus lent qu'un code C optimisé. Mais c'était en 98. Depuis, on a encore largement amélioré les optimisations concernant Java (et aussi celles concernant C avec GCC, mais moins -- les efforts à partir de GCC 3 sont bien plus concentrés sur C++).
« Developing numerical libraries in Java » (Ronald F. Boisvert, Jack J. Dongarra, Roldan Pozo, Karin A. Remington, G.W. Stewart). Résultats (là encore, il ne faut pas oublier qu'on est en 98) : oui ben, y'a plein de trucs bien en Java, mais bon, quand même, c'est pas la panacée, y'a plein d'autres trucs qui manquent, du coup il faut faire plus d'effort quand on est programmeur pour avoir de bons résultats. Mais les travaux sur le JIT ont l'air intéressants, ça devrait booster les résultats.
Et miracle, c'est le cas.
Dernière chose, je te conseille de mater à cette adresse : http://shootout.alioth.debian.org/benchmark.php?test=all&(...)
Tu y verras entre autres les différents résultats obtenus par des benches dans le domaine du calcul [1]. Et que Java se situe devant g++ et le compilo c++ d'intel.
Mais à part ça, Java, c'est lent.
[1] évidemment, il en faut pas oublier ce que dit l'auteur sur le site, à propos des biais qu'on trouve dans ce genre de tests.-
[^]Re: Sauf que ...
Posté par Guillaume Knispel () le 29/10/2005 à 17:38. (lien). Évalué à 6.Hélas, 1000x hélas, pas beaucoup de calcul numérique sur ce site (site qui a déjà été cité plus haut) (du moins tel que je l'entend, les FFT cadrant très bien avec ce que cela veut dire dans cet esprit). De l'algorithmie, certes, mais du calcul, quand il y en a, Java se fait ramasser. Jave reste derrière C (ce qui n'est guère étonnant). Étant donné la structure des tous petits tests proposé, un bon gros calcul numérique bien barbarre ferait fondre la différence C, C++ (d'ailleurs quand on entre dans ce domaine dans les tests précités, le C++ repasse largement devans Java et reste ultra proche de C). De toute manière le classement final dépand des coefficiant, on pourrait augmenter les perf du C++ en ajoutant des options de compilation (mais qui ne serait pas forcement utilisable en prod selon le contexte, donc faut-il le faire ou non?). Bref le lien me montre que Java est lent (même s'il y a pire).
Mais on peut faire dire n'importe quoi aux bench, non ? Donc autant les oublier completement, why not...
Je me rappele un soft de FTP distribué en Java qu'on avait écrit en projet de 2è année d'école d'info. Il utilisait un calcul MD5, et au début on avait pas trouvé la routine de la biblio standard qui permet de faire ça, donc on avait pris un code source Java qui avait été écrit au temps ou le calcul de MD5 n'était pas encore en standard dans la biblio. Les performances étaient, JIT ou pas JIT, horrible. N'importe quelle routine en C même écrite n'importe comment explosait litteralement le pauvre code source Java d'un rapport au moins x4 (j'ai plus les chiffres exactes en tête, mais à mon avis c'étais plutôt x10). Et à chaque fois que j'essaie la bête opération de prendre un gros bout de code C absolument bête, linéaire, etc, et que je le porte en Java tel quel (impossible de faire autrement qu'une bête recopie + adaptations ultra minimal de toute façon vu comment le code est bête), et que je fais un bench, ben j'ai la confirmation que Java c'est lent. Et je ne parle même pas des perfs qu'on peut atteindre en asm avec un code vectoriel. Dès qu'on a utilisé la routine fournis avec la JVM, les choses sont devenues correctes. Bref, quand Java est "rapide" en calcul numérique (et ça reste relatif, le "rapide"), c'est que les implémentations des routines de calcul critiques en question sont écrites en C.
Java n'est pas mauvais quand il s'agit de faire de l'algorithmie. Par contre je n'appele pas être 3x plus lent s'en sortir bien en matière de calcul numérique, domaine par excellence ou l'on veut tout tirer du processeur, jusqu'à qu'il en puisse plus (en utilisant les optim que j'ai citée plus haut et d'autres, dont certaines sont inaccessibles par nature à Java). Java ne permet pas de faire ça. En matière de calcul numérique, je persiste Java est lent.
En matière d'IHM aussi, Java est très lent. Pas besoin de faire des bench, suffit d'utiliser une appli pour ce rendre compte à quel point ça rame (ou alors c'est juste une coincidence et toutes les appli que j'utilise en Java rament ? De toute manière c'est vrai que je dois être mauvaise langue, si ça se trouve ce n'est pas Java mais mon ordi qui est lent, et ouai les gens qui ont des P12 à 20THz ne doivent pas trouver les appli dotées d'IHM et écrites en Java particulièrement lente ;)
Je ne vois pas pourquoi malgré l'évidence les défenseurs de Java omnubilés par ce langage n'arrivent pas à reconnaitre qu'il est par nature plus lent que le C dans enormement de domaines. Ça n'a rien de honteux, ça n'en fait pas un langage pestiféré, et il a d'autres qualités. Python aussi est lent, Perl est lent, bash est lent (si tant est que dire que bash est lent ait un sens) et alors ?
Bref à l'heure actuelle implanter les routines de calculs critique en Java n'a pas trop d'interet et cela va pas changer du jour au lendemain (ni même en 1 an).
Pour un langage à VM, Java s'en sort vraiment pas mal, j'en conviens (grâce au JIT justement). Ça n'en fait pas un foudre de guerre. Java reste plus lent que d'autres.-
[^]Re: Sauf que ...
Posté par Cook Captain () le 29/10/2005 à 22:50. (lien). Évalué à 2.A propos du md5, je te conseille le site suivant :
http://www.twmacinta.com/myjava/fast_md5.php
"The very surprising (for me) thing to note is that the Fast MD5 implementation outperforms the native "md5sum" (textutils-2.0.14-2.i386.rpm ) binary even when the native methods aren't used"
-
-
[^]Re: Sauf que ...
Posté par benp () le 29/10/2005 à 22:22. (lien). Évalué à 2.En haut du benchmark que tu indique on lis:
« And remember, languages that implement more benchmarks will move to the top of the list, and those with many missing benchmarks (No Program, Error, Timeout) will stay at the bottom! »
Or il manque 4 benchs seulement pour Java, mais il en manque 9 pour g++ et 11 pour i++.
Parce que bon, c#/mono qui pulvérise intel c++ bofff...
Donc tout ce qu'on peut déduire de ce benchmark, c'est que pour les tests effecutés, java est le plus lent parmi les language pour lesquels il ne manque que 4 progs de bench. Derrière Pascal (!), Ocaml, forth, Haskell et Ada95.
-
-
-
[^]Re: Sauf que ...
Posté par benp () le 29/10/2005 à 00:21. (lien). Évalué à 2.pour la millieme fois une jvm n'est pas lente!!!
gourmande en ram, oui, ca c'est avere.
Il consomme tellement de ram (qu'il faut allouer au départ, c'est pas rapide) que les ordinateurs personnels sont considérablement ralentis: surexitation de la vm, eventuelle swappage de furieux etc. Et le temps d'initialisation de toute cette mémoire (et de la jvm) est très long.
Bref, au fur et a mesure que le temps passe, les devs java trouvent de nouvelles belles techniques objet, et ajoutent des couches d'abstractions qui font que les applis sont toujours plus gourmandes. L'évolution de la puissance du matériel domestique ne suffit pas à endiguer l'évolution des libs java.
Java sur un poste de travail domestique (je veut dire: tout sauf un serveur):
- relancer les applis très souvent (vs prgm résident, sur les serveurs): lourd
- pas beaucoup de mémoire (vs plusieurs gigas sur les serveurs): lourd
Lance OOo à froid, mesure le temps de chargement. Puis décoche toutes les options java, redémare la machine et relance OOo à froid. J'ai fait cette expérience, et il faudrait vraiment etre de mauvaise fois pour ne pas reconnaitre l'influence nefaste de Java sur une appli déjà pas favorisée.
-
-
-
-
-
[^]Re: Sauf que ...
Posté par Brice Arnould ( un_brice ) (page perso, ) le 28/10/2005 à 17:49. (lien). Évalué à 1.Ah bon ? Il m'avait pourtant semble que Mono avait une CLR, qui permettrait des lors de faire tourner les softs sans recompilation tant que les assemblies sont presentes.
Le problème c'est que les API sont pas toutes implémentables, pour des raisons de brevets.--
Respect à RMS.-
[^]Re: Sauf que ...
Posté par pasBill pasGates () le 29/10/2005 à 06:24. (lien). Évalué à 2.De ce que je vois, ca ne semble pas gener Mono, et MS ne semble pas s'en plaindre non plus.
-
-
-
[^]Re: Sauf que ...
Posté par Sigmatador () le 28/10/2005 à 11:08. (lien). Évalué à 4.99% des exportations de NTDLL.DLL et de KERNEL32.DLLl de Windows 2000/XP sont présentes dans leur version "Vista", et il y en a très peu de rajoutée. Au pire, les programmes "Vista only" utiliseront des DLL specifiques, mais au final l'interface avec le noyau restant quasiment inchangée, ca ne fera que des DLL de plus à rajouter dans la liste des DLL à developper pour la team WINE. Au pire pire, pour les sans scrupule, les DLL de microsoft pourront etre utilisées tel quel.
Enfin bon, je doute que Microsoft casse la compatibilité avec XP avant un bout de temps.
Sinon pour .NET, tous les binaires compatibles .NET 1.1 SP1 que l'on m'a passé ont fonctionnés normalement avec mono (maintenant p-e qu'ils n'utilisaient pas d'API .NET très exotiques)
-
-
[^]Re: Sauf que ...
Posté par Matthieu Moy (page perso, ) le 27/10/2005 à 20:38. (lien). Évalué à 5.Je crois pas que Mono se soit donné comme objectif de supporter les API spécifiques Windows.
-
-
-
[^]Re: Ben
Posté par JAGUENAUD Anthony () le 27/10/2005 à 20:07. (lien). Évalué à 2.Je fonctionne sous Win 2000, que j'ai acheté, et je n'ai pour l'instant trouvé aucun programe qui ne fonctionnait pas sous Win 2000, donc le temps que Vista s'impose vraiment, WINE aura eu le temps de suivre.
-
[^]Re: Ben
Posté par gnumdk (page perso, ) le 27/10/2005 à 20:38. (lien). Évalué à 3.Euh, tu sais, Windows Vista, il est pas encore sorti ;)
Mais t'inquietes, Microsoft a tout prévu, les technologies de Vista seront dispo pour les versions précédentes de Windows, comme ca, les programmes récent tourneront sous Xp & co.
Après, je sais pas comment Microsoft pense gérer la phase de transition, parce que Vista impose de grand changement niveau IHM, et ca risque d'être un beau bordel au début, pire que la transition gtk1 vers gtk2.
http://www.bentuser.com/FileRepository/c655ca0d-740f-4a1f-98(...)-
[^]Re: Ben
Posté par Sylvain (Jabber id, page perso, ) le 27/10/2005 à 21:26. (lien). Évalué à 2.Euh... Windows vista a part directX 10 sera toujours du w32sdk ... Donc compatible W2k,wxp, se sera l'ajout de fonction via .NET.
de plus d'une version de windows a une autre il ajoute des fonctions dans le w32sdk donc il ya fort a parier qu'il yaura une extension du w32sdk.
A part si il passe tout les anciens programme en emulations il sont obliger de garder le w32sdk meme si il change certaine routine dans leur travail de fond la plupart voir toutes auront les meme structures... A part les nouvelles fonctions mais qui seront pas utilisé dans les anciens programme.
-
-
-
-
[^]Re: Ben
Posté par b (page perso, ) le 28/10/2005 à 11:40. (lien). Évalué à 3.C'est pas trop grave, la majorité des gens ne va pas passer à Vista. Et Wine sera la pour faire tourner les vieux programmes antiques.
-
[^]Re: Ben
Posté par arno (Jabber id, ) le 29/10/2005 à 02:52. (lien). Évalué à 2.C'est clair. Tout ce que je lui demandes c'est de continuer a faire tourner la série des Baldur's Gate et de rajouter (bientôt ? :) la série Total War (Shogun, médieval). Ça, ce serait le pied.
Un grand merci aux développeurs pour ce boulot souvent décrié.
-
[+] ReactOS ?
À mon avis, voilà un truc débile. Car à ma connaissance la documentation technique de Windows est secrète (NFS par exemple). Déjà que la tâche de Wine et de Mono est titanesque et périlleuse. Alors comment peuvent ils cloner Windows NT? L'approche de Qemu me semble de loin la meilleur et la plus simple. Enfin si ça les occupe.
-
[^]Re: ReactOS ?
-
[^]Re: ReactOS ?
Posté par Matthieu C () le 27/10/2005 à 19:40. (lien). Évalué à 2.Car à ma connaissance la documentation technique de Windows est secrète (NFS par exemple).
Et alors pourquoi veux tu utiliser du NTFS ?
Tu crois que les appli windows comme Office regarde sur quel fs il tourne ?
Non ils font comme pour ndiswrapper, java, mono, ... il reimplemente toute l'API windows dont une grande partie est detaillé sur msdn...-
[+] [^]Re: ReactOS ?
Posté par salvaire () le 27/10/2005 à 23:00. (lien). Évalué à -9.NTFS est le système de fichier de NT. Donc NT sans NTFS c'est pas NT. Et il y a surement des applications lié à NTFS.
-
[^]Re: ReactOS ?
Posté par Seazor (Jabber id, ) le 28/10/2005 à 08:44. (lien). Évalué à 5.Des applis liées à ntfs ?
Si ils utilisent les APIs win, les API réécrites peuvent utiliser autre chose que ntfs.
Si pas, j'leur ferais pas trop confiance sous un vrai NT !
De toutes facons, tout ce boulot, c'est pas vraiment pour faire tourner les programmes de defrag pour NT !!--
"We all freezed on a bugged subroutine, bugged subroutine, bugged subroutine..." (nearly Beatles)
-
-
[^]Re: ReactOS ?
Posté par salvaire () le 27/10/2005 à 23:03. (lien). Évalué à 1.il reimplemente toute l'API windows dont une grande partie est detaillé sur msdn..
Là j'ai des doutes. Si il y a des tractations avec Bruxelles à propos de la documentation de Windows. C'est que tout n'est pas divulgué!-
[^]Re: ReactOS ?
Posté par serge_kara () le 28/10/2005 à 08:55. (lien). Évalué à 5.et s'il a ecrit "dont une grande partie", c'est qu'il est au courant du probleme, non?
-
-
-
[^]Re: ReactOS ?
Posté par inico (Jabber id, page perso, ) le 27/10/2005 à 21:03. (lien). Évalué à 4.C'est en bonne voie.
Et puis c'est un moyen d'avoir un OS win32 stable :D--
"Les États-Unis sont le seul pays à être passé de la barbarie à la décadence sans connaître la civilisation." -- (origine réelle inconnue) Albert Einstein/Oscar Wilde/Georges Clemenceau/etc..
Complet ?
Si c'est complet, pourquoi est-ce que tous les programmes windows ne fonctionnent pas ?
Question innocente, honnêtement, je n'essaie pas de dénigrer ce travail.
Le seul programme que j'aimerais pouvoir faire tourner sous Wine, c'est Operation Flashpoint. Le seul truc qui me manque vraiment de mes années windows. Qqn l'a fait fonctionné ?
-
[^]Re: Complet ?
Posté par Benjamin G. ( Prae ) (page perso, ) le 27/10/2005 à 19:33. (lien). Évalué à 3.surement à cause de l'implémentation de DirectX qui n'est pas complet.
La version de Wine est dite complète pour les applications classiques, pas forcément pour les jeux.-
[^]Re: Complet ?
Posté par Mildred (Jabber id, page perso, ) le 27/10/2005 à 23:11. (lien). Évalué à 4.Question peut être bête ... pourquoi ne peux on pas télécharger DirectX de chez MS et l'installer avec Wine ..?
Ca ne marcherait pas ?-
[^]DirectX de chez MS et l'installer avec Wine
Posté par rzr (Jabber id, page perso, ) le 27/10/2005 à 23:49. (lien). Évalué à 2.oui... A condition que les drivers win s installent ds wine
sinon un article interessant sur directX X (X)
http://www.transgaming.com/gavstates.php
.... Microsoft's announcement that in Windows Vista, OpenGL will be implemented on top of the DirectX 9 APIs. ...
-
-
[^]Re: Complet ?
Posté par ploum (page perso, ) le 28/10/2005 à 01:13. (lien). Évalué à 3.y'a pas que des programmes avec direct X qui foirent, non ?
-
[^]Re: Complet ?
Posté par Mildred (Jabber id, page perso, ) le 28/10/2005 à 10:01. (lien). Évalué à 2.Il y a ausi les programmes buggés à mort sur Windows ...
Et aussi les programmes qui utilisent des bugs de l'API Windows. Tout le problème vient de trouver ces bugs et de les implémenter dans Wine. J'ai bon ?-
[^]Re: Complet ?
Posté par Krunch (Jabber id, page perso, ) le 28/10/2005 à 16:17. (lien). Évalué à 6.Les développeurs de Windows ont le même problème.
http://blogs.msdn.com/oldnewthing/archive/2003/12/23/45481.a(...)
http://blogs.msdn.com/oldnewthing/archive/2003/10/15/55296.a(...)--
Free Softwares Users Group Arlon (Sud Luxembourg, Belgique)
pertinent, e adj. Approprié ; qui se rapporte exactement à ce dont il est question.
-
-
-
-
[^]Re: Complet ?
Posté par inico (Jabber id, page perso, ) le 28/10/2005 à 08:14. (lien). Évalué à 3.Le probléme de ces programmes, c'est qu'ils utilisent des API qui ne sont pas documenté.
Wine a un bon support des API documenté mais apres c'est beaucoup plus dur.
--
"Les États-Unis sont le seul pays à être passé de la barbarie à la décadence sans connaître la civilisation." -- (origine réelle inconnue) Albert Einstein/Oscar Wilde/Georges Clemenceau/etc..-
[^]Re: Complet ?
Posté par ploum (page perso, ) le 28/10/2005 à 09:58. (lien). Évalué à 3.et comment ils font les programmeurs de ces programmes pour découvrir les API non documentées ?
-
[^]Re: Complet ?
-
[^]Re: Complet ?
Posté par inico (Jabber id, page perso, ) le 28/10/2005 à 17:54. (lien). Évalué à 3.Il faut du RE sur des programmes Microsoft et ils patchent en urgence leur programmes quand une nouvelle version de Windows sort ....
--
"Les États-Unis sont le seul pays à être passé de la barbarie à la décadence sans connaître la civilisation." -- (origine réelle inconnue) Albert Einstein/Oscar Wilde/Georges Clemenceau/etc..
-
[^]Re: Complet ?
Posté par Black Fox (page perso, ) le 28/10/2005 à 18:58. (lien). Évalué à 2.Certains sites et forums donnent ces informations.
-
-
question pour s'amuser
Mon fils qui n'en est pas à sa première compilation de wesnoth demande :
<<s'il est envisageable de lancer wine dans cygwin, peut on aussi lancer cygwin dans wine?
Et combien de fois peut on jouer à en mettre des couches comme ça?>>
Je ne dis pas que c'est utile, mais ça peut être marant à faire.
-
[^]Re: question pour s'amuser
Posté par inico (Jabber id, page perso, ) le 27/10/2005 à 20:58. (lien). Évalué à 4.On peut déjà lancer cygwin dans wine...
Après il y a un projet de virtualisation: wine via cygwin via wine ...--
"Les États-Unis sont le seul pays à être passé de la barbarie à la décadence sans connaître la civilisation." -- (origine réelle inconnue) Albert Einstein/Oscar Wilde/Georges Clemenceau/etc..
performances
Une question toute conne :
Si wine n'est pas de l'émulation, ça veux donc dire que si les bibliothèques win32 sont aussi bien faite que celles de windows, il est aussi rapide de faire tourner un programme sous wine que sous windows. C'est ça ?
et es-ce qu'elle sont aussi "bien" faites ?
je veux dire, aussi rapide
il sagit pas de troller, mais ça m'interroge.
et même si c'est pas aussi rapide, c'est déja super que ça marche...
-
[^]Re: performances
Posté par Seazor (Jabber id, ) le 28/10/2005 à 11:47. (lien). Évalué à 1.Aussi rapide, ben non forcément...
Si c'est win, c'est l'api native (=> difficile d'être + proche du système)
Si c'est du wine pour linux, faut exécuter les api linux qui vont faire l'équivallent, et ca n'est pas forcément fait en une seule fonction équivallente.
Exemple : si Direct3D demande un rectangle, pour wine, ca entrainera un démarrage d'OpenGL pour faire l'équivallent, ce qui ne se fait pas forcément de la même manière et donc implique une exécution plus lourde de par la "traduction".
En fait, c'est considéré a peu près comme des lib classiques.--
"We all freezed on a bugged subroutine, bugged subroutine, bugged subroutine..." (nearly Beatles)
-
[^]Re: performances
Posté par inico (Jabber id, page perso, ) le 28/10/2005 à 17:55. (lien). Évalué à 3.De temps en temps, tu as des applications qui sont plus rapide sous wine que sous windows.
Sinon generalement c'est legerement plus lent ...--
"Les États-Unis sont le seul pays à être passé de la barbarie à la décadence sans connaître la civilisation." -- (origine réelle inconnue) Albert Einstein/Oscar Wilde/Georges Clemenceau/etc..-
[^]Re: performances
Posté par Mickaël L () le 29/10/2005 à 09:24. (lien). Évalué à 2.Je me souviens avoir écrit un programme (un peu intensif pour ma machine de l'époque) sous scilab.
C'était du temps où j'avais encore les deux systèmes sur ma machine, et du coup, je n'avais plus de place sur la partition linux pour installer scilab. J'avais donc installé la vesion windows, et je faisais macer sous windows.
Un jour, j'en ai eu marre, et j'ai lancé le programme sous scilab sous wine. Je m'attendais réellemnt à mettre lamachine à genoux, mais j'étais désespéré.
Ca tournait très bien. En fait, en mesurant le temps passé dans l'algo, on trouvait que scilab sous wine était de l'ordre 5 fois plus rapide que scilab sous windows.
Même mi je n'en revenait pas.
-
ah ! ... d'accord !
mais ça sert à quoi d'utiliser des logiciels win sous linux. Autant retourner sous windows. Enfin, l'intérêt m'a l'air tellement petit que je vois pas l'utilité d'essayer.
-
[^]Re: ah ! ... d'accord !
Posté par kursus_hc () le 29/10/2005 à 18:59. (lien). Évalué à 4.Après avoir scalpé le semblant de troll que j'ai cru apercevoir au fond de ta question, je peux y répondre en toute sécurité:
mais ça sert à quoi d'utiliser des logiciels win sous linux
Basiquement ca sert à utiliser des logiciels win sous linux. Comme par exemple quand on veut utiliser un programme qui n'existe que sous windows (tu trouveras des exemples de programmes tout au long de ce journal).
Mais ca peut aussi servir dans une multitude de cas, qui varient selon tes besoins et ta curiosité. Si je prend mon cas personnel:
- faire tourner msn messenger pour avoir un support son/webcam
- lancer itunes parceque meme si c'est pas libre et trop gourmand l'interface rox
- s'amuser a comparer la vitesse d'execution du meme programme sous les deux os et perdre lamentablement son temps
- lancer le solitaire
Je n'oublie pas tous les utilisateurs pour qui au contraire de moi wine est un spectaculaire moyen de gagner du temps et de la productivité (car pas de reboot forcé), tous ceux qui vont pouvoir se séparer de leur multiboot, et aussi toux ceux pour qui wine est un excellent argument pour faire une transition win/linux en douceur.-
[^]Re: ah ! ... d'accord !
Posté par wohlgi () le 30/10/2005 à 03:22. (lien). Évalué à 1.Effectivement, l'argument de la transition me semble être celui qui tient le mieux la route.
A part ça, ça reste un forum dont le but est l'expression et le partage d'avis personnels. Et un avis qui amène à une réaction est toujours plus intéressant qu'un autre.
Merci pour ta réaction.-
[^]Re: ah ! ... d'accord !
Posté par Khanh-Dang (page perso, ) le 01/11/2005 à 21:34. (lien). Évalué à 4.Et d'ailleurs, même pour les extrémistes du libre, je tiens à dire que dans mon cas, j'essaye d'utiliser un programme libre (sous license GPL) qui a été écrit pour Windows et sans soucis de portabilité. Ce n'est pas parce qu'un programme est écrit pour un système propriétaire qu'il est nécessairement non libre.
D'ailleurs, il semble qu'il existe pas mal de logiciels libres de très bonne qualité écrits pour Windows uniquement. Je dis « il semble » parce que j'en ai croisé quelques uns que je n'ai pas eu l'occasion de tester, ne possédant pas le système d'exploitation de Microsoft.-
[^]Re: ah ! ... d'accord !
Posté par wohlgi () le 02/11/2005 à 17:58. (lien). Évalué à 0.En fait, ce que je voulais dire, c'est qu'il me semble que la quantité et la diversité de programmes existant pour linux est relativement étendue pour rendre l'utilisation de Wine quasiment inutile. Sans vouloir dénigrer l'utilisation de windows et du libre sous windows.
-
-
-



Cette discussion est archivée, il n'est plus possible de laisser des commentaires.
Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.