Changes between Version 3 and Version 4 of ParallelismPerformances


Ignore:
Timestamp:
2012-10-01T14:16:26+02:00 (12 years ago)
Author:
dsolyga
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • ParallelismPerformances

    v3 v4  
    1919 
    2020== Optimization of moycum subroutine == 
     21 
     22=== Results for 8 processors === 
     23 
     24 * Standard IOIPSL : 
     25  
     26[[Image(http://dods.ipsl.jussieu.fr/orchidee/WIKI/VAMPIR_RESULTS_PATCH/PERF_STD_8PROCS.png,70%)]] 
     27 
     28 * IOIPSL with patch : 
     29 
     30[[Image(http://dods.ipsl.jussieu.fr/orchidee/WIKI/VAMPIR_RESULTS_PATCH/PERF_PATCH_8PROCS.png,70%)]] 
     31 
     32=== Results for 16 processors === 
     33 
     34 * Standard IOIPSL : 
     35 
     36[[Image(http://dods.ipsl.jussieu.fr/orchidee/WIKI/VAMPIR_RESULTS_PATCH/STD_16PROCS.png,70%)]] 
     37 
     38 
     39 * IOIPSL with patch : 
     40 
     41[[Image(http://dods.ipsl.jussieu.fr/orchidee/WIKI/VAMPIR_RESULTS_PATCH/PATCH_PERF_16PROCS.png,70%)]] 
     42 
     43 * Standard IOIPSL, processor 16 only : 
     44 
     45[[Image(http://dods.ipsl.jussieu.fr/orchidee/WIKI/VAMPIR_RESULTS_PATCH/STD_PROC_16.png,70%)]] 
     46 
     47 
     48 * Modified IOIPSL, processor 16 only : 
     49 
     50[[Image(http://dods.ipsl.jussieu.fr/orchidee/WIKI/VAMPIR_RESULTS_PATCH/PATCH_PROC_16.png,70%)]] 
     51 
     52 
     53 
    2154 
    2255|| Number of processors  ||  moycum_std (%)  || moycum_index (%) || 
     
    5083|| 96 ||  '''91,68%''' ||   
    5184 
     85New problem to solve, the routine fliopen_works takes 90% of time computing on 96 processors : 
    5286 
     87[[Image(http://dods.ipsl.jussieu.fr/orchidee/WIKI/VAMPIR_RESULTS_PATCH/STD_96_PROCS.png,70%)]] 
     88 
     89 
     90== PARTIAL CONCLUSION (September 2012) == 
     91 
     92 * The modified IOIPSL helps to improve the performances of the model. On 16 processors, we divide by 10 the computational time taken by the subroutine moycum. It seems that the last processor always takes much more time that the others. Should we revise the algorithm for the LoadBalance.dat ? 
     93 * An other big problem appears with the subroutine flinopen_work : on 96 processors, this subroutine takes 90% of the time computing! This problem neutralizes the patch. 
     94 * Possible explanations : bug in IOIPSL, bug in the parallelization, bad use of Vampir? 
     95 * To investigate : why flinopen takes so much time? Test with previous ORCHIDEE tag and IOIPSL tag. Study the influence of th file LoadBalance.dat.