I have some questions regarding the use of peach and memory writes.Consider the following code.q:q)c:0q)m:{raze string 100000{md5 raze string x}/x}q)f:{show (string x)," “,(string c),” “,m x}q)f peach til 5;q)g:{c+:1;show (string x),” “,(string c),” ",m x}q)g peach til 5;The output from “q code.q -s 3” is:"2 0 76434926f6ba1addfdfc06d2df677021"“0 0 50126c94dc7987d9d4bc823e6967cc2d”"1 0 65d485bbd7574038653525a057a96f40"“3 0 f2699f60c6f3637e29e770b1c1aca88b”"4 0 6326abeaf482cda2e9529a4b847b1238"Segmentation faultThe first 5 lines of output suggest that several threads weresimultaneously running since 2,0,1,3,4 is out of order. The segfaultis probably caused by threads simultaneously writing to the samememory location of c.Is there any way I can update c without causing the segfault? (In myactual application, c is a function implementing a large memoizationtable so I need to update it as the computation proceeds.) Onepossible way is perhaps to maintain c in a separate non-threaded qprocess listening on some TCP port. Then the multi-threaded part ofthe code can access and update it via IPC. Are there better ways ofachieving this?SH
X-Mailer: Apple Mail (2.929.2)latest version shows the following# l32/q test.q -s 5KDB+ 2.5 2008.12.31 Copyright (C) 1993-2008 Kx Systemsl32/ 2()core 7687MB xxx xxxxx xxxxx PLAY 2009.03.31"0 0 50126c94dc7987d9d4bc823e6967cc2d""1 0 65d485bbd7574038653525a057a96f40""2 0 76434926f6ba1addfdfc06d2df677021"“3 0 f2699f60c6f3637e29e770b1c1aca88b”“4 0 6326abeaf482cda2e9529a4b847b1238"k){x’:y}'noupdate@{c+:1;show (string x),” “,(string c),” “,m x}':0 1 2 3 4q))exit 0Currently you can’t do peach and memory writes.On Dec 29, 2008, at 6:58 PM, Swee Heng wrote:>> I have some questions regarding the use of peach and memory writes.> Consider the following code.q:> q)c:0> q)m:{raze string 100000{md5 raze string x}/x}> q)f:{show (string x),” “,(string c),” “,m x}> q)f peach til 5;> q)g:{c+:1;show (string x),” “,(string c),” ",m x}> q)g peach til 5;>> The output from “q code.q -s 3” is:> “2 0 76434926f6ba1addfdfc06d2df677021”> “0 0 50126c94dc7987d9d4bc823e6967cc2d”> “1 0 65d485bbd7574038653525a057a96f40”> “3 0 f2699f60c6f3637e29e770b1c1aca88b”> “4 0 6326abeaf482cda2e9529a4b847b1238”> Segmentation fault>> The first 5 lines of output suggest that several threads were> simultaneously running since 2,0,1,3,4 is out of order. The segfault> is probably caused by threads simultaneously writing to the same> memory location of c.>> Is there any way I can update c without causing the segfault? (In my> actual application, c is a function implementing a large memoization> table so I need to update it as the computation proceeds.) One> possible way is perhaps to maintain c in a separate non-threaded q> process listening on some TCP port. Then the multi-threaded part of> the code can access and update it via IPC. Are there better ways of> achieving this?>> SH
I don’t find “peach” in the index of “Q For Mortals”.
Is this a non-documented capability or something available only to licensed clients?
https://code.kx.com/trac/wiki/Reference/peachpeach - parallel eachit’s available in the non-commercial version too, at least the latest releaseOn Jan 9, 2009, at 7:11 PM, Tom Szczesny wrote:> I don’t find “peach” in the index of “Q For Mortals”.> Is this a non-documented capability or something available only to > licensed clients?>> On Fri, Jan 9, 2009 at 8:13 AM, Charles Skelton,Kx > wrote:>> latest version shows the following>> # l32/q test.q -s 5> KDB+ 2.5 2008.12.31 Copyright (C) 1993-2008 Kx Systems> l32/ 2()core 7687MB xxx xxxxx xxxxx PLAY 2009.03.31>> “0 0 50126c94dc7987d9d4bc823e6967cc2d”> “1 0 65d485bbd7574038653525a057a96f40”> “2 0 76434926f6ba1addfdfc06d2df677021”> “3 0 f2699f60c6f3637e29e770b1c1aca88b”> “4 0 6326abeaf482cda2e9529a4b847b1238”> k){x’:y}> ‘noupdate> @> {c+:1;show (string x)," “,(string c),” ",m x}’:> 0 1 2 3 4> q))exit 0>> Currently you can’t do peach and memory writes.>> On Dec 29, 2008, at 6:58 PM, Swee Heng wrote:>> >> > I have some questions regarding the use of peach and memory writes.> > Consider the following code.q:> > q)c:0> > q)m:{raze string 100000{md5 raze string x}/x}> > q)f:{show (string x)," “,(string c),” “,m x}> > q)f peach til 5;> > q)g:{c+:1;show (string x),” “,(string c),” ",m x}> > q)g peach til 5;> >> > The output from “q code.q -s 3” is:> > “2 0 76434926f6ba1addfdfc06d2df677021”> > “0 0 50126c94dc7987d9d4bc823e6967cc2d”> > “1 0 65d485bbd7574038653525a057a96f40”> > “3 0 f2699f60c6f3637e29e770b1c1aca88b”> > “4 0 6326abeaf482cda2e9529a4b847b1238”> > Segmentation fault> >> > The first 5 lines of output suggest that several threads were> > simultaneously running since 2,0,1,3,4 is out of order. The segfault> > is probably caused by threads simultaneously writing to the same> > memory location of c.> >> > Is there any way I can update c without causing the segfault? (In my> > actual application, c is a function implementing a large memoization> > table so I need to update it as the computation proceeds.) One> > possible way is perhaps to maintain c in a separate non-threaded q> > process listening on some TCP port. Then the multi-threaded part of> > the code can access and update it via IPC. Are there better ways of> > achieving this?> >> > SH>>>>> >–Apple-Mail-1992–184824812Content-Type: text/htmlhttps://code.kx.com/trac/wiki/Reference/peach
I don't find "peach" in the index of "Q For Mortals".
Is this a non-documented capability or something available only to licensed clients?On Fri, Jan 9, 2009 at 8:13 AM, Charles Skelton,Kx <charlie@kx.com> wrote:
latest version shows the following
# l32/q test.q -s 5
KDB+ 2.5 2008.12.31 Copyright (C) 1993-2008 Kx Systems
l32/ 2()core 7687MB xxx xxxxx xxxxx PLAY 2009.03.31
"2 0 76434926f6ba1addfdfc06d2df677021"
"0 0 50126c94dc7987d9d4bc823e6967cc2d"
"1 0 65d485bbd7574038653525a057a96f40"
"3 0 f2699f60c6f3637e29e770b1c1aca88b"k){x':y}
"4 0 6326abeaf482cda2e9529a4b847b1238"
'noupdate
@
{c+:1;show (string x)," ",(string c)," ",m x}':
0 1 2 3 4
q))exit 0
Currently you can't do peach and memory writes.
On Dec 29, 2008, at 6:58 PM, Swee Heng wrote:
>
> I have some questions regarding the use of peach and memory writes.
> Consider the following code.q:
> q)c:0
> q)m:{raze string 100000{md5 raze string x}/x}
> q)f:{show (string x)," ",(string c)," ",m x}
> q)f peach til 5;
> q)g:{c+:1;show (string x)," ",(string c)," ",m x}
> q)g peach til 5;
>
> The output from "q code.q -s 3" is:
> "2 0 76434926f6ba1addfdfc06d2df677021"
> "0 0 50126c94dc7987d9d4bc823e6967cc2d"
> "1 0 65d485bbd7574038653525a057a96f40"
> "3 0 f2699f60c6f3637e29e770b1c1aca88b"
> "4 0 6326abeaf482cda2e9529a4b847b1238"
> Segmentation fault
>
> The first 5 lines of output suggest that several threads were
> simultaneously running since 2,0,1,3,4 is out of order. The segfault
> is probably caused by threads simultaneously writing to the same
> memory location of c.
>
> Is there any way I can update c without causing the segfault? (In my
> actual application, c is a function implementing a large memoization
> table so I need to update it as the computation proceeds.) One
> possible way is perhaps to maintain c in a separate non-threaded q
> process listening on some TCP port. Then the multi-threaded part of
> the code can access and update it via IPC. Are there better ways of
> achieving this?
>
> SH