I did a LOT of the SIMD Boolean support in SHARP APL, and I agree that doing that can be a lot of work. It is certainly intellectually challenging and rewarding. The first time, anyway.
However, again, the important thing is to let the compiler do the dirty work, and avoid having to write the same thing over and over again at the C level. E.g., I introduced a word-at-a-time (if shift was required) Boolean mover into SHARP APL, and we used it whenever a contiguous set of Booleans needed moving. I used it in take/drop, rotate, reverse, catenate/laminate, at least. I don't recall, offhand, if I put it into indexing (for your x[;;b;;;;] case or into rank/compose/dual. Having a generalized SIMD mover made the interpreter somewhat simpler, and helped to reduce code faults caused by the tedious and error-prone nature of manipulating dense Boolean structures on that hardware. Remember, this was assembler code that predated C. Bob On 16-04-28 01:27 PM, Roger Hui wrote: > The major limitation of SAC, at present, is its lack of a one-bit Boolean > data type. ... > If somebody wants to volunteer to do the one-bit Boolean support for > SAC, we can find out! > > > I believe a high performance implementation of bit booleans for all the > relevant APL primitives requires several years of work. Intellectually > challenging and rewarding work. See, for example, the bit (ha!) about x[b;…;] > in In Praise of Magic Functions, Part II > <http://www.dyalog.com/blog/2015/06/in-praise-of-magic-functions-part-two/> > > > > On Thu, Apr 28, 2016 at 9:44 AM, Robert Bernecky <[email protected]> > wrote: > >> One of the great advantages of SAC is that you can solve the >> "...define words like..." problem with it, with NO loss of performance >> or clarity. >> >> In fact, you can define those functions and give them names of +, -, *... >> without confusion. These can be used to expand the standard library >> of functions, or they could be placed in a different library, such as >> unums. [Objections to unplanned execution of unums are, IMO, the same >> as objections to unplanned execution of complex numbers, etc.] >> >> SAC has a clean (ish), minimum set of primitive functions defined in >> the compiler, then defines EVERYTHING else as stdlib (standard library) >> code. For example, the scalar functions over arrays are all defined >> in the stdlib, in terms of data-parallel operations over operations >> on scalars. This simplifies the compiler considerably. >> >> Moving array-based function definitions to a standard library >> offers SAC two significant advantages over languages like APL and J, >> which still allow the language implementor to rule over (and overrule) >> the user: >> >> - Introduction of new data types can be done by ANYBODY, without having >> to beg, bribe, or become the implementor. >> >> - The array optimizations in the sac2c compiler give those new data >> types equivalent performance to hand-coded, specialized versions >> of them. >> >> In fact, SAC usually offers superior performance to primitives >> that are >> hand-coded in C (or equivalent language), because the functions >> written in >> SAC are exposed to the compiler's optimizations, often generating >> better-performing code. Elimination of array-valued temps is key >> here, >> because of the dismal performance of contemporary memory subsystems. >> As a trivial example, consider: >> >> z = A + transpose( B); >> >> If transpose is written as a high-performance built-in primitive, >> as it is in APL and J, >> then things work this way: >> >> tmp = transpose(B); // Transpose the array and generate an >> array-valued >> // intermediate result, tmp. >> z = A + tmp; // Do the addition >> >> This is very slow, because it has to write, then read, all >> elements of tmp, >> and perform array allocation, deallocation, and initialization of >> tmp's >> array descriptor. >> >> In SAC, the transpose and tmp are optimized away >> by one or more flavors of "with-loop folding", >> so the resulting C code would be something like: >> >> for( i=0; i< shape(A)[0]; i++) { >> for( j=0; j<shape(A)[1]; j++) { >> z[i,j] = A[i,j] + B[j,i]; >> } >> } >> >> Also, in SAC, gauss-jordan, etc., would work on unums with no changes >> to the J/APL code, and with no need to kowtow to an implementor >> (or to become one yourself). >> >> The major limitation of SAC, at present, is its lack of a one-bit Boolean >> data type. Introduction of one-bit Booleans, which would require modest >> sac2c compiler enhancements, would do a lot for unums. >> Perhaps Sven-Bodo has something to say about this topic, which >> is why I've CC'd him on this message. >> >> However, there are still a few places where specialized primitives (or >> stdlib >> functions) could outperform such an implementation, as described above. >> I suspect that they are, in practice, not frequently encountered. >> If somebody wants to volunteer to do the one-bit Boolean support for >> SAC, we can find out! >> >> Bob >> >> On 16-04-28 06:16 AM, Raul Miller wrote: >>> Btw, just to be clear: when I said "implement in J" I did not mean >>> "modify the interpreter" or anything like that. I would not expect >>> (p.inv) to work on native unums. >>> >>> Instead, I meant to define words like add, sub, mul, div, fmt, ... >>> which work like +, -, *, %, ": and maybe a few others on some >>> representation of unums. (Perhaps a box of bits - each box >>> representing one unum and the contents of each box being a list of >>> bits. This will not be high speed, but would be good for a first >>> implementation because of its transparency.) >>> >>> Then, once you have that, you use those to build relevant algorithms >>> using these new "primitives" and see how guass-jordan reduction (or >>> whatever) works with them. >>> >>> The question is: are these just a gimmick, optimized for a certain set >>> of algorithms, or do they have general utility? (Or, if you prefer, >>> the question is: how much utility does this representation have?) >>> >>> Thanks, >>> >> -- >> Robert Bernecky >> Snake Island Research Inc >> 18 Fifth Street >> Ward's Island >> Toronto, Ontario M5J 2B9 >> >> [email protected] >> tel: +1 416 203 0854 >> >> ---------------------------------------------------------------------- >> For information about J forums see http://www.jsoftware.com/forums.htm >> > ---------------------------------------------------------------------- > For information about J forums see http://www.jsoftware.com/forums.htm -- Robert Bernecky Snake Island Research Inc 18 Fifth Street Ward's Island Toronto, Ontario M5J 2B9 [email protected] tel: +1 416 203 0854 ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
