| Re: [epsilon-dev] First-order operations revisited |
_______________________________________________Hi Antonio,
I have managed to implement a fix (and tests) for the nested parallelism issue. Users will now get an EolNestedParallelismException. Tests for this are implemented in EOL as well as in EVL, and in both cases the exception is thrown as expected. However due to the nature of parallel execution the line numbers (“Region”) where the nesting occurs is not always reported correctly. I hope this is more useful than undefined behaviour.
Thanks,
Sina
From: Sina Madani
Sent: 01 August 2018 13:38
To: Epislon Project developer discussions
Subject: RE: [epsilon-dev] First-order operations revisited
Hi Antonio,
Thank you for bringing this up. Currently there’s no notification mechanism for reporting this, so at present it will fail in some undefined way. If you have a suggestion for a good way to handle this please let me know. The only “hack” / workaround I can think of which doesn’t involve static analysis is to keep track of every time an EolExecutorService is requested from the context, and if it is more than once this means nested parallelism, and we can inform the user then. I’ll experiment with this and update accordingly.
Thanks,
Sina
From: Antonio Garcia-Dominguez
Sent: 01 August 2018 12:28
To: Epislon Project developer discussions
Subject: Re: [epsilon-dev] First-order operations revisited
Hi Sina,
One question: do we notify users properly when they nest parallel operations, or is it going to fail in some undefined way? I can already see the forum threads coming if we don't report the situation directly :-D.
Cheers,
Antonio
On 30 July 2018 at 13:12, Sina Madani <sinadoom@xxxxxxxxxxxxxx> wrote:
Hi all,
I have recently been working on org.eclipse.epsilon.eol.execute.operations.declarative and have made a number of additions and improvements. These are as follows:
- Parallel variants of all first-order operations except for aggregate and closure under the org.eclipse.epsilon.eol.execute.operations.declarative.concurrent package. These can be invoked by adding “parallel” prefix to the operation – e.g. select becomes parallelSelect. These operations can be used in any Epsilon language on-the-fly seamlessly without setting up parallel execution infrastructure (i.e. you don’t need to use a special IEolModule or IEolContext beforehand – the setup is done in the operations themselves).
- Added EUnit tests for all first-order operations under org.eclipse.epsilon.eol.engine.test.acceptance.firstOrder. This includes tests for both sequential and parallel variants, as well as equivalence tests, scope tests (i.e. visibility of global variables) and exception handling.
- select (and parallelSelect) now takes an additional parameter. Before it was “boolean returnOnMatch” (allowing for selectOne). Now it also takes “boolean isSelect”, allowing for reject.
- Added rejectOne (and parallelRejectOne) in same codebase as select (and parallelSelect).
- Added findOne.
- Refactored one operation to short-circuit when not enough or too many matches are found. Previously this just called select and checked the size == 1, which was inefficient.
- Added none operation (as well as parallelNone). As with one, this short-circuits. The codebase for one and none is generalised as nMatch where n = 1 for one and n = 0 for none.
- forAll (and parallelForAll) delegate to nMatch where n is the size of the source collection. This also fixes the bug with variables leaking as “scope.leaveLocal(_expression_)” was not previously called when short-circuiting.
- sortBy (and parallelSortBy) now use arrays for intermediate results, saving memory and making it possible to perform sorting in parallel using java.util.Arrays.parallelSort. Note that Arrays.parallelSort will sort sequentially if the length of the array is less than 8192. This conveniently allows the codebase to be shared between sequential and parallel, by introducing “CollectBasedOperation” in the same way as “SelectBasedOperation” and using parallelCollect as the delegate for parallelSortBy.
- Updated Epsilon book with newly added operations and a note on the existence of parallel variants, as well as restrictions on using them.
Currently the restrictions on using the parallel variants of first-order operations are as follows:
- No nested parallel operations – e.g. “col.parallelSelect(d | d.prop.exists(p | <expr>))” is valid but “col.parallelSelect(d | d.prop.parallelExists(p | <expr>))” is not.
- No side-effects are permitted. This means no invocations of operations which modify global variables or extended properties.
- Cannot be used with parallel EVL (or any other parallel execution engine, for now).
I hope that this will be useful. Please let me know if you have any questions or comments.
Thanks,
Sina Madani
_______________________________________________
epsilon-dev mailing list
epsilon-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/epsilon-dev
--
Antonio Garcia-Dominguez
epsilon-dev mailing list
epsilon-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/epsilon-dev