Author: thimel Date: 2006-08-29 10:40:09 +0000 (Tue, 29 Aug 2006) New Revision: 3 Modified: doc/etude.rst Log: fin du doc Modified: doc/etude.rst =================================================================== --- doc/etude.rst 2006-08-28 17:13:03 UTC (rev 2) +++ doc/etude.rst 2006-08-29 10:40:09 UTC (rev 3) @@ -1,25 +1,47 @@ Introduction ============ -Ce document a pour but de comparer les diff�rentes solutions envisageables pour l'utilisation de R en Java. +Ce document a pour but de comparer les diff�rentes solutions envisageables pour +l'utilisation de R en Java. -R est un outil libre de calculs et cr�ation de graphiques li�s aux statistiques. Il pr�sente l'avantage non n�gligeable d'�tre optimis� pour bon nombre de calculs. Cependant, R n'est pas �crit en Java et ne permet donc pas d'�tre directement utilis� dans une application Java. +R est un outil libre de calculs et de cr�ation de graphiques li�s aux +statistiques. Il pr�sente l'avantage non n�gligeable d'�tre optimis� pour bon +nombre de calculs. Cependant, R n'est pas �crit en Java et ne permet donc pas +d'�tre directement utilis� dans une application Java. -Heureusement, R est un projet tr�s modulaire et permet par le biais d'extensions d'ouvrir son moteur � d'autres appplications. En Java, deux possibilit�s s'offrent � nous : - - Acc�s par le r�seau : L'application envoie des requ�tes par le r�seau � une extension de R faisant office de serveur, laquelle renvoie par la suite les r�sultats obtenus. - - Acc�s par une librairie JNI : Il s'agit d'�crire du code en un langage autre que Java qui sera compil� et exc�cut� par la machine plut�t qu'interpr�t�. Gr�ce � JNI, il est ensuite possible d'appeler ce code depuis une application Java. +Heureusement, R est un projet tr�s modulaire et permet par le biais d'extensions +d'ouvrir son moteur � d'autres appplications. En Java, deux possibilit�s +s'offrent � nous : + - Acc�s par le r�seau : L'application envoie des requ�tes par le r�seau � une + extension de R faisant office de serveur, laquelle renvoie par la suite les + r�sultats obtenus. + - Acc�s par une librairie JNI : Il s'agit d'�crire du code en un langage autre + que Java qui sera compil� et exc�cut� par la machine plut�t qu'interpr�t�. + Gr�ce � JNI, il est ensuite possible d'appeler ce code depuis une application + Java. -Le pr�sent document va donc comparer ces deux solutions afin de d�terminer laquelle est la plus adapt�e. Afin d'effectuer une comparaison plus pertinente, ces solutions seront compar�es, lorsque c'est possible, � l'utilisation de R seul (sans Java) et Java seul (sans R). +Le pr�sent document va donc comparer ces deux solutions afin de d�terminer +laquelle est la plus adapt�e. Afin d'effectuer une comparaison plus pertinente, +ces solutions seront compar�es, lorsque c'est possible, � l'utilisation de R +seul (sans Java) et Java seul (sans R). R�sultats attendus ================== -Chacune des solutions a ses avantages et ses inconv�nients qui entreront dans la d�cision finale. Avant m�me de commencer, la nature m�me des solutions sugg�re certains r�sultats qu'il faudra v�rifier : +Chacune des solutions a ses avantages et ses inconv�nients qui entreront dans la +d�cision finale. Avant m�me de commencer, la nature m�me des solutions sugg�re +certains r�sultats qu'il faudra v�rifier : - - Les temps de r�ponse obtenus en R pur seront inf�rieurs aux solutions r�seau et JNI. Le contraire serait �tonnant dans la mesure o� l'utilisation de R pur est la seule solution n'impliquant pas de technologie tierce. - - Les appels JNI devraient prendre moins de temps que les appels r�seau. L'utilisation des interfaces r�seau est reconnue est informatique pour �tre un point qui ralenti souvent les applications. - - Certaines calculs simples effectu�s en Java pur pourraient parfois s'av�rer plus rapide. Cependant, des calculs plus complexes comme des calculs matriciels devraient faire ressortir l'avantage de R. + - Les temps de r�ponse obtenus en R pur seront inf�rieurs aux solutions r�seau + et JNI. Le contraire serait �tonnant dans la mesure o� l'utilisation de R pur + est la seule solution n'impliquant pas de technologie tierce. + - Les appels JNI devraient prendre moins de temps que les appels r�seau. + L'utilisation des interfaces r�seau est reconnue est informatique pour �tre + un point qui ralenti souvent les applications. + - Certains calculs simples effectu�s en Java pur pourraient parfois s'av�rer + plus rapide. Cependant, des calculs plus complexes comme des calculs + matriciels devraient faire ressortir l'avantage de R. Consid�rations techniques @@ -28,32 +50,49 @@ R�seau ------ -Par d�faut, R n'int�gre aucune interface r�seau, et ne peut donc �tre utilis� � distance. Il existe une extension du nom de 'Rserve' permettant d'ajouter � R la possibilit� de recevoir et traiter des requ�tes TCP/IP, le rendant ainsi accessible � tous types de langages. +Par d�faut, R n'int�gre aucune interface r�seau, et ne peut donc �tre utilis� � +distance. Il existe une extension du nom de 'Rserve' permettant d'ajouter � R la +possibilit� de recevoir et traiter des requ�tes TCP/IP, le rendant ainsi +accessible � tous types de langages. -Avantages : R non n�cessaire sur la machine cliente, d�l�gation des calculs � une machine tierce, appli 100% portable -Inconv�nients : Rserve a installer sur le serveur + - Avantages : R non n�cessaire sur la machine cliente, d�l�gation des calculs � + une machine tierce, appli 100% portable + - Inconv�nient : Rserve � installer sur le serveur JNI --- -L'utilisation de JNI implique la cr�ation d'une librarie d�pendante du syst�me. On perd donc un peu de la portabilit� du Java. +L'utilisation de JNI implique la cr�ation d'une librairie d�pendante du syst�me. +On perd donc un peu de la portabilit� du Java. -Avantages : Installation basique de R -Inconv�nients : M�me machine, n�cessite des param�tres de d�marrage de l'application Java, l'application Java n'est plus 100% portable car cr�ation/compilation d'une librairie n�cessaire. + - Avantages : Installation basique de R + - Inconv�nients : M�me machine, n�cessite des param�tres de d�marrage de + l'application Java, l'application Java n'est plus 100% portable car + cr�ation/compilation d'une librairie n�cessaire. D�roulement (protocole) des tests ================================= -Le but des tests est de faire ressortir le co�t de chacune des solutions de mani�re � d�terminer laquelle pourrait �tre la meilleure, mais surtout les conditions, s'il y en a, dans lesquelles telle ou telle solution est meilleure. +Le but des tests est de faire ressortir le co�t de chacune des solutions de +mani�re � d�terminer laquelle pourrait �tre la meilleure, mais surtout les +conditions, s'il y en a, dans lesquelles telle ou telle solution est meilleure. Deux types de tests ont �t� effectu�s. - - Le permier consiste � envoyer de tr�s petits calculs � R et ce beaucoup de fois de suite. On obtient donc une moyenne pour chacune des solutions ce qui permettra d'�valuer le co�t de chaque m�thode. - - Le second se base sur la quantit� de donn�es � v�hiculer. Il s'agit donc l� de calculs plus long mais surtout g�n�rant un plus gros volume de donn�es. Plusieurs mesures seront effectu�es avec des tailles croissantes afin d'�valuer l'impact de l'augmentation volum�trique. - - Le dernier test est surtout informatif et ne fera ressortir que le temps n�cessaires � initialiser chacune des solutions �tudi�es. + - Le premier consiste � envoyer de tr�s petits calculs � R et ce beaucoup de + fois de suite. On obtient donc une moyenne pour chacune des solutions ce qui + permettra d'�valuer le co�t de chaque m�thode. + - Le second se base sur la quantit� de donn�es � v�hiculer. Il s'agit donc l� + de calculs plus long mais surtout g�n�rant un plus gros volume de donn�es. + Plusieurs mesures seront effectu�es avec des tailles croissantes afin + d'�valuer l'impact de l'augmentation volum�trique. + - Le dernier test est surtout informatif et ne fera ressortir que le temps + n�cessaire � initialiser chacunes des solutions �tudi�es. A noter que : - De fa�on � ne pas trop laisser libre cours aux optimisations des diff�rentes plateformes, les calculs r�p�t�s sont volotairement changeants au sein d'un m�me test (il restent n�anmoins identiques entre les tests). + De fa�on � ne pas trop laisser libre cours aux optimisations des diff�rentes +plateformes, les calculs r�p�t�s sont volontairement changeants au sein d'un +m�me test (ils restent n�anmoins identiques entre les tests). R�sultats des tests @@ -110,31 +149,47 @@ Exploitation des r�sultats ========================== -Les tests �tant effectu�s, il faut maintenant les interpr�ter et en tirer des conclusions. +Les tests �tant effectu�s, il faut maintenant les interpr�ter et en tirer des +conclusions. Test A - Calculs rapides ------------------------ Le premier test avait pour but d'isoler le co�t de chaque appel � R. -La comparason avec du Java pur n'avait ici aucun int�ret dans la mesure ou le but est de calculer le temps d'appel � R. +La comparaison avec du Java pur n'avait ici aucun int�ret dans la mesure ou le +but est de calculer le temps d'appel � R. -Premi�rement, l'op�ration est r�alis�e en R pur afin d'avoir un temps de base : 229.83ms. +Premi�rement, l'op�ration est r�alis�e en R pur afin d'avoir un temps de +base : 229.83ms. A partir de l�, on peut estimer que le temps n�cessaire � chaque technologie. -Ainsi, un appel JNI est en moyenne d'un peu moins de 3ms (2.73ms), alors que par le r�seau, il faut plus de 10ms (10,23ms), soit un ecart d'environ 7ms en faveur de JNI. +Ainsi, un appel JNI est en moyenne d'un peu moins de 3ms (2.73ms), alors que par +le r�seau, il faut plus de 10ms (10,23ms), soit un ecart d'environ 7ms en faveur +de JNI. -La diff�rence est relativement faible, elle ne repr�sente ici que 3%, mais r�p�t� � grande �chelle elle peut �tre p�nalisante. Si par exemple 100.000 appels cons�cutifs sont n�cessaires, la diff�rence se monte � 700 secondes soit 11 minutes et 40 secondes ce qui peut �tre �norme pour des simulateurs par exemple. +La diff�rence est relativement faible, elle ne repr�sente ici que 3%, mais +r�p�t�e � grande �chelle elle peut �tre p�nalisante. Si par exemple 100.000 +appels cons�cutifs sont n�cessaires, la diff�rence se monte � 700 secondes soit +11 minutes et 40 secondes ce qui peut �tre �norme pour des simulateurs par +exemple. -Pour ce test, l'�cart-type �tait mesur� afin d'estimer la r�partition des valeurs. -L'�cart-type nous permet ici de constater que la r�partition des valeurs avec JNI est plus proche de la moyenne que par le r�seau. La solution r�seau est donc plus sensible aux variations de temps. +Pour ce test, l'�cart-type �tait mesur� afin d'estimer la r�partition des +valeurs. +L'�cart-type nous permet ici de constater que la r�partition des valeurs avec +JNI est plus proche de la moyenne que par le r�seau. La solution r�seau est donc +plus sensible aux variations de temps. Test B - Volumes importants --------------------------- -La deuxi�me s�rie de tests veut mettre en valeur l'�volution des temps n�cessaires avec l'augmentation du volume de donn�es. -Inversement au pr�c�dent test, c'est la solution R pur qui n'a ici pas de sens puisqu'on cherche � �valuer l'impact d'un passqge de Java � R. +La deuxi�me s�rie de tests veut mettre en valeur l'�volution des temps +n�cessaires avec l'augmentation du volume de donn�es. +Inversement au pr�c�dent test, c'est la solution R pur qui n'a ici pas de sens +puisqu'on cherche � �valuer l'impact d'un passage de Java � R. -L'op�ration r�alis�e pour ce test est un simple produit scalaire entre deux vecteurs dont la taille va augmenter progressivement. Le graphique ci-dessous permet de voir instantann�ment la mani�re dont �voluent ces technologies : +L'op�ration r�alis�e pour ce test est un simple produit scalaire entre deux +vecteurs dont la taille va augmenter progressivement. Le graphique ci-dessous +permet de voir instantann�ment la mani�re dont �voluent ces technologies : .. image:: img/testB-results.png :alt: Evolution des temps de r�ponse @@ -143,25 +198,51 @@ A faibles volumes de donn�es, les r�sultats des 3 solutions sont comparables. -Cependant, la solution r�seau montre vite ses faiblesses. D�s l'utilisation de vecteurs d'une taille de 5.000 chiffres la comparaison devient ridicule tant les temps n�cessaires pour transf�rer les vecteurs prend le pas sur le calcul. Pour le reste de ce test, le r�seau restera toujours la solution la moins adapt�e. +Cependant, la solution r�seau montre vite ses faiblesses. D�s l'utilisation de +vecteurs d'une taille de 5.000 chiffres la comparaison devient ridicule tant les +temps n�cessaires pour transf�rer les vecteurs prend le pas sur le calcul. Pour +le reste de ce test, le r�seau restera toujours la solution la moins adapt�e. -Du c�t� de JNI, la solution s'av�re beaucoup plus pertinente. R sur JNI s'offre m�me le luxe de battre Java sur certaines tailles ce qui est tr�s flatteur si on tient compte du fait que les r�sultats doivent �tre convertis de R � Java afin d'�tre exploitables. La solution se montre donc viable mais uniquement jusqu'� ce que la taille des vecteurs depasse les 100.000 chiffres. Les optimisations de Java prennent alors le dessus et affichent des temps bien inf�rieurs. +Du c�t� de JNI, la solution s'av�re beaucoup plus pertinente. R sur JNI s'offre +m�me le luxe de battre Java sur certaines tailles ce qui est tr�s flatteur si on +tient compte du fait que les r�sultats doivent �tre convertis de R � Java afin +d'�tre exploitables. La solution se montre donc viable mais uniquement jusqu'� +ce que la taille des vecteurs depasse les 100.000 chiffres. Les optimisations de +Java prennent alors le dessus et affichent des temps bien inf�rieurs. -Enfin le dernier test sur des vecteurs d'une taille de 1.000.000 de chiffres indique des temps qui, m�me s'ils ne sont plus comparables � Java (94ms), restent honorables. La solution JNI n�cessite 282ms pour effectuer le calcul et le renvoyer � Java, ce qui signifie qu'il est toujours possible d'effectuer 3 produits scalaires sur des vecteurs d'un million d'entr�es en moins d'une seconde. Le temps n�cessaire � la solution r�seau (620ms) n'est pas non plus ridicule compte tenu de la taille des donn�es � traiter. La solution r�seau souffre simplement de temps de transfert trop longs qui sont le reflet habituel de l'utilisation des r�seaux. +Enfin le dernier test sur des vecteurs d'une taille de 1.000.000 de chiffres +indique des temps qui, m�me s'ils ne sont plus comparables � Java (94ms), +restent honorables. La solution JNI n�cessite 282ms pour effectuer le calcul et +le renvoyer � Java, ce qui signifie qu'il est toujours possible d'effectuer 3 +produits scalaires sur des vecteurs d'un million d'entr�es en moins d'une +seconde. Le temps n�cessaire � la solution r�seau (620ms) n'est pas non plus +ridicule compte tenu de la taille des donn�es � traiter. La solution r�seau +souffre simplement de temps de transfert trop longs qui sont le reflet habituel +de l'utilisation des r�seaux. Test C - Temps d'initialisation ------------------------------- -Le temps d'initialisation repr�sente le temps n�cessaire � la premi�re utilisation de l'application avant de pouvoir acc�der � R. Il peut parraitre annodin, mais en r�alit� il peut s'av�rer primordial dans le choix de la solution � utiliser. +Le temps d'initialisation repr�sente le temps n�cessaire � la premi�re +utilisation de l'application avant de pouvoir acc�der � R. Il peut parraitre +annodin, mais en r�alit� il peut s'av�rer primordial dans le choix de la +solution � utiliser. -Si les tests pr�c�dents n'ont pas �t� en faveur de la solution r�seau, ce test l� montre que l'initialisation de JNI prend en moyenne 550ms de plus que l'initialisation du r�seau. Cette diff�rence peut s'av�rer cruciale si les calculs � effectuer sont petits et peu r�p�t�s. +Si les tests pr�c�dents n'ont pas �t� en faveur de la solution r�seau, ce test +l� montre que l'initialisation de JNI prend en moyenne 550ms de plus que +l'initialisation du r�seau. Cette diff�rence peut s'av�rer cruciale si les +calculs � effectuer sont petits et peu r�p�t�s. Notes ----- -Certains faits n'apparaissent pas dans les chiffres pr�c�demment cit�s mais peuvent �galement pencher dans la balance. +Certains faits n'apparaissent pas dans les chiffres pr�c�demment cit�s mais +peuvent �galement faire pencher la balance. -Par exemple, les diff�rents tests ont fait ressortir que la solution r�seau n�cessite un "temps de chauffe". Un simple test r�p�t� 10 fois de suite peut le mettre en �vidence. Chaque ligne suivante repr�sente l'�volution d'un m�me test : +Par exemple, les diff�rents tests ont fait ressortir que la solution r�seau +n�cessite un "temps de chauffe". Un simple test r�p�t� 10 fois de suite peut le +mettre en �vidence. Chaque ligne suivante repr�sente l'�volution d'un m�me +test : +-----------------+ | duration: 801ms | @@ -185,9 +266,62 @@ | duration: 326ms | +-----------------+ -La diff�rence entre le premier et le dernier test atteint quasiment la demi seconde soit plus de 150% du temps n�cessaire au final pour l'op�ration. +La diff�rence entre le premier et le dernier test atteint quasiment la demi +seconde soit plus de 150% du temps n�cessaire au final pour l'op�ration. + R�capitulatif ------------- +Les tests effectu�s se sont montr�s r�v�lateurs. +Net +--- + +Cette solution s'est montr�e moins efficace que les autres. La diff�rence n'est +pas pour autant dramatique puisque les temps restent tout � fait corrects. + +Cette approche n'a pas que des inconv�nients. En effet, la mise en place de la +solution r�seau est plus simple compar�e � JNI et b�n�ficie �galement d'un temps +d'initialisation beaucoup plus faible. A ne pas oublier aussi que le r�seau +offre la possibilit� de mobiliser une seconde machine pour effectuer les calculs +en R, ce qui permettra encore d'am�liorer les performances. A noter cependant +que les performances de la solution r�seau s'am�liorent avec le temps. Ceci +signifie que la solution perd de son inter�t seulement si quelques rares appels +sont effectu�s. + +JNI +--- + +La solution JNI a fait ses preuves sur les diff�rents tests. Il s'est av�r� que +les temps d'appels �taient toujours inf�rieurs � la solution r�seau. + +N�anmoins, la solution JNI n'a pas que des avantages. La mise en place, par +exemple, est plus complexe car elle n�cessite une recompilation des sources JNI. +On perd ainsi un peu de la portabilit� de Java. D'autre part, la premi�re +initialisation de JNI s'av�re particuli�rement longue (une demi seconde) surtout +si elle est compar�e � la solution r�seau. + +Java +---- + +La comparaison n'a que peu d'inter�t mais permet de faire ressortir la puissance +de Java qui par le biais d'optimisations parvient � devancer R sur de nombreux +calculs. + +Il n'en reste pas moins que l'utilisation de R a des avantages. Les tests +effectu�s ici ne se basaient que sur des calculs simples. En appelant des +fonctions plus optimis�es de R voire des librairies sp�cifiques, Java ne +pourraient certainement plus rivaliser avec R. + +Conclusion +========== + +Les deux principales solutions �tudi�es (JNI et r�seau) ont toutes deux montr�s +des avantages et inconv�nients et fait ressortir des cas dans lesquels elles +sont pr�f�rables � l'autre. + +Difficile donc de faire un choix. C'est pourquoi ce choix est laiss� � +l'utilisateur avec la librairie LutinJ2R qui propose une interface unifi�e pour +acc�der aux fonctionnalit�s de R permettant ainsi de choisir � la vol�e quelle +solution utiliser.