(". , ".) has the same issues as 7!:2 did. That is necessary because the
result of the sentence is used.
7!:2 per se doesn't affect the speed of the sentence it executes; but
the time a sentence takes depends greatly on the state of the caches,
including branch predictors. If you execute a sentence twice, it will
run faster the second time. To get a true idea of how long a sentence
will take in your system, you have to use the J Performance Monitor or
take great care in measurement.
Henry Rich
On 10/22/2021 12:42 AM, Ben Gorte wrote:
Perhaps I'm getting too involved, but I noticed something else, which might
be related:
$(".) 'b=:1 (2 3 4) } b' NB. Elijah's b
1000000000
executes instantaneously, whereas:
$(". , ".) 'b=:1 (2 3 4) } b'
2000000000
takes about half a second (estimated).
Apparently there is no relation with 7!:2, which means my previous mail was
incorrect. Sorry about that.
Ben
On Fri, 22 Oct 2021 at 09:46, Ben Gorte <[email protected]> wrote:
Yesterday I was a bit surprised here that with (6!:2 , 7!:2) Elijah's
problem shows up, but with (7!:2, 6!:2) it does not. Also after Henry's
deep explanation I don't understand why it is like this, but okay, it's
solved in the next beta. The impression remains that somehow 6!:2 and/or
7!:2 influence the way the sentence is executed, and one might argue that
this is not really desirable (Heisenberg strikes back).
On a related note: casual users of verbs in the standard library may not
be aware that timespacex executes the sentence twice, and will only find
out the hard way in case their sentences have side effects. Perhaps a
warning in the wiki could be helpful.
On Fri, 22 Oct 2021 at 03:08, Henry Rich <[email protected]> wrote:
Solved, and fixed for next beta.
This is deep but I know Elijah likes it that way.
(7!:2 , 7!:2 , 7!:2 , 7!:2 , 7!:2 , 7!:2) 'b =: 1 (2 3 4)} b'
1408 1408 1408 1408 1073743328 1408
The problem is in the usecount of b. It starts at 1, as is fitting for
a value assigned to a name.
The first inner sentence executes an amend-in-place, but that execution
returns b as its result, and that gives b a usecount of 2 (one for the
stored b, one for the use of the value in a result). This result is
returned from the inner sentence and discarded by 7!:2 - but WITHOUT
DECREMENTING THE USECOUNT. (The decrement request is on a stack and
will not be lost, but it waits till the fork containing the first inner
sentence completes).
Thus, when the second 7!:2 is executed, the usecount of b is 2 and the
assignment is not inplace.
But... why isn't the pattern repeated, with the 3d assignment inplace
and the 4th not, etc?
Because when an inplaceable value is assigned to a name, as when the
second 7!:2 is executed, there is a special short path that decrements
the usecount immediately rather than marking it for later, to save a
little work. Thus, the usecount is 1 after all the subsequent
assignments.
Henry Rich
On 10/21/2021 10:29 AM, Henry Rich wrote:
Wow, that's weird. I don't think it has to do with cache, because
only a tiny bit of the arguments are touched.
No, it has to do with inplacing:
b =: 1e9$0
(7!:2 , 7!:2) 'b =: 1 (2 3 4)} b'
1073743328 1408
(7!:2 , 7!:2 , 7!:2 , 7!:2 , 7!:2 , 7!:2) 'b =: 1 (2 3 4)} b'
1408 1408 1408 1408 1073743328 1408
(7!:2 , 7!:2 , 7!:2 , 7!:2 , 7!:2 , 6!:2) 'b =: 1 (2 3 4)} b'
1408 1408 1408 1408 1408 2.21e_5
(7!:2 , 7!:2 , 7!:2 , 7!:2 , 7!:2 , 0:@".) 'b =: 1 (2 3 4)} b'
1408 1408 1408 1408 1408 0
Something is making the second sentence not run inplace. I'll have to
look at that.
Henry Rich
On 10/21/2021 8:08 AM, Raul Miller wrote:
This looks like a cache liveness issue.
https://en.wikipedia.org/wiki/Cache_hierarchy#Multi-level_cache
I hope this makes sense,
--
This email has been checked for viruses by AVG.
https://www.avg.com
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
--
This email has been checked for viruses by AVG.
https://www.avg.com
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
