What form might these thread parameters take? Priority? Affinity? Both of
these seem suspect as it is not practical to control which threads are
responsible for which tasks. This might be controlled with the n argument to
t., but I am still a bit sceptical. I think affinity controls for things like
numa and hyperthreading are best dealt with automatically (e.g. numa turns
into graph partitioning; a problem which, like register allocation, is hard
for both humans and machines, but which machines can do a good job at st
manual allocation is not generally worthwhile).
On Thu, 28 Apr 2022, Henry Rich wrote:
I was enthusiastic about this proposal when I first saw it, but on
reflection, I have misgivings. The y argument to (0 T. y) is reserved
for thread parameters; with the proposal, how will thread parameters be set?
I think it would be better to leave the design as it is, to allow the
user complete control over the thread parameters.
Using 0&T.@''^:n'' will come to be seen as naive. Users will first
check the number of threads and then create what they need.
Henry Rich
On 4/28/2022 10:04 PM, Elijah Stone wrote:
(If more than y threads are already doing work when 0 T.y is issued,
then the extraneous threads should exit as soon as they are finished;
this should be completely transparent. Thread count is a hint; it
should not affect semantics except in a buggy program.)
On Thu, 28 Apr 2022, Elijah Stone wrote:
Current interface for creating threads is 0 T.''. I find this
interface problematic for a couple of reasons:
1. Pretty much every j script I have seen anyone write is headed by
something like 0&T.@''^:n'', where n is the desired number of threads
to create. I haven't ever seen anyone call 0 T.'' directly by hand,
and I don't think there is ever a good reason to do that.
0&T.@''^:n'' is cumbersome and not particularly clear.
2. There is no mechanism to reduce the number of threads.
3. (This was pointed out by somebody else:) if a script is headed by
0&T.@''^:n'', then every time that script is reloaded, n _new_
threads will be created, which is probably not desirable behaviour.
I therefore suggest that the threading interface be changed so that 0
T.y ensures that there are y threads, creating or destroying threads
as needed.
Question: should y be the overall number of threads, or the number of
threads on top of the master thread? If the former, should 0 T.0 be
punned to exit the session (i.e. kill all threads, including the
master thread)?
----------------------------------------------------------------------
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
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
