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
