From 4ec4941d8cabedfa8abfe0933cb231461485c994 Mon Sep 17 00:00:00 2001
From: Pedro Gonnet <pedro.gonnet@durham.ac.uk>
Date: Thu, 13 Nov 2014 21:29:46 +0000
Subject: [PATCH] more corrections and proofreading, fixed some of the figures.
---
paper/figures/Spawn.pdf | Bin 16554 -> 20150 bytes
paper/figures/Spawn.svg | 26 ++++++-
paper/figures/TaskWeight.pdf | Bin 11590 -> 11603 bytes
paper/figures/TaskWeight.svg | 17 +++--
paper/paper.tex | 139 +++++++++++++++++++----------------
5 files changed, 110 insertions(+), 72 deletions(-)
diff --git a/paper/figures/Spawn.pdf b/paper/figures/Spawn.pdf
index 263a78ebd1469b9299f37009926eca1d83faa697..a444386670c83f969883eb397d29298211ccac4f 100644
GIT binary patch
delta 5560
zcmZ40$hd7T;{@OO@RNBWh5~zkYrmQyb8KU5+|G$Cii(9CJx3G^B-&!V6dFYA<n>dx
z-%Z*z(_v9YQ0nz>G2d42OlG?DzI%DWHsKE+*(cvQRC~p)yFUKLS80Km1J=tPTHa|q
zGu!;7v(?dF?kI~J_YL%Sn6piJ79_cYaZ=#N1XYVCW*!%m)<?~~?oofMd1H)*kYvXF
z=t(Yh-$SRhY0ICu^gYftH$`Ogi79+Ddr!W5C|u1M&T`~?f5E=gOKFOA66e=`)w`8-
zbS)2~X-@u)o9(?fj__{yd%#a_e%}5K>bE&hu`XD_@Sam+QnT*UQ**Y6sBYzO@{7LW
zlYDAp!lcME>&?|phI4q7DT>GX)F<oBO`ddPADbGhs_V4mQ>P0wPtWb$J;$Eq+E2j*
z&y{XlRxJwCInxln!FbQ2M4efotg<$dldrr|nz>4E84HJHn##NAl%OknPLxgiZj|C!
zpnBFQWBT#(875gdhM7k%BwypVP5XNz*)`8LZ0+idD>qVulCP%;y?wB!gC}b7RbJD2
z^G)-f?z@$JF#XF{#XEW&+qHKjYsqDNk$rv1&H2Hh%o_`y98|2S=U@L|+TD#y%npeZ
zoL&?tw<*_Z(Tr{14(*;WK~G<8&fiT1Kc~h%)$nuqu6J$vJY|-bl{MC885YNSqGv3*
z=9s)vb-mSc)0EdD>MVH|qPm@B%#S+$*Du`k^`S+5UDxFW>Qx=;0u_bR?M|=G5O%w?
z<nZN{+@}psylkwQa!#>SyT7aa%`cXQ;<{gHzjK!T{g_)`&%In?erM~^)0r2S9-aL8
zF>{Phx7cO>vXYI@PPlBy;jG%Z?Yimy>+0sa&u{Oa_Nnqu`_bQbpU;oH8~?Xm(Bzin
z#}HQAwv6;E$<ONVG+V{yn!P>HSi9=Ry*;ZIm~Wh6&ZPBDa*Oy@wE*)Qjm>E<_3e3P
z$hG|UytQ?T*}V`}U(FRx_74^aJ#J~9$S=fywR9nSw$N>xAW@Tb6Slsu-E8*a%8fdU
zDOpx(`<SAi%=fv+y+Zczy{I#7hgPj9ZBNv3v7gO-@g}3GwNG2<oce&xhjTox?fZUr
zq1dmF8`RvEZ9WnnaCzIO?}>6&ZTpv7U3s%Aj4!WzYtW9F#TC0(mt7OP%6u+!Pi9Bw
z%Ux#A@(eq6Ea$$x<6d8k-TGwNV~3u#FJCb4Y~X+9x#Eux*XX&rZ%IqKl`(mym~G%%
zsg+`~ZGBm(Dp8kbm<1Yk6&(v!slVwO)TjMeUP?1s-zBKt_m$M&{|aCGw8DSxyuI7&
zVE1Q-<4;%rv0<%Mu-Es~?%gBKKH-b+!aI#$&bu8Ew-BBls{C%%!+q7Yvt9*F(&kwi
z@3QV&Zs79Q2kV%pd^6SHO3h0tE-6Y)%muOXld`x>6buwVw1R?yrG+V1>SS@2v&sqz
z3i@ffM!E(HhQ<m83PD^73JP|1Ty}OaU4|x;KeJeiSQ_XVn^{;InJXBY8|j&vTbdY{
zPj+IR%4j;-gnirO0s(=^^VsSc%_hsSYciTo4&?BeY{3>bNr;EZ&~)+-c0ES($qz+D
zm<%l@ujT|P=by~PIcf4-E}qE?IAxiP3?>J1ECQ>xn9R?s$7ldnZDcrkBcJf(IG)9m
z3j~BF*KqHcY|G0t*?~un(HNqEm(dWc-Wa0ZWb#Hnkm(@D)G-;EPM*c5#b}0b4e#Xd
z?0QT_W)RipVAEp-L8c#?Y$L=o*-lWN(Gq5|IoM>&$qz+D84V`C69yT~H(6YG|KtZE
zJd+;@%QG55l=3hc8%)mU(q%F>0x1>+1tch-ZEO_ueNyw%OEMIUO(q9&C~npfE#YP~
znY>UzT+|dA8_0@4E|s0=z%%)q!aoT!r~(BA1tVi~SacYhZ{|_rXJj;<ETcS^(R}hQ
z<tb_)qk@p4%-8~|71?Z%w-hJqh;nS6tD+#xXgPVGxtOSl0j5fm$&4a$6CHRq3tLz*
zG8#_yvlL@An#`l5H+iz<N=A#xwpKliMw?Gr@iVG}wIkbXg2n45V6TI0t~WL{vjDjh
znl3BmybY}`nQ~Ng|L4E^Zt~tt*}VHEi&Bbwr?&$Kr?ikyg|48B+$D#AgR{z*Pdlxg
zkx}Dt*+azH;ex`cMI9zbMNEREb=%H5zh(}Qz7(Z6Z&ifL!3<x+tR-cQo#l&vxch&d
z|835^d6##lf1CY#-+t@O^~Ne48q-#BK8f12Y0ICr{Bn_wEfz{|Z>es-_vV%Tq*?wd
z(}g>W4}MD3-u=C{s^Nr0!usCR>*8hSY+sUXwEp|1z4bpYT{>W0{<f<3>t3DH(dU>>
zmpnFFG(+%A{GOVpXIHPedrRcmbA$Yy`*J*2{s@qmv0pFh=&4JgPk)IxGk%`aUmx?-
zTvvB~!k;PA4PUcoUC>zJR25)Wu+?qX3GwCgRS!oBDqqjAN|m*^WjsyCy}IvPih9)D
zu>RYx_+FK)V{$$}H%M{u&(r7gjC!6(O#S=*^~@^O#oq#U>nk74l(ISD)6Z|VWyacd
zrRT0C>b^{Tz3gD2iG=eb_M<cAbZqpO&$GN<U;HDZ|9bY>^YW*6`hA=G`t?Q`t6a<6
zv)iBD{<OK)JY{*B^`^Nu*X5L#-I~G^zv}$M;$Ja#+x6FKY&{Y9M5jn}XZNKpqf^FN
zLD{lf&qal=-K~~e>{jcR-}boaHS2P2zPk4NFUx=4ecD%)zH{}R*taXn!gjB^>+I#y
z>0zvLb8>P0p32EbDzdBAMJ`#+dtP?>^vCC9&24PYCY+h8Q?%#gt>WX~?*)Df@V2m7
zTKo52-{<t!ZRxZ3S023deBIwY;ioyn^ww1r-#=mb{Cx(`w0#?1-+Z2%ZPq7wdB()T
zzU_0QuB1oJJm~iE$rn`#`6an&ixnpO`u8YqetP4`zIlyh1^Jumg^MTUdX}A?F)#hJ
z>~hm9?c4HruU=mho4w)diq7NrLs{kL3$gFseYAVeT&b;}<V+;qq%2A-S*g#eTgcfQ
z)uxi`#le4fnv>b>9>v188QpsRPfx_<%fHVKJAZN?^ToDw^WU;p`>NO_{xh6eAFZ$`
zA~&r2nC%G<ukFtsT$!gE{jJ{R`Oj+Zd8=&h+^^s9X=T$iG2PXRckgaqZe|~_>ekii
zK5v&c9^WC+rNrj?U$AgVcJa^G3f$gjwzU0n-KZhD`pDa)?lKSSXHxG@m5J{7w(Ih*
z-;2|yzB*d-FunGw`7f7i&+AwJf2U}1+;C&;8v*N?ul6r=_F3N%{%>jfx4j?#eO9i&
zHTi#keQ`$&S1|i!?kgVFNAjLE>Fk@R`t{c35a;b1o~T|_G|QN&bK7@sNsDgwO6Fdx
z&d4c;gBF=Db*oKceEV49=OMjMy=-&8?EGa{yHD=g?yr7Q>%(8n-4(xH!19Lb`f0l>
zpFLiXwmAHxXJX+Ttrep3itKNHncVd`ezDWd>S%prN#A|P(kl*AW4dFfT$EZHH2eId
z>8a|u=~~IP>hmut$HcCV@Q(eWQ1X`RmgX*raQ3+iw?-^j`|!K6J9p7v{o*x#-|qW~
zTAkDr^!AcIYP4=%v98<?U)N=Cq!z^en;v?JDa)XRw=CHzy|XN5dxhs0iFeDZteRdI
zDBlw^t=jdkenuVZ)!Ms^KUVf7=lB1TXi73o?hi^e*;O|Cop|q;iSNwyp50(y++p$D
zF4s<(E6Do%Z62{>CXQDUn8T&6E(=;-IBnk1e=-Lnj;`oDHNjiEBGl9W(&Z_g0#^%{
zFz#vl_=%_b-35PxXI6#%Wo=f5y>3AP_GkC1S({2P;q$$aF};4N=jSs#CO@C)mh9bh
zVy@+{`4Q8PzQ|g%XxWde>k8`YFFMt(h`FNDZhBDo@{;OH{x#D-xjcJu)0I2c_xW=F
z-)gT){+mn_)qj#YCE4)wa{tpy8gKXJPw>C8dz-wv&!46_hRn}5Z(V9`^P#rzW^Gop
zSMS{9n3FkY8vY(&d=|GRWM%yypY5CLoZrmJHx+L?w_JZkd9do7D++I~oZ4h^@9<=$
z-`Vw-UV7DS=l;3+<K9<~O<#KcS@(Ia^tDyBf73;k%KjW~*5CW1nj`(p52uCx4~zNj
zj2~YXsIvX><lV|o!mXDT|LC^N<FM;{u%1g^^ub}L678A?M^{ch`YD7%{pN=h!+Z7h
z`riBG4^~H7Ec~$UP@(?6q~q3#GQkzM+qSRzkS6_a%?GyG`vY6oEjCUG7wtQDVB+=m
zQ_5WH`H#*Qi3|R*_>jDam9xd2hZEXGtz>@e6<@C<vufih=fedClI$XJK^1`ySzDir
z)-C@q=g?-Zw_LegYs0pz`FujG^}|0i$*>#uW9pT@Z%?e>dhbt<yV>*~zb?MHJpW_D
z{6qQ96;Tg0Th&_cYuHF0Sbz4$?-uuWybn6vX4f2Qc9WKSzDU0RfnlpH*KX0eROjYH
zi+7*-6sTV|^W$lTS2vf~wZv<@sZsHJ7gC|ZXD#P9(VD5EVz;Z^oTj&8HX_~ZqT5;@
zJvD0$u-Ue${_-^exgGa)<Ruz^pS>Y;uy*$CC$(I&Uwb`yW|p(=+Us{;PwW!9^7Biz
z?GE?E%f}3hCLcOxxMOzWJzG)fYqOuQSzntSaJuOh!?nWY*D3>&kH&Ikzu$6dD_40`
zVY}1TLsG2q|KEm&ekyBSrS-?A;S{Uqrc2H9HP?hiq#nyH++iwKzg^>wjH4@yxobf(
z%TumYE_02T_s9H2!y>q!b|w9BNvsr|W+)sIu}UByV$p_(g<BZ@any;l3$@B?#jM_t
zk+>#C<lv!*n8|aL)_;7I)w<f^b7*VCgqEbliAS9c?)O!07J6#asw7;uz~H-A_ng%Q
zOIeFW(l)1UJG5q|n5DL$aeeUPr#{^4I*#+So_3xgcgUpm^cJ7WNS4;z8CKGEt(shu
z)o(sYu~zf-nJ_tLhJ|9B-<PlI2~IX#BA-O{Wb>y_cQdd%uXOzO#Oc|SD#f16GC0>b
zr=sHctR>-zYdCL4s?C(`*AYIJ!Z#^d=Y&kl#kihbN0i-J3r>2>-gBgRqFGP<i4P|P
zgC{;bSkUju=ihL=rCaop=p~^CX>;<VV;C)z3k+D?8CHIjI3_Ez%)q3nn``1BpRPj_
z7}$!JvuUer4ld%FB=Ux<lgrF(gJy)}>a7CPv{YCU!aDlBr+wrq%#oeWGudekYqLnw
z4IQ_G8SRP;bEjI(Z&2AF(zV{Z`-+ibq>cispjhLq>LV-uw>tiR%e1e2NgeCnMTu^p
z)*ZA_l$w_UYCD=BwbqS{EX_bFz~Z3B9*BX|wljgX8|z~O&So7^5ZL!yr1*}Um@s#1
z6U(V@lbq`_Zm}C!Epu9IWZ1r^Rz2;e6Tj8D@5VKKd%m2n<zandt!kaXD8EQK=8~6K
z;t@@ki&_N-r)7udThG=}ncbeNY4QD{`a;ta{A$ykr02|wk^1Pz&`_h?F7k+F`TElZ
z4u@xb=07LFZL+BT^?`-Y3-#6Z&ysWu`@FOKO#7y}H@_|aamT1>Rc*D)rjrjR^|~4r
zIxU>NjQMS?y1}mcJAWTa?EPz|^2Pb|sbvq9wp6Xj*Xvo$9A0`Xbg%#I{k7eh;YxlH
z<-v>JE_6C_`&ZGa-K*!t`<fTGfWiYU#LN`L;2j(zV^fd{P(YcOgBq`L&b|?@uD;q%
znI#ZyVW~xl!HIdrx<UE5iFuR5m0ScYj1_c^j7=2`jV#O+ER8HCpS4t&d|Jt$4cx2^
zn*5AKZgQNJ@Z<nxu~7WRfqGH;Zka{JCC(X%MGD47U;&>*DBsco%y-MrD{)CJPA<wU
zD9JBUFafpZotTU*Cx1}3nWUmKS-_f8%Fsx`%-BRB7NkKzKO{diFEcqmB~`)1bn<O$
zV@8w7{5Eoo7L)aC8W}AoZ?LgqGBud|#ztDg!otu*!2kpl@)Wp0w1I)4fu-eSd0Vx5
zb8~blO9L}YbTLCq0}L@EQ&5{9WE{d+V<ST&G`)r<mX-!+Vg|+*My6n~dIN-J6BA5@
zriNx_V1)>Eh889!7>+hHHa0|4XJBY*hGDUxg$0Uv^&s~f8Jc2fHZn9fMmNyN)DXjB
zBXbLM9~&517+?grv7rS<2pXH1)?+F(F-LJB$brTd1{ju@7?@e0JJ7@cGXzac%rG2n
zVr~rc98&O`n?m9Q5!42zhLaQRh3ic)W8c&SGr%oOFvG{f!~`R3EzC_ZoMd5cfe~4j
z#*m=!F+e!U(8SmnJ<JSEj7`zQ!qCJVi#l^t^U2x{D)r{(mgs?OXl`MI?gB##Lrg;~
z3^819XkmfjdP7SCLnQM`iV`z(Qj54iWp%JaW>u<!sR1Y>>j&lMmnfK6!UkOQJ@eA?
i6-+?gc5rXHxFoTtq@pM_jmyx|z|5FSRn^tsjSB#68O<~R
delta 2599
zcmdlsmvL1i;{@OOFz<XBbDn*#!#`xm>v%6(;hwiKR)ph1^KI5DgCYa7v)mhk)miV%
zkI!nm<Z<~;&h@iW$8_#r*?y&_CW!6S{q^>TpYCnszdz+F<Gje<ZU608@7|uUrLp|f
zVf_y*Wkvfm_@zCp->==ip+4Z?>l7XBQXfe<hZJ`!3#Kls1eTJ?SL>IbRJ$Z+@LI+r
zC3Ifw3Xe$@@lRJ6C-$1uMk)7sb)DPv#kjrq?7N4HfAQwAcC43wkhMH#21{MV^5&;@
zZ@#FeKTr6+K<|G14DM}*-|e-kuHE;0P2DYBkGuyeZ`GA8LM{E<b<>|s`+P^@dw9;y
zZIa6mpIh{(xU_NE`Ca0Mw_a{3u9uj<^R(urIIUHyR=hYjF?sWCi^wvgrBi3{JuE3@
z^0Vx*2(7fstJJYj-F)aIpTo)Zx(h>BrLSsMjJPSM<7wmFHFxQ{8B5hUWv%bAX;<ZH
zCf{*-{p`!iP51hfQ#pU{+;s4ZbHGunNTur+R~<|{5!-%Rsq}Jctd!CDMOn<(WU`X$
zh4yCsdC~ForJ7vRn<$0dt?H?=ElX@a%47)J#wh&v5q$Vs{)4s6D)rDSDH+E~%qDr?
z(MY&pH&eu^v8+z}(9`>jdHYt})-<o|of$hZz1=3lPO6ac(uvq@Os;P?AK&@^q}1Z?
z2QJDLU29RCAe(h$X<PCC<!tWqt0qp9;!UgkYFvNI=E3AmHfy<OH5E?0y&&Y)0UxGa
zvG?lMbG=H{G1b1ea<?(V+OI!v-<>`6+wJ+^&-WMf{ZYDMa8Ku0L{ED7a`7E;J&dQ*
zy-I3z1X=%`an0}hd2HJEcW)m4yZm_d+Pb*<<3DQtzg+Km_x{J}6ZQGub%kau5dFfu
zUSVAa>)n#>(Bk?6=A9-NP3ny=9dR(66sM~a{5qUnDzeRQf#med{Lhk&_4Gmmuk&~R
zebscVe|Pt36K8d)=|S>wN4I5#9Np95vE_}%q?oOu%f!qNuUA@q{>BfpEQvWAKC|U4
zzhJ!V>b`JM(QOtvH4@jf<)1Qcvtl-#b1hn)H(UN|^?a503Eh96)rVV8zEE=LU3-R>
zzr5Pq$rZEyxn40bD&4C!b@uDn*d4oKuRVL@wlA+p`RcOFHP#!pMXloS)(_wI(QIwU
zY`?^JOey#7@K(Qat5GbUe&GG&?WWwX7sju+`XP|3JxM69RC#;SkvoN}zXmLt8O8m6
z*O?NFkd3jTr{DjY6Cc&O`0he2|9AGrJD%G<U^l2Z-tB&J$7kD9+h;$yFZeysD6VVY
zgdX$o$;YnDzU?L%_m%(29%*r|)V!49lA_eaTo5ZiDT~WQ!9W2-D<~*f8e2|wW;s7u
zjg^nlcyhg`=wvTeH4$?YJ!3;7GYew{Lo-u7BNG!t6T`_ZtW!l{I&Ewe^nFtE(n~TF
z3{599a`{ZIVtdMHIyr$|bFwbm;>kK3yo@H3H*yJ2_T`YC9M8@(`85}(n4vk;Vr1<W
zlNq@dO}@a!KiP$I5~IcB>zo>sCvq$S8(}_qBbP3dq2=TUT%w`|n3|0Yp_&CI@8RCX
zXgIl?M{_bKH^_b-CL@E%8@cotjX;`3jIn5*>}aF3*`JM{k;%wpass>P<d1x!lUMRW
zbsIySFE#lVAMfPXTwJ1NSj;eoJK&JOCPwqgrGi?M`30axn1LN&0d{~Tre@<wT#F}P
zVB?z{DZHQ2V6vo$*5nmJP_33ApHCJS0olwcW^9B-xA9~~F2&7xq9xqAFyARCC>U8-
z8o=V&7)x{+gQ81zq65!l3&npDrciT18ja22`phN^dWcTmV<|bgM(H7=(d0Pgxr}C$
z7kD^L@-r=p|=GB}9K&JL~vOUxRBVpef-o+!uW`zi{;j24qD#6*p;goDW>F1d*g
zJexx;tQZ*$CQq;wV>E<1;1Hwv<a(<fM#ISqJPan=Sl?$dww#>rX{-S9agahRmx6+V
zzH@$QUWtMsl5<RqCLi)_oUCiZGuhuupUK2za)Xz&gsHKyg@OSHDC8+{foKB*LjzOe
z$(y~@>WvN2r7R5$jM2pmEle=Pj7-c;(A60mnwX)98JbucVX8AXwFIlHH$b?_!~|2J
zsiA=ZSRs-+LnAX&3^5Z+3`-0xj4<>X8Cam`tp^2%k)eS(x`9R}rWhe(WNwJ=I|Czg
z%)m7^G{OiiV`B@9NH8`rtjBPnvAHpZB_;+2M(7SSF~AHh6B7drN1K?LVR+8O%mNbp
z2K9*GH#IQFP-tq58SkdXn89yhj2T)M#^xwN4GL)sGfPwlg2Laz+z=z~ER7A(L&ng=
z$P7IQ4NZ(J(L=`2#0-l%bc+oP3{6c8OeR0~6<{$nH8z<X?<Z|zVgk-sLHYS53LuXw
o1cCXUd1?6yCZMtiocD`M5{pVIic-_K3{6cf%(+xmUH#p-06(W<`~Uy|
diff --git a/paper/figures/Spawn.svg b/paper/figures/Spawn.svg
index e58a69e..2b0eea7 100644
--- a/paper/figures/Spawn.svg
+++ b/paper/figures/Spawn.svg
@@ -95,7 +95,7 @@
<dc:format>image/svg+xml</dc:format>
<dc:type
rdf:resource="http://purl.org/dc/dcmitype/StillImage" />
- <dc:title></dc:title>
+ <dc:title />
</cc:Work>
</rdf:RDF>
</metadata>
@@ -581,5 +581,29 @@
id="tspan3358"
style="line-height:110.00000238%" /></text>
</g>
+ <text
+ xml:space="preserve"
+ style="font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:center;line-height:125%;letter-spacing:0px;word-spacing:0px;text-anchor:middle;fill:#000000;fill-opacity:1;stroke:none;font-family:Urania Czech;-inkscape-font-specification:Urania Czech"
+ x="36"
+ y="444.36218"
+ id="text3070"
+ sodipodi:linespacing="125%"><tspan
+ sodipodi:role="line"
+ id="tspan3072"
+ x="36"
+ y="444.36218"
+ style="-inkscape-font-specification:Bitstream Vera Sans;font-family:Bitstream Vera Sans;font-weight:normal;font-style:normal;font-stretch:normal;font-variant:normal;font-size:16px">a)</tspan></text>
+ <text
+ sodipodi:linespacing="125%"
+ id="text3074"
+ y="444.36218"
+ x="376"
+ style="font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:center;line-height:125%;letter-spacing:0px;word-spacing:0px;text-anchor:middle;fill:#000000;fill-opacity:1;stroke:none;font-family:Urania Czech;-inkscape-font-specification:Urania Czech"
+ xml:space="preserve"><tspan
+ style="font-size:16px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;font-family:Bitstream Vera Sans;-inkscape-font-specification:Bitstream Vera Sans"
+ y="444.36218"
+ x="376"
+ id="tspan3076"
+ sodipodi:role="line">b)</tspan></text>
</g>
</svg>
diff --git a/paper/figures/TaskWeight.pdf b/paper/figures/TaskWeight.pdf
index b8edb62d24e271a46c359007c321dc44863559ff..68138a3c630a68295aa440ec325bab856320e84b 100644
GIT binary patch
delta 1636
zcmX>WbvbH+e|=Ysxxn4m+FN{>V#7jT?&RfUbQYV;lajcH<L%6i&i-d^us#1=ToQWe
z?Yzc~yvs6oou3$@f7O})-6{JWQY%+Zzon7+X_80s7j|8h1@?D-?Eka>-ND>F*8*w}
zq_61;+duc&gkPSDok39_k5_+x^!~wnyI<n}RsWx^F5jBTb^E4$UH#|ei-xKHCEs}0
z{4ZP|_uJv%{=$p@-^ttL&*uN@zHmuffL8g*GgFHMa`d+TtUf<UQ_b{@R*2WfR*N?s
ziK)k4x?XV!UG;hSQIn-H(+&6z`n&$M_cIb%vQa?Eb*{SE1D~Y(7Gb_mGn0%nJPf1t
zZ7hFnf9GHSbY9`!2SO@`PGs$?4_CdmiQ`V9h{T%AV6#M#&-XZvYX;|W9y_aR8Pt_}
zQoAwBO~7~l!NuoWg`T_aIHR)5Pul3=@lM~rnMs@TPDyRE{(oZUdJgvI4mvM&<aieP
zmMg|6ot$~DHQb}8FmA%bvczqkAuBiOEEHPkw|lqq+am%^SHgcJ^)&zSaXh7$lvE#F
z6mv#y?oprU_JHlypHJMCTo@NM_w}}zDH}rzD?^UzXjO|&7dhJhxLQ*AoW{S;M(3&}
zze{<ZGLR_yvZE&X^oGx|lE%R`w~SAHe=j+6)`KRaL&me*WVZ1$?Nk27AwOxuN4`LQ
z)zjC^&Db(8aUGqu{g|Oy=8L*(szDEf-}N3WsrS2M?X3LFNb*k3gteJEf^EwuJw7)>
zb@^Pw;C7$wHaow3(O%`j6#R0hWwP?Yq6~pUdp93lS#VHPI(g3ZIcHDo^bGWxS=#Ah
z))QnjSNL#X$>n3EMjgJoQ<mxqa?hUhIO$xHv1Iqz2|JTMpSaxpi!t<z(bD}3Yqnjk
zcC*)=zbn0@J~7BcfQRGi8|hZ2Pz{F(-ofd?9*-~mlDgjY_3fJr!54LRc<i`xd0+X{
zGwbe5NZUHES4KIffy2mR;YHsQUbDXDJn0bO(tW4wF2ZcIOw(Vf?eHv%wrd9r_wWjA
z@9V2HQaxX3TzbCJ*mw5lV?6S+?i@0fHn=IU?0J>vT8X+{_vGt$FmYL>|H^#$FX)A)
zWf}jMr9m#<7rUl4EjTh~*9VTr!BJ;24ZY{iomufYG5Ev7bN_34{}=pf(ErqNG0Z6>
zaf`x>wX+0{W-mGaR#9fd#rXTX!tG`5*Z=wQ`1R}Q?;4Cwisnyep66l6nfLY=uUXB$
z%JT1JIX}Nvo!^|UZn`z(o4Wt)hTXy9Zr%%87G6w9*m!p5!!;szZ|S|#zNMwGsL|W4
zRpp9eo!4y#=Tmb}zr0@kd-84`4(^9rFS%zO+%F?6m+XJ&<IB5$&wlxO>M#E*KkM|#
z+$?fT=Ejq?S-x|cndq5Y7#bLuZPsFSRu!`_S1<qpg**i=5N%*!XkcMJxmioC-pmwT
z%E-XX3`5Mq!T?>&*xV39or$S2hB{M26C*Ueh6aXa#$d5}10**YVLHap#L@(;5J{bp
zfeA!2vY4@f1%^6fOve~mn4*M5Jt#Pg4UN!UXkct;f?=_-nI(qB#+IfS78_e)hL(w`
z0gA;Sdri#E>oF`gF~{_=siC1Iy6;SlEifEtYGQy9C6*@U7<w&D4WJ(JLIl61g{dLB
mC6*TE=$057n3+N~!}S^(m|GZ6ey`)lX>7)&s_N?R#svWQ|88Ue
delta 1623
zcmcZ{bu4Ove|=Vnqrlzo;a`GUGk34LA061z(EXyJ`+?Ij6)j;^w+rXLm)w7~%UHNW
zP{k+h)tz<0{p*hJHGTf=TFCpFjWM&m6(jxhj%1iGw8%U7Z^xGRZ_SId+2mHOzxFu4
z^3=jx>*i*A#ZH!W*IRqzZg1tki??4}|Nc|HNq_(B&xt4b?`~iJw*J$F38%k_UofuO
zH>;apEauzf&TqYYx0>+f{|aAmG4#Fn(sMo{F^#G3y>h=D6PoO;+vO7zvpAz$dB2xP
z?CA?(3)I4QO6?9`!a9BRq>10lq+ab`_;O*;=?PLrQ#Y^BX%h6BGi7;Fv3=@CkBlR?
z7e|zR+gzD`{w(uB@%Kr71)IIT)GxKtb7Yk9<J_ajn;qPv^N~A2BXxRoQ~76)W92%h
z*qu$CMXHtF<)lp))=oGe{K59>a*Z$6tVf#nGCg|uB>Io}H<bhKOIm`8=KNGppTg{A
zrRB79XTb!~siwM35~o*uK6<{g!?|E;gr{YdJENq~=3q8Y9ld1+g3Jvv3!SDUovKet
zS$<-coa?gn+$$rSEji26R+vi^9(XJJebbgA%gj`nr(36bcg+>N#lE-4B$-L(TTxu~
zPIE80d53u;eqP_H`0K8O;LeKrf+_#)EhIK`nYYdMUF^4FXH*8$5y_R?V+yR71i7|5
zWiEF(+`45?PhTU;{p2-X;vPZD-<I7;_b8cDzes68mZfBB#FNZL{X&dKI`=X?TKvJ2
zVY#5)vdSno`F2xvo>MVXnojl~5^2`T3S)8PvFz^u9H6ma(Sj)}n63wCU4AxYqPWN!
zcU6w2r1d<T)`)0zPn@fioh35yj?Nsn{O=Z*7H>QFVO6q+?3GXUU(N=^d;hGve`V_w
zL5DN8>o3-~Hi#OfonqU|6Seiq#V41Gvj0k6?RxH9zA<?7=a3unw=@6mPJL!_jH{WO
z{k0oIq+HK0Ux|X?BVpW@GHaxdP5K(KdRLxBg7q<zpAy0SrMEkloOXMXS}bvOs;|+`
z((68-cV#cDF21gFZvAezrkSdZXWK$-ub7yw%a>nk71MH}x_;{KY^U`nHTM6z)ZP;~
zsj9o>;ia<?N|LEI6Za}zp0vWJu)^*|eavm~=s$ToKKcG{m-@8!dS0r4(e4g0SElV6
zb65A?e-L^+Z~d90lka}tJ>TCx=lq#AA-AHhdwB~IRawt$eXB0>v-IcFU!RL!TrFF>
zseRMY$5q#^Z&h4ZC~L{L+gWnn){lKAeBV`HxKCVA@u17bId5VgkH!~m-W?BIGY%y_
zN!WjNb^0?C<z&IB_dM^hp1=3`Z^@rOMa7oNw&wK=@3U<9CX2JkF_{@oHfQ<HVQQ*p
zY;101y4jr7Syjy3M8N<A6!H|fK(v8@p@F&S<Oy18^`^$?Qbq<?#4OCr(bXB78(`=)
zF*U?cXKH9<iKf@kz|hnHELLxT<R&9biw#XI48aPK)EOBVLo_3c8CjZQs58cNjFE*2
zN?6o`g2UL*0NsTK#)ifi78{#cU|4KyX@X&~u_b0`nV49jSPZh)#N4zV!(tP2Odp#X
z8knK`&eYf(!-1y8mKafDX<~+<*V4oi>JcwQ@LO6KTcBHFX<>$LiJ^g+2~;y&uc3jt
UxxwT=I)0o+#$2kZuKsRZ00T*13;+NC
diff --git a/paper/figures/TaskWeight.svg b/paper/figures/TaskWeight.svg
index b958867..4393ed8 100644
--- a/paper/figures/TaskWeight.svg
+++ b/paper/figures/TaskWeight.svg
@@ -14,7 +14,7 @@
id="svg5074"
version="1.1"
inkscape:version="0.48.4 r9939"
- sodipodi:docname="New document 10">
+ sodipodi:docname="TaskWeight.svg">
<defs
id="defs5076">
<marker
@@ -112,7 +112,7 @@
<dc:format>image/svg+xml</dc:format>
<dc:type
rdf:resource="http://purl.org/dc/dcmitype/StillImage" />
- <dc:title></dc:title>
+ <dc:title />
</cc:Work>
</rdf:RDF>
</metadata>
@@ -215,26 +215,28 @@
xml:space="preserve"
style="font-size:12px;font-style:normal;font-variant:normal;font-weight:bold;font-stretch:normal;text-align:center;line-height:125%;letter-spacing:0px;word-spacing:0px;text-anchor:middle;fill:#000000;fill-opacity:1;stroke:none;font-family:Bitstream Vera Sans;-inkscape-font-specification:Bitstream Vera Sans Bold"
x="-371.12311"
- y="474.59158"
+ y="478.59158"
id="text5713"
sodipodi:linespacing="125%"
transform="matrix(0,-1,1,0,0,0)"><tspan
sodipodi:role="line"
id="tspan5715"
x="-371.12311"
- y="474.59158">cost</tspan></text>
+ y="478.59158"
+ style="font-size:20px">cost</tspan></text>
<text
xml:space="preserve"
style="font-size:12px;font-style:normal;font-variant:normal;font-weight:bold;font-stretch:normal;text-align:center;line-height:125%;letter-spacing:0px;word-spacing:0px;text-anchor:middle;fill:#000000;fill-opacity:1;stroke:none;font-family:Bitstream Vera Sans;-inkscape-font-specification:Bitstream Vera Sans Bold"
x="-547.51123"
- y="529.49603"
+ y="533.49603"
id="text5717"
sodipodi:linespacing="125%"
transform="matrix(0,-1,1,0,0,0)"><tspan
sodipodi:role="line"
id="tspan5719"
x="-547.51123"
- y="529.49603">weight</tspan></text>
+ y="533.49603"
+ style="font-size:20px">weight</tspan></text>
<path
style="fill:none;stroke:#000000;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;marker-end:url(#Arrow2Lend)"
d="m 228.0315,308.26769 0,478.34646"
@@ -251,6 +253,7 @@
sodipodi:role="line"
id="tspan6101"
x="-547.64691"
- y="222.03149">time</tspan></text>
+ y="222.03149"
+ style="font-size:20px">time</tspan></text>
</g>
</svg>
diff --git a/paper/paper.tex b/paper/paper.tex
index c4ea1fc..ce53b3f 100644
--- a/paper/paper.tex
+++ b/paper/paper.tex
@@ -90,8 +90,8 @@ Task dependencies are used to model the flow of data between
tasks, e.g.~if task $B$ requires some data generated by task $A$,
then task $B$ {\em depends} on task $A$ and cannot be executed
before task $A$ has completed.
-The tasks and their dependencies can be seen as the nodes and edges
-of a Directed Acyclic Graph (DAG) which can be
+The tasks and their dependencies can be seen as the nodes and edges,
+respectively, of a Directed Acyclic Graph (DAG) which can be
traversed in topological order, executing the tasks at the nodes
on the way down.
@@ -172,7 +172,7 @@ imperative that the execution of both tasks do not overlap,
yet the order in which the tasks are executed is irrelevant.
In the following, such a relationship will be referred to
as a {\em conflict} between two tasks.
-\fig{TaskConflicts} shows a task graph with conflicting tasks
+\fig{TaskConflicts} shows a task graph extended by conflicting tasks
joined by thick dashed lines.
None of tasks $F$, $H$, and $I$ can be executed concurrently,
i.e. they must be serialized, yet in no particular order.
@@ -180,8 +180,8 @@ i.e. they must be serialized, yet in no particular order.
In dependency-only systems, such conflicts can be modelled
with dependencies, which enforce a pre-determined arbitrary
ordering on conflicting tasks.
-This unnecessary restriction on the order
-in which tasks can be scheduled can severely limit the
+This artificial restriction on the order
+in which tasks can be scheduled can, however, severely limit the
parallelizability of a computation, especially in the presence
of multiple conflicts per task.
Both \cite{ref:Ltaief2012} and \cite{ref:Agullo2013} note
@@ -193,14 +193,14 @@ This paper presents QuickSched, a framework for task-based
parallel programming with constraints, which aims to achieve
the following goals:
\begin{itemize}
- \item {\em Correct}: All constraints, i.e.~dependencies and
+ \item {\em Correctnes}: All constraints, i.e.~dependencies and
conflicts, must be correctly enforced,
- \item {\em Fast}: The overheads associated with task management
+ \item {\em Speed}: The overheads associated with task management
should be as small as possible,
- \item {\em Memory/cache-efficient}: Tasks accessing similar
+ \item {\em Memory/cache efficiency}: Tasks accessing similar
sets of data should be preferentially executed on the
same core to preserve memory/cache locality as far as possible, and
- \item {\em Parallel-efficient}: Tasks should be executed in an order
+ \item {\em Parallel efficiency}: Tasks should be executed in an order
that sufficient work is available for all computational
threads at all times.
\end{itemize}
@@ -237,40 +237,30 @@ directions.
\section{Design Considerations}
-\begin{itemize}
- \item Two flavours of dependency generation: Through spawning as in Cilk,
- or automatically as per QUARK, OmpSS, etc...
- \item Limitation of spawning with complex task hierarchies.
- \item Limitation of dependency guessing is sometimes over-protective dependencies.
- \item We let the user define dependencies explictly.
- \item Con: Some effort needed to get dependencies right,
- \item Pro: All dependencies known at the start of a computation, better
- scheduling decisions can be made (see QR).
- \item A word on task granularity...
-\end{itemize}
-
From a programmer's perspective, there are two main paradigms for generating
task dependencies:
\begin{itemize}
- \item Implicitly via spawning and waiting, e.g.~as is done in Cilk, or
- \item Automatic extraction from data dependencies, e.g.~as is done in OmpSs.
+ \item Implicitly via spawning and waiting, e.g.~as is done in Cilk
+ \cite{ref:Blumofe1995}, or
+ \item Automatic extraction from data dependencies, e.g.~as is done in OmpSs
+ \cite{ref:Duran2011}.
\end{itemize}
The first scheme, spawning and waiting, is arguably the simplest to
use.
For simple depedency structures in which each task depends on only a
single task, i.e.~if the task DAG is a tree, each task {\em spawns}, or
-creates, its dependent tasks after its completion (see \fig{Spawn}).
+creates, its dependent tasks after its completion (see \fig{Spawn}a).
Hence for the tasks $A$--$E$ in \fig{Tasks}, task $A$ would spawn
tasks $B$ and $D$, task $B$ would spawn task $C$, and task $D$ would
spawn task $E$.
If a task has more than one dependency, e.g. tasks $D$--$F$ in \fig{Tasks},
then the task generation order is reversed: Task $E$ is executed first,
and first spawns tasks $D$ and $F$, and waits for both their completion
-before doing its own computations.
+before doing its own computations (see \fig{Spawn}b).
Although simple to use, this implicit dependency management
-limits the types of DAGs that can be represented, i.e.~for
+limits the types of DAGs that can be represented, e.g.~for
all the tasks in \fig{Tasks}, using such a spawning and waiting model
would create implicit dependencies between the lowest-level
tasks $C$, $E$, and $K$.
@@ -298,12 +288,13 @@ These data dependencies are provided explicitly by the programmer, e.g.~by
describing which parameters to a task are input, output, and input/output.
The dependencies are enforced in the order in which the tasks are
created.
-This approach usually relies on compiler extensions, e.g.~ {\tt pragma}s
+This approach usually relies on compiler extensions, e.g.~{\tt pragma}s
in C/C++, or a system of function call wrappers, to describe the task parameters
and their intent.
This approach allows programmers to specify rich dependency hierarchies
-with very little effort, they still only allow for one type of relationship,
+with very little effort, i.e.~without having to explicitly think about
+dependencies at all, yet they still only allow for one type of relationship,
i.e.~dependencies, and lack the ability to deal with conflicts as
described in the previous section.
They may also not be able to understand more complex memory access patterns,
@@ -319,22 +310,23 @@ This approach has two main advantages:
\begin{itemize}
\item It gives the user maximum flexibility with regards to the
structure of the task graph generated,
- \item Knowing the structure of the task graph before execution
+ \item Knowing the complete structure of the task graph before execution
allows the task scheduler to make more informed decisions
as to how the tasks should be prioritized.
\end{itemize}
\noindent The obvious disadvantage is the burden of producing a correct
-task graph is placed on the user.
+task graph is placed on the programmer.
Although some problems such as cyclic dependencies can be detected
automatically, there is no automatic way to detect whether the
-dependencies actualy reflect the intent of the user.
+dependencies actualy reflect the intent of the programmer.
Due to this added complexity, we consider QuickSched to be
a tool not designed for casual parallel programmers, but for
-those interested in investing more programming effort to achieve
+those interested in investing a bit more programming effort to achieve
better performance.
-Conflicts between tasks or groups of tasks are not specified directly,
+As opposed to the dependencies,
+conflicts between tasks or groups of tasks are not specified directly,
but are instead modeled as exclusive locks on a shared resource
which have to be obtained by a task before it can execute.
Thus, in \fig{TaskConflicts}, before executing, task $F$ has
@@ -344,8 +336,8 @@ While task $F$ is being executed, neither $H$ nor $I$ can
lock the same resource, and therefore will not execute until
task $F$ is done and the lock has been released.
-The partitioning of the computation into tasks is also left entirely
-to the user.
+As with all other task-based libraries, the partitioning of the
+computation into tasks is also left entirely to the programmer.
In theory, any program can be automatically converted to a task-based
representation since each statement in the program code
can be considered a single task, with dependencies to the
@@ -356,8 +348,9 @@ of graph algorithms.
The decomposition of a computation into tasks, however, usually
involves re-thinking the underlying algorithms such that they
best fit the task-based paradigm, e.g.~as in the examples in the
-following sections, or as in \cite{ref:Gonnet2014}.
-This process requires careful evaluation and is probably best
+following sections, or as in \cite{ref:Gonnet2014,ref:Buttari2009,ref:Ltaief2012}.
+This process requires careful evaluation of the underlying
+computation, and is probably best
not left as an automatic transformation of an otherwise serial code.
Finally, the task granularity is an important issue: if the task
@@ -387,7 +380,6 @@ cache efficiency of the computation.
The QuickSched task scheduler consist of four main
objects types: {\em task}, {\em resource}, {\em scheduler},
and {\em queue}.
-
The task and resource objects are used
to model the computation, i.e. the work that is to be done
and the data on which it will be done, respectively.
@@ -438,10 +430,8 @@ The scheduler is in charge of selecting the most appropriate
queue for each task, based on information stored in each task
on which resources are used.
Given a set of tasks with similar resources for which all
-dependencies are resolved, the queue then decides which
+dependencies are resolved, it is up to the queue to decide which
tasks to prioritize.
-This decision is made based on the length of the critical
-path of the dependencies of each task.
The following subsections describe these four object types
in detail, as well as their operations.
@@ -510,7 +500,7 @@ as per \cite{ref:Kahn1962}, and computing each task's weight
up the task DAG.
\begin{figure}
- \centerline{\epsfig{file=figures/TaskWeight.pdf,height=0.3\textwidth}}
+ \centerline{\epsfig{file=figures/TaskWeight.pdf,height=0.4\textwidth}}
\caption{Computation of the task weight.
In this task graph, the height of each task corresponds to its
computational {\em cost}.
@@ -624,8 +614,8 @@ has been locked (line~5).
In lines~9--10 the hold counters of the hierarchical parents
are incremented using the procedure described earlier.
If this process fails at any point (line~11), the
-previously set hold counters are decremented (line~12)
-and the lock is released (line~13).
+previously set hold counters are decremented (line~13)
+and the lock is released (line~14).
The procedure then returns {\tt 1} or {\tt 0} if the resource
could be locked or not, respectively.
@@ -637,7 +627,8 @@ resource hierarchy are decremented.
\subsection{Queues}
The main job of the task queues is, given a set of ready tasks,
-to find the task with maximum weight whose resources can all
+to find the task with maximum weight, i.e.~the task along the
+longest critical path, whose resources can all
be locked, and to do so as efficiently as possible.
One possible strategy would be to maintain an array of tasks
@@ -656,16 +647,20 @@ organized as a max-heap, i.e.~where the $k$th entry is ``larger''
than both the $2k+1$st and the $2k+2$nd entry,
with the task with maximum weight
in the first position.
-Maintaining this heap structure thus requires \oh{\log n}
+Maintaining this heap structure requires \oh{\log n}
operations for both insertion and deletion, i.e. for the
bubble-up and trickle-down operations respectively.
-The array of tasks is then traversed as if it were sorted,
+Unfortunately, there is no way of efficiently traversing all
+the elements in the heap in decreasing order.
+The array of tasks is therefore traversed as if it were sorted,
returning the first task that can be locked.
Although the first task in the array will be the task with
maximum weight, the following tasks are only loosely ordered,
where the $k$th of $n$ tasks has a larger weight than at least
$\lfloor n/k\rfloor -1$ other tasks.
+Although this is not a particularly good lower bound, it turns
+out to be quite sufficient in practice.
The data structure for the queue is defined as follows:
\begin{center}\begin{minipage}{0.9\textwidth}
@@ -736,6 +731,14 @@ and the heap order is restored (line~17).
Finally, the queue lock is released (line~19) and the locked task
or, if no lockable task could be found, {\tt NULL} is returned.
+Note that this approach of sequentially locking multiple resources
+is prone to the so-called ``dining philosophers'' problem, i.e.~if
+two tasks attempt, simultaneously, to lock the resources $A$ and $B$;
+and $B$ and $A$, respectively, via separate queues, their respective calls
+to {\tt queue\_get} will potentially fail perpetually.
+This type of deadlock, however, is easily avoided by sorting the
+resources in each task according to some global creiteria, e.g.~the
+resource ID or the address in memory of the resource.
\subsection{Scheduler}
@@ -784,7 +787,8 @@ for most compilers, is used to create a parallel section
in which the code between lines~4 and~11 is executed
concurrently.
A version using {\tt pthreads} \cite{ref:Pthreads1995}
-directly is also available.
+directly\footnote{In most environments, OpenMP is implemented
+on top of {\tt pthreads}, e.g. gcc's libgomp.} is also available.
The parallel section consists of a loop (lines~7--10) in
which a task is acquired via {\tt qsched\_gettask}
and its type and data are passed to a user-supplied
@@ -806,24 +810,25 @@ the resources used and locked by the task, e.g.:
\begin{center}\begin{minipage}{0.9\textwidth}
\begin{lstlisting}
void qsched_enqueue(qsched *s, struct task *t) {
- int k, qid, score[s->nr_queues];
- for (k = 0; k < s->nr_queues; k++)
+ int best = 0, score[s->nr_queues];
+ for (int k = 0; k < s->nr_queues; k++)
score[k] = 0;
- for (j = 0; j < t->nr_locks; j++)
- score[t->locks[j]->owner] += 1;
- for (j = 0; j < t->nr_uses; j++)
- score[t->uses[j]->owner] += 1;
- for (qid = 0, k = 1; k < s->nr_queues; k++)
- if (score[k] > score[qid])
- qid = k;
- queue_put(&s->queues[qid], t);
+ for (int k = 0; k < t->nr_locks; k++) {
+ int qid = t->locks[k]->owner;
+ if (++score[qid] > score[best]) best = qid;
+ }
+ for (int k = 0; k < t->nr_uses; k++) {
+ int qid = t->uses[k]->owner;
+ if (++score[qid] > score[best]) best = qid;
+ }
+ queue_put(&s->queues[best], t);
}
\end{lstlisting}
\end{minipage}\end{center}
\noindent where the array {\tt score} keeps a count of the
task resources ``owned'', or last used, by each queue.
-In lines~9--11 the queue with the highest such score is
-chosen on which the task is then put (line~12).
+The task is then sent to the queue with the highest such score
+(line~13).
The function {\tt qsched\_gettask} fetches a task from
one of the queues:
@@ -876,9 +881,9 @@ Once all the dependent tasks have been unlocked, the
\section{Validation}
-This section presents two test cases showing
+This section presents two test cases that show
how QuickSched can be used in real-world applications, and
-providing benchmarks to assess its efficiency and scalability.
+provides benchmarks to assess its efficiency and scalability.
The first test is the tiled QR decomposition originally
described in \cite{ref:Buttari2009}, which has been used as a benchmark
by other authors \cite{ref:Agullo2009b,ref:Badia2009,ref:Bosilca2012}.
@@ -897,8 +902,7 @@ QuickSched library, along with scripts to run the benchmarks
and generate the plots used in the following.
All examples were compiled with gcc v.\,4.8.2 using the
{\tt -O2 -march=native} flags and run on
-a 64-core AMD Opteron 6376 machine running
-at 2.67\,GHz.
+a 64-core AMD Opteron 6376 machine at 2.67\,GHz.
\subsection{Task-Based QR Decomposition}
@@ -990,6 +994,13 @@ the DGEQRF tasks (in red) are scheduled as soon as they
become available in QuickSched, thus preventing bottlenecks
near the end of the computation.
+Since in QuickSched the entire task structure is known explicitly
+in advance, the scheduler ``knows'' that the DGEQRF tasks all
+lie on the longest critical path and therefore executes them as
+soon as possible.
+OmpSs, does not exploit this knowledge, resulting in the less efficient
+scheduling seen in \fig{QRTasks}.
+
\begin{figure}
\centerline{\epsfig{file=figures/QR_scaling.pdf,width=0.9\textwidth}}
\caption{Strong scaling and parallel efficiency of the tiled QR decomposition
--
GitLab