Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.forth > #59188 > unrolled thread

illustration of syscalls fork and mmap

Back to article view | Back to comp.lang.forth

Contents

  illustration of syscalls fork and mmap krishna.myneni@ccreweb.org - 2017-05-13 12:25 -0700
    Re: illustration of syscalls fork and mmap krishna.myneni@ccreweb.org - 2017-05-22 16:00 -0700
      Re: illustration of syscalls fork and mmap anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-23 12:01 +0000
        Re: illustration of syscalls fork and mmap krishna.myneni@ccreweb.org - 2017-05-23 16:30 -0700
          Re: illustration of syscalls fork and mmap anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-24 10:13 +0000
            Re: illustration of syscalls fork and mmap krishna.myneni@ccreweb.org - 2017-05-24 13:59 -0700
              Re: illustration of syscalls fork and mmap anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-25 08:47 +0000
                Re: illustration of syscalls fork and mmap krishna.myneni@ccreweb.org - 2017-05-25 04:04 -0700
                  Re: illustration of syscalls fork and mmap krishna.myneni@ccreweb.org - 2017-05-25 04:29 -0700
                  Re: illustration of syscalls fork and mmap anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-25 11:27 +0000
                    Re: illustration of syscalls fork and mmap krishna.myneni@ccreweb.org - 2017-05-25 05:23 -0700
      Re: illustration of syscalls fork and mmap krishna.myneni@ccreweb.org - 2017-05-25 16:54 -0700
        Re: illustration of syscalls fork and mmap krishna.myneni@ccreweb.org - 2017-05-25 19:19 -0700
          Re: illustration of syscalls fork and mmap krishna.myneni@ccreweb.org - 2017-05-25 19:34 -0700
            Re: illustration of syscalls fork and mmap Roelf Toxopeus <rt4all@nothishetnet.nl> - 2017-05-26 11:03 +0200
              Re: illustration of syscalls fork and mmap krishna.myneni@ccreweb.org - 2017-05-26 05:15 -0700
                Re: illustration of syscalls fork and mmap anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-26 15:22 +0000
                  Re: illustration of syscalls fork and mmap krishna.myneni@ccreweb.org - 2017-05-26 17:13 -0700
                    Re: illustration of syscalls fork and mmap josv@planet.nl - 2017-05-26 23:26 -0700
                      Re: illustration of syscalls fork and mmap krishna.myneni@ccreweb.org - 2017-05-27 06:20 -0700
                        Re: illustration of syscalls fork and mmap josv@planet.nl - 2017-05-27 07:41 -0700
                    Re: illustration of syscalls fork and mmap anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-27 06:21 +0000
                      Re: illustration of syscalls fork and mmap krishna.myneni@ccreweb.org - 2017-05-27 06:32 -0700
                  Re: illustration of syscalls fork and mmap Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-27 01:17 -0500
                    Re: illustration of syscalls fork and mmap josv@planet.nl - 2017-05-26 23:43 -0700
                      Re: illustration of syscalls fork and mmap Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-27 01:49 -0500
                        Re: illustration of syscalls fork and mmap mhx@iae.nl - 2017-05-28 03:25 -0700
                          Re: illustration of syscalls fork and mmap josv@planet.nl - 2017-05-28 04:56 -0700
                    Re: illustration of syscalls fork and mmap krishna.myneni@ccreweb.org - 2017-05-27 06:53 -0700
                  Re: illustration of syscalls fork and mmap Roelf Toxopeus <rt4all@nothishetnet.nl> - 2017-05-27 10:23 +0200
            Re: illustration of syscalls fork and mmap krishna.myneni@ccreweb.org - 2017-05-27 12:07 -0700

Page 1 of 2  [1] 2  Next page →

#59188 — illustration of syscalls fork and mmap

I've updated an earlier example, parallel-mm.4th, which used the system call, fork, to demonstrate DIY parallel processing for matrix multiplication. This example demonstrated computing the product of a 2 x N matrix, A{{ , with an N x 1 array B{ , in which the first row was computed by the parent process and the second row was computed by the forked child process (which typically runs on a separate processor core for a multi-core machine). There was no interprocess communication from the child back to the parent in the earlier example. The revised version generalizes the calculation to an arbitrary number of rows for matrix A{{ , with the parent process handling the multiplication for the even rows and the child process doing the odd rows. A shared memory region is set up, using mmap, so that the parent has access to the results of the calculations done by the child. 

The program provides a nice example for using the fork and mmap system calls, and doing a quick and dirty form of parallel computing. There is no attempt to do the matrix multiplication with any efficiency, but one can should easily see the factor of two speed-up with the parallel process on a suitable system. The revised version may be found at

ftp://ccreweb.org/software/kforth/examples/parallel-mm.4th

Krishna

[toc] | [next] | [standalone]

#59739

On Saturday, May 13, 2017 at 2:25:22 PM UTC-5, krishna...@ccreweb.org wrote:
> I've updated an earlier example, parallel-mm.4th, ...

The parallel-mm.4th example has been updated to use the new mmul.4th module, which provides a much more efficient matrix multiplication algorithm. The matrix multiplication in this example is executed 5x faster as a result. An additional factor of 1.8x is demonstrated on my system (AMD Athlon-64 1 GHz 4-core machine) by using parallel processing with 2 processes.

Note that mmul.4th required an update to allow the row/column multiplier word, df_mul_r1c2,  to be called independently of the matrix multiplication word df_mmul. A new word, set_mmul_params,
is included for this purpose.

Links to the kForth code are:

ftp://ccreweb.org/software/kforth/examples/parallel-mm.4th
ftp://ccreweb.org/software/kforth/examples/fsl/extras/mmul.4th

An updated version of mmul.fs, for standard Forth systems with a
separate fp stack may be found at

ftp://ccreweb.org/software/fsl/extras/mmul.fs

I would like to test parallel-mm.4th on a Forth system like gforth under Linux, but don't know how to do fork and mmap on other systems.

Krishna

[toc] | [prev] | [next] | [standalone]

#59745

krishna.myneni@ccreweb.org writes:
>I would like to test parallel-mm.4th on a Forth system like gforth under Li=
>nux, but don't know how to do fork and mmap on other systems.

In current development Gforth, unix/libc.fs contains fork(), and
unix/mmap.fs contains mmap.

c-function fork() fork -- n ( -- pid_t )
c-function mmap mmap a n n n n n -- a ( addr len prot flags fd off -- addr' )

- anton
-- 
M. Anton Ertl  http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
     New standard: http://www.forth200x.org/forth200x.html
   EuroForth 2017: http://www.euroforth.org/ef17/

[toc] | [prev] | [next] | [standalone]

#59762

On Tuesday, May 23, 2017 at 7:05:24 AM UTC-5, Anton Ertl wrote:
> krishna...org writes:
> >I would like to test parallel-mm.4th on a Forth system like gforth under Li=
> >nux, but don't know how to do fork and mmap on other systems.
> 
> In current development Gforth, unix/libc.fs contains fork(), and
> unix/mmap.fs contains mmap.
> 
> c-function fork() fork -- n ( -- pid_t )
> c-function mmap mmap a n n n n n -- a ( addr len prot flags fd off -- addr' )
> 

Thanks. From where (how) do I obtain the latest development version?

Krishna

[toc] | [prev] | [next] | [standalone]

#59771

krishna.myneni@ccreweb.org writes:
>On Tuesday, May 23, 2017 at 7:05:24 AM UTC-5, Anton Ertl wrote:
>> krishna...org writes:
>> >I would like to test parallel-mm.4th on a Forth system like gforth under Li=
>> >nux, but don't know how to do fork and mmap on other systems.
>> 
>> In current development Gforth, unix/libc.fs contains fork(), and
>> unix/mmap.fs contains mmap.
>> 
>> c-function fork() fork -- n ( -- pid_t )
>> c-function mmap mmap a n n n n n -- a ( addr len prot flags fd off -- addr' )
>> 
>
>Thanks. From where (how) do I obtain the latest development version?

https://www.complang.tuwien.ac.at/forth/gforth/Snapshots/current/gforth.tar.xz

- anton
-- 
M. Anton Ertl  http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
     New standard: http://www.forth200x.org/forth200x.html
   EuroForth 2017: http://www.euroforth.org/ef17/

[toc] | [prev] | [next] | [standalone]

#59791

On Wednesday, May 24, 2017 at 5:16:02 AM UTC-5, Anton Ertl wrote:
...
> 
> https://www.complang.tuwien.ac.at/forth/gforth/Snapshots/current/gforth.tar.xz
> 

All the build steps (configure, make, make check, make bench) completed successfully. The following fails, but maybe I need to read the manual (?):

-----------------------
$ ./gforth
Gforth 0.7.9_20170518, Copyright (C) 1995-2016 Free Software Foundation, Inc.
Gforth comes with ABSOLUTELY NO WARRANTY; for details type `license'
Type `help' for basic help
  ok
include unix/mmap.fs 
in file included from *the terminal*:2
unix/mmap.fs:39: error: Invalid memory address
end-c-library
Backtrace:
                                         0 $7FCD70B6F390 close-lib 
                                         1 $7FCD70B6FDC0 check-c-hash 
                                         2 $7FCD70B71E68 compile-wrapper-function1 
--------------------------------

Also, I can't find the syscall, waitpid. Should that be part of the unix/libc.fs ?

Krishna

[toc] | [prev] | [next] | [standalone]

#59811

krishna.myneni@ccreweb.org writes:
>On Wednesday, May 24, 2017 at 5:16:02 AM UTC-5, Anton Ertl wrote:
>...
>> 
>> https://www.complang.tuwien.ac.at/forth/gforth/Snapshots/current/gforth.tar.xz
>> 
>
>All the build steps (configure, make, make check, make bench) completed successfully. The following fails, but maybe I need to read the manual (?):
>
>-----------------------
>$ ./gforth
>Gforth 0.7.9_20170518, Copyright (C) 1995-2016 Free Software Foundation, Inc.
>Gforth comes with ABSOLUTELY NO WARRANTY; for details type `license'
>Type `help' for basic help
>  ok
>include unix/mmap.fs 
>in file included from *the terminal*:2
>unix/mmap.fs:39: error: Invalid memory address
>end-c-library
>Backtrace:
>                                         0 $7FCD70B6F390 close-lib 
>                                         1 $7FCD70B6FDC0 check-c-hash 
>                                         2 $7FCD70B71E68 compile-wrapper-function1 
>--------------------------------

That you get the exception indicates a Gforth bug in a code path that
I don't exercise (this works for me).  We will look into the bug, but
you have some other problem as well, or you would not be exercising
this code path.  My guess is that you don't have libltdl installed.
Gforth's build works around missing features, but that means that the
features are then missing in the resulting Gforth system.

>Also, I can't find the syscall, waitpid. Should that be part of the unix/libc.fs ?

Or some other library, but it's not yet there.  Now you can read the
manual about the C interface and defined the C function for waitpid
yourself.  Or you are patient and wait until we supply it.

- anton
-- 
M. Anton Ertl  http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
     New standard: http://www.forth200x.org/forth200x.html
   EuroForth 2017: http://www.euroforth.org/ef17/

[toc] | [prev] | [next] | [standalone]

#59821

On Thursday, May 25, 2017 at 4:32:04 AM UTC-5, Anton Ertl wrote:
...
> That you get the exception indicates a Gforth bug in a code path that
> I don't exercise (this works for me).  We will look into the bug, but
> you have some other problem as well, or you would not be exercising
> this code path.  My guess is that you don't have libltdl installed.
> Gforth's build works around missing features, but that means that the
> features are then missing in the resulting Gforth system.
> 

I checked and found libltdl to be installed on my CentOS 7 system:

$ ls libltdl*
libltdl.so.7  libltdl.so.7.3.0

I checked the messages from ./configure and the following seem to indicate the problem: some necessary package(s) to support the C library interface appear to be missing.

checking for library containing dlopen... -ldl
checking for dlerror... yes
:
checking whether libtool supports -dlopen/-dlpreopen... yes
checking for ltdl.h... no
checking where to find libltdl headers... -I$(top_srcdir)/libltdl
checking where to find libltdl library... $(top_build_prefix)libltdl/libltdlc.la
:
checking for libtool... libtool
:
checking for lt_dlinit in -lltdl... no
:
./configure: line 16026: test: too many arguments
configure: WARNING: No LIBTOOL found, skip pre-building libcc-based libraries
configure: WARNING: No LIBTOOL found, skip building library


> >Also, I can't find the syscall, waitpid. Should that be part of the unix/libc.fs ?
> 
> Or some other library, but it's not yet there.  Now you can read the
> manual about the C interface and defined the C function for waitpid
> yourself. ...

I can add it myself.

Krishna

[toc] | [prev] | [next] | [standalone]

#59823

On Thursday, May 25, 2017 at 6:04:18 AM UTC-5, krishna...org wrote:
...
> I checked and found libltdl to be installed on my CentOS 7 system:
> 
> $ ls libltdl*
> libltdl.so.7  libltdl.so.7.3.0
> 
> I checked the messages from ./configure and the following seem to indicate the problem: some necessary package(s) to support the C library interface appear to be missing.
> 
> checking for library containing dlopen... -ldl
> checking for dlerror... yes
> :
> checking whether libtool supports -dlopen/-dlpreopen... yes
> checking for ltdl.h... no
> checking where to find libltdl headers... -I$(top_srcdir)/libltdl
> checking where to find libltdl library... $(top_build_prefix)libltdl/libltdlc.la
> :
> checking for libtool... libtool
> :
> checking for lt_dlinit in -lltdl... no
> :
> ./configure: line 16026: test: too many arguments
> configure: WARNING: No LIBTOOL found, skip pre-building libcc-based libraries
> configure: WARNING: No LIBTOOL found, skip building library
> ... 

I fixed the problem by installing the following package on CentOS 7: libtool-ltdl-devel

--------------------------
$ ./gforth
Gforth 0.7.9_20170518, Copyright (C) 1995-2016 Free Software Foundation, Inc.
Gforth comes with ABSOLUTELY NO WARRANTY; for details type `license'
Type `help' for basic help
include unix/mmap.fs  ok
---------------------------

Krishna

[toc] | [prev] | [next] | [standalone]

#59824

krishna.myneni@ccreweb.org writes:
>On Thursday, May 25, 2017 at 4:32:04 AM UTC-5, Anton Ertl wrote:
>...
>> That you get the exception indicates a Gforth bug in a code path that
>> I don't exercise (this works for me).  We will look into the bug, but
>> you have some other problem as well, or you would not be exercising
>> this code path.  My guess is that you don't have libltdl installed.
>> Gforth's build works around missing features, but that means that the
>> features are then missing in the resulting Gforth system.
>> 
>
>I checked and found libltdl to be installed on my CentOS 7 system:
>
>$ ls libltdl*
>libltdl.so.7  libltdl.so.7.3.0
>
>I checked the messages from ./configure and the following seem to indicate the problem: some necessary package(s) to support the C library interface appear to be missing.
...
>checking for ltdl.h... no
...
>checking for lt_dlinit in -lltdl... no

libltdl is apparently not there in a way that is found by Gforth's build.

>./configure: line 16026: test: too many arguments
>configure: WARNING: No LIBTOOL found, skip pre-building libcc-based libraries
>configure: WARNING: No LIBTOOL found, skip building library

That also indicates a problem.  Debian-based distros don't install the
real libtool with the libtool-package; you have to install
libtool-bin.  Maybe Red Hat based distros have a similar problem.

- anton
-- 
M. Anton Ertl  http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
     New standard: http://www.forth200x.org/forth200x.html
   EuroForth 2017: http://www.euroforth.org/ef17/

[toc] | [prev] | [next] | [standalone]

#59827

On Thursday, May 25, 2017 at 6:32:16 AM UTC-5, Anton Ertl wrote:
> krishna...org writes:

> >./configure: line 16026: test: too many arguments
> >configure: WARNING: No LIBTOOL found, skip pre-building libcc-based libraries
> >configure: WARNING: No LIBTOOL found, skip building library
> 
> That also indicates a problem.  Debian-based distros don't install the
> real libtool with the libtool-package; you have to install
> libtool-bin.  Maybe Red Hat based distros have a similar problem.
> ...

That's not the same problem on Red Hat-based distros. The libtool executable is part of the libtool package:

$ rpm -q libtool
libtool-2.4.2-22.el7_3.x86_64

The header files are usually in a package named, pkgname-devel, e.g.

$ rpm -q libtool-ltdl-devel
libtool-ltdl-devel-2.4.2-22.el7_3.x86_64

The particular warnings above about No LIBTOOL found were a result of not having the headers installed. The actual libtool executable was present originally, so the warning is misleading.

Krishna

[toc] | [prev] | [next] | [standalone]

#59838

On Monday, May 22, 2017 at 6:00:05 PM UTC-5, krishna...org wrote:
...
> I would like to test parallel-mm.4th on a Forth system like gforth under Linux, but don't know how to do fork and mmap on other systems.


I've now ported parallel-mm.4th to run under the latest development snapshot of gforth (code below). I see only a modest improvement (23%) by forking the process to run the matrix multiplication using two processes in parallel. The run output is shown below, and I'll stress that it's preliminary -- I may not be doing something correctly.

Here are the execution time comparisons with gforth-fast and kforth-fast, on the same system, for multiplying a double-precision floating point 4 x 1000000 matrix with a 1000000 x 1 matrix :

single-process   two-processes   system
--------------------------------------------
    53 ms         41 ms          gforth-fast
   315 ms        179 ms          kforth-fast

As you can see, the two-process calculation runs 1.8x faster than the single-process calc under kforth-fast. However, the gain is 1.3x under gforth-fast. Although I had to change from static to dynamic matrices under the gforth code to avoid overflowing the dictionary space, this should make no difference for the matrix multiplication since only the addresses of the data are passed to the multiplier.

Krishna
---

Output from gforth-fast:
-----------------------------

$ ./gforth-fast parallel-mm.fs

FSL-UTIL          V2.2      19 May      2017 
fsl/fsl-util.fs:413:27: redefined b
fsl/fsl-util.fs:415:41: redefined g
DYNMEM            V1.9d          22 December 2014   EFC 
HORNER            V1.5d          26 February 2012  EFC 
NOISE             V1.0b         06 November  2007   KM 
MMUL               V1.2         21 May  2017 
Initializing the matrices ... 
The matrix A is 4 x 1000000 

Performing singe process calculation. 
Elapsed [ms]: 53 

Performing the parallel processing calculation. 
Allocate shared memory. 
Elapsed [ms]: 41 
Free shared memory region 

Parallel result is equal to single process result. 

To print the results, type 

   NROWS S{ }fprint 
   NROWS P{ }fprint Gforth 0.7.9_20170518, ...
----------------------------

parallel-mm.fs
----------------------------
\ parallel-mm.fs
\
\ Parallel matrix multiplication on a multi-core machine using the
\ syscalls, fork and mmap.
\
\ Krishna Myneni, 2010-04-17
\
\ Multiply an n x m matrix A with a m x 1 vector B to find the n x 1
\ result. Use one process to multiply the even rows of A with B, and
\ use the child process to multiply the odd rows of A with B.
\
\ Notes:
\
\  0) The syscalls, "fork", "mmap", "munmap", and "waitpid" 
\     are implemented in syscalls.4th.
\
\  1) It is assumed that on a multi-core CPU, the child process is
\     forked by the OS to use a different core. On a 4-core machine,
\     we find this to be true under Linux.
\
\  2) The input matrix A{{ and array B{ are not in shared memory
\     since both processes have access to separate copies of their
\     fixed data, and do not write to these. The computed product
\     data must be in a shared region to allow the main process to
\     obtain the child-computed data. For very large matrices, A{{
\     and B{ can be kept in shared memory as well.
\
\ Revisions:
\   2010-04-17  km  use syscall waitpid to wait for child to terminate
\                   before measuring elapsed time; renamed syscalls386.4th
\                   to syscalls.4th so INCLUDE statement changed accordingly.
\   2015-08-01  km  include modules.fs since syscalls.4th is now a module.
\   2017-05-13  km  updated to use shared memory to communicate child
\                   process calculation to parent. Store single process
\                   and parallel process calculations in separate arrays
\                   for comparison. The code is generalized for an 
\                   arbitrary number of rows for matrix A{{ .
\   2017-05-22  km  updated to use the generic matrix multiplication 
\                   module fsl/extras/mmul.4th; execution speed improved
\                   from previous version by a factor of 5 with 
\                   kforth-fast.
\   2017-05-25  km  ported to current development snapshot of gforth
\                   (0.7.9_20170518). The file unix/libc.fs was modified
\                   to include a declaration of the syscall, waitpid :
\
\      c-function waitpid waitpid n a n -- n ( pid addr options -- ret )
\
\                   changed to dynamic matrix and array to avoid 
\                   overflowing the dictionary.

include modules.fs
include unix/mmap.fs
include fsl/fsl-util.fs
include fsl/dynmem.fs
include fsl/horner.fs
include fsl/extras/noise.fs
include fsl/extras/mmul.fs

: fork fork() ;

variable cpid        \ child process id
variable status
variable shared_mem  \ address of shared memory buffer used by
                     \   both child and parent.

1000000 constant NCOLS
4       constant NROWS

NROWS DFLOATS constant SHARED_LEN  \ length of shared memory region

FLOAT DMATRIX A{{
FLOAT DARRAY  B{
& A{{ NROWS NCOLS }}malloc  malloc-fail?
& B{ NCOLS }malloc          malloc-fail? or
[IF]
  cr .( Unable to allocate matrix and/or array memory. )
  ABORT
[THEN]

NROWS FLOAT ARRAY S{          \ result from single process
NROWS FLOAT ARRAY P{          \ result from parallel processes

\ Allocate u bytes of shared memory for parallel processes
\ to write their outputs. Return shared memory address or
\ -1 if allocation fails.
: allocate-shared ( u -- addr )
   0                         \ address picked by kernel 
   swap                      \ length of region to map
   PROT_READ PROT_WRITE or   \ able to read and write 
   MAP_SHARED MAP_ANONYMOUS or   \ shared memory, no file used
   -1                            \ fd
   0                             \ offset
   mmap ;

\ Return -1 if free-shared fails.
: free-shared ( addr u -- n )  munmap ;

: init-matrices ( -- )
	NCOLS 0 DO  NROWS 0 DO  ran0 A{{ I J }} F!  LOOP  LOOP
	NCOLS 0 DO  ran0  B{ I } F!  LOOP ;

\ Use a single process to perform the multiplication
: single-process ( -- )
     \ a1 a2 a3 nr1 nc1 nc2
     A{{ 0 0 }} B{ 0 } S{ 0 } NROWS NCOLS 1 df_mmul
;

2 DFLOATS constant DFL2

: parallel-process ( -- )
     A{{ 0 0 }} B{ 0 } shared_mem @ NROWS NCOLS 1 set_mmul_params
     \ ashared nr1
     fork  dup cpid !
     0< ABORT" Unable to fork!"  
     cpid @ 0= IF
	\ child  handles multiplication of odd rows of A{{
        swap dfloat+ swap
        1 ?DO
          I 0 df_mul_r1c2 dup f!
          DFL2 + 
	2 +LOOP
        drop
        bye    
     ELSE
 	\ parent handles multiplication of even rows of A{{ 
        0 ?DO
	  I 0 df_mul_r1c2 dup f!
          DFL2 +
        2 +LOOP
        drop
     THEN
;

\ Setup matrices, run the single process calculation,
\ then the parallel calculation, storing the results in
\ arrays S{ and P{ , respectively. Measure and report the
\ execution times for both calculations 
cr .( Initializing the matrices ... )
init-matrices
cr .( The matrix A is ) NROWS . .( x ) NCOLS . 

cr cr .( Performing singe process calculation. )
utime single-process utime 2swap d- d>s 1000 / 
cr .( Elapsed [ms]: ) .

cr cr .( Performing the parallel processing calculation. )
cr .( Allocate shared memory. )
SHARED_LEN allocate-shared
dup shared_mem !
-1 = [IF]
  cr .( Unable to allocate shared memory! )
  quit
[THEN]

utime 
parallel-process
\ parent has finished; now, wait for the child to terminate
cpid @ status 0 waitpid cpid @ <> 
[IF] 
cr .( Child process did not terminate properly! )
[ELSE]
\ Transfer shared memory to array P{
shared_mem @ P{ 0 } NROWS floats move  
utime 2swap d- d>s 1000 / 
cr .( Elapsed [ms]: ) . 
[THEN]

& A{{ }}free  malloc-fail?
& B{ }free    malloc-fail? or
[IF]
  cr .( Error freeing matrix or array memory. )
[THEN]

cr .( Free shared memory region ) cr
shared_mem @ SHARED_LEN free-shared
-1 = [IF]
   .( Error freeing shared memory! ) cr
[THEN]

\ Compare parallel and serial results
P{ 0 } S{ 0 } NROWS floats tuck compare
cr .( Parallel result is ) [IF] .( NOT ) [THEN]
.( equal to single process result. ) cr

cr .( To print the results, type ) cr
cr .(    NROWS S{ }fprint )
cr .(    NROWS P{ }fprint )

[toc] | [prev] | [next] | [standalone]

#59839

On Thursday, May 25, 2017 at 6:54:38 PM UTC-5, krishna...org wrote:
> On Monday, May 22, 2017 at 6:00:05 PM UTC-5, krishna...org wrote:
> ...
> I've now ported parallel-mm.4th to run under the latest development snapshot of gforth (code below). ...
> Here are the execution time comparisons with gforth-fast and kforth-fast, on the same system, for multiplying a double-precision floating point 4 x 1000000 matrix with a 1000000 x 1 matrix :
> 
> single-process   two-processes   system
> --------------------------------------------
>     53 ms         41 ms          gforth-fast
>    315 ms        179 ms          kforth-fast
>

Changing the code to multiply two 500 x 500 matrices shows a definite speedup with the parallel mode in gforth-fast!

single-process   two-processes   system
--------------------------------------------
   2659 ms         1184 ms       gforth-fast
  11353 ms         5602 ms       kforth-fast


Now, the speedup factor in both gforth-fast and kforth-fast is actually greater than 2x for parallel process computation vs single process. How do we explain the difference between these two cases:

1) 4x1000000 multiplied by 1000000x1 vs.
2) 500x500   multiplied by 500x500

kforth-fast shows a more consistent speedup factor for both cases. But, it's clear that we can get a factor of 2x speedup in gforth-fast as well. The code for case 2) is given below.

Krishna
---

Output from gforth-fast:
-----------------------------
$ ./gforth-fast parallel-mm2.fs

FSL-UTIL          V2.2      19 May      2017 
fsl/fsl-util.fs:413:27: redefined b
fsl/fsl-util.fs:415:41: redefined g
DYNMEM            V1.9d          22 December 2014   EFC 
HORNER            V1.5d          26 February 2012  EFC 
NOISE             V1.0b         06 November  2007   KM 
MMUL               V1.2         21 May  2017 
Initializing the matrices ... 
The matrix A is 500 x 500 
The matrix B is 500 x 500 

Performing single process calculation. 
Elapsed [ms]: 2659 

Performing the parallel processing calculation. 
Allocate shared memory. 
Elapsed [ms]: 1184 
Free shared memory region 

Parallel result is equal to single process result. 
------------------------------

parallel-mm2.fs
------------------------------
\ parallel-mm2.fs
\
\ Parallel matrix multiplication on a multi-core machine using the
\ syscalls, fork and mmap.
\
\ Krishna Myneni, 2010-04-17
\
\ Multiply a n x n matrix A with a n x n matrix B to find the n x n
\ result. Use one process to multiply the even rows of A with B, and
\ use the child process to multiply the odd rows of A with B.
\
\ Notes:
\  ... ( needs editing )

include modules.fs
include unix/mmap.fs
include fsl/fsl-util.fs
include fsl/dynmem.fs
include fsl/horner.fs
include fsl/extras/noise.fs
include fsl/extras/mmul.fs

: fork fork() ;

variable cpid        \ child process id
variable status
variable shared_mem  \ address of shared memory buffer used by
                     \   both child and parent.

500 constant NCOLS
500 constant NROWS

NROWS NCOLS * DFLOATS constant SHARED_LEN  \ length of shared memory region

FLOAT DMATRIX A{{
FLOAT DMATRIX B{{
FLOAT DMATRIX S{{    \ result from single process
FLOAT DMATRIX P{{    \ result from parallel processes
& A{{ NROWS NCOLS }}malloc  malloc-fail?
& B{{ NROWS NCOLS }}malloc  malloc-fail? or
& S{{ NROWS NCOLS }}malloc  malloc-fail? or
& P{{ NROWS NCOLS }}malloc  malloc-fail? or
[IF]
  cr .( Unable to allocate matrix and/or array memory. )
  ABORT
[THEN]

\ Allocate u bytes of shared memory for parallel processes
\ to write their outputs. Return shared memory address or
\ -1 if allocation fails.
: allocate-shared ( u -- addr )
   0                         \ address picked by kernel 
   swap                      \ length of region to map
   PROT_READ PROT_WRITE or   \ able to read and write 
   MAP_SHARED MAP_ANONYMOUS or   \ shared memory, no file used
   -1                            \ fd
   0                             \ offset
   mmap ;

\ Return -1 if free-shared fails.
: free-shared ( addr u -- n )  munmap ;

: init-matrices ( -- )
	A{{ 0 0 }} NCOLS NROWS * 0 DO  ran0 dup F!  dfloat+ LOOP drop
	B{{ 0 0 }} NCOLS NROWS * 0 DO  ran0 dup F!  dfloat+ LOOP drop ;

\ Use a single process to perform the multiplication
: single-process ( -- )
     \ a1 a2 a3 nr1 nc1 nc2
     A{{ 0 0 }} B{{ 0 0 }} S{{ 0 0 }} NROWS NCOLS NCOLS df_mmul
;

NCOLS dfloats constant ROFFS

: parallel-process ( -- )
     A{{ 0 0 }} B{{ 0 0 }} shared_mem @ NROWS NCOLS NCOLS set_mmul_params
     \ ashared nr1
     fork  dup cpid !
     0< ABORT" Unable to fork!"  
     cpid @ 0= IF
	\ child  handles multiplication of odd rows of A{{
        swap ROFFS + swap
        1 ?DO
          NCOLS 0 DO
            J I df_mul_r1c2 dup f!
            dfloat+
          LOOP
          ROFFS + 
	2 +LOOP
        drop
        bye    
     ELSE
 	\ parent handles multiplication of even rows of A{{ 
        0 ?DO
          NCOLS 0 DO
	    J I df_mul_r1c2 dup f!
            dfloat+
          LOOP
          ROFFS +
        2 +LOOP
        drop
     THEN
;

\ Setup matrices, run the single process calculation,
\ then the parallel calculation, storing the results in
\ arrays S{ and P{ , respectively. Measure and report the
\ execution times for both calculations 
cr .( Initializing the matrices ... )
init-matrices
cr .( The matrix A is ) NROWS . .( x ) NCOLS . 
cr .( The matrix B is ) NROWS . .( x ) NCOLS .
cr cr .( Performing single process calculation. )
utime single-process utime 2swap d- d>s 1000 / 
cr .( Elapsed [ms]: ) .

cr cr .( Performing the parallel processing calculation. )
cr .( Allocate shared memory. )
SHARED_LEN allocate-shared
dup shared_mem !
-1 = [IF]
  cr .( Unable to allocate shared memory! )
  quit
[THEN]

utime 
parallel-process
\ parent has finished; now, wait for the child to terminate
cpid @ status 0 waitpid cpid @ <> 
[IF] 
cr .( Child process did not terminate properly! )
[ELSE]
\ Transfer shared memory to array P{
shared_mem @ P{{ 0 0 }} SHARED_LEN move  
utime 2swap d- d>s 1000 / 
cr .( Elapsed [ms]: ) . 
[THEN]

cr .( Free shared memory region ) cr
shared_mem @ SHARED_LEN free-shared
-1 = [IF]
   .( Error freeing shared memory! ) cr
[THEN]

\ Compare parallel and serial results
P{{ 0 0 }} S{{ 0 0 }} NROWS NCOLS * dfloats tuck compare
cr .( Parallel result is ) [IF] .( NOT ) [THEN]
.( equal to single process result. ) cr

& A{{ }}free  malloc-fail?
& B{{ }}free  malloc-fail? or
& S{{ }}free  malloc-fail? or
& P{{ }}free  malloc-fail? or
[IF]
  cr .( Error freeing matrix or array memory. )
[THEN]

[toc] | [prev] | [next] | [standalone]

#59840

On Thursday, May 25, 2017 at 9:19:24 PM UTC-5, krishna...org wrote:
> On Thursday, May 25, 2017 at 6:54:38 PM UTC-5, krishna...org wrote:
> > On Monday, May 22, 2017 at 6:00:05 PM UTC-5, krishna...org wrote:
> > ...
> > I've now ported parallel-mm.4th to run under the latest development snapshot of gforth (code below). ...
> > Here are the execution time comparisons with gforth-fast and kforth-fast, on the same system, for multiplying a double-precision floating point 4 x 1000000 matrix with a 1000000 x 1 matrix :
> > 
> > single-process   two-processes   system
> > --------------------------------------------
> >     53 ms         41 ms          gforth-fast
> >    315 ms        179 ms          kforth-fast
> >
> 
> Changing the code to multiply two 500 x 500 matrices shows a definite speedup with the parallel mode in gforth-fast!
> 
> single-process   two-processes   system
> --------------------------------------------
>    2659 ms         1184 ms       gforth-fast
>   11353 ms         5602 ms       kforth-fast
> 
> 
> Now, the speedup factor in both gforth-fast and kforth-fast is actually greater than 2x for parallel process computation vs single process. How do we explain the difference between these two cases:
> 
> 1) 4x1000000 multiplied by 1000000x1 vs.
> 2) 500x500   multiplied by 500x500
> 
> kforth-fast shows a more consistent speedup factor for both cases. But, it's clear that we can get a factor of 2x speedup in gforth-fast as well. The code for case 2) is given below.
> ...

The gforth code for case 1) and case 2) are found at the following links:

ftp://ccreweb.org/software/gforth/parallel-mm.fs
ftp://ccreweb.org/software/gforth/parallel-mm2.fs

All of the supporting files may be found in 

ftp://ccreweb.org/software/gforth/

and its subfolders.

Please note that the latest development snapshot of gforth requires the addition of the waitpid syscall, which may be added to unix/libc.fs.

Krishna

[toc] | [prev] | [next] | [standalone]

#59845

On 26/05/17 04:34, krishna.myneni@ccreweb.org wrote:
> On Thursday, May 25, 2017 at 9:19:24 PM UTC-5, krishna...org wrote:
>> On Thursday, May 25, 2017 at 6:54:38 PM UTC-5, krishna...org 
>> wrote:
>>> On Monday, May 22, 2017 at 6:00:05 PM UTC-5, krishna...org wrote:
>>> ... I've now ported parallel-mm.4th to run under the latest
>>> development snapshot of gforth (code below). ... Here are the
>>> execution time comparisons with gforth-fast and kforth-fast, on
>>> the same system, for multiplying a double-precision floating 
>>> point 4 x 1000000 matrix with a 1000000 x 1 matrix :
>>> 
>>> single-process   two-processes   system 
>>> -------------------------------------------- 53 ms         41 ms 
>>> gforth-fast 315 ms        179 ms          kforth-fast
>>> 
>> 
>> Changing the code to multiply two 500 x 500 matrices shows a 
>> definite speedup with the parallel mode in gforth-fast!
>> 
>> single-process   two-processes   system 
>> -------------------------------------------- 2659 ms         1184 
>> ms       gforth-fast 11353 ms         5602 ms       kforth-fast
>> 
>> 
>> Now, the speedup factor in both gforth-fast and kforth-fast is 
>> actually greater than 2x for parallel process computation vs
>> single process. How do we explain the difference between these two
>> cases:
>> 
>> 1) 4x1000000 multiplied by 1000000x1 vs. 2) 500x500   multiplied
>> by 500x500
>> 
>> kforth-fast shows a more consistent speedup factor for both cases. 
>> But, it's clear that we can get a factor of 2x speedup in 
>> gforth-fast as well. The code for case 2) is given below. ...
> 
> The gforth code for case 1) and case 2) are found at the following 
> links:
> 
> ftp://ccreweb.org/software/gforth/parallel-mm.fs 
> ftp://ccreweb.org/software/gforth/parallel-mm2.fs
> 
> All of the supporting files may be found in
> 
> ftp://ccreweb.org/software/gforth/
> 
> and its subfolders.
> 
> Please note that the latest development snapshot of gforth requires 
> the addition of the waitpid syscall, which may be added to 
> unix/libc.fs.

Krishna,

Thank you very much for showing this (and the effort for doing this).
I've been following this thread with a kind of interest. Especially
the usage of the fork and mmap syscalls to obtain parallelism.
Doesn't seem to bad :-)

Actually it's much much better than I expected. My first encounter
with fork() was in Atari MultiTos (early 90s) and it was dog slow
and I have ignored it ever since, till now that is.

iForth, VFX-OSX and SwiftForth-OSX also have the abilities to run
things in parallel. Though the implementations are different from
yours. They fork in to threads/tasks on separate cores, using a
dedicated threadpool (iForth) and Grand Central Dispatch (macOS).
Like multitasking with USER variables etc. but parallel on separate
cores.

I have not looked at your code leave alone tried to port it to iForth64
using both the fork, mmap syscalls  and its PAR ENDPAR feature for
measurements (no time, sorry). Would it make much differences with
situations where OS housekeeping is dwarfed compared with the actual
computation? Could be a good alternative.

Very useful this fork() heads up.

-r

[toc] | [prev] | [next] | [standalone]

#59854

On Friday, May 26, 2017 at 4:03:17 AM UTC-5, Roelf Toxopeus wrote:
> On 26/05/17 04:34, krishna...org wrote:
> > On Thursday, May 25, 2017 at 9:19:24 PM UTC-5, krishna...org wrote:
> >> On Thursday, May 25, 2017 at 6:54:38 PM UTC-5, krishna...org 
> >> wrote:
> >>> On Monday, May 22, 2017 at 6:00:05 PM UTC-5, krishna...org wrote:
> >>> ... I've now ported parallel-mm.4th to run under the latest
> >>> development snapshot of gforth (code below). ... Here are the
> >>> execution time comparisons with gforth-fast and kforth-fast, on
> >>> the same system, for multiplying a double-precision floating 
> >>> point 4 x 1000000 matrix with a 1000000 x 1 matrix :
> >>> 
> >>> single-process   two-processes   system 
> >>> -------------------------------------------- 53 ms         41 ms 
> >>> gforth-fast 315 ms        179 ms          kforth-fast
> >>> 
> >> 
> >> Changing the code to multiply two 500 x 500 matrices shows a 
> >> definite speedup with the parallel mode in gforth-fast!
> >> 
> >> single-process   two-processes   system 
> >> -------------------------------------------- 2659 ms         1184 
> >> ms       gforth-fast 11353 ms         5602 ms       kforth-fast
> >> 
> >> 
> >> Now, the speedup factor in both gforth-fast and kforth-fast is 
> >> actually greater than 2x for parallel process computation vs
> >> single process. How do we explain the difference between these two
> >> cases:
> >> 
> >> 1) 4x1000000 multiplied by 1000000x1 vs. 2) 500x500   multiplied
> >> by 500x500
> >> 
> >> kforth-fast shows a more consistent speedup factor for both cases. 
> >> But, it's clear that we can get a factor of 2x speedup in 
> >> gforth-fast as well. The code for case 2) is given below. ...
> > 
> > The gforth code for case 1) and case 2) are found at the following 
> > links:
> > 
> > ftp://ccreweb.org/software/gforth/parallel-mm.fs 
> > ftp://ccreweb.org/software/gforth/parallel-mm2.fs
> > 
> > All of the supporting files may be found in
> > 
> > ftp://ccreweb.org/software/gforth/
> > 
> > and its subfolders.
> > 
> > Please note that the latest development snapshot of gforth requires 
> > the addition of the waitpid syscall, which may be added to 
> > unix/libc.fs.
> 
> Krishna,
> 
> Thank you very much for showing this (and the effort for doing this).
> I've been following this thread with a kind of interest. Especially
> the usage of the fork and mmap syscalls to obtain parallelism.
> Doesn't seem to bad :-)
> 
> Actually it's much much better than I expected. My first encounter
> with fork() was in Atari MultiTos (early 90s) and it was dog slow
> and I have ignored it ever since, till now that is.
> 
> iForth, VFX-OSX and SwiftForth-OSX also have the abilities to run
> things in parallel. Though the implementations are different from
> yours. They fork in to threads/tasks on separate cores, using a
> dedicated threadpool (iForth) and Grand Central Dispatch (macOS).
> Like multitasking with USER variables etc. but parallel on separate
> cores.
> 
> I have not looked at your code leave alone tried to port it to iForth64
> using both the fork, mmap syscalls  and its PAR ENDPAR feature for
> measurements (no time, sorry). Would it make much differences with
> situations where OS housekeeping is dwarfed compared with the actual
> computation? Could be a good alternative.
> 
> Very useful this fork() heads up.
> 
> -r

Hi Roelf,

Thank you for the encouragement and discussion. I am particularly encouraged by the results because I have other computation problems which can benefit from this approach. However, as a first step, the results I presented should be reproduced by others, and the code checked for any obvious or subtle blunders. Given that we get past this step, then there are several questions which should be examined:

1) What causes the discrepancy in two-process vs one-process speedup for the two different matrix multiplications cases presented here, which is more pronounced in gforth? Is it simply the overhead involved in forking the process compared to the problem computation time?

2) How are we able to get a speedup greater than 2x, e.g. for the case of gforth-fast, our results show a speedup of 2.2x? Is this reproducible on other systems?

3) How well does forking scale in problem computation time, for this problem and for other specific problems, to a larger number of processes, n? Does OS overhead provide diminishing returns as n goes to 8, or even to 16?

4) How does this method compare in programming complexity and in computation speedup with respect to using multiple threads? Clearly, I would think that forking involves more system resources, primarily memory. Are threads a better way to achieve the same thing, considering use of system resources, speedup, and programming complexity? I would like to see the matrix multiplication example(s) given here, recoded for execution under a multi-threaded Forth system, for comparison.

In general, the Forth community (or maybe just me) needs to be more cognizant of using parallel techniques. It's not uncommon to see systems with 8 cores now, and using single process/thread methods seems archaic, like using an ox cart when one has a sports car, unless the computing problem cannot be parallelized. I'm not even utilizing my 10-year old home PC system anywhere near its capability when I run my own code.

Krishna

[toc] | [prev] | [next] | [standalone]

#59873

krishna.myneni@ccreweb.org writes:
>1) What causes the discrepancy in two-process vs one-process speedup for th=
>e two different matrix multiplications cases presented here, which is more =
>pronounced in gforth? Is it simply the overhead involved in forking the pro=
>cess compared to the problem computation time?
>
>2) How are we able to get a speedup greater than 2x, e.g. for the case of g=
>forth-fast, our results show a speedup of 2.2x? Is this reproducible on oth=
>er systems?

Resource (e.g., bandwidth) limitations as well as synchronization
overhead can be responsible for sub-linear speedups.  Dividing the
work in a way that fits in the cache can be responsible for
super-linear speedups (that's basically the cache-blocking effect).  I
have no idea what is the case for your benchmarks, though.

>3) How well does forking scale in problem computation time, for this proble=
>m and for other specific problems, to a larger number of processes, n? Does=
> OS overhead provide diminishing returns as n goes to 8, or even to 16?

Matrix multiplication can be divided very well into lots of parallel
computations.  For a 500x500 matrix multiply, each of the 250k
elements of the result matrix can be computed independently of the
others, and that computation consists of 1000 loads, all of which can
be performed in parallel, 500 multiplies, all of which can be
performed in parallel, and 499 adds, which can be organized as an
11-deep tree.  So if you have unlimited hardware, you can do the 250M
loads (with, say, 50 cycles latency), 125M multiplies (4 cycles
latency), and 124.5M adds (4 cycles latency) in 50+4+11*4=98cycles
total.  Well, not quite: with that many functional units, you probably
have to add quite a number of cycles for getting data from one
functional unit to the next.

Matrix multiplication is used as a benchmark for supercomputers,
because it is very parallelization, but OTOH, has quite a bit of
communication requirements (unlike, e.g., computing the Mandelbrot
set), and is something that supercomputers do a lot in real
applications.

>4) How does this method compare in programming complexity and in computatio=
>n speedup with respect to using multiple threads? Clearly, I would think th=
>at forking involves more system resources, primarily memory. Are threads a =
>better way to achieve the same thing, considering use of system resources, =
>speedup, and programming complexity? I would like to see the matrix multipl=
>ication example(s) given here, recoded for execution under a multi-threaded=
> Forth system, for comparison.

Probably not that much difference on all counts.

>In general, the Forth community (or maybe just me) needs to be more cogniza=
>nt of using parallel techniques. It's not uncommon to see systems with 8 co=
>res now, and using single process/thread methods seems archaic, like using =
>an ox cart when one has a sports car, unless the computing problem cannot b=
>e parallelized. I'm not even utilizing my 10-year old home PC system anywhe=
>re near its capability when I run my own code.

Many people are too euphoric about using multi-threading (or other
kinds of shared-memory or distributed-memory multiprocessing
parallelization) for getting speedups.  You get additional kinds of
bugs (race conditions, deadlocks), execution is not perfectly
reproducible, which makes debugging harder, and as result, you get
only a speedup by a small factory, and you consume at least as much
CPU time as before.  It's better to first apply techniques for
speeding up single threads; in the present case you can use
vectorization and cache blocking to get quite a bit more.  Once you
are close to the limit of single-thread performance, one can consider
multiprocessing.

- anton
-- 
M. Anton Ertl  http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
     New standard: http://www.forth200x.org/forth200x.html
   EuroForth 2017: http://www.euroforth.org/ef17/

[toc] | [prev] | [next] | [standalone]

#59887

On Friday, May 26, 2017 at 10:53:22 AM UTC-5, Anton Ertl wrote:
...
> Many people are too euphoric about using multi-threading (or other
> kinds of shared-memory or distributed-memory multiprocessing
> parallelization) for getting speedups.  You get additional kinds of
> bugs (race conditions, deadlocks), execution is not perfectly
> reproducible, which makes debugging harder, and as result, you get
> only a speedup by a small factory, and you consume at least as much
> CPU time as before.  It's better to first apply techniques for
> speeding up single threads; in the present case you can use
> vectorization and cache blocking to get quite a bit more.  Once you
> are close to the limit of single-thread performance, one can consider
> multiprocessing.
> 

Somewhat naively, I would think that the two activities commute: 1) writing the code for parallel (multi-process/multi-thread) computation, and 2) writing the code for high efficiency in a single process. Your argument about the preferred order is that a greater gain will be realized in a shorter time by doing 2) first, and that will be true for some tasks such as the example here. But, I can think of examples where you might want to start with the multi-processing approach first, e.g. a data acquisition application consisting of one part which continuously takes data at a high-rate and a second part which displays the data in a graphics window at periodic intervals. The first part (acquiring the data) needs to operate with very low latency, maybe on the microsecond time scale, while the display part needs to operate on a different time scale of visual refresh rates. Such an application would seem ideal for coding with parallel computing from the outset.

Krishna

[toc] | [prev] | [next] | [standalone]

#59902

Hi,
When there is no limit set MultiTaskingClass.f is able to fork a word automatic till all hardware threads are used.  The forked word must only be able to use an index.
And yes you might run into all kinds of troubles. 
But as is demonstrated in Julia443 problems can be solved.  
MultiTaskingClass.f and Julia443 can be downloaded from: https://sites.google.com/site/win324th/sources

Jos

On 27 mei 2017 02:13:53 UTC+2 krishna...@ccreweb.org wrote :
> On Friday, May 26, 2017 at 10:53:22 AM UTC-5, Anton Ertl wrote:
> ...
> > Many people are too euphoric about using multi-threading (or other
> > kinds of shared-memory or distributed-memory multiprocessing
> > parallelization) for getting speedups.  You get additional kinds of
> > bugs (race conditions, deadlocks), execution is not perfectly
> > reproducible, which makes debugging harder, and as result, you get
> > only a speedup by a small factory, and you consume at least as much
> > CPU time as before.  It's better to first apply techniques for
> > speeding up single threads; in the present case you can use
> > vectorization and cache blocking to get quite a bit more.  Once you
> > are close to the limit of single-thread performance, one can consider
> > multiprocessing.
> > 
> 
> Somewhat naively, I would think that the two activities commute: 1) writing the code for parallel (multi-process/multi-thread) computation, and 2) writing the code for high efficiency in a single process. Your argument about the preferred order is that a greater gain will be realized in a shorter time by doing 2) first, and that will be true for some tasks such as the example here. But, I can think of examples where you might want to start with the multi-processing approach first, e.g. a data acquisition application consisting of one part which continuously takes data at a high-rate and a second part which displays the data in a graphics window at periodic intervals. The first part (acquiring the data) needs to operate with very low latency, maybe on the microsecond time scale, while the display part needs to operate on a different time scale of visual refresh rates. Such an application would seem ideal for coding with parallel computing from the outset.
> 
> Krishna

[toc] | [prev] | [next] | [standalone]

#59917

On Saturday, May 27, 2017 at 1:26:42 AM UTC-5, jo...@planet.nl wrote:
> Hi,
> When there is no limit set MultiTaskingClass.f is able to fork a word automatic till all hardware threads are used.  The forked word must only be able to use an index.
> And yes you might run into all kinds of troubles. 
> But as is demonstrated in Julia443 problems can be solved.  
> MultiTaskingClass.f and Julia443 can be downloaded from: https://sites.google.com/site/win324th/sources
> ...

Nice example. I haven't looked at the source yet. Are you able to set up inter-thread communication if it is needed?

Krishna

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.lang.forth

csiph-web