Hi Prakhar,
The bar for getting new language features added is extremely high - new
operators even higher I think. New operators for parallelism ... well I
don't see that ever happening.
I'm not a fan of implicit parallelism like you propose, it simply raises
too many issues for the system to be able to make good enough judgements
in all cases. If you want to terminate parallel computations when the
outcome of the operator has been determined then that gets very messy
semantically as you basically have a race and can never know which
computation will complete first, nor how far others got - you would have
to use expressions that are completely side-effect free for this to not
be an issue. (And we don't have very good mechanisms for cancelling
computations in the first place.)
There's also an underlying assumption that parallelising the expression
and managing that parallelism will actually yield performance benefits,
but that will only happen if the expressions are each extremely
computationally intensive. Fibers might eventually change the "sweet
spot" for such decisions, but in general forking off parallel tasks,
managing them and combining results has significant overhead.
Such things can already be written using library calls with the ForkJoin
framework and/or parallel streams (as Bernd mentioned). Firing off a
task for each sub-expression and then combining the results as desired.
Having language syntax as a short-hand for that likely appeals to you as
an end-user, but is less appealing to the language architects etc. As I
said the bar is very high to get in new language features - parallel
streams themselves don't have syntactic support.
It is an interesting topic academically at least, but I don't expect you
will find that much interest here.
Cheers,
David
-----
On 24/07/2019 10:19 pm, Prakhar Makhija wrote:
Hi David / All,
Earlier wanted to discuss just the implementation of 'OR operator',
neither 'Conditional OR operator', nor 'Bitwise OR operator'
Same goes with 'AND operator'
Technically OR operator and AND operator are just binary operators,
that's true
I don't find it wrong considering there can be n operands, in an
expression, with either of the two operators or a combination of both,
where n >= 2
n can go nearby anything in powers of 10, it will take those many
sequential clock cycles, to actually resolve the expression
If you consider the same n as an expression of powers of 2, the same
thing can be done in parallel clubbed with divide and conquer, taking
the same number of clock cycles, but saving actual response time
This can be given as a input from console, or as a property, specifying
which implementation to use at runtime, sequential or parallel
But with the latter would lead to very frequent resource starvage, this
would need to be handled, to actually free the resources and give to pid
or ppid, heirarically, or based upon who is the callee, or who asked who
to wait, or some more other logic
All the threads parallelly evaluating the same expression, with either
operand, should be terminated and concluded as, when any thread results to:
'true' in case of OR
'false' in case of AND
An expression can have further sub-expressions; so an expression with
combination of both operands, will be considered as parent expression
Yes it does change the conventional implementation of OR operator, and
AND operator, in Java
So it would be better to have two new operators/symbols itself
Parallel OR
|||
Parallel AND
&&&
We can go with the symbol |&& also in case of Parallel AND
Looking forward to hearing your thoughts
Best Wishes & Regards
Prakhar Makhija
----
Hi Prakhar,
On 22/06/2019 1:28 am, Prakhar Makhija wrote:
> Topic: OR operator represented by ||
That should be the subject of your email - not a reply to a digest.
> Query: The expression evaluation of the operands, of OR operator, does it
> happen in parallel, when Java code runs, in the current versions?
No, there is no parallel evaluation of anything in Java. It would be
wrong to do so in this case as:
"The conditional-or operator || operator is like | (ยง15.22.2), but
evaluates its righthand operand only if the value of its left-hand
operand is false."
David
