| Custom implementation of OCLstdlib [message #1800531] |
Tue, 01 January 2019 17:21  |
Sina Madani
Messages: 160
Registered: November 2015
Location: York, UK |
Senior Member |
|
|
Hi Ed,
I was wondering whether it is possible to provide a custom implementation for a subset of the operations in the standard library and if so, whether there is any documentation for it. In particular, I am interested in the iteration-based operations such as forAll, exists, select etc. as well as sum() and product(). I see that the PivotUtil.createOperation method allows to specify an implementation class, and I was wondering whether there are any requirements for custom implementation (e.g. is it mandatory that all first-order operations which have a for / while loop extend from AbstractIteration), and also what is the cleanest way to delegate to a custom implementation, since OCLstdlib is auto-generated and I only want to re-implement a subset of the standard library.
My motive for doing this is to make the operations parallel, and I wanted to see if OCL presents any impediments to parallel execution (in theory there is nothing in the specification which precludes this). If all is well then I'll compare the performance of sequential vs parallel as well as to Epsilon sequential vs parallel.
Kind Regards,
Sina
|
|
|
| Re: Custom implementation of OCLstdlib [message #1800533 is a reply to message #1800531] |
Tue, 01 January 2019 18:17  |
 Ed Willink
Messages: 7655
Registered: July 2009 |
Senior Member |
|
|
Hi
In principle you can have other libraries and you will find that GIT\org.eclipse.ocl\tests\org.eclipse.ocl.examples.xtext.tests\models\oclstdlib\minimal.oclstdlib has evolved to contain enough to stop a few minimal tests blowing up. You might search for references.
The above tests demonstrate that it can be done, but https://bugs.eclipse.org/bugs/show_bug.cgi?id=415146 is an open bug on providing documentation and the discussion highlights that providing a math.oclstdlib was not as easy as I hoped. A few relevant bugs have been fixed since then so it might be easier now.
You will find that many of the Pivot OCL caches have 'synchronized' in the code. This is an indication of what needs to be worried about. It in no way indicates that the 'synchronized' was ever right or is still right. IMHO this kind of threadsafe code can only be genuinely threadsafe if autogenerated. On my stack of things to do, but not 'this' year.
Any implementation you extract performance information from will be embarrassing to the original authors, since for both Epsilon and Pivot OCL, functionality has been higher priority than speed and with limited resources, optimization has been severely neglected. Each new test I do uncovers an area where I could do much, often very much, better.
For OCL/EOL, but not QVTd/ETL there is a problem of knowing what the totality of user execution is. This tends to inhibit global analysis/optimization. QVTd has some global analyses of the transformation, and of the loaded input model. These can help, but there is a lot more that can be done.
If you come up with something that 'works', I might take a shot at optimizing it so that your results can present today's state of the art and an indication of typical deficiencies.
OCL typically requires full evaluation since you must guarantee that no invalid is overlooked. The Pivot OCL has quite a bit of static analysis that can prove that invalid is impossible allowing short-circuiting. Safe navigation is the hardest bit and is there; accurate for simple and some not-so-simple cases, pessimistic for horrible cases. Divide by zero etc are easy but missing. Index-out-of-range has an easy pessimistic solution but needs more work to detect that size() expressions give ok-indexes; this functionality is missing.
Regards
Ed Willink
|
|
|
|
|
|
Powered by
FUDForum. Page generated in 0.03200 seconds
] 
Search
Help
Register
Login
Home
