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 2 of 2 — ← Prev page 1 [2]

#59924

Hi,

> Are you able to set up inter-thread communication if it is needed?

The threads are organized in a clusters (objects).
The system is able to know when all the threads are ready in one cluster to avoid nesting or continuation while the threads are still running.
Each thread in the same process can use all of the memory of other threads.
A thread can use it’s index to read or write data to or from an array.
In Julia443 the memory of a DibSection is used as an array to write the fractal in a parallel way. 

Memory can be protected by a semaphore when needed.

At the end of the source of MultiTaskingClass.f there are various examples which can be activated.

Jos

On 27 mei 2017 15:20:13 UTC+2 krishna...@ccreweb.org wrote:
> On Saturday, May 27, 2017 at 1:26:42 AM UTC-5, jo...anet.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]

#59903

krishna.myneni@ccreweb.org writes:
>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.
>>=20
>
>Somewhat naively, I would think that the two activities commute: 1) writing=
> the code for parallel (multi-process/multi-thread) computation, and 2) wri=
>ting 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 ti=
>me by doing 2) first

Yes, that is my point.  Of course, when optimizing the single-threaded
program, the more you optimize, the lower the gains of the next step,
and at some point, using multiple cores will be more cost-effective.
But I often see people thinking about using multiple cores long before
that point is reached.

>But, I can think of examples where you might want to start with t=
>he multi-processing approach first, e.g. a data acquisition application con=
>sisting of one part which continuously takes data at a high-rate and a seco=
>nd 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 oper=
>ate on a different time scale of visual refresh rates. Such an application =
>would seem ideal for coding with parallel computing from the outset.

Sure, here you have requirements that make multi-tasking a natural
fit.  I.e., you would go for it even if you don't have multiple cores.
That's the difference between "parallel computing" and "concurrent
computing".

- 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]

#59918

On Saturday, May 27, 2017 at 1:30:51 AM UTC-5, Anton Ertl wrote:
...
> That's the difference between "parallel computing" and "concurrent
> computing".
> ...

Parallel vs concurrent is an appropriate distinction for this second example. Again, the system calls, fork, and mmap are useful in this case as well. My original focus was on parallel computing, but the approach is useful for both parallel and concurrent computing.

This brings me to another point: by the word, "fork", in this discussion, we may not be referring to the same system function. It appears that multi-threaded Forth systems may be using "fork" with a different meaning than the Posix system call. The latter's man page says,

fork() creates a new process by duplicating the calling process.  The new process, referred to as the child, is an exact duplicate of  the  calling process, referred to as the parent, except for the following points: ...

This is what I mean by the word, "fork", with regard to the examples I presented here. I was confused when I saw that the word "fork()" was defined in gforth's unix/libc.fs, instead of just "fork". Now, I see that it may have been done to avoid a conflict in naming with multi-threaded Forth systems, in which "fork" means something different, i.e. does not duplicate the calling process. We need to avoid confusion here when referring to which "fork" we mean, if there is a conflict.

Krishna

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

#59899

Anton Ertl <anton@mips.complang.tuwien.ac.at> 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 factor, 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.

I'm not sure that's totally correct: for example, work-stealing
fork/join is fairly easy for programmers to reason about and can
produce a speedup without heroic efforts.  Hand optimization can
produce code which is harder to parallelize than something more
straightforward, so perhaps it makes sense to alternate
serial/parallel optimizations.  It's true, though, that
parallelization very rarely produces a speedup proportional to the
number of cores.

Andrew.

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

#59905

> parallelization very rarely produces a speedup proportional to the
> number of cores.

To draw a full screen julia fractal takes 403 ms when one thread is used.
When 8 threads are used it takes only 63 ms.
Indeed only a 6* speedup.
Still not bad I think. 

Jos


On 27 mei 2017 08:17:24 UTC+2 Andrew Haley wrote:
> Anton Ertl <anton....ac.at> 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 factor, 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.
> 
> I'm not sure that's totally correct: for example, work-stealing
> fork/join is fairly easy for programmers to reason about and can
> produce a speedup without heroic efforts.  Hand optimization can
> produce code which is harder to parallelize than something more
> straightforward, so perhaps it makes sense to alternate
> serial/parallel optimizations.  It's true, though, that
> parallelization very rarely produces a speedup proportional to the
> number of cores.
> 
> Andrew.

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

#59907

josv@planet.nl wrote:
>> parallelization very rarely produces a speedup proportional to the
>> number of cores.
> 
> To draw a full screen julia fractal takes 403 ms when one thread is used.
> When 8 threads are used it takes only 63 ms.
> Indeed only a 6* speedup.
> Still not bad I think. 

Indeed not: fractals tend to be embarrassingly parallel.  :-)

[For those who haven't seen this before, that really is a term of art:
see https://en.wikipedia.org/wiki/Embarrassingly_parallel]

Andrew.

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

#59968

On Saturday, May 27, 2017 at 8:49:09 AM UTC+2, Andrew Haley wrote:
> josv@planet.nl wrote:
> >> parallelization very rarely produces a speedup proportional to the
> >> number of cores.
> > 
> > To draw a full screen julia fractal takes 403 ms when one thread is used.
> > When 8 threads are used it takes only 63 ms.
> > Indeed only a 6* speedup.
> > Still not bad I think. 
> 
> Indeed not: fractals tend to be embarrassingly parallel.  :-)
> 
> [For those who haven't seen this before, that really is a term of art:
> see https://en.wikipedia.org/wiki/Embarrassingly_parallel]
> 
> Andrew.

With fractals, the speedup is so large that plotting the pixels
is the bottleneck. In this demo a homegrown framebuffer is used
as the OS's pixel or lineops would be too slow (At least they 
were on my 2003 graphics card).

The *FB* words manipulate the framebuffer, the PAR ENDPAR
STARTP ENDP and TH-PART parallelize (stripping the displayed area).

Parallelizing in this way is easier than inventing an SSE wordset.

-marcel

---
(*
 * LANGUAGE    : ANS Forth
 * PROJECT     : Forth Environments
 * DESCRIPTION : Julia fractal of exp(z)-z-1
 * CATEGORY    : Graphic example
 * AUTHOR      : Marcel Hendrix 
 * LAST CHANGE : Tuesday, December 30, 2003 4:56 PM, Marcel Hendrix 
 *)



        NEEDS -miscutil
	NEEDS -graphics
	NEEDS -threads
	NEEDS -framebuffer

        REVISION -julexp "--- Julia exp(z)-z-1    Version 1.00 ---"

	PRIVATES


DOC
(*
 Julia fractal of exp(z)-z-1
*)
ENDDOC

-- Parameters 
 4e       FVALUE delH
 5e 	  FVALUE delV
   9       VALUE amp

: COLORIZE ( x y ix -- ) amp 0 >PALETTECOLOR2 SET-FBDOT ;

: INNERLOOP ( x y -- ) 
		DLOCAL @xy 
		@xy UNSCALE? DROP FLOCALS| yy xx |
		0e 0e FLOCALS| x1 y1 |
		#40  1 DO  xx 6e 
			    F> IF  @xy I COLORIZE  LEAVE  ENDIF
			   xx FEXP yy FCOS F*  xx F- F1- TO x1
			   xx FEXP yy FSIN F*  yy F-     TO y1
			   xx x1 F- FSQR ( yy y1 F- FSQR F+ ) 1e-6 
			    F< IF  @xy I COLORIZE  LEAVE  ENDIF
			   x1 TO xx  y1 TO yy
		     LOOP ; PRIVATE

: COMPUTE	TEXTMODE? $FF AND DUP >R IF GRAPHICS ENDIF  
		0 0 Xmax Ymax  
		delH FNEGATE  delV FNEGATE delH delV SET-GWINDOW 
\		#40 RANDOMPALETTE
		#256 SHADEPALETTE
		RESET-FBDOTS+
		PAR
		  STARTP  Xmax 0 TH-PART ?DO  Ymax 0 ?DO  J I INNERLOOP  LOOP  LOOP  ENDP
		  STARTP  Xmax 1 TH-PART ?DO  Ymax 0 ?DO  J I INNERLOOP  LOOP  LOOP  ENDP
		  STARTP  Xmax 2 TH-PART ?DO  Ymax 0 ?DO  J I INNERLOOP  LOOP  LOOP  ENDP
		  STARTP  Xmax 3 TH-PART ?DO  Ymax 0 ?DO  J I INNERLOOP  LOOP  LOOP  ENDP
		  STARTP  Xmax 4 TH-PART ?DO  Ymax 0 ?DO  J I INNERLOOP  LOOP  LOOP  ENDP
		  STARTP  Xmax 5 TH-PART ?DO  Ymax 0 ?DO  J I INNERLOOP  LOOP  LOOP  ENDP
		  STARTP  Xmax 6 TH-PART ?DO  Ymax 0 ?DO  J I INNERLOOP  LOOP  LOOP  ENDP
		  STARTP  Xmax 7 TH-PART ?DO  Ymax 0 ?DO  J I INNERLOOP  LOOP  LOOP  ENDP
		ENDPAR
		FLUSH-FBDOTS
		R> IF  TEXT  ENDIF ;

:ABOUT		CR ." Type COMPUTE for a Julia fractal."
		CR
		CR ."  1.4e TO delH  1.4e TO delV -- zoom picture "
		CR ."  9 TO amp  COMPUTE          -- influence contrast " ;

                .ABOUT -julexp CR
		DEPRIVE

                              (* End of Source *)

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

#59969

Hi,
> plotting the pixels is the bottleneck
Indeed using the OS is a disaster in Windows.

In MultiTaskingClass.f the following lines
PAR 
STARTP  Xmax 0 TH-PART ?DO  Ymax 0 ?DO  J I INNERLOOP  LOOP  LOOP  ENDP 
STARTP  Xmax 1 TH-PART ?DO  Ymax 0 ?DO  J I INNERLOOP  LOOP  LOOP  ENDP 
STARTP  Xmax 2 TH-PART ?DO  Ymax 0 ?DO  J I INNERLOOP  LOOP  LOOP  ENDP 
STARTP  Xmax 3 TH-PART ?DO  Ymax 0 ?DO  J I INNERLOOP  LOOP  LOOP  ENDP 
STARTP  Xmax 4 TH-PART ?DO  Ymax 0 ?DO  J I INNERLOOP  LOOP  LOOP  ENDP 
STARTP  Xmax 5 TH-PART ?DO  Ymax 0 ?DO  J I INNERLOOP  LOOP  LOOP  ENDP 
STARTP  Xmax 6 TH-PART ?DO  Ymax 0 ?DO  J I INNERLOOP  LOOP  LOOP  ENDP 
STARTP  Xmax 7 TH-PART ?DO  Ymax 0 ?DO  J I INNERLOOP  LOOP  LOOP  ENDP 
ENDPAR 

are reduced to:
n1 n1 negate  ['] outerloop_parallel Parallel: FractalTask

( prepared for the hexacore)

What are the elapsed times when you use:
1.) 1 thread 
2.) all your hardware threads?

Jos

On 28 mei 2017 12:25:18 UTC+2 m...@iae.nl wrote :
> On Saturday, May 27, 2017 at 8:49:09 AM UTC+2, Andrew Haley wrote:
> > josv...nl wrote:
> > >> parallelization very rarely produces a speedup proportional to the
> > >> number of cores.
> > > 
> > > To draw a full screen julia fractal takes 403 ms when one thread is used.
> > > When 8 threads are used it takes only 63 ms.
> > > Indeed only a 6* speedup.
> > > Still not bad I think. 
> > 
> > Indeed not: fractals tend to be embarrassingly parallel.  :-)
> > 
> > [For those who haven't seen this before, that really is a term of art:
> > see https://en.wikipedia.org/wiki/Embarrassingly_parallel]
> > 
> > Andrew.
> 
> With fractals, the speedup is so large that plotting the pixels
> is the bottleneck. In this demo a homegrown framebuffer is used
> as the OS's pixel or lineops would be too slow (At least they 
> were on my 2003 graphics card).
> 
> The *FB* words manipulate the framebuffer, the PAR ENDPAR
> STARTP ENDP and TH-PART parallelize (stripping the displayed area).
> 
> Parallelizing in this way is easier than inventing an SSE wordset.
> 
> -marcel
> 
> ---
> (*
>  * LANGUAGE    : ANS Forth
>  * PROJECT     : Forth Environments
>  * DESCRIPTION : Julia fractal of exp(z)-z-1
>  * CATEGORY    : Graphic example
>  * AUTHOR      : Marcel Hendrix 
>  * LAST CHANGE : Tuesday, December 30, 2003 4:56 PM, Marcel Hendrix 
>  *)
> 
> 
> 
>         NEEDS -miscutil
> 	NEEDS -graphics
> 	NEEDS -threads
> 	NEEDS -framebuffer
> 
>         REVISION -julexp "--- Julia exp(z)-z-1    Version 1.00 ---"
> 
> 	PRIVATES
> 
> 
> DOC
> (*
>  Julia fractal of exp(z)-z-1
> *)
> ENDDOC
> 
> -- Parameters 
>  4e       FVALUE delH
>  5e 	  FVALUE delV
>    9       VALUE amp
> 
> : COLORIZE ( x y ix -- ) amp 0 >PALETTECOLOR2 SET-FBDOT ;
> 
> : INNERLOOP ( x y -- ) 
> 		DLOCAL @xy 
> 		@xy UNSCALE? DROP FLOCALS| yy xx |
> 		0e 0e FLOCALS| x1 y1 |
> 		#40  1 DO  xx 6e 
> 			    F> IF  @xy I COLORIZE  LEAVE  ENDIF
> 			   xx FEXP yy FCOS F*  xx F- F1- TO x1
> 			   xx FEXP yy FSIN F*  yy F-     TO y1
> 			   xx x1 F- FSQR ( yy y1 F- FSQR F+ ) 1e-6 
> 			    F< IF  @xy I COLORIZE  LEAVE  ENDIF
> 			   x1 TO xx  y1 TO yy
> 		     LOOP ; PRIVATE
> 
> : COMPUTE	TEXTMODE? $FF AND DUP >R IF GRAPHICS ENDIF  
> 		0 0 Xmax Ymax  
> 		delH FNEGATE  delV FNEGATE delH delV SET-GWINDOW 
> \		#40 RANDOMPALETTE
> 		#256 SHADEPALETTE
> 		RESET-FBDOTS+
> 		PAR
> 		  STARTP  Xmax 0 TH-PART ?DO  Ymax 0 ?DO  J I INNERLOOP  LOOP  LOOP  ENDP
> 		  STARTP  Xmax 1 TH-PART ?DO  Ymax 0 ?DO  J I INNERLOOP  LOOP  LOOP  ENDP
> 		  STARTP  Xmax 2 TH-PART ?DO  Ymax 0 ?DO  J I INNERLOOP  LOOP  LOOP  ENDP
> 		  STARTP  Xmax 3 TH-PART ?DO  Ymax 0 ?DO  J I INNERLOOP  LOOP  LOOP  ENDP
> 		  STARTP  Xmax 4 TH-PART ?DO  Ymax 0 ?DO  J I INNERLOOP  LOOP  LOOP  ENDP
> 		  STARTP  Xmax 5 TH-PART ?DO  Ymax 0 ?DO  J I INNERLOOP  LOOP  LOOP  ENDP
> 		  STARTP  Xmax 6 TH-PART ?DO  Ymax 0 ?DO  J I INNERLOOP  LOOP  LOOP  ENDP
> 		  STARTP  Xmax 7 TH-PART ?DO  Ymax 0 ?DO  J I INNERLOOP  LOOP  LOOP  ENDP
> 		ENDPAR
> 		FLUSH-FBDOTS
> 		R> IF  TEXT  ENDIF ;
> 
> :ABOUT		CR ." Type COMPUTE for a Julia fractal."
> 		CR
> 		CR ."  1.4e TO delH  1.4e TO delV -- zoom picture "
> 		CR ."  9 TO amp  COMPUTE          -- influence contrast " ;
> 
>                 .ABOUT -julexp CR
> 		DEPRIVE
> 
>                               (* End of Source *)

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

#59920

On Saturday, May 27, 2017 at 1:17:24 AM UTC-5, Andrew Haley wrote:
> Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
...
> > 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.
> 
> I'm not sure that's totally correct: for example, work-stealing
> fork/join is fairly easy for programmers to reason about and can
> produce a speedup without heroic efforts.  Hand optimization can
> produce code which is harder to parallelize than something more
> straightforward, so perhaps it makes sense to alternate
> serial/parallel optimizations. ...

Your comment about hand optimization can be illustrated with the matrix multiplication example. Writing it first as a hand-optimized monolithic word (or assembly language definition) means that it would later have to be factored to allow for parallel computing. Writing it as a well-factored high-level word first helps identify those components which can be used in parallel computation, e.g. in mmul.4th, the word df_mmul is factored to use the words, set_mmul_params and df_mul_r1c2, both of which are needed to distribute the computation among different processes. In contrast, the single process simply calls df_mmul and doesn't need to worry about how it is implemented.

Hand optimization should be done after the words needed for parallel computation have been identified and factored. Now that I have the appropriate factoring for both single process and multiple processes, I can hand optimize the row and column dot product word, df_mul_r1c2, e.g. write it as an assembler definition.

KM

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

#59912

On 26/05/17 17:22, 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.

And a faster Forth or a faster computer could make all the difference!

Another critique would be to question the usage of the CPU for these
computations in the first place. Much can be done many times faster on
dedicated processors: a GPU for instance. Using OpenCL, Vulcan, Metal,
etc. from within Forth is IMHO very attractive and the way to go.
Also using existing (foreign) library functions exercising those GPU's
is worth serious consideration.

So far I have had no trouble at all using FORK/JOIN. All for graphical
usage and any bug or glitch is immediately revealed. Instant visual feed
back :-) And all are significantly faster than their serial counterpart.
Making all the difference in the world. Debugging is no trouble at all.

: 4fill ( -- )   fork bottom-right bottom-left top-right top-left join ;

But it's not the right tool for the job. All effort should go in that
GPU interface. The CPU is no match. Fun though to see it works.

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

#59941

On Thursday, May 25, 2017 at 9:34:45 PM UTC-5, krishna...org wrote:
...
> > > 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
> > 

There is now a new matrix multiplication module, mmul_x86.4th, which provides a CODE definition of the inner loop word, df_mul_r1c2 . Using the revised matrix multiplier, the execution time tables for the two cases have been updated: case 1) is the 4x1000000 times 1000000x1 multiplication, case 2) is the 500x500 time 500x500 multiplication:

case 1)

single-process   two-processes   system
--------------------------------------------
    53 ms          41 ms         gforth-fast
   315 ms         179 ms         kforth-fast w/ mmul.4th
    22 ms          32 ms         kforth-fast w/ mmul_x86.4th


case 2)

single-process   two-processes   system
--------------------------------------------
    2659 ms         1184 ms      gforth-fast
   11353 ms         5602 ms      kforth-fast w/ mmul.4th
     865 ms          517 ms      kforth-fast w/ mmul_x86.4th

For case 1), the two-process run-time (32 ms) is actually slower than the single process (22 ms) using mmul_x86.4th. Here, I presume the overhead of forking is causing the slowdown. 

For case 2) we have obtained an overall speedup of 22x in going from pure Forth code, single process (11,353 ms) to a two-process, mixed Forth and assembly code (517 ms), which replaces a single short Forth word with its assembler equivalent. 

I will note that kforth-fast is not an optimizing compiler (not even peephole optimizations) and does not provide multi-thread support, although both are being considered for a future version. We simply used the Forth assembler judiciously and the OS facilities to achieve what I consider a high level of optimization without requiring specialized hardware. And we haven't even started to vectorize, yet.

Krishna

---
The new mmul_x86 module may be found at

ftp://ccreweb.org/software/kforth/examples/fsl/extras/mmul_x86.4th

It is a drop-in replacement for mmul.4th, as evidenced by the revised parallel-mm2.4th:

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

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

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

csiph-web