Having display with changes the timings a=: 1e6 ?@$ 0 b=: 1e6 ?@$ 0 c=: 1e6 ?@$ 2 10 ts 'c}b,:a' NB. ben0 disp 0.119505 4.19441e7 10 ts 'r=: c}b,:a' NB. ben1 0.0189249 8.38976e6 10 ts 'b=: c}b,:a' NB. ben2 0.0104832 1152 10 ts '[b=: c}b,:a' NB. ben2 disp 0.0898452 4.19443e7 10 ts 'a=: c}b,:a' NB. ben3 0.0100367 1152 10 ts '[a=: c}b,:a' NB. ben3 disp 0.100718 4.19443e7 10 ts '[r=: c}b,:a' NB. ben1 disp 0.0865346 4.19443e7 10 ts 'c}b,:a' NB. ben0 disp 0.0844734 4.19441e7
2011/12/22 Roger Hui <rogerhui.can...@gmail.com> > Henry's analysis and recollection are essentially correct. > > In preparation to answering Johann Hibschman's question, > One question though: why is the particular form (result=:c}b,:a > singled out, rather than the general (c}b,:a)? > I did the following benchmarks: > > a=: 1e6 ?@$ 0 > b=: 1e6 ?@$ 0 > c=: 1e6 ?@$ 2 > ts=: 6!:2 , 7!:2@] > 10 ts 'c}b,:a' NB. ben0 > 0.0656868 4.19441e7 > 10 ts 'r=: c}b,:a' NB. ben1 > 0.01968 8.38976e6 > 10 ts 'b=: c}b,:a' NB. ben2 > 0.0142325 1152 > 10 ts 'a=: c}b,:a' NB. ben3 > 0.0142765 1152 > > It is right and proper that ben2 and ben3 should be the fastest and > leanest, because the interpreter can go through c and (a or b) just once, > modifying a or b according to c. It is also expected that ben1 would also > be fast (but slightly slower) but take more space, because the interpreter > has to transfer a or b to a new array. But why is ben0 so much slower and > fatter than ben1? (That's Johan Hibschman's question.) > > The immediate answer can be found in file w.c of the J source, function > jtenqueue(). The special code for > x=:c}b,:a<http://www.jsoftware.com/help/release/iamend.htm>and friends > is recognized not at parse time (parse in the sense of Section > IIE of the dictionary <http://www.jsoftware.com/help/dictionary/dicte.htm > >), > but in a small gray area between word formation and parsing, implemented by > jtenqueue(). After word > formation<http://www.jsoftware.com/help/dictionary/d332.htm>, > the words are put into a form required by the parser, and it is at that > stage that a few special forms > abc=: pqr (xyz}) abc > abc=: abc,blah > abc=: abc xyz}~ pqr > abc=: pqr}x,y,...,:z > are recognized. This is done for every sentence you enter in your session, > and for every line of an explicit definition at the time of definition. > This procedure avoids modifying the parser, avoids slowing down the parser, > etc. It does of course slow down every sentence you enter in your session > and the definition of every explicit definition. In this I exercised my > right as the "holder of the pencil", and deemed the trade-off worthwhile. > > Tacit expressions too have a similar thing happen, with logic that is more > dispersed. What you enter (for example) > blah0 f/. blah1 > whether assigned or not, within the /. adverb the interpreter looks at f > and decides to do all manner of weird and wonderful things. If this is > assigned, as for example in keysum=:+//., then the analysis happens only > once, but you get the benefit every time you apply the named verb. If this > is not assigned, then you benefit just once, and the result of the analysis > is thrown away when the parser is done with this part of the sentence. The > execution of f/. and the definition of keysum=:+//. are slowed down > minutely as a result of this analysis, but no other verb, adverb, or > conjunction is affected, nor is the parsing of a sentence not involving /. > affected. > > I imagine that in the future, it is possible that one of Henry's bright > young students can carry this further, and do all sorts of analysis and > optimization at the time that a script is loaded or saved. > > Come to my talk at the J > Conference<http://www.jsoftware.com/jwiki/Community/Conference2012>, > and I will tell you more about this and other marvels ☺ > > > > On Thu, Dec 22, 2011 at 10:44 AM, Henry Rich <henryhr...@nc.rr.com> wrote: > > > > I think Raul has the right idea. > > > > Consider execution of > > > > q} a,b,c,:d > > > > This goes right-to-left and the c,:d is executed long before the q} is > > ever seen by the parser (and remember, the q} could actually be a > > defined name). To prevent the execution of c,:d would require either > > > > - a full analysis of the names in the stack > > or > > - designation of a special case that will get fast treatment. > > > > Roger has said that he was very loath to slow down the parser, because > > that would cost on every sentence executed. So the parser recognizes a > > few special cases for those combinations that cannot be turned into a > > single compound verb. > > > > > > In addition to avoiding the ,: there is the greater payoff of performing > > in-place operation when you have the form > > > > name =: q} a,:name > > > > Similar arguments apply. The given variant is in-place, while the > > equivalent > > > > name =: a q}@:,: name > > > > is not. > > > > Henry Rich > > > > > > > > On 12/22/2011 1:26 PM, Raul Miller wrote: > > > I think (but I do not know for sure) that in the explicit case, the > > > code gets flagged for special handling when the verb (or adverb or > > > conjunction) is being defined. And, I think the code that is doing > > > the flagging is rather simple -- it's checking to make sure there are > > > no syntax errors, and is designed to be fast. It sees the assignment > > > with this code and builds a special copy of the representation of that > > > line. > > > > > > So... if this was correct... the underlying mechanisms (that the > > > recognition code is built on) are not there for the more general case. > > > This means that the interpreter does not have to pay a speed penalty > > > for the general case (and, while the actual evaluation is faster you > > > need to also keep in mind that the code analysis is not instant, and > > > you have to wait for it to execute every time it runs). > > > > > > If J were redesigned to perform this kind of code analysis every time > > > } was used, it might, for example, delay execution of ,: which would > > > cause other problems: > > > > > > Every operation would be slower (because every operation would now > > > have to check to see if it was being passed a delayed ,: before it > > > could do anything else). > > > > > > J would be a larger program (because every operation would need new > code). > > > > > > J would probably have new bugs (because all of this new code will need > > > to be debugged after it's implemented). > > > > > > So that particular implementation is probably a bad idea. > > > > > > Another variation might involve a re-designed parser (which would also > > > add complexity and add new opportunities for bugs). This one might > > > actually be worthwhile, if it could do a better job of supporting > > > special code than the current one does. But designing a new parser > > > system which does not change the language syntax and does the analysis > > > needed for this kind of special code (and which is still fast enough) > > > is no small task. But you if you feel like designing and implementing > > > one, it would be a very interesting project. > > > > > > (I imagine that an "efficient" implementation would introduce and > > > manage the deferred execution needed for the various sorts of special > > > code. It's "just a small matter of engineering" to make that kind of > > > thing worth using.) > > > > > ---------------------------------------------------------------------- > > For information about J forums see http://www.jsoftware.com/forums.htm > ---------------------------------------------------------------------- > For information about J forums see http://www.jsoftware.com/forums.htm > -- Björn Helgason, Verkfræðingur Fornustekkum II 781 Hornafirði, t-póst: gos...@gmail.com gsm: +3546985532 twitter: @flugfiskur http://groups.google.com/group/J-Programming Tæknikunnátta höndlar hið flókna, sköpunargáfa er meistari einfaldleikans góður kennari getur stigið á tær án þess að glansinn fari af skónum /|_ .-----------------------------------. ,' .\ / | Með léttri lund verður | ,--' _,' | Dagurinn í dag | / / | Enn betri en gærdagurinn | ( -. | `-----------------------------------' | ) | (\_ _/) (`-. '--.) (='.'=) ♖♘♗♕♔♙ `. )----' (")_(") ☃☠ ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
