Le sql integre au langage me parait pas forcement indispensable quand on voit la qualite d'un ORM tel qu'hibernate
Je penses qu'il fait référence à la syntaxe LINQ disponible en C# et issu de SQL, pas directement à SQL.
Explique moi un peu mieux, parce que si tu codes un kernel en C, tu fais de la compilation séparée, avec le défaut de perf qui vient avec (mais C est tellement bas niveau que ça ne se voit pas trop, tout est fait à la main).
Tout est dans les parenthèses que tu as mis : en C tu ne fais pas de compromis au final, ca ne change pas grand chose sur les perfs.
Dans un langage à compilation globale (je répète, SMartEiffel, Lisaac et d'autres), tu as toujours la possibilité de compiler globalement tes petits bouts, ce qui ne te fera perdre aucun avantage par rapport à C, tout en gagnant le haut niveau
Ben non, parcque en Lisaac le fait de ne pas compiler globalement ca va te faire "réellement" perdre des perfs (sinon c'est que le compiler global n'apporte pas de gain).
Je sais pas moi, découper votre encodeur MPEG2 en par exemple 10 modules séparés, et remesurez les perfs. Soit il n'y a quasiment pas de perte et on se rend compte que l'optimisation globale ne sert quasiment à rien, soit les perfs sont nettement dégradées et ca justifie l'optimisation globale tout en mettant en avant la contradiction de la modularité.
De plus, pour info, il existe pas mal de techniques pour faire de la compilation globale à partir de compilation séparée
Oué bah c'est pour ça que je dis : "quand est ce que Lisaac va résoudre le problème".
Ils font comment quand ils développent en C/C++ ?
Ben la chaîne de production à partir de modules est parfaitement prise en compte par les outils (compilo, linker, makefile, IDE). Je te demande comment on fait en Lisaac.
Je te rappelle que le but du projet, c'est l'embarqué, pas d'être un concurrent de Java et C# pour des logiciels de gestion.
Euh, le troll du journal cible le kernel Linux, même si Linux tourne sur de l'embarqué, c'est un projet pour moi "énorme", les problématiques de modularité sont pleinement à prendre en compte.
la compilation séparée pour être un langage "moderne" couvrant les problèmes de "dev en équipe à l'exécution en passant par les tests, la documentation et le déploiement."
C'était une remarque plus général sur Lisaac, pas spécialement lié à la compilation séparée.
Tests : possibilité d'inclure des méta-données, de mocker dynamiquement le code (nécessite l'introspection et la génération dynamique de code).
Documentation : syntaxe spécialisée et utilisable par le compilateur pour générer automatiquement une documentation externe synchronisée à chaque compil
ation (cf C#).
Déploiement : composants "versionnable", "signables", introspection et chargement dynamique (plugins), abstraction hardware, déploiement à distance, etc.
Linux passe directement de la case je casse l'API à la case je corrige tous les drivers.
Euh, quand ils changent une API, c'est pas pour "corriger" les drivers, c'est généralement pour offrir de nouvelles possibilités (nécessaire pour le kernel ou les améliorations des périphériques supportés). Donc ils ne corrigent rien, au contraire, ils sont obligés de modifier tous les drivers (alors que certains étaient sans doute stable et éprouvés) en prenant le risque d'introduire de nouveaux bugs/régression. Ceci est d'autant plus dangereux que la fondation Linux n'a pas les moyens de faire des tests de non-régression sur l'ensemble du matos. Bref, ca se fait globalement au détriment de la qualité, sans parler du fait que ces bugs va falloir les corriger, et ca prend du temps.
Si l'API introduit une faille de sécurité tu la gardes ?
Bien sûr que non. Celà dis le cas est rare et justifie une évolution.
Le problème avec une ABI standardisée qu'on change
Je penses qu'il voulait dire "stabilisé" plutôt que "standardisé" : en gros faut pas qu'il change, ou rarerement.
On peut imaginer une ABI "stable" pendant 3 ans. Au bout de 3 ans une nouvelle version arrive, moyennant un coût supplémentaire le noyau peut gérer l'ancienne qui devient "deprecated" mais qui pête pas les drivers existants. Au bout de 3 nouvelles années, tu vires la vieille interface (on va pas la maintenir 107 ans) : en tout on a eu 6 ans de compatibilité binaire et 3 ans pour migrer les drivers encore maintenus/utilisés.
Ca me paraît totalement réalisable.
Euh, c'est vrai, une compil kernel ça prend 30s sur un Atom.
Tu réponds pas au problème : pour des questions d'emprunte mémoire, de sécurité, de spécificité matérielle, on a pas envie de charger tout le bouzin en mémoire. Comment en Lisaac je charge dynamiquement des modules en mémoire sans passer par une compilation/déploiement séparée ?
Faut savoir : le principal intérêt de Lisaac, c'est la compil globale qui apporte un gain de perf. Si le code est "modulable" et compilable/déployable séparrement, le compilo peut plus faire son boulot de compilation globale, on perd une bonne partie de l'intérêt de Lisaac.
Lisaac est "bydesign" conçu pour mettre en contradiction les gains de perf avec la modularité du code. Faut vous faire une raison, Lisaac se focalise sur des objectifs qui sont loins des préocupations des développeurs et packageurs.
Peut être que sur de l'embarqué où le kernel n'est pas trop complexe et qu'il y a un seul mainteneur ca peut servir à quelque chose... ou pas.
il y a toujours la possibilité de découper le C en petits bouts, et de coller un .h pour lier le tout.
\o/ J'attend de voir ça dans une équipe de développement et son environnement SVN/GIT+IDE+makefile...
J'attend aussi de voir le débuggueur...
Les langages modernes s'occupe de toutes les problématiques de la réalisation d'un soft, du dev en équipe à l'exécution en passant par les tests, la documentation et le déploiement.
On a l'impression qe Lisaac se focalise uniquement sur le dev et l'exécution.
Je ne parle pas de modules pour les perfs, mais tout simplement de modules pour des questions de distribution, de développement en équipe séparée, etc. Exemple : le kernel Linux est capable de charger un module "à chaud". Le module en question est déployé en tant que binaire séparé et n'est pas chargé automatiquement (sauf si la configuration de la machine l'indique bien évidemment).
Il faut également pouvoir charger des modules dans des espaces mémoires différents avec des droits différents (séparation userland/kernelland). Tout ca suppose qu'on passe par une autre étape qu'une bonne grosse compilation du bouzin qui contient tout vu quon connait pas la machine cible.
Sans parler que même si ca prend "seulement" 5 minutes à compiler sur ton quadri-coeur de la mort, pour le développeur c'est attroce comme environnement de test/déboggage.
Bref autant de critère qui rend la séparation en module indispensable pour tout gros projet, et un kernel est un gros projet.
Disons qu'il y a une interface 32 bits. Après suivant l'architecture cible, c'est soit une émulation (genre sur Itanium 64), soit un switch du mode d'exécution du thread (sur x64), cf http://en.wikipedia.org/wiki/WOW64
Oué euh si Windows tourne en 32 bits sur des machines 64 bits, c'est pas à cause de Flash : une application 32 bits peut tourner sur un Windows 64 bits, à commencer par Internet Explorer qui est présent dans les 2 versions sous Vista 64 bits.
C'est bien les pilotes 32 bits (et les vieux progs 16 bits) qui posent problème sur Windows 64 bits.
Moi aussi je vais troller :
Alors quand est-ce qu'on peut développer de façon modulaire avec compilation séparée en Lisaac ?
Non parcque bon le principal soucis du kernel Linux, son côté bloatware, c'est pas tant le fait que le langage utilisé ne propose d'héritage, c'est surtout que l'architecture monolithique retenue en fait un gros bouzin là où les micro-noyaux apporte "bydesign" une plus grande modularité.
Evidemment ca suppose que le langage soit "utilisable" pour cela...
Je suis globalement d'accord avec toi, mais pour relativiser tes propos, il faut tout de même noter qu'il n'y a pas non plus beaucoup d'appli/contenu "critique" en Flash. A part les risques sociaux que tu encours parcque tu n'a pas vu la dernière vidéo kikoolol sur youtube, il est quand même pas si compliqué de vivre sans Flash, alors que tous les jours au taf tu peux avoir des problèmes plus important en refusant d'utiliser un poste Windows.
Il n'y a pas de code Microsoft dans Moonlight (si ce n'est la suite de tests de compatibilité).
Moonlight et Gnash peuvent décoder des vidéos grâce à FFmpeg.
Le plus dangereux, c'est FFmpeg qui implémente des standards archi-blindés de brevets (et dont les licences sont payantes, y'a un modèle commercial derrière).
La FSF pousse Gnash (top 10 des appli prioritaires), dénigre ce qui tourne autour de mono, et oublie de parler de FFmpeg... cherchez l'erreur.
En C# le byte-code est donc bien interprété
Je vois pas le rapport entre le premier et le 2ème paragraphe.
La présence d'une machine virtuelle ou d'un environnement d'exécution ne défini en rien le fait que C# soit interprété.
cette interprétation utilise la technologie JIT qui permet de gagner en performance
JIT est une technique de "compilation", pas d'interprétation.
C'est même dans le nom : http://en.wikipedia.org/wiki/Just-in-time_compilation
je cite : "It converts code at runtime prior to executing it natively, for example bytecode into native machine code. The performance improvement over interpreters originates from caching the results of translating blocks of code, and not simply reevaluating each line or operand each time it is met (see Interpreted language)."
Ce qui se traduit par :
"Il converti le code pendant son déroulement avant de l'exécuter nativement, par exemple il converti le bytecode en code natif. Le gain de performance par rapport aux interpréteurs vient du fait de mettre en cache le résultat de la tranduction de bloc de code plutôt que de réévaluer chaque ligne ou opérateur à chaque fois qu'il le rencontre. (voir langage interprété)."
La compilation et l'interprétation sont 2 techniques différentes pour exécuter du code. Que la compilation se fasse en 2 étapes pour ajouter un niveau d'abstraction (machine virtuelle) ne change rien.
C# est un langage conçu pour être compilé en ciblant la CLI et cette dernière est conçue pour compiler du bytecode en code natif.
Il est possible d'interpréter le bytecode intermédaire, mais l'intérêt est limité. La page de mono sur l'environnement d'exécution décrit bien les différentes techniques utilisées et précise à propos de l'interpréteur : http://www.mono-project.com/Mono:Runtime
"Mono has both an optimizing just-in-time (JIT) runtime and a interpreter runtime. The interpreter runtime is far less complex and is primarily used in the early stages before a JIT version for that architecture is constructed. The interpreter is not supported on architectures where the JIT has been ported. "
Ce qui se traduit par : Mono a un moteur d'exécution optimisé à la volée (JIT) et un interpréteur. L'interpréteur est beaucoup moins complexe et est avant tout utilisé en amont avant qu'une version du moteur JIT pour l'architecture cible soit construit. L'interpréteur n'est pas supporté sur les architectures où le moteur JIT a été porté.
"Contrairement à C# le code n'est pas interprété par une machine virtuelle, c'est un langage compilé."
C# n'a jamais été conçu pour être interprété mais pour être compilé dans un code intermédiaire qui est lui même compilé à la volée (JIT), voir en avance (AOT).
L'interprétation, c'est totalement has been, ca sert uniquement à porter "rapidement" un langage sur une nouvelle plateforme matérielle en attendant une chaîne de compilation native.
Les mauvaises langues diront que les linuxiens se rabattent sur le peu de jeu disponible et que les windowsiens ont des jeux bien plus sexy à acheter pour le même prix.
Ben comme indiqué dans le journal qui cite Nero, le principal "atout" est la gravure de disque Blu-ray. Je sais pas si un soft libre le permet, mais si Nero est bien le seul a le proposer, ca a forcement un intérêt pour les possesseur de ce type de matériel.
Ben on aimerai qu'il représente ses élus, mais concrêtement il vote en âme et conscience, enfin plus généralement il suit les consigne de son parti.
Après la démocratie permet de renouveller les mandats et d'éliminer les "menteurs", enfin quand les électeurs s'en aperçoivent et n'oublient pas.
Non, ce n'est pas la bonne raison : on aurait très bien pu décider de tout mettre en LGPL/GPL
Pas convaincu, d'après ma compréhension tu ne peux pas mettre de code sous GPL/LGPL sur iPhone du tout, puisque l'application doit obligatoirement être signé numériquement. Un soft sous (L)GPL oblige à redistribuer cette clé pour permettre d'utiliser la version modifiée, mais c'est Apple qui détient la clé en question... (sauf jailbreak m'enfin ne pas respecter une licence (Apple) pour en utiliser une autre voilà quoi :))
Donc la véritable question n'est pas de savoir si monotouch doit être libre ou non, mais de savoir si c'est acceptable de faire un produit proprio quand on fait par ailleur la promotion du libre.
Là où je suis d'accord avec Jb, c'est que le modèle de double licence est largement répendu et accepté dans le monde du libre. Là où je ne suis pas d'accord, c'est que monotouch n'est justement pas sous double licence : même si la version sous GPL/LGPL n'est pas "utilisable", elle pourrait toujours être utile pour d'autres développeurs : technique de binding Objective-C par exemple ou façon de s'interfacer avec xcode, etc.
Bref, ca fait vraiment bizzare de voir MDI faire la promotion d'un produit totalement proprio sans version "libre". Je comprends que c'est un choix qui incombe à son employeur, Novell, mais quand même, c'est contraire à tout ce qu'il nous avait habitué.
Se sont-ils contentés d'encapsuler les APIs existantes via une couche Mono/C# ?
En gros c'est ça.
Ils utilisent la compilation AOT (AheadOfTime) pour produire un exécutable natif pour l'iPhone, ce dernier interdisant toute technique de JIT (JustInTime).
A côté ils fournissent un wrapper sur les API iPhone comme ils le font pour GTK ou autre, et un plugin de dev pour l'IDE MonoDevelop.
il a juste dit que c'était destiné à windows
C'est un simple préjugé sans fondement.
Je ne suis pas utilisateur de codeplex, je ne sais pas ce qui conduit ses utilisateurs à le choisir, mais faut croire que certains le choisisse pour faire des trucs pour Linux et pas pour Windows, exemple : http://openblade.codeplex.com/
ou tout simplement multiplateforme par nature : http://pyspec.codeplex.com/
On peut poser exactement la même question avec google code : pourquoi aller sur google code alors que sourceforce et tuxfamily existe ? Il y a sans doute de bonnes raisons puisque des gens font ce choix. C'est pas parcque toi tu vois pas les raisons qu'il n'y en a pas.
c'était de l'humour
Oué mais l'humour c'est plus drôle quand elle a un fond de vérité.
Ben en même temps il parle de la forge CodePlex qui soit disant imposerait Windows, un lien sur la FAQ de la forge en question ca me paraît pertinent non ?
Je ne vois rien sur le site de la fondation qui contredise la FAQ de codeplex...
Consommation mémoire après toutes ces opérations :
PN : 187Mo
TG : 233Mo
Evidemment les applis ne sont pas identiques, TG a sans doute beaucoup plus de fonctionnalités, mais quand même, il semble possible de faire des applis réactives et fonctionnelles avec autre chose que du C.
Ca n'a tout de même rien à voir avec le fait que ce soit un logiciel propriétaire ou non.
Si le format OpenDocument engendrait la violation d'un brevet du même genre par OpenOffice & co, la situation serait identique : obligé d'utiliser un logiciel "illégal" ou avoir des documents "inutilisables".
Le problème, c'est bien les brevets logiciels, et le fait d'utiliser un logiciel libre ou un format ouvert ne protège en rien.
[^] # Re: Rien de transcendant dirait-on
Posté par TImaniac (site web personnel) . En réponse au journal Noop : encore un nouveau langage ou bien nouvelle génération de langage. Évalué à 3.
Je penses qu'il fait référence à la syntaxe LINQ disponible en C# et issu de SQL, pas directement à SQL.
[^] # Re: rentrons dans le vif du sujet
Posté par TImaniac (site web personnel) . En réponse au journal Linux un bloat, ah bon ?. Évalué à 2.
Tout est dans les parenthèses que tu as mis : en C tu ne fais pas de compromis au final, ca ne change pas grand chose sur les perfs.
Dans un langage à compilation globale (je répète, SMartEiffel, Lisaac et d'autres), tu as toujours la possibilité de compiler globalement tes petits bouts, ce qui ne te fera perdre aucun avantage par rapport à C, tout en gagnant le haut niveau
Ben non, parcque en Lisaac le fait de ne pas compiler globalement ca va te faire "réellement" perdre des perfs (sinon c'est que le compiler global n'apporte pas de gain).
Je sais pas moi, découper votre encodeur MPEG2 en par exemple 10 modules séparés, et remesurez les perfs. Soit il n'y a quasiment pas de perte et on se rend compte que l'optimisation globale ne sert quasiment à rien, soit les perfs sont nettement dégradées et ca justifie l'optimisation globale tout en mettant en avant la contradiction de la modularité.
De plus, pour info, il existe pas mal de techniques pour faire de la compilation globale à partir de compilation séparée
Oué bah c'est pour ça que je dis : "quand est ce que Lisaac va résoudre le problème".
Ils font comment quand ils développent en C/C++ ?
Ben la chaîne de production à partir de modules est parfaitement prise en compte par les outils (compilo, linker, makefile, IDE). Je te demande comment on fait en Lisaac.
Je te rappelle que le but du projet, c'est l'embarqué, pas d'être un concurrent de Java et C# pour des logiciels de gestion.
Euh, le troll du journal cible le kernel Linux, même si Linux tourne sur de l'embarqué, c'est un projet pour moi "énorme", les problématiques de modularité sont pleinement à prendre en compte.
la compilation séparée pour être un langage "moderne" couvrant les problèmes de "dev en équipe à l'exécution en passant par les tests, la documentation et le déploiement."
C'était une remarque plus général sur Lisaac, pas spécialement lié à la compilation séparée.
Tests : possibilité d'inclure des méta-données, de mocker dynamiquement le code (nécessite l'introspection et la génération dynamique de code).
Documentation : syntaxe spécialisée et utilisable par le compilateur pour générer automatiquement une documentation externe synchronisée à chaque compil
ation (cf C#).
Déploiement : composants "versionnable", "signables", introspection et chargement dynamique (plugins), abstraction hardware, déploiement à distance, etc.
[^] # Re: rentrons dans le vif du sujet
Posté par TImaniac (site web personnel) . En réponse au journal Linux un bloat, ah bon ?. Évalué à 2.
Gni ?
Linux passe directement de la case je casse l'API à la case je corrige tous les drivers.
Euh, quand ils changent une API, c'est pas pour "corriger" les drivers, c'est généralement pour offrir de nouvelles possibilités (nécessaire pour le kernel ou les améliorations des périphériques supportés). Donc ils ne corrigent rien, au contraire, ils sont obligés de modifier tous les drivers (alors que certains étaient sans doute stable et éprouvés) en prenant le risque d'introduire de nouveaux bugs/régression. Ceci est d'autant plus dangereux que la fondation Linux n'a pas les moyens de faire des tests de non-régression sur l'ensemble du matos. Bref, ca se fait globalement au détriment de la qualité, sans parler du fait que ces bugs va falloir les corriger, et ca prend du temps.
Si l'API introduit une faille de sécurité tu la gardes ?
Bien sûr que non. Celà dis le cas est rare et justifie une évolution.
[^] # Re: rentrons dans le vif du sujet
Posté par TImaniac (site web personnel) . En réponse au journal Linux un bloat, ah bon ?. Évalué à 3.
Je penses qu'il voulait dire "stabilisé" plutôt que "standardisé" : en gros faut pas qu'il change, ou rarerement.
On peut imaginer une ABI "stable" pendant 3 ans. Au bout de 3 ans une nouvelle version arrive, moyennant un coût supplémentaire le noyau peut gérer l'ancienne qui devient "deprecated" mais qui pête pas les drivers existants. Au bout de 3 nouvelles années, tu vires la vieille interface (on va pas la maintenir 107 ans) : en tout on a eu 6 ans de compatibilité binaire et 3 ans pour migrer les drivers encore maintenus/utilisés.
Ca me paraît totalement réalisable.
[^] # Re: rentrons dans le vif du sujet
Posté par TImaniac (site web personnel) . En réponse au journal Linux un bloat, ah bon ?. Évalué à 2.
Tu réponds pas au problème : pour des questions d'emprunte mémoire, de sécurité, de spécificité matérielle, on a pas envie de charger tout le bouzin en mémoire. Comment en Lisaac je charge dynamiquement des modules en mémoire sans passer par une compilation/déploiement séparée ?
Faut savoir : le principal intérêt de Lisaac, c'est la compil globale qui apporte un gain de perf. Si le code est "modulable" et compilable/déployable séparrement, le compilo peut plus faire son boulot de compilation globale, on perd une bonne partie de l'intérêt de Lisaac.
Lisaac est "bydesign" conçu pour mettre en contradiction les gains de perf avec la modularité du code. Faut vous faire une raison, Lisaac se focalise sur des objectifs qui sont loins des préocupations des développeurs et packageurs.
Peut être que sur de l'embarqué où le kernel n'est pas trop complexe et qu'il y a un seul mainteneur ca peut servir à quelque chose... ou pas.
il y a toujours la possibilité de découper le C en petits bouts, et de coller un .h pour lier le tout.
\o/ J'attend de voir ça dans une équipe de développement et son environnement SVN/GIT+IDE+makefile...
J'attend aussi de voir le débuggueur...
Les langages modernes s'occupe de toutes les problématiques de la réalisation d'un soft, du dev en équipe à l'exécution en passant par les tests, la documentation et le déploiement.
On a l'impression qe Lisaac se focalise uniquement sur le dev et l'exécution.
[^] # Re: approche local vs. globale?v
Posté par TImaniac (site web personnel) . En réponse au journal Linux un bloat, ah bon ?. Évalué à 2.
[^] # Re: rentrons dans le vif du sujet
Posté par TImaniac (site web personnel) . En réponse au journal Linux un bloat, ah bon ?. Évalué à 1.
Il faut également pouvoir charger des modules dans des espaces mémoires différents avec des droits différents (séparation userland/kernelland). Tout ca suppose qu'on passe par une autre étape qu'une bonne grosse compilation du bouzin qui contient tout vu quon connait pas la machine cible.
Sans parler que même si ca prend "seulement" 5 minutes à compiler sur ton quadri-coeur de la mort, pour le développeur c'est attroce comme environnement de test/déboggage.
Bref autant de critère qui rend la séparation en module indispensable pour tout gros projet, et un kernel est un gros projet.
[^] # Re: Utilité ?
Posté par TImaniac (site web personnel) . En réponse au journal Gnash: décodage fluide de vidéos Flash HD (H.264). Évalué à 2.
[^] # Re: Utilité ?
Posté par TImaniac (site web personnel) . En réponse au journal Gnash: décodage fluide de vidéos Flash HD (H.264). Évalué à 2.
C'est bien les pilotes 32 bits (et les vieux progs 16 bits) qui posent problème sur Windows 64 bits.
# rentrons dans le vif du sujet
Posté par TImaniac (site web personnel) . En réponse au journal Linux un bloat, ah bon ?. Évalué à 4.
Alors quand est-ce qu'on peut développer de façon modulaire avec compilation séparée en Lisaac ?
Non parcque bon le principal soucis du kernel Linux, son côté bloatware, c'est pas tant le fait que le langage utilisé ne propose d'héritage, c'est surtout que l'architecture monolithique retenue en fait un gros bouzin là où les micro-noyaux apporte "bydesign" une plus grande modularité.
Evidemment ca suppose que le langage soit "utilisable" pour cela...
[^] # Re: Oui mais ...
Posté par TImaniac (site web personnel) . En réponse au journal HADOPI ... encore :). Évalué à 10.
[^] # Re: Utilité ?
Posté par TImaniac (site web personnel) . En réponse au journal Gnash: décodage fluide de vidéos Flash HD (H.264). Évalué à 3.
[^] # Re: Utilité ?
Posté par TImaniac (site web personnel) . En réponse au journal Gnash: décodage fluide de vidéos Flash HD (H.264). Évalué à 6.
Moonlight et Gnash peuvent décoder des vidéos grâce à FFmpeg.
Le plus dangereux, c'est FFmpeg qui implémente des standards archi-blindés de brevets (et dont les licences sont payantes, y'a un modèle commercial derrière).
La FSF pousse Gnash (top 10 des appli prioritaires), dénigre ce qui tourne autour de mono, et oublie de parler de FFmpeg... cherchez l'erreur.
[^] # Re: C# pas interprété
Posté par TImaniac (site web personnel) . En réponse à la dépêche Sortie de Vala 0.7.6. Évalué à 4.
Je vois pas le rapport entre le premier et le 2ème paragraphe.
La présence d'une machine virtuelle ou d'un environnement d'exécution ne défini en rien le fait que C# soit interprété.
cette interprétation utilise la technologie JIT qui permet de gagner en performance
JIT est une technique de "compilation", pas d'interprétation.
C'est même dans le nom : http://en.wikipedia.org/wiki/Just-in-time_compilation
je cite : "It converts code at runtime prior to executing it natively, for example bytecode into native machine code. The performance improvement over interpreters originates from caching the results of translating blocks of code, and not simply reevaluating each line or operand each time it is met (see Interpreted language)."
Ce qui se traduit par :
"Il converti le code pendant son déroulement avant de l'exécuter nativement, par exemple il converti le bytecode en code natif. Le gain de performance par rapport aux interpréteurs vient du fait de mettre en cache le résultat de la tranduction de bloc de code plutôt que de réévaluer chaque ligne ou opérateur à chaque fois qu'il le rencontre. (voir langage interprété)."
La compilation et l'interprétation sont 2 techniques différentes pour exécuter du code. Que la compilation se fasse en 2 étapes pour ajouter un niveau d'abstraction (machine virtuelle) ne change rien.
C# est un langage conçu pour être compilé en ciblant la CLI et cette dernière est conçue pour compiler du bytecode en code natif.
Il est possible d'interpréter le bytecode intermédaire, mais l'intérêt est limité. La page de mono sur l'environnement d'exécution décrit bien les différentes techniques utilisées et précise à propos de l'interpréteur :
http://www.mono-project.com/Mono:Runtime
"Mono has both an optimizing just-in-time (JIT) runtime and a interpreter runtime. The interpreter runtime is far less complex and is primarily used in the early stages before a JIT version for that architecture is constructed. The interpreter is not supported on architectures where the JIT has been ported. "
Ce qui se traduit par :
Mono a un moteur d'exécution optimisé à la volée (JIT) et un interpréteur. L'interpréteur est beaucoup moins complexe et est avant tout utilisé en amont avant qu'une version du moteur JIT pour l'architecture cible soit construit. L'interpréteur n'est pas supporté sur les architectures où le moteur JIT a été porté.
# C# pas interprété
Posté par TImaniac (site web personnel) . En réponse à la dépêche Sortie de Vala 0.7.6. Évalué à 7.
C# n'a jamais été conçu pour être interprété mais pour être compilé dans un code intermédiaire qui est lui même compilé à la volée (JIT), voir en avance (AOT).
L'interprétation, c'est totalement has been, ca sert uniquement à porter "rapidement" un langage sur une nouvelle plateforme matérielle en attendant une chaîne de compilation native.
# mauvaises langues
Posté par TImaniac (site web personnel) . En réponse au journal Indie game surpris par les ventes de la version Linux de son jeu. Évalué à 9.
[^] # Re: En même temps
Posté par TImaniac (site web personnel) . En réponse au journal Sortie de Nero Linux 4. Évalué à 3.
[^] # Re: mailto:cgoasguen@assemblee-nationale.fr
Posté par TImaniac (site web personnel) . En réponse au journal Hadopti II adopé. Évalué à 2.
Après la démocratie permet de renouveller les mandats et d'éliminer les "menteurs", enfin quand les électeurs s'en aperçoivent et n'oublient pas.
[^] # Re: Ce n'est pas sale de se MonoToucher
Posté par TImaniac (site web personnel) . En réponse au journal Miguel, iPhone et développement. Évalué à 4.
Pas convaincu, d'après ma compréhension tu ne peux pas mettre de code sous GPL/LGPL sur iPhone du tout, puisque l'application doit obligatoirement être signé numériquement. Un soft sous (L)GPL oblige à redistribuer cette clé pour permettre d'utiliser la version modifiée, mais c'est Apple qui détient la clé en question... (sauf jailbreak m'enfin ne pas respecter une licence (Apple) pour en utiliser une autre voilà quoi :))
Donc la véritable question n'est pas de savoir si monotouch doit être libre ou non, mais de savoir si c'est acceptable de faire un produit proprio quand on fait par ailleur la promotion du libre.
Là où je suis d'accord avec Jb, c'est que le modèle de double licence est largement répendu et accepté dans le monde du libre. Là où je ne suis pas d'accord, c'est que monotouch n'est justement pas sous double licence : même si la version sous GPL/LGPL n'est pas "utilisable", elle pourrait toujours être utile pour d'autres développeurs : technique de binding Objective-C par exemple ou façon de s'interfacer avec xcode, etc.
Bref, ca fait vraiment bizzare de voir MDI faire la promotion d'un produit totalement proprio sans version "libre". Je comprends que c'est un choix qui incombe à son employeur, Novell, mais quand même, c'est contraire à tout ce qu'il nous avait habitué.
# ouaip
Posté par TImaniac (site web personnel) . En réponse au journal Miguel, iPhone et développement. Évalué à 10.
En gros c'est ça.
Ils utilisent la compilation AOT (AheadOfTime) pour produire un exécutable natif pour l'iPhone, ce dernier interdisant toute technique de JIT (JustInTime).
A côté ils fournissent un wrapper sur les API iPhone comme ils le font pour GTK ou autre, et un plugin de dev pour l'IDE MonoDevelop.
[^] # Re: Lire entre les lignes
Posté par TImaniac (site web personnel) . En réponse au journal Microsoft lance la fondation CodePlex. Évalué à 1.
C'est un simple préjugé sans fondement.
Je ne suis pas utilisateur de codeplex, je ne sais pas ce qui conduit ses utilisateurs à le choisir, mais faut croire que certains le choisisse pour faire des trucs pour Linux et pas pour Windows, exemple :
http://openblade.codeplex.com/
ou tout simplement multiplateforme par nature :
http://pyspec.codeplex.com/
On peut poser exactement la même question avec google code : pourquoi aller sur google code alors que sourceforce et tuxfamily existe ? Il y a sans doute de bonnes raisons puisque des gens font ce choix. C'est pas parcque toi tu vois pas les raisons qu'il n'y en a pas.
c'était de l'humour
Oué mais l'humour c'est plus drôle quand elle a un fond de vérité.
[^] # Re: Lire entre les lignes
Posté par TImaniac (site web personnel) . En réponse au journal Microsoft lance la fondation CodePlex. Évalué à 2.
Je ne vois rien sur le site de la fondation qui contredise la FAQ de codeplex...
[^] # Re: Lire entre les lignes
Posté par TImaniac (site web personnel) . En réponse au journal Microsoft lance la fondation CodePlex. Évalué à 1.
Il n'y a aucune contrainte sur l'OS :
http://codeplex.codeplex.com/Wiki/View.aspx?title=CodePlex%2(...)
[^] # Re: Langage plus sûr?
Posté par TImaniac (site web personnel) . En réponse au journal Un coup de gueule contre Gimp 2.6. Évalué à 7.
Lancement de l'appli :
PN : 3s
TG : 6s
Consommation mémoire après lancement :
PN : 32Mo
TG : 23Mo
Chargement de la photo (800ko, 2048x1536)
PN : 1s
TG : 2s
Retaillage en 4096x3072 (bicubique)
PN : 7s
TG : 10s
Passage en N&B :
PN : 3s
TG : 3s
Enregistrement du résultat (jpg, qualité 89) :
PN : 2s
TG : 2s
Consommation mémoire après toutes ces opérations :
PN : 187Mo
TG : 233Mo
Evidemment les applis ne sont pas identiques, TG a sans doute beaucoup plus de fonctionnalités, mais quand même, il semble possible de faire des applis réactives et fonctionnelles avec autre chose que du C.
[^] # Re: Pas d'accord
Posté par TImaniac (site web personnel) . En réponse à la dépêche Microsoft Office interdit aux USA ?. Évalué à 3.
Si le format OpenDocument engendrait la violation d'un brevet du même genre par OpenOffice & co, la situation serait identique : obligé d'utiliser un logiciel "illégal" ou avoir des documents "inutilisables".
Le problème, c'est bien les brevets logiciels, et le fait d'utiliser un logiciel libre ou un format ouvert ne protège en rien.