J already uses "bytecode". That said, it's "bytecode" with J semantics.
FYI, -- Raul On Sun, Aug 29, 2021 at 1:10 AM Elijah Stone <[email protected]> wrote: > > 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 ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
