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
