On Sun, 29 Aug 2021, Henry Rich wrote:
By my analysis, the beta-o parser would not be any faster than it is if
it had to verify the types of its arguments.
Not even if it could generate bytecode or native code? Currently, given
x=.i.1e9, {{x+y}}/x is 100-200x slower than +/x. (Though it is 2-2.6x
faster than Dyalog APL!)
This is perhaps somewhat unrealistic, but I think not unrepresentative.
And +/x is bandwidth-limited, so the 'true' performance delta may be worse
yet.
A preliminary benchmark I constructed suggests that compiling the direct
function to native code would result in a {{x+y}}/ only 5-10x slower than
the obvious +/. (This models an indirectly-calling / and a {{x+y}} that
dispatches on the rank + element type of its parameters.)
Code using if. and co--which are likely to be seen in JTRAN!--would likely
see an even greater benefit, because of the branch predictor.
-E
Your last point is absolutely right, and yet I want to ignore it.
Experienced J programmers have learned ways to avoid sentences that do
little work. Programmers new to J write what I call JTRAN: FORTRAN code
translated to J, with lots of scalar arithmetic. With a little
experience they will write better J, but I don't want to lose them
before they get the experience. I am trying to make the parser execute
JTRAN efficiently.
And, most of us lapse into JTRAN occasionally. (maybe not Roger)
Henry Rich
On 8/28/2021 11:37 PM, Elijah Stone wrote:
On Sat, 28 Aug 2021, Henry Rich wrote:
Large improvement would require heroic intervention: parsing &
caching sentences on the fly & watching assignments to make sure the
cached parse is valid. I would rather avoid that.
The technique has been implemented, to great effect -
http://www.softwarepreservation.org/projects/apl/Papers/DYNAMICINCREMENTAL
That implementation placed the invalidation in the parsed (and
compiled) sentence itself, rather than invalidating existing sentences
on assignment, which simplified matters; before a sentence is
executed, the inferred nameclasses of its referents are verified.
This is much simpler and easier to get right, and retains similar
performance (especially with modern branch predictors).
That being said, if the parser is a bottleneck for some code, then it
is likely doing something wrong and should perhaps not be encouraged :)
-E
----------------------------------------------------------------------
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
