Dan - good tips. Originally I was thinking the stack may have multiple
types, but I did settle on numbers. I eliminated the boxing but it
didn't speed things up. I'm still happy to get rid of it though
92% of the time is spent just in the looping code (35 out of the 38 seconds)
Executing 50,000 operations is quite fast:
6!:2 'eval parse , > 50000 # (<''ADD 1 5'',LF)'
1.18579
On Tue, Nov 10, 2015 at 4:57 PM, Dan Bron <j...@bron.us> wrote:
> In re: performance, probably the biggest bang for your buck would come from
> using integers in place of boxes.
>
> From the examples on that page, it appears that stack elements can either be
> integers (“ADD 5 2”, “LABEL 100”) or opcodes (“ADD”, “LABEL”). So you could
> modify the parse function to convert string opcodes to integers (use s: if
> you want, or simply the indices into the global noun OPS [1]).
>
> Then ditch all the <s and {::s etc.
>
> In terms of other speedups, I don’t know if you’re going for some kind of
> stack-oriented purity, but I’d imagine e.g. +/ _2 {. stack (or define a pop2
> which returns _2 {. stack) would be a lot faster than op_pop + op_pop which
> requires transitioning to an explicit context twice, as well as two updates
> to the global noun stack.
>
> But … this is all speculation. Maybe the best advice I could give you is to
> run your 50,000 op test under the performance manager and see what the actual
> bottlenecks are.
>
> Anyway, cool stuff.
>
> -Dan
>
> [1] FYI, you don’t need the verb defOps . You could simply say:
>
> (OPS) =: i.#OPS=:;:’POP PUSH ADDS ADD CMP EXIT LABEL DISP JGE DSTR’
>
> For some silly fun, you could use a gerund instead of a string:
>
> (OPS) =: i.#OPS=: POP`PUSH`ADDS`ADD`CMP`EXIT`LABEL`DISP`JGE`DSTR
>
> This latter approach is dangerous because one day someone might decide to
> define e.g. a noun POP in the z locale or something.
>
>
>
>> On Nov 10, 2015, at 4:07 PM, Joe Bogner <joebog...@gmail.com> wrote:
>>
>> I wrote this over lunch today and was pleased to see how simple it
>> was. I'm posting here for those who don't follow Recent Changes.
>> Feedback welcome
>>
>> http://code.jsoftware.com/wiki/User:Joe_Bogner/ByteCodeInterpreter
>>
>> I'd be interested in any speedups to the timing test that still permit
>> jumps. It's fine as-is for a toy though
>> ----------------------------------------------------------------------
>> 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
