- discuss - mailman3.cels.anl.gov

Re: [mpich-discuss] Problem in the step of "make"
by Eric A. Borisch 22 Mar '13

22 Mar '13

On Fri, Mar 22, 2013 at 10:35 AM, yuanp <peng.yuan(a)student.ecp.fr> wrote: > Hello, > > I am currently a student at Ecole Central Paris in Paris following the > cours of *High Performance Computing* which demand the installation of > mpich2. Possessing a macbook air with OSX Lion version 10.7.5, I have met a > problem when install mpich2 at the step "make". I don't know what to do > now. > I have enclosed the c.txt, m.txt, mi.txt files for you. Thank you for help. > Any reason you can't use MacPorts to install mpich? - Eric

1 0

Problem in the step of "make"
by yuanp 22 Mar '13

22 Mar '13

Hello, I am currently a student at Ecole Central Paris in Paris following the cours of /High Performance Computing/ which demand the installation of mpich2. Possessing a macbook air with OSX Lion version 10.7.5, I have met a problem when install mpich2 at the step "make". I don't know what to do now. I have enclosed the c.txt, m.txt, mi.txt files for you. Thank you for help. Best regards Peng YUAN

1 0

success and failure report for mpich-3.0.2
by Siegmar Gross 22 Mar '13

22 Mar '13

Hi today I tried to install mpich-3.0.2. I could compile and install the package for the following architectures. openSuSE Linux 12.1, x86_64, Sun C 5.12, 64-bit Solaris 10, x86_64, Sun C 5.12, 64-bit Solaris 10, sparc, Sun C 5.12, 32-bit Solaris 10, sparc, Sun C 5.12, 64-bit As described in the RELEASE_NOTES a communication between little-endian and big-endian machines is not possible (broken pipe). Unfortunately you don't even allow different operating systems (it seems that you don't evaluate PATH to find a program). sunpc1 fd1026 103 mpiexec -np 2 -host sunpc0,sunpc1 init_finalize Hello! Hello! sunpc1 fd1026 104 mpiexec -np 2 -host sunpc0,linpc1 init_finalize [proxy:0:1@linpc1] HYDU_create_process (../../../../mpich-3.0.2/src/pm/hydra/utils/launch/launch.c:74): execvp error on file init_finalize (No such file or directory) ======================================================================== = BAD TERMINATION OF ONE OF YOUR APPLICATION PROCESSES = EXIT CODE: 255 = CLEANING UP REMAINING PROCESSES = YOU CAN IGNORE THE BELOW CLEANUP MESSAGES ======================================================================== [proxy:0:0@sunpc0] HYD_pmcd_pmip_control_cmd_cb (../../../../mpich-3.0.2/src/pm/hydra/pm/pmiserv/pmip_cb.c:886): assert (!closed) failed [proxy:0:0@sunpc0] HYDT_dmxu_poll_wait_for_event (../../../../mpich-3.0.2/src/pm/hydra/tools/demux/demux_poll.c:77): callback returned error status [proxy:0:0@sunpc0] main (../../../../mpich-3.0.2/src/pm/hydra/pm/pmiserv/pmip.c:206): demux engine error waiting for event The programs are available on both machines. sunpc1 fd1026 105 which init_finalize /home/fd1026/SunOS/x86_64/bin/init_finalize sunpc1 fd1026 106 ssh linpc1 which init_finalize /home/fd1026/Linux/x86_64/bin/init_finalize sunpc1 fd1026 107 I wasn't able to build the package on the following architectures. openSuSE Linux 12.1, x86_64, Sun C 5.12, 32-bit openSuSE Linux 12.1, x86_64, GNU C 4.7.1, 32-bit ------------------------------------------------ tyr mpich-3.0.2-Linux.x86_64.32_cc 158 tail log.make.Linux.x86_64.32_cc CC mplstr.lo CC mpltrmem.lo CC mplenv.lo CCLD libmpl.la /usr/lib/libxml2.so: could not read symbols: File in wrong format make[2]: *** [libmpl.la] Error 2 make[2]: Leaving directory `.../src/mpl' make[1]: *** [all-recursive] Error 1 openSuSE Linux 12.1, x86_64, GNU C 4.7.1, 64-bit ------------------------------------------------ tyr mpich-3.0.2-Linux.x86_64.64_gcc 171 tail log.make.Linux.x86_64.64_gcc CC mpltrmem.lo CC mplenv.lo CCLD libmpl.la /usr/local/bin/ld: libmpl.so.1: No such file: No such file or directory collect2: error: ld returned 1 exit status make[2]: *** [libmpl.la] Error 1 make[2]: Leaving directory `.../src/mpl' Solaris 10, x86_64, Sun C 5.12, 32-bit -------------------------------------- hangs Solaris 10, x86_64, GNU C 4.7.1, 32-bit --------------------------------------- tyr mpich-3.0.2-SunOS.x86_64.32_gcc 193 tail -12 log.make.SunOS.x86_64.32_gcc CC src/mpi/coll/barrier_group.lo CC src/mpi/coll/helper_fns.lo Assembler: helper_fns.c "/var/tmp//ccIdXgrh.s", line 912 : Syntax error Near line: "mov $PREFETCHBLOCK/16, %eax" "/var/tmp//ccIdXgrh.s", line 920 : Syntax error Near line: "mov $PREFETCHBLOCK/8, %eax" make[2]: *** [src/mpi/coll/helper_fns.lo] Error 1 Solaris 10, x86_64, GNU C 4.7.1, 64-bit Solaris 10, sparc, GNU C 4.7.1, 32-bit Solaris 10, sparc, GNU C 4.7.1, 64-bit --------------------------------------- tyr mpich-3.0.2-SunOS.x86_64.64_gcc 195 tail log.make.SunOS.x86_64.64_gcc CXX src/binding/cxx/initcxx.lo CXXLD lib/libmpichcxx.la ld: fatal: file libmpichcxx.so.10: open failed: No such file or directory ld: fatal: file processing errors. No output written to lib/.libs/libmpichcxx.so.10.0.2 collect2: error: ld returned 1 exit status make[2]: *** [lib/libmpichcxx.la] Error 1 Kind regards Siegmar

1 0

Re: [mpich-discuss] mpich2 support processor affinity by default
by benzhi cao 22 Mar '13

22 Mar '13

2013/3/22 benzhi cao <caobenzhi0915(a)gmail.com> > Hi~ > when you run a program with multi-threads.(For instance ,you just type > "mpiexec -n 4 ./app" to run an app with four threads.) ,obviously the > processor manager will fork several processes to execute the app.What I am > wondering is the MPICH2 support processor affinity by default? Does the > MPI process manager(MPICH2 hydra) will bind each forked process to a cpu > automatically or just do nothing after forking the processes and waithing > for the os to dispatch this? > I am appreciate for any reply~Thanks in advance~ > Best~ >

1 0

Re: [mpich-discuss] Query regarding structure of dynamic array derived datatype
by Jed Brown 21 Mar '13

21 Mar '13

On Thu, Mar 21, 2013 at 8:29 PM, Pavan Balaji <balaji(a)mcs.anl.gov> wrote: > You'll still need to create a datatype for MPI_Pack. This is the > structure you mentioned: > > struct A > { > int size; > int *lptr; > }; > > I'm assuming you want to send the size and the data associated with lptr > in a single message. In this case, the only approaches I can think of are: > > 1. Create a datatype every time you want to send this information and > free it once you are done. > > 2. Send two messages, one with the size parameter and the second with > the data pointed to by lptr. > > Someone else might have a better way to do this. > If the receiver does not know the size in advance (or at least an upper bound), then they would have to allocate before receiving anyway. If you have to do that, you may as well either send two messages or use MPI_Probe/MPI_Iprobe and allocate once you know the message size. If the receiver knows an upper bound in advance, just MPI_Recv that upper bound and use MPI_Get_count to find out how much you received. If you have many of these, I would send all the sizes in one message and all the data in another message, unless the receiver knows the sizes in advance. Once you know all the sizes, you could make an MPI_Type_create_hindexed and send with respect to MPI_BOTTOM to send all those separate arrays without explicit packing. I would only bother with that in a memory-constrained environment or after exhausting the simpler options.

1 0

Re: [mpich-discuss] Query regarding structure of dynamic array derived datatype
by Pavan Balaji 21 Mar '13

21 Mar '13

You'll still need to create a datatype for MPI_Pack. This is the structure you mentioned: struct A { int size; int *lptr; }; I'm assuming you want to send the size and the data associated with lptr in a single message. In this case, the only approaches I can think of are: 1. Create a datatype every time you want to send this information and free it once you are done. 2. Send two messages, one with the size parameter and the second with the data pointed to by lptr. Someone else might have a better way to do this. -- Pavan On 03/21/2013 08:21 PM US Central Time, Raghu Reddy wrote: > As far as I know, since your struct contains a pointer, I donï¿½t believe > you have a choice other than to pack. > > > > Someone can correct me if Iï¿½m wrong. > > > > Thanks, > > > > Raghu > > > > > > > > *From:*[email protected] [mailto:[email protected]] *On > Behalf Of *Mahesh Doijade > *Sent:* Thursday, March 21, 2013 4:42 AM > *To:* mpich-discuss(a)mcs.anl.gov > *Subject:* Re: [mpich-discuss] Query regarding structure of dynamic > array derived datatype > > > > Hi, > Thanks for your reply, after looking at various MPI derived > datatype creation functions other than MPI_Pack according to me option > can probably be of using MPI_Type_create_struct but then for each > structure element I have to create a separate derived datatype as the > block lengths will be different due to dynamic array present in them, so > again the extra memory will be required now for type-maps of these > datatypes. > Is the approach of MPI_Type_create_struct mentioned above will be > better than MPI_Pack in this case? also is there any other optimal way > to do this? > > > -- > > Regards, > -- Mahesh Doijade > > On Thu, Mar 21, 2013 at 2:36 AM, Pavan Balaji <balaji(a)mcs.anl.gov > <mailto:[email protected]>> wrote: > > > Please look through the derived datatype constructs in MPI. Google can > help you find some tutorials. > > -- Pavan > > > On 03/19/2013 06:12 AM US Central Time, Mahesh Doijade wrote: >> Hi, >> I have a struct as - >> struct A >> { >> int size; >> int *lptr; >> }; >> And then I have array of such structure, I want to only send >> dynamic array present in each of the structs to other process. >> One of the options is to do it with MPI_Pack but then I have read it is >> not so good from performance point of view. >> What can be the other opt >> >> -- >> >> Regards, >> -- Mahesh Doijade >> >> >> >> >> > >> _______________________________________________ >> discuss mailing list discuss(a)mpich.org <mailto:[email protected]> >> To manage subscription options or unsubscribe: >> https://lists.mpich.org/mailman/listinfo/discuss >> > > -- > Pavan Balaji > http://www.mcs.anl.gov/~balaji <http://www.mcs.anl.gov/%7Ebalaji> > > > > > > > > _______________________________________________ > discuss mailing list discuss(a)mpich.org > To manage subscription options or unsubscribe: > https://lists.mpich.org/mailman/listinfo/discuss > -- Pavan Balaji http://www.mcs.anl.gov/~balaji

1 0

Re: [mpich-discuss] Query regarding structure of dynamic array derived datatype
by Raghu Reddy 21 Mar '13

21 Mar '13

As far as I know, since your struct contains a pointer, I don't believe you have a choice other than to pack. Someone can correct me if I'm wrong. Thanks, Raghu From: discuss-bounces(a)mpich.org [mailto:[email protected]] On Behalf Of Mahesh Doijade Sent: Thursday, March 21, 2013 4:42 AM To: mpich-discuss(a)mcs.anl.gov Subject: Re: [mpich-discuss] Query regarding structure of dynamic array derived datatype Hi, Thanks for your reply, after looking at various MPI derived datatype creation functions other than MPI_Pack according to me option can probably be of using MPI_Type_create_struct but then for each structure element I have to create a separate derived datatype as the block lengths will be different due to dynamic array present in them, so again the extra memory will be required now for type-maps of these datatypes. Is the approach of MPI_Type_create_struct mentioned above will be better than MPI_Pack in this case? also is there any other optimal way to do this? -- Regards, -- Mahesh Doijade On Thu, Mar 21, 2013 at 2:36 AM, Pavan Balaji <balaji(a)mcs.anl.gov> wrote: Please look through the derived datatype constructs in MPI. Google can help you find some tutorials. -- Pavan On 03/19/2013 06:12 AM US Central Time, Mahesh Doijade wrote: > Hi, > I have a struct as - > struct A > { > int size; > int *lptr; > }; > And then I have array of such structure, I want to only send > dynamic array present in each of the structs to other process. > One of the options is to do it with MPI_Pack but then I have read it is > not so good from performance point of view. > What can be the other opt > > -- > > Regards, > -- Mahesh Doijade > > > > > > _______________________________________________ > discuss mailing list discuss(a)mpich.org > To manage subscription options or unsubscribe: > https://lists.mpich.org/mailman/listinfo/discuss > -- Pavan Balaji http://www.mcs.anl.gov/~balaji <http://www.mcs.anl.gov/%7Ebalaji>

1 0

Re: [mpich-discuss] MPI_Comm_Spawn causing zombies of hydra_pmi_proxy
by Silvan Brändli 21 Mar '13

21 Mar '13

PS: Just some additional information on compilers: so far I used icpc, when changing it to gcc-4.7.2 I still get the zombies. The only change in the linked libraries is an additional libdl.so.2 => /lib64/libdl.so.2 Any hint / idea? Best regards Silvan On 19.03.2013 10:47, Silvan Brï¿½ndli wrote: > Dear Pavan, > > in the attached example I use mpich3, but still I get the zombies. Is > there something wrong with > - my MPI function calls? (disconnect, finalize) > - my linked libraries? (see below) > > Thanks in advance! > Best regards > Silvan > > ldd_hi > linux-vdso.so.1 (0x00007fffa01ff000) > libmpichcxx.so.10 => /opt/mpich3/lib/libmpichcxx.so.10 > (0x00007fdfec0e4000) > libmpich.so.10 => /opt/mpich3/lib/libmpich.so.10 (0x00007fdfebc6f000) > libopa.so.1 => /opt/mpich3/lib/libopa.so.1 (0x00007fdfeba6d000) > libmpl.so.1 => /opt/mpich3/lib/libmpl.so.1 (0x00007fdfeb868000) > libaio.so.1 => /lib64/libaio.so.1 (0x00007fdfeb666000) > libpthread.so.0 => /lib64/libpthread.so.0 (0x00007fdfeb449000) > libm.so.6 => /lib64/libm.so.6 (0x00007fdfeb14e000) > libstdc++.so.6 => > /usr/lib/gcc/x86_64-pc-linux-gnu/4.7.2/libstdc++.so.6 (0x00007fdfeae47000) > libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007fdfeac30000) > libc.so.6 => /lib64/libc.so.6 (0x00007fdfea882000) > libdl.so.2 => /lib64/libdl.so.2 (0x00007fdfea67e000) > libgfortran.so.3 => > /usr/lib/gcc/x86_64-pc-linux-gnu/4.7.2/libgfortran.so.3 > (0x00007fdfea361000) > libquadmath.so.0 => > /usr/lib/gcc/x86_64-pc-linux-gnu/4.7.2/libquadmath.so.0 > (0x00007fdfea12b000) > /lib64/ld-linux-x86-64.so.2 (0x00007fdfec308000) > librt.so.1 => /lib64/librt.so.1 (0x00007fdfe9f23000) > ldd_main > linux-vdso.so.1 (0x00007fffeb1ff000) > libmpichcxx.so.10 => /opt/mpich3/lib/libmpichcxx.so.10 > (0x00007f6fc797e000) > libmpich.so.10 => /opt/mpich3/lib/libmpich.so.10 (0x00007f6fc7509000) > libopa.so.1 => /opt/mpich3/lib/libopa.so.1 (0x00007f6fc7307000) > libmpl.so.1 => /opt/mpich3/lib/libmpl.so.1 (0x00007f6fc7102000) > libaio.so.1 => /lib64/libaio.so.1 (0x00007f6fc6f00000) > libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f6fc6ce3000) > libm.so.6 => /lib64/libm.so.6 (0x00007f6fc69e8000) > libstdc++.so.6 => > /usr/lib/gcc/x86_64-pc-linux-gnu/4.7.2/libstdc++.so.6 (0x00007f6fc66e1000) > libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007f6fc64ca000) > libc.so.6 => /lib64/libc.so.6 (0x00007f6fc611c000) > libdl.so.2 => /lib64/libdl.so.2 (0x00007f6fc5f18000) > libgfortran.so.3 => > /usr/lib/gcc/x86_64-pc-linux-gnu/4.7.2/libgfortran.so.3 > (0x00007f6fc5bfb000) > libquadmath.so.0 => > /usr/lib/gcc/x86_64-pc-linux-gnu/4.7.2/libquadmath.so.0 > (0x00007f6fc59c5000) > /lib64/ld-linux-x86-64.so.2 (0x00007f6fc7ba2000) > librt.so.1 => /lib64/librt.so.1 (0x00007f6fc57bd000) > > On 07.03.2013 17:23, Pavan Balaji wrote: >> >> I just tried this with the mpich master and it seems to work correctly, >> and there are no zombie processes (though I reduced the number of >> iterations to 10000, instead of 200000). This was a problem in mpich >> once upon a time, but that was a few years ago. Are you using the >> latest version of mpich (3.0.2)? >> >> -- Pavan >> >> On 03/07/2013 09:44 AM US Central Time, Silvan Brï¿½ndli wrote: >>> PS: The attached programs are a simplification of my code. They >>> reproduce the zombie problem. Waiting for the 32k zombies takes a >>> while... but I expect the same behaviour as with my original code. >>> >>> Am I missing something when finishing the called program? I just use >>> MPI_Comm_disconnect and MPI_Finalize. >>> >>> Best regards >>> Silvan >>> >>> main.cpp >>> >>> #include <mpi.h>; >>> >>> int main(int argc, char *argv[]) >>> { >>> int myrank; >>> int spawnerror; >>> int value = 123; >>> void *buf = &value; >>> MPI_Comm child_comm; >>> >>> if (MPI_Init(&argc,&argv)!=MPI_SUCCESS) >>> { >>> printf("MPI_Init failed"); >>> } >>> >>> MPI_Comm_rank(MPI_COMM_WORLD, &myrank); >>> >>> char* hiargv[] = {"23",NULL}; >>> for(int i = 1; i <= 200000; i++) >>> { >>> value = i; >>> printf("Main before spawn %d\n",i); >>> MPI_Comm_spawn("./hi",hiargv, 1, MPI_INFO_NULL, myrank, >>> MPI_COMM_SELF, &child_comm, &spawnerror); >>> MPI_Send(buf, 1, MPI_INTEGER, 0, 1, child_comm); >>> MPI_Comm_disconnect(&child_comm); >>> } >>> >>> MPI_Finalize(); >>> return 0; >>> } >>> >>> hi.cpp: >>> >>> #include <mpi.h>; >>> >>> int main(int argc, char** argv) { >>> MPI_Comm parent; >>> MPI_Status status; >>> int err; >>> int value = -1; >>> void* buf= &value; >>> >>> if (MPI_Init(&argc,&argv)!=MPI_SUCCESS) >>> { >>> printf("MPI_Init failed"); >>> } >>> MPI_Comm_get_parent(&parent); >>> if (parent == MPI_COMM_NULL) printf("No parent!"); >>> >>> MPI_Recv(buf, 1, MPI_INTEGER, 0, MPI_ANY_TAG, parent, &status); >>> MPI_Comm_disconnect(&parent); >>> err = MPI_Finalize(); >>> printf("hi finalized %d %d \n",err, value); >>> return 0; >>> } >>> >>> >>> >>> On 07.03.2013 12:38, Silvan Brï¿½ndli wrote: >>>> Dear all, >>>> >>>> again I have a question related to spawning processes. I understand the >>>> situation as follows: >>>> >>>> My program A spawns program B. Program B spawns program C1, C2 ... >>>> C10000 ... >>>> Program Cx terminates correctly before Cx+1 is called, however >>>> returning >>>> 1 to mpiexec. To handle this I use the workaround as described in >>>> http://lists.mpich.org/pipermail/discuss/2013-February/000429.html >>>> >>>> Now it looks like with every Spawn a "hydra_pmi_proxy" is started, the >>>> calling program is mpiexec. When the program Cx is finished this >>>> "hydra_pmi_proxy" remains as a zombie until the programs A, B and >>>> mpiexec are finished. When approx. 32k of those "hydra_pmi_proxy" exist >>>> I get some problems (too many processes or something similar). >>>> >>>> What can I do to finish "hydra_pmi_proxy" while my programs A, B and >>>> mpiexec are still running? >>>> >>>> I'm glad about every hint. >>>> >>>> Best regards >>>> Silvan >>>> >>> >>> >>> >>> >>> _______________________________________________ >>> discuss mailing list discuss(a)mpich.org >>> To manage subscription options or unsubscribe: >>> https://lists.mpich.org/mailman/listinfo/discuss >>> >> > > > > > _______________________________________________ > discuss mailing list discuss(a)mpich.org > To manage subscription options or unsubscribe: > https://lists.mpich.org/mailman/listinfo/discuss > -- Dipl.-Ing. Silvan Brï¿½ndli Numerische Strukturanalyse mit Anwendungen in der Schiffstechnik (M-10) Technische Universitï¿½t Hamburg-Harburg Schwarzenbergstraï¿½e 95c 21073 Hamburg Tel. : +49 (0)40 42878 - 6187 Fax. : +49 (0)40 42878 - 6090 e-mail: silvan.braendli(a)tuhh.de www : http://www.tuhh.de/skf 5th GACM Colloquium on Computational Mechanics http://www.tu-harburg.de/gacm2013

1 0

Re: [mpich-discuss] Query regarding structure of dynamic array derived datatype
by Mahesh Doijade 21 Mar '13

21 Mar '13

Hi, Thanks for your reply, after looking at various MPI derived datatype creation functions other than MPI_Pack according to me option can probably be of using MPI_Type_create_struct but then for each structure element I have to create a separate derived datatype as the block lengths will be different due to dynamic array present in them, so again the extra memory will be required now for type-maps of these datatypes. Is the approach of MPI_Type_create_struct mentioned above will be better than MPI_Pack in this case? also is there any other optimal way to do this? -- Regards, -- Mahesh Doijade On Thu, Mar 21, 2013 at 2:36 AM, Pavan Balaji <balaji(a)mcs.anl.gov> wrote: > > Please look through the derived datatype constructs in MPI. Google can > help you find some tutorials. > > -- Pavan > > On 03/19/2013 06:12 AM US Central Time, Mahesh Doijade wrote: > > Hi, > > I have a struct as - > > struct A > > { > > int size; > > int *lptr; > > }; > > And then I have array of such structure, I want to only send > > dynamic array present in each of the structs to other process. > > One of the options is to do it with MPI_Pack but then I have read it is > > not so good from performance point of view. > > What can be the other opt > > > > -- > > > > Regards, > > -- Mahesh Doijade > > > > > > > > > > > > _______________________________________________ > > discuss mailing list discuss(a)mpich.org > > To manage subscription options or unsubscribe: > > https://lists.mpich.org/mailman/listinfo/discuss > > > > -- > Pavan Balaji > http://www.mcs.anl.gov/~balaji >

1 0

Re: [mpich-discuss] Re : MPI I/O vs Sequential I/O
by Rajeev Thakur 20 Mar '13

20 Mar '13

megabytes, gigabytes. On Mar 20, 2013, at 6:13 PM, Muhammad Zulfikar Handana wrote: > > exactly how big the files are great for use on a comparison of MPI I / O? > > thank a lot for your attention > > handana > > fwrite() does buffered I/O, which will perform better for small writes. A better comparison would be to use write(), which is what MPI-IO uses internally. > > Rajeev > > On Mar 18, 2013, at 3:49 PM, Muhammad Zulfikar Handana wrote: > > > hello, i have some questions about MPI-I/O. > > > > 1) when i trying execute my program using MPI-I/O. why when iam execute > > with 1 proses, execute time more good than when iam execute with 2 proses. > > am i wrong? this is my source code. > > MPI_File_open (MPI_COMM_WORLD, file_akhir, MPI_MODE_CREATE | > > MPI_MODE_WRONLY, MPI_INFO_NULL, &hasil); > > int jumlah1 = (((block-1)*16)+pad); > > int jumlah = jumlah1 / size; > > > > > > MPI_File_set_view(hasil, rank * jumlah * > > sizeof(char),MPI_CHAR, MPI_CHAR, "native", MPI_INFO_NULL); > > MPI_File_write (hasil, output, jumlah1, MPI_CHAR, > > MPI_STATUS_IGNORE); > > > > MPI_File_close(&hasil); > > > > 2) and after that i have compared that source using MPI - I/O and with > > sequential I/O, apparently, sequential i / o is better than the parallel i > > / o. how it could be happen? this is my sequential source. > > if (rank==0) { > > > > hasil = fopen (file_akhir, "wb"); > > int test = (((block-1)*16)+pad); > > fwrite (output, sizeof(char), test, hasil ); > > fclose (hasil); > > } > > > > thanks a lot for your attention > _______________________________________________ > discuss mailing list discuss(a)mpich.org > To manage subscription options or unsubscribe: > https://lists.mpich.org/mailman/listinfo/discuss

1 0