Fixed for the release. Thanks for the clear report. The problem was
specific to the forms you mentioned. Workaround: use
< @: ((+/) @:]) instead of < @: (+/) @:]
The form <@:f is given special treatment. Your form was incorrectly
being given that treatment.
If t. in cut is not meeting your expectations, perhaps you should adjust
your expectations. Verbs like (+/) will not benefit from threading in
most cases, and may slow down considerably. +/;.0 might be even worse.
Why? Because +/ is totally limited by the speed of reading from
memory. If the data fits in level-2 data cache (D2$) many cores are no
faster than one.
In fact they are much slower, because only one core has the data in
D2$. The rest have to transfer the data from the bottom of the ocean
(i. e. from the core with the data through D3$) or from the moon
(SDRAM). They are spending their time waiting for responses from memory.
+/;.0 creates a virtual block for each section and passes that to +/ .
There is no need to move the data except for the reading required by +/
. If you run the +/ in a thread, the virtual block must be realized
with an explicit copy from the bottom of the ocean. That doesn't add
much, because once the copy is made the data will be in D2$ of the
receiving core, but it is a small slowdown.
A thread needs to be able to run in its own core until it has done
reads+writes to D1$/D2$ at least, say, 100 times the size of its
arguments+result. +/ . * is a perfect example. On large matrices the
arguments are cycled through repeatedly.
Henry Rich
On 1/25/2023 7:08 AM, vadim wrote:
Hi, please consider this:
((0,:2),:(2,:2)) (< @: +: @: ]);.0 i. 4
+---+---+
|0 1|2 3|
+---+---+
((0,:2),:(2,:2)) (< @: (+/) @: ]);.0 i. 4
+---+---+
|0 1|2 3|
+---+---+
((0,:2),:(2,:2)) (< @: (\:~) @: ]);.0 i. 4
+---+---+
|0 1|2 3|
+---+---+
No issues in 8.07; and a bug (that's what I'd call it) in 9.03 and 9.04.
Looks like it happens if the left arg has multiple ranges; and a verb to
apply is composed with "same" and "box" verbs as first and last in
sequence. But it's at 1st glance only. Sometimes omitting parentheses would
help (which clearly means parsing issue?). All these produce expected
output:
(2,:2) (< @: +: @: ]);.0 i. 4
+---+
|4 6|
+---+
((0,:2),:(2,:2)) (] @: +: @: ]);.0 i. 4
0 2
4 6
((0,:2),:(2,:2)) (< @: +/ @: ]);.0 i. 4
+-+-+
|1|5|
+-+-+
(0,:2) (< @: (\:~) @: ]);.0 i. 4
+---+
|1 0|
+---+
((0,:2),:(2,:2)) (] @: (\:~) @: ]);.0 i. 4
1 0
3 2
((0,:2),:(2,:2)) (< @: (\:~));.0 i. 4
+---+---+
|1 0|3 2|
+---+---+
While "why would you want to use the ']' here?" would be reasonable to ask,
but, in the end, syntax is either correct or not. In fact, I was testing
all kinds of different constructs investigating why multi-threaded
operation (with "t.") on subarrays is so much slower than expected,
although it's perhaps totally unrelated to what's discovered above.
Best regards,
Vadim
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
