220 17245 <363fb8c3-5127-47c4-8a08-c6b4202809c6@isocpp.org> article Path: news.gmane.org!not-for-mail From: tef@tentity.com Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Generic Parallel Computing (GPC) API Date: Sat, 4 Apr 2015 16:39:15 -0700 (PDT) Lines: 457 Approved: news@gmane.org Message-ID: <363fb8c3-5127-47c4-8a08-c6b4202809c6@isocpp.org> References: <3be1928f-2116-4712-be20-7368682abf26@isocpp.org> <81e0ac7b-2e97-4ecc-8c37-c9851be3d81c@isocpp.org> <45d4c30d-72b4-474a-9df6-9efa17d4d0b1@isocpp.org> <2000ef45-bc5b-4453-8252-d78c7406afc8@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_1596_717802005.1428190755506" X-Trace: ger.gmane.org 1428190762 25277 80.91.229.3 (4 Apr 2015 23:39:22 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 4 Apr 2015 23:39:22 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBDL4BSXDYUBBBJHMQGUQKGQEN7VDPAY@isocpp.org Sun Apr 05 01:39:21 2015 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-ie0-f200.google.com ([209.85.223.200]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1YeXeo-0005kg-6N for gclcip-std-proposals@m.gmane.org; Sun, 05 Apr 2015 01:39:18 +0200 Original-Received: by iecqx6 with SMTP id qx6sf4651023iec.0 for ; Sat, 04 Apr 2015 16:39:17 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:message-id:in-reply-to:references :subject:mime-version:content-type:x-original-sender:reply-to :precedence:mailing-list:list-id:list-post:list-help:list-archive :list-subscribe:list-unsubscribe; bh=gHmjZSDAUu1x6EpQgrdECrxPJcYkmwMGduEqLmSlcDA=; b=bX1O4vhZzPqfiVmkARA4sT1PCJUbTjm/R9XSxLWlTUVcNcmNenbhsCyxaCcnNIfwU4 Bw95OyeSZcJnH4hKJDBclTEy1U9ttJ3N+nmkA7phScIzmo3XhtWtPLLC5y1cCszZ9oek ne5/wgLF3nQffYbyD8bpFZvkXgYOw61RD09+jnjdfBp08YrsiGiNVOViVLpN1MD5qnM8 uUjJYzjY36UVHsLn7/UhosG92Vuq14cuCNNWjpks1wFQ21Yk/1PgdAbo6THm4P247tNs 3QtqiL82KOS56/3DxcKp1SI+5X/QChvBI5oGatAxTdcDrtylytp4kdgrk/bhNLBMk7eF Thcw== X-Gm-Message-State: ALoCoQn1xbE3/YYU46OG0MC90C3WX/f24j1ty89VCm5RIZEg4TWMYAG6cPgvGzoBK0MtuFhQodip X-Received: by 10.42.78.144 with SMTP id n16mr11043261ick.12.1428190757015; Sat, 04 Apr 2015 16:39:17 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.140.102.212 with SMTP id w78ls1666734qge.36.gmail; Sat, 04 Apr 2015 16:39:16 -0700 (PDT) X-Received: by 10.140.105.133 with SMTP id c5mr109037qgf.28.1428190756254; Sat, 04 Apr 2015 16:39:16 -0700 (PDT) In-Reply-To: <2000ef45-bc5b-4453-8252-d78c7406afc8@isocpp.org> X-Original-Sender: tef@tentity.com Precedence: list Mailing-list: list std-proposals@isocpp.org; contact std-proposals+owners@isocpp.org List-ID: X-Google-Group-Id: 399137483710 List-Post: , List-Help: , List-Archive: List-Subscribe: , List-Unsubscribe: , Xref: news.gmane.org gmane.comp.lang.c++.isocpp.proposals:17245 Archived-At: ------=_Part_1596_717802005.1428190755506 Content-Type: multipart/alternative; boundary="----=_Part_1597_1682652836.1428190755506" ------=_Part_1597_1682652836.1428190755506 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Let me make some clarification. In my system, I have one thread pool for everything: forks, joins, http=20 requests, timers, etc. I avoid creating threads (that is why I do not use std::async) and I avoid= =20 switching threads. I don't see any reason to have more than one thread per core (20 years ago= =20 I would do because it was only one core CPU, but not now).=20 So, I do not create a thread pool per a qutex, but I use one thread pool=20 for everything.=20 Here is the algorithm of the mutual exclusion that is used in the thread=20 pool: static intptr_t __stdcall Run(tef::sys::THREAD_TASK* task) {=20 ExclusiveTask* $this =3D static_cast(task);=20 auto qutex =3D $this->qutex;=20 if( qutex->Lock() =3D=3D 1 ) {=20 $this->Callback(); // call back the lambda while( qutex->Unlock() > 0 ) {=20 task =3D qutex->UnsafePop();=20 while( task =3D=3D nullptr ) {=20 task =3D qutex->UnsafePop();=20 }=20 // call back the lambda ExclusiveTask* t =3D static_cast(task);=20 t->Callback(); delete t; }=20 delete $this;=20 } else {=20 qutex->Push($this);=20 }=20 return 0;=20 } It is very simple, now, but it wasn't year ago. And it is multiple=20 producer/single consumer queue (non-blocking, based on the atomic increment= =20 and compare exchange). I realize that in the standard library thread pool creation would be=20 explicit. Something like: auto h =3D std:setThreadPoolSize(32); and/or a thread pool handler could be passed as a parameter to forks and=20 joins also. However, I don't think the "qutex" concept gets us anywhere close to where= =20 > we ought to be in the end. What is the end?=20 I do not see any parallel computational model so far. Intel TBB Flow Graph or Intel Cnc are awkward. Imagine you have to declare= =20 a call order of all functions of your program in advance and their call=20 conditions. So, what is alternative? I have even more advance computational model, but= =20 it is a way out of the conventional thinking (Method for Automatic Parallel= =20 Computing ). By the way, you used 'qutex', not 'qumex'. I am not english native speaker,= =20 so 'qumex' does not sound right? Thanks Andrew On Saturday, April 4, 2015 at 3:39:15 PM UTC-4, Arthur O'Dwyer wrote: > > Now that I've read more of the documentation and have a better idea of th= e=20 > concepts involved... If I understand correctly, you start from the atomic= =20 > concept of > > (work-queue + consumer-pool-of-size-N) > > In your particular system there is a singleton global (work-queue +=20 > consumer-pool-of-size-LARGE) that you call "the thread pool", to which jo= bs=20 > can be submitted via gpc::fork(); and your system also supports=20 > constructible-on-the-fly (work-queue + consumer-pool-of-size-1)s, which y= ou=20 > call "qutexes" and to which jobs can be submitted via qutex::join(). > > If anything like this model were proposed for standardization, I'd hope= =20 > that it would standardize the underlying (work-queue +=20 > consumer-pool-of-size-N) model, so that you could have=20 > constructible-on-the-fly work-queues with consumer-pools of size 2 (for= =20 > example). Perhaps the atomic concept should even *be* split up, so that = a=20 > single consumer-pool could pull from two different work-queues, etc. etc. > > Notice that a work-queue with only a single producer and/or only a single= =20 > consumer can be implemented with greater efficiency than a work-queue wit= h=20 > multiple producers and/or consumers, so there's an efficiency win there= =20 > that should be reflected in the library somehow. However, I don't think t= he=20 > "qutex" concept gets us anywhere close to where we ought to be in the end= .. > > =E2=80=93Arthur > > On Saturday, April 4, 2015 at 7:46:59 AM UTC-7, t...@tentity.com wrote: >> >> Thanks.=20 >> Now I am thinking "qumex" which abbreviation for *Qu*eue of *M*utual *Ex= * >> clusion.=20 >> Would it be better? >> >> On Friday, April 3, 2015 at 6:48:48 PM UTC-4, Arthur O'Dwyer wrote: >>> >>> On Friday, April 3, 2015 at 5:15:13 AM UTC-7, t...@tentity.com wrote: >>>> >>>> Quetex is Mutual Exclusion Queue. It eliminates blocking/waiting and= =20 >>>> thread switching in comparison to mutexes and futures. >>>> >>>> gpc::quetex qtx; >>>> >>>> >>> Not related to the semantics, but FYI, "quetex" looks like it ought to= =20 >>> be pronounced "kaytex", and you lose the pun. Consider "queuetex" or=20 >>> "qutex" instead. :) >>> >>> =E2=80=93Arthur >>> >> --=20 ---=20 You received this message because you are subscribed to the Google Groups "= ISO C++ Standard - Future Proposals" group. To unsubscribe from this group and stop receiving emails from it, send an e= mail to std-proposals+unsubscribe@isocpp.org. To post to this group, send email to std-proposals@isocpp.org. Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa= ls/. ------=_Part_1597_1682652836.1428190755506 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Let me make some clarification.
In my syste= m, I have one thread pool for everything: forks, joins, http requests, time= rs, etc.
I avoid creating threads (that is why I do not use std::= async) and I avoid switching threads.
I don't see any reason to h= ave more than one thread per core (20 years ago I would do because it was o= nly one core CPU, but not now). 
So, I do not create a t= hread pool per a qutex, but I use one thread pool for everything. 
=
Here is the algorithm of the mutual exclusion that is used in th= e thread pool:

static intptr_t __stdcall Run(tef::sys::THREAD_TASK<= /span>* task)
{

  ExclusiveTask* $this =3D static_cast<ExclusiveTask*>(task);

&nb= sp; auto qutex =3D $this->qutex;

  if( qutex->Lock() =3D=3D= 1 ) {

      $this->Callback(); // call back the lambda

      while( qutex->Unlock() &g= t; = 0 ) {

         task =3D qutex->UnsafePop();

         while= ( task =3D=3D nullptr ) {
            task =3D qutex->UnsafePop();

         }
         // call back the lambda
      &nb= sp;  = ExclusiveTask* t =3D static_cast<ExclusiveTask*>(task);
         t->Callback();
         delete t;

      }

      = delete $this;

  } else {

      qutex->Push($this); <= br>
  }
=
  return 0;

}
<= p class=3D"p1">

It is very simp= le, now, but it wasn't year ago. And it is multiple producer/single consume= r queue (non-blocking, based on the atomic increment and compare exchange).=

I realize that in the standard library thread poo= l creation would be explicit. Something like:

auto h =3D std:<= /span>setThreadPo= olSize(32);

and/or a thread pool handler could be passed as a par= ameter to forks and joins also.

However, I don't think the "qutex" concept gets us anywhere close to = where we ought to be in the end.

What is th= e end? 

I do not see any parallel computation= al model so far.
Intel TBB Flow Graph or Intel Cnc are awkward. I= magine you have to declare a call order of all functions of your program in= advance and their call conditions.
So, what is alternative? I ha= ve even more advance computational model, but it is a way out of the conven= tional thinking (Method for Automatic Parallel Computing).

By the way, you used 'qutex', not 'qumex'. I am not english native speake= r, so 'qumex' does not sound right?

Thanks
Andrew
On Saturday, April 4, 2015 at 3:39:15 PM UTC-4, Arthur O= 'Dwyer wrote:
= Now that I've read more of the documentation and have a better idea of the = concepts involved... If I understand correctly, you start from the atomic c= oncept of

    (work-queue + consumer-pool-of-s= ize-N)

In your particular system there is a single= ton global (work-queue + consumer-pool-of-size-LARGE) that you call "the th= read pool", to which jobs can be submitted via gpc::fork();  and your = system also supports constructible-on-the-fly (work-queue + consumer-pool-o= f-size-1)s, which you call "qutexes" and to which jobs can be submitted via= qutex::join().

If anything like this model w= ere proposed for standardization, I'd hope that it would standardize the un= derlying (work-queue + consumer-pool-of-size-N) model, so that you could ha= ve constructible-on-the-fly work-queues with consumer-pools of size 2 (for = example).  Perhaps the atomic concept should even *be* split up, so th= at a single consumer-pool could pull from two different work-queues, etc. e= tc.

Notice that a work-queue with only a single pr= oducer and/or only a single consumer can be implemented with greater effici= ency than a work-queue with multiple producers and/or consumers, so there's= an efficiency win there that should be reflected in the library somehow. H= owever, I don't think the "qutex" concept gets us anywhere close to where w= e ought to be in the end.

=E2=80=93Arthur
On Saturday, April 4, 2015 at 7:46:59 AM UTC-7, t...@tentity.com wr= ote:
Thanks. <= div>Now I am thinking "qumex" which abbreviation for Queue of Mutual Exclusion. 
Would it be better?

On Fri= day, April 3, 2015 at 6:48:48 PM UTC-4, Arthur O'Dwyer wrote:
On Friday, April 3, 2015 at 5:15= :13 AM UTC-7, t...@tentity.com wrote:

Quetex is Mutual Exclusion Queue. It eliminates = blocking/waiting and thread switching in comparison to mutexes and futures.=


=  gpc::quetex<int> qtx;

<= br>
Not related to the semantics, but FYI, "quetex" looks like it= ought to be pronounced "kaytex", and you lose the pun. Consider "queuetex"= or "qutex" instead. :)

=E2=80=93Arthur

--

---
You received this message because you are subscribed to the Google Groups &= quot;ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to std-proposa= ls+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/<= /a>.
------=_Part_1597_1682652836.1428190755506-- ------=_Part_1596_717802005.1428190755506-- .