Manque(s) de R2 -> R3

Manque(s) de R2 -> R3
nve	30-Dec-2010/0:38:28+1:00
Encore un sujet à polémique... Quel(s) était le ou les manque(s) de R2 qui ont motivé R3 ? Je suis un peu nouveau sur ce genre de sujet et pas très balaise en architecture de langage de programmation. Je sais qu'il y avait l'absence de support de l'UTF-8, l'absence de programmation parallèle type thread encore que j'ai cru comprendre qu'en R2 on puisse le simuler avec les ports... le support du 64 bits... Une meilleure prise de VID sous Linux ? Des composants standards à VID plus évolués mais il y avait l'excellent RebGUI ? La non-compatibilité Windows 8...
DocKimbel	30-Dec-2010/15:18:04+1:00
Carl a rédigé une page pour répondre à ce genre de question: http://www.rebol.com/rebol3/motivation.html Si je me souviens bien, c'était principalement pour supporter un AltME3 (aka Altissimo) qui aurait succédé à AltME et REBOL/IOS à la fois. Certaines parties de REBOL devaient être ré-architecturées comme les port! ou les faces (View) et de nouvelles fonctionnalités prévues de longue date, devaient être ajoutées, comme le support des extensions en C à REBOL (annoncé en 2004 ou 2005). De nouvelles évolutions se sont ensuite greffées au projet, comme les fonctions avec contexte non persistant (gain en performance), et le support de l'Unicode, qui nécessitaient des changements profonds. Je crois que R3 est né du fait que la plupart de ces changements cassaient la compatibilité avec les scripts écrits pour R2, et donc Carl a décidé qu'une nouvelle branche de développement était nécessaire. AMHA, des modifications incrémentales de R2 auraient été préférables, même s'il avait fallu adapter son code à chaque nouvelle version, au moins le travail de mise à niveau des applications de chacun aurait été lissé dans le temps. ...l'absence de programmation parallèle type thread encore que j'ai cru comprendre qu'en R2 on puisse le simuler avec les ports... Un support minimaliste des threads OS était présent dès la première version publique de R3, mais celà reste incomplet et expérimental. Il n'est pas certain que les threads soient opérationnels pour la 3.0 d'ailleurs. Non, il n'est pas possible d'executer du code en parallèle en R2, celà nécessite obligatoirement le support des threads OS. Au mieux, on peut lancer plusieurs processus R2 et les faire communiquer par TCP, ce qui est très gourmands en ressources et peu performant par rapport à une exécution par threads. Quand aux ports en R2, ils peuvent fonctionner en asynchrone, c'est à dire qu'il n'est pas nécessaire d'attendre un évènement réseau (ou clavier/souris) en bloquant le processus, on peut définir des "callbacks", type "awake", permettant d'exécuter du code lorqu'un évènement intervient. Ce code reste sequentiel et bloquant, c'est à dire qu'aucun autre code ne peut s'exécuter pendant l'exécution d'un "callback". Impossible d'exécuter plusieurs fonctions simultanément, ni tirer parti d'un CPU multicore. Une meilleure prise de VID sous Linux ? Des composants standards à VID plus évolués mais il y avait l'excellent RebGUI ? VID est un dialecte défini au niveau "mezzanine", c'est à dire écrit 100% en REBOL et dont le code source est accessible (à ne pas confondre avec View, qui est le moteur graphique en C). Il n'est pas nécessaire de changer le noyau View pour faire évoluer VID ou ajouter de nouveaux composants. La non-compatibilité Windows 8 Un peu prématuré non?
RebKodeur	31-Dec-2010/14:00:28+1:00
Le multi-threading est possible avec R2, en utilisant les rebol/services, Rebol ouvre des ports et peut continuer à travailler sur le thread principal jusqu'à ce que des données reviennent dans le port. Par contre, n'est pas destiné au multicore. Doc, dis-moi si je me trompe..
DocKimbel	31-Dec-2010/19:36:09+1:00
Réponse courte: Non, les REBOL/Services (R/S) ne permettent pas de faire du multithreading. Il n'est pas possible d'exécuter du code et d'attendre un évènement réseau simultanément, c'est soit l'un, soit l'autre. Il est possible toutefois d'entrelacer les deux en utilisant un WAIT [0] au sein d'une boucle (ce que ne font pas les R/S de mémoire), ce qui peut parfois suffire si on ne cherche pas les performances, mais le code bloquant reste interdit. Cette technique permet de produire un semblant de multitâche (et non "multithreading"), mais très limité (1 thread + des traitements rapides d'évènements). Réponse longue: Un "thread OS" ou encore "thread kernel" est une unité d'exécution ordonnancée par l'OS au sein d'un processus. "Multithreading" désigne la possibilité d'utiliser plusieurs threads au sein d'un même processus, ce que R2 ne permet pas au programmeur, en aucune manière. On parle également de "green thread" (ou "user thread") pour désigner des threads ordonnancés (prémptivement) par le processus lui-même et non par l'OS. Enfin, on parle de "light threads" pour désigner la plupart du temps des co-routines qui sont ordonnancées par le programmeur (en utilisant le fameux appel "yield") de manière coopérative (pas d'éxecution simultanée). R2 ne permet aucune de ces différentes formes de threading. Il serait néanmoins possible d'implémenter un système de co-routines en R2. Si je me souviens bien, Maarten Koopmans en avait proposé une implémentation il y a quelque années, mais la perte de performance est importante pour une granularité ("time slices") faible. Pour une implémentation performante, il est nécessaire de le faire en C au sein du noyau REBOL. Les R/S sont un client et un serveur utilisant un protocole de communication TCP/IP pour échanger des informations suivant une variante du modèle RPC ("Remote Procedure Call", en français, appel de procédure distante). Si le client et le serveur sont dans le même processus REBOL, le traitement de chaque évènement est séquentiel, aucune concurrence n'est possible et le code bloquant est interdit. Si le client et le serveur sont dans deux processus REBOL différents, on peut avoir une exécution parallèle limitée (il est nécessaire d'avoir des boucles d'évènements des deux cotés, donc code bloquant interdit), mais comme dit dans mon post précédent: "ce qui est très gourmand en ressources et peu performant par rapport à une exécution par threads.". Voici quelques différences entre les deux types: - un processus typiquement consomme plusieurs Mo, un thread consomme typiquement quelques dizaines de Ko (principalement la pile d'exécution). - les processus s'exécutent dans des espaces mémoires séparés, les threads d'un processus partagent le même espace mémoire. - le changement de contexte (context switching) d'un processus est beaucoup plus couteux que celui d'un thread. - un processus n'ayant qu'un seul thread ne peut profiter de plusieurs cores ou de plusieurs CPUs. Pour revenir aux R/S, il n'y a pas de différences fondamentales entre faire un: >> read http://localhost:8000/ajouter?a=1&b=2 == 3 et utiliser les R/S pour envoyer une commande "ajouter" avec [1 2] en argument et recevoir le résultat. Le seul avantage des R/S serait de proposer un standard commun pour les RPC afin d'éviter que chacun développe sa propre solution. Pour information, R2/Core utilise 2 threads en interne, un pour l'interpréteur, et un pour la résolution des requêtes DNS en asynchrone. Sous UNIX, R2/Core utilise 2 processus pour le même travail au lieu de threads (les threads n'étant pas forcément natifs sur les différents UNIX). Sur ce, bon réveillon à tous !
shadwolf	1-Jan-2011/10:59:41+1:00
DocKimbel très sympatique dernier poste. Voila ca élève le débat et ca invite à la réflexion! Pour ce qui est du multithreading François Jouen avait fait un émulateur de gestionnaire de tache multiple disponible pour rebol/view 2. Ca peut paraître du bricolage mais c'est complètement ce que j'adore comme logiciel fait en rebol... Un manière de refaire ce qui existe ailleurs mais en exploitant rien d'autre que ce que rebol propose déjà. http://www.rebol.org/view-script.r?script=demo1.r&sid=z8td Quand on en est a ce niveau dans le débat technique et qu'on cherche à simuler des technologies existant ailleurs à ce moment là on est à la fois didactique, ingénieux et complétement dans l'esprit rebol, et surtout on essai d'élever le débat en proposant des solutions concrètes immédiatement applicables. François Jouen basait son systeme de gestion de tâches multiples sur l'évènement Time de rebol/view et donc il se serait de la boucle infinie de gestion des évènements comme base pour son simulateur de multi-thread. Le problème de cette méthode est de déterminer le temps d'exécution à attribuer a chaque processus. Pour faire simple c'est parfait pour gérer l'affichage et la mise a jours de plusieurs barre de progression simultanées par example, par contre dans le domaine client/serveur réseau ou les thread sont en mode attente de données la ça ne fonctionne plus trop... Avec host kit il est déjà possible de rajouter une véritable gestion de thread basée sur une librairie C reste à savoir quelle librairie ne faisant que de la gestion de thread on choisi et surtout quelle modalité de contrôle pour rebol (dialecte). En règle général les librairie de thread sont intégrée commes outil de base au sein d'une librairie plus vaste comme la Glib ou GTK+ ou QT ou WxWindows etc... Chacun ayant ses propres avantages et inconvénients. Autre problème c'est qu'il faut que ce soit portable. Ce qui fait par exemple que si nous basions VID sur une librairie existante à la fois sur Windows, linux et MacOSX, une des technologies que nous récupérerions serait le gestionnaire multi-thread quelle intègre. La librairie QT aurait aussi d'autres avantage comme ouvrir rebol a certains os embarqués comme Symbian 3 et Meego. Mais si on part de ca alors pourquoi ne pas faire simplement de rebol un wraper java? java etant présent sur tout les OS évolués et étant aussi présent sur beaucoup de systèmes embarqués dont android qui va devennir de plus en plus important dans les années avenir... Enfin y a problème idéologique majeur dans la gestion de tâches multiple. Carl préfère un processus unique de traitement de l'information en mode asynchrone plutot que la gestion. Réinventer la roue pour faire de rébol un logiciel de moins d'un méga à l'époque ou les disquettes 1M44 sont été remplacées par des clef usb de plus d'un gigat octet semble très anachronique et force constement à chercher des moyens pour réinventer la roue et comme la place est limité la roue elle est bien souvent en bois et sans gente aliage ni ornementation .
Login required to Post.