<div dir="ltr"><div>Hi,</div><div><br></div><div>Boy, this is interesting.  It does illustrate you can simplify a complex pipeline of computation, but</div><div>it is sort of wishy washy on how it sets up the thread pools and controls the client thread resources.</div><div><br></div><div>begin blathering...<br></div><div>A long time ago, there was a design called HEP (heterogeneous element processor, back in the Cray days)</div><div>but it did not catch on well.  It was similar to this kind of pipeline simplification in that it did not require a</div><div>great deal of programming to setup.  It employed an extra bit (the sting bit) on every reg/mem cell that</div><div>indicated that the result was stored (ready).  The CPUs all were not bound strictly to a user context, and the</div><div>instruction fetch would block and switch to a ready context if the input operands had not yet been stung</div><div>(stored with a pipeline result).  This meant that the computation would inherently create a serial pipeline</div><div>sqrt(f(x)**2 + f(y)**2)<br></div><div>cpu1 f(x) stings cpu3, then cpu3 runs **2 and stings cpu5(lt) then cpu5 runs +, and then sqrt<br></div><div>cpu2 f(y) stings cpu4, then cpu4 runs **2 and stings cpu5(rt)<br></div><div>The programmer normally did not see any of this functional parallelism in the code design, and</div><div>the instruction fetch and context binding was per functional unit, so that float/int/simd etc were all</div><div>part of a pool of computational resources that could decode and execute any next operation with</div><div>all of the input regs/memory sting bits set.  Hell, there were event context register sets with lambda</div><div>parameter registers so that tail recursions could be unwound into iterations by the hardware.</div><div><br></div><div>In reality, much of this is good in the classroom, but not as easy to use as all of that in real life.</div><div>The stung memory idea could get hung up with A waiting on B, and B waiting on A by some unrealized</div><div>recursive dependency, and much of it was way past what could be implemented by hardware design,</div><div>time, and money... since it did eventually have to make it into the market and do something useful.</div><div>end bathering...<br></div><div><br></div><div>As for the OpenMP pragmas.  This may be a great way to speed up a bunch of striping done in</div><div>many of the standard transformations.  To that extent, much of this code has already been painstakingly</div><div>threaded using pthreads.  This is mostly done using LoadBalance, a class in cinelerra.  It is not nearly</div><div>as easy as the OpenMP design, but does some of the code parallel operation that OpenMP seems to</div><div>offer.   I have found that there frequently is a trade with the overhead of setting up a thread to do a</div><div>function, and the function itself.  It does not make sense (usually) to create a thread for a trivial work load.</div><div>The thread management is not free, and the needed locks and atomic ops do apply a cost in the code.</div><div>Threading works well when the loop is much bigger than the cpu count, but not as well with lots of cpus.</div><div>That is sort of a problem, especially with debugging.  On my devel machine there are 128 cpus.  This</div><div>means that when you ask gdb: "inf thr", you get hundreds of results, and only one or two are interesting.</div><div>A lot of effort has to be added to the lock trace just to get a handle on what is actually happening.</div><div><br></div><div>I am concerned that by using a more opaque thread system, that simple things like tracing a thread,</div><div>determining a thread owner, lock holder, or thread client set may be much more difficult.  It is already</div><div>quite difficult to just address a threaded program under the debugger.</div><div><br></div><div>For computations near the outer edge of the code graph, this could be great.  The simple setup and</div><div>high degree of parallelism is exactly what you need for the math to code abstraction. It might be a good</div><div>idea to make  a sort of "test" plugin, and see if it is worth it.  IF the results are good, and not difficult to</div><div>achieve, then there may be a case to "backport" some of the threaded code just to see how it goes.</div><div><br></div><div>gg</div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Mar 10, 2020 at 6:29 PM Andrew Randrianasulu <<a href="mailto:randrianasulu@gmail.com">randrianasulu@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi, all!<br>
<br>
Currently I'm experimenting with OpenMP<br>
<br>
<a href="https://bisqwit.iki.fi/story/howto/openmp/" rel="noreferrer" target="_blank">https://bisqwit.iki.fi/story/howto/openmp/</a><br>
<br>
--quote---<br>
Support in different compilers<br>
GCC (GNU Compiler Collection) supports OpenMP 4.5 since version 6.1, OpenMP 4.0 since version 4.9, OpenMP 3.1 since version 4.7, OpenMP 3.0 since version 4.4, and OpenMP 2.5 since version 4.2. Add the commandline option -fopenmp to enable it. OpenMP offloading is supported for Intel MIC targets only (Intel Xeon Phi KNL + emulation) since version 5.1, and to NVidia (NVPTX) targets since version 7 or so.<br>
<br>
[...]<br>
<br>
The syntax<br>
 All OpenMP constructs in C and C++ are indicated with a #pragma omp followed by parameters, ending in a newline. The pragma usually applies only into the statement immediately following it, except for the barrier and flush commands, which do not have associated statements. <br>
<br>
The parallel construct<br>
 The parallel construct starts a parallel block. It creates a team of N threads (where N is determined at runtime, usually from the number of CPU cores, but may be affected by a few things), all of which execute the next statement (or the next block, if the statement is a {…} -enclosure). After the statement, the threads join back into one. <br>
<br>
  #pragma omp parallel<br>
  {<br>
    // Code inside this region runs in parallel.<br>
    printf("Hello!\n");<br>
  }<br>
<br>
 This code creates a team of threads, and each thread executes the same code. It prints the text "Hello!" followed by a newline, as many times as there are threads in the team created. For a dual-core system, it will output the text twice. (Note: It may also output something like "HeHlellolo", depending on system, because the printing happens in parallel.) At the }, the threads are joined back into one, as if in non-threaded program. <br>
Internally, GCC implements this by creating a magic function and moving the associated code into that function, so that all the variables declared within that block become local variables of that function (and thus, locals to each thread).<br>
<br>
 ICC, on the other hand, uses a mechanism resembling fork(), and does not create a magic function. Both implementations are, of course, valid, and semantically identical. <br>
Variables shared from the context are handled transparently, sometimes by passing a reference and sometimes by using register variables which are flushed at the end of the parallel block (or whenever a flush is executed).<br>
--quote end---<br>
<br>
<a href="http://gregslabaugh.net/publications/OpenMP_SPM.pdf" rel="noreferrer" target="_blank">http://gregslabaugh.net/publications/OpenMP_SPM.pdf</a><br>
Multicore Image Processing with OpenMP<br>
Greg Slabaugh, Richard Boyes, Xiaoyun Yang<br>
<br>
<br>
<a href="https://nccastaff.bournemouth.ac.uk/jmacey/OpenMP/" rel="noreferrer" target="_blank">https://nccastaff.bournemouth.ac.uk/jmacey/OpenMP/</a><br>
-quote-<br>
OpenMP by Rob Bateman<br>
Introduction<br>
<br>
 OpenMP is an open standard that lets you easily make use of multi-threaded processors. It's currently supported by the following compilers: Visual C++, gcc (though not the Win32 version that comes with cygwin), XCode, and the Intel compiler; and It's supported on the following platforms: Win32, Linux, MacOS, XBox360*, and PS3*.<br>
<br>
 * Not amazingly well on those platforms<br>
--quote end--<br>
<br>
I used bcast2000 example , namely bcast/overlayframe.C<br>
<br>
and those CFLAGS:<br>
<br>
CFLAGS = -O3 -fpermissive -fomit-frame-pointer -march=pentium3 -ffast-math -mfpmath=both -fopenmp -I/usr/local/include<br>
+ enabled linking with libgomp (gcc 5.5.0) by adding  -lgomp to bcast-2000c/bcast/Makefile<br>
<br>
it makes code slower, so far  :}<br>
<br>
but it eats all processors :} unlike original code<br>
-- <br>
Cin mailing list<br>
<a href="mailto:Cin@lists.cinelerra-gg.org" target="_blank">Cin@lists.cinelerra-gg.org</a><br>
<a href="https://lists.cinelerra-gg.org/mailman/listinfo/cin" rel="noreferrer" target="_blank">https://lists.cinelerra-gg.org/mailman/listinfo/cin</a><br>
</blockquote></div>