My comments on the difference between @: and @ was not intended for primitives. It was about defined verbs. If I have a defined verb as an argument to @: then I am saying that the defined verb may create a dependency between cells and the interpreter should avoid optimization. Where using @ says that there is no dependence between cells and optimization is safe. At least that's how I see the purpose of both @: and @ .
I don't want to second guess the interpreter. That is what bothers me about this thread. It is second guessing the interpreter when we prefer @: over @ because it is faster with today's interpreter. It is based entirely on the fact that today's interpreter uses only one processor and it always reruns the defined verb from scratch for each cell. In an earlier version of the primitive + was defined to have infinite rank. It was changed to rank zero. Why was this done? Certainly we all know that it is vectorized by the interpreter. I think that it was done to better describe the concept of + . We should do the same with defined verbs. On Wed, Aug 20, 2008 at 8:00 PM, Mark D. Niemiec <[EMAIL PROTECTED]>wrote: > From: "Don Guinn" <[EMAIL PROTECTED]> wrote: > > @:may be faster than @ today, but what happens when J supports multiple > > processors? To me using @ tells the interpreter that there is no > dependence > > between cells, where @: means that there could be. Therefore, @: > restricts > > the computation to one processor or at least extra processing to check > for > > dependencies between cells, where @ could allow cells to be handled in > > multiple processors. > > Any interpreter that can transparently schedule tasks among multiple > processors will also have to perform various kinds of global optimizations > in order to do the scheduling effectively. > > J already has mechanisms in place that recognize certain verbs as having > stable shapes, or as operating on atoms. For most built-in primitives, the > interpreter could easily deduce whether the semantics of @ and @: would > yield the same results (and, if so, freely substitute one for the other). > > The interpreter must already do something like this in some cases, since > atomic verbs like + are heavily optimized and are likely treated as if they > are of infinite rank for internal looping purposes. > > There are also quite a few frequently-used idioms that the interpreter > recognizes and turns into special code, without requiring that users > tweak their J in order to get better performance. I would expect that > a more heavily optimizing interpreter would do more of this, and relieve > the user of the burden of trying to understand how the current > implemntation > is optimized. This has been the trend in other languages - you write what > you want, and the compiler figures out how to do it without you having to > second guess it. > > In cases where extreme performance is required, and certain constructions > seem to generate faster execution, then perhaps user code can be tweaked > to take advantage of this; however, such cases should be the exception > rather than the rule. > > > I use @: instead of @ for the very reasons you have stated, but I get the > > feeling from the discussion that people feel that @: should always be > used > > instead of @ and that it will always be that way. > > J is an array language, and its general philosophy is that it's faster to > do many similar things simultaneously rather than individually. With that > in mind, constructs like @: should generally be perferred over @ whenever > the two have the same result; this allows the interpreter to subdivide > the problem at its own discretion. While it's true that sometimes the > interpreter ignores explicit rank (such as in atomic verbs), it only > does so in special cases, so there are likely many cases where lowering > the rank of a verb will produce identical results, but with larger > overhead. > > (As a matter of personal style, I often use [EMAIL PROTECTED] instead of u@:v > for > brevity > whenever v is of infinite rank; I haven't done any tests to see whether > this > results in any performance penalty - nor have I compared either with [: u > v. > I supect that the differences are negligible.) > > -- Mark D. Niemiec <[EMAIL PROTECTED]> > > ---------------------------------------------------------------------- > For information about J forums see http://www.jsoftware.com/forums.htm > ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
