Ideally: you express the maximum degree of parallelism which is present in
your problem, and JE figures out the best way of mapping that parallelism to
the hardware. Tuning is available, because JE cannot benchmark your code
(hotspot does profiling, but it does not do these sorts of global transforms);
'thread count' is one thing which can be tuned.
In this bright future, then, libraries would not care how many threads there
are; this would be the domain of the application programmer, benchmarking
their application as a whole.
You make an interesting point about latency-sensitive tasks, though.
On Fri, 29 Apr 2022, Raul Miller wrote:
Ok... for that last sentence:
Let's imagine that I am working with something which has both an
extensive UI and deals with an extensive variety of libraries to get
its work done. Maybe some sort of media composition application.
And, let's also imagine that we have found a variety of practical ways
of using threading for various IO and math related tasks.
So... what happens when a library which uses threads is loaded when we
have multiple running threads?
Consider, especially, the case where two different libraries which
want threads to exist and be used get loaded in two separate threads.
Generally speaking, libraries are all going to be loaded "up front"
more or less at the same time. Also, generally speaking, programmers
are going to take documentation at "face value" and not think about
hidden interdependencies. And, once you have more than a few
programmers involved, you're going to have to have some approach to
either untangle or avoid interdependencies which could cause system
failure.
Here, the problem is that between the time you count the threads and
the time that you create the missing threads, you are likely to have
another library which would also have been counting the threads and
creating the missing threads.
Conceptually speaking, you only want to count the threads once, and
you only want to create the threads once, and that's the primitive
operation you would want in most libraries. The more tenuous this
primitive becomes, the more likely it is that people will run into
unanticipated situations because they thought it was just going to
work.
Or: we do not want thread counting and creation to be running in
multiple threads.
So designing the language such that that would be a typical case is
just asking for future problems.
I hope this makes sense?
--
Raul
On Fri, Apr 29, 2022 at 4:37 PM Elijah Stone <[email protected]> wrote:
I completely agree.
(Except that I do not quite understand your last sentence.)
On Fri, 29 Apr 2022, Raul Miller wrote:
> On Fri, Apr 29, 2022 at 1:35 PM Henry Rich <[email protected]> wrote:
>> Given that a primitive to allocate a single thread suffices, I see no
>> reason to support more complexity in the primitive.
>
> This argument conflicts with a significant aspect of the design of J,
> which I would try to express as:
>
> J favors primitive recursive (perhaps described as: well bounded)
> mechanisms with demonstrated high utility, with full recursive (bound
> omitting, except in a narrowly focussed sense) mechanisms as a perhaps
> grudging acceptance of academic and edge-case requirements. [Primitive
> recursive is roughly analogous to "for loops", full recursive is
> roughly analogous to while loops.]
>
> Or: we could build all arithmetic operations using >: <: and $:, and
> we could build all arrays from pairs, but in J those arithmetic
> operations are implemented on a base which focuses on frequently used
> array and math operations.
>
> Or:
>
> I have some sympathy for the external pressures which led to this:
>
> k=. (expression which depends on external characteristics)
> 0 T.^:k ''
>
> But from a linguistic perspective, I do not like it.
>
> (And, from a software development perspective: what are the use cases?)
>
> Or: "create one more thread" can crash J much more easily than "ensure
> that Y threads exist".
>
> Thanks,
>
> --
> Raul
> ----------------------------------------------------------------------
> For information about J forums see http://www.jsoftware.com/forums.htm
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
