I think of the 6809 as a 16-bit microprocessor, myself (pace Wikipedia). It has 16-bit registers, load/stores, and add/subtracts. A nice clean architecture for its day.
The discussion there badly misunderstands the nature of ELEMENTAL procedures in Fortran and their relevance to parallel execution.
ELEMENTAL is relevant to DO CONCURRENT only indirectly. The ELEMENTAL attribute matters there only because it implies the PURE attribute by default, and PURE is required for procedures referenced in DO CONCURRENT. (Which is not a parallel construct, but that's another matter.)
ELEMENTAL in array expressions (incl. FORALL) should not be understood as being a way for one procedure invocation to receive and return entire arrays as arguments and results. That would require buffering during the evaluation of an array expression. Instead, ELEMENTAL should be viewed (and implemented) as a means of allowing a function to be called as part of the implementation of unbuffered array expression execution.
ELEMENTAL has its roots in compilation for true vector machines. It once caused a function to have multiple versions generated: a normal one with scalar arguments, and a vector one with vector register arguments. This would allow a user-written ELEMENTAL function to be called in a vectorized DO loop, just like an intrinsic vectorizable function like SIN. A compiler for today's SIMD "vector" ISAs could implement ELEMENTAL in a similar fashion.
I can see the subtle distinction you make. The flang notes on array composition provide a good introduction to the way array expressions (https://flang.llvm.org/docs/ArrayComposition.html) are treated.
But in practice it looks like the elemental function must be in the same translation unit for vectorization to occur with compilers popular today. Explicit options like !$omp declare simd are a different matter (and have different pitfalls).
Range reduction for trig functions is basically a real remainder of division by 2*pi, and real remainders can be computed precisely if you want to, even when quotients can't be.
> There are thousands of contributors and the distribution is relatively flat (that is, it’s not the case that a small handful of people is responsible for the majority of contributions.)
This certainly varies across different parts of llvm-project. In flang, there's very much a "long tail". 80% of its 654K lines are attributed to the 17 contributors responsible for 1% or more of them, according to "git blame", out of 355 total.
That was ambiguously phrased. The point I was trying to make here is that we don't have the situation that is very common for open-source projects, where a project might nominally have a 100 contributors, but in reality it's one person doing 95% of the changes.
LLVM of course has plenty of contributors that only ever landed one change, but the thing that matters for project health is that that the group of "top contributors" is fairly large.
(And yes, this does differ by subproject, e.g. lld is an example of a subproject where one contributor is more active than everyone else combined.)
26 bytes is 208 bits, about twice what you really need for a minimal encoding that has enough context (en passant, castling) to generate an accurate set of legal moves. I wrote a chess database tool back in the 90's (CDB) that used 96-bit encodings (if memory serves) to index all the positions reached in a collection of games so that one could see the moves made from any position, their frequencies, and their game outcomes. Good fun.
96 bits is not nearly enough, as there are ~4.8 * 10^44 > 2^148 legal chess positions (with side to move/castling/ep info) [1].
Chess Position Ranking provides a 153 bit encoding but it's very slow to decode.
If the encoding only needs to work for the set of positions occurring in some database, then there's almost no limit to the number of coding optimizations one can make (until the encoding just becomes an index in the set of all unique db positions).
"legal chess positions" is a larger space than pklausler's "observed chess positions". Novel positions reached in future that violated the 96-bit encoding could be encoded using a variable-length additional "patch" suffix.
Given the current upper bound on legal chess positions is 7.7e45 ≈ 152.4 bits, you either have found a better upper bound or your memory doesn't serve.
They didn't try to encode all legal positions though, only ones that were actually reached in their database of games. It sounds very plausible to me that this allows a lot of simplifying assumptions that cut the state space by about 60 bits
I can put it all in, say, 24 bits, if my database is small. 140k games, 120 positions each. log(140000*120)/log(2) ~~ 24.001, and surely there will be some duplication.
The encoding is just the index number of the game + move that resulted in that position.
I think that it would be easier to get younger people to study Quenya to be able to read fragments of Tolkien in the "original" than it would be to somehow get them to learn to read classical Greek. But it's not that hard to learn to just read Attic and Homeric Greek, and then there's a lifetime of really great stuff that opens up for one to enjoy.
>it's not that hard to learn to just read Attic and Homeric Greek
I studied Attic, Koine, and Homeric, as well as a few other dialects for 10 years through college until I left my PhD program in Classics. Learning Greek was _very_ hard and even after that time I still had many gaps.
It's not all-or-nothing, though, and free sources like Attikos provide word definitions at a tap. Since I'm old, I also have a shelf of Loebs, and have no shame about skimming the dull bits by reading the trots.
reply