Nothing really changes in IT. It just gets recycled. I refer to the
following 20 year old document by Nick MacLaren from the Cambridge
Computer Lab.
https://doi.org/10.1007/978-1-4615-4873-7_6
MacLaren N. (1999), From Flops to Udaps: Algorithms, Benchmarking and
Tuning. In: Allan R.J., Guest M.F., Simpson A.D., Henty D.S., Nicole D.A.
(eds), High-Performance Computing. Springer, Boston, MA, pp53-56
He says:
.... I believe that both Fortran and C9X will reach their limits
and that it will become increasingly hard to write efficient code
using those languages, except possibly for vector operations.
There will be an increasing need for a much more disciplined
language, where the programmer can pass much more information to
the compiler, and hence to the hardware. But I am not optimistic
that we shall see such a language.
We also believe the truth of the first sentence or else we would not be on
this list. And we know the answer to the last sentence - this language IS
here today and it is called Chapel.
That said, Chapel was not around in 1999 when Nick wrote this. HPF and a
few others were but they have either died or, in the case of a few, been
the inspiration pr Chapel. But the contention is the middle sentence is
still quite valid. How does the programmer help the compiler? The most
obvious are the constructs of the language. But this only goes so far.
What about subtle or not so subtle hints to the compiler?
We are starting to see some of this type of thing. I am not talking about
PRAGMA's which totally destroy the readability of a program although they
have their place in a developing language. I am talking about what C++
now calls attributes as have GCC and CLANG or quite a while. I suggest
that anything that destroys readability is ignored.
The next few words are a discussion starter and by definition, incomplete.
Thanks - Damian
PARALLELISM
Chapel has this in spades so it already is doing this sort of thing.
The team already have this in focus.
ASSIGNMENT
The swap operator is already there.
LEAVE FOR ANOTHER TIME:
There are a few other concepts from other languages might be
considered.
ITERATION:
The only thing I can think about immediately in Chapel is
vectorizeOnly
But how do we force the unrolling of a loop on a loop by loop basis?
What else is there?
LEAVE FOR ANOTHER TIME:
There is a need to consider hardware level vectors as a part of Chapel.
In this day and age, be the only vectors in existence seem to be those
with a fixed length 2^N. On CPUs, these seem to all anything from two
real(32) (Intel + others) up to 256 real(64) (NEC Tsubasa). Any such
document should be written only or CPUs, discussed, refined and then
reworked modulo GPUs.
COMPARISON:
Borrowing from C++20, but being a bit loose in my interpretation we can
introduce
likely(boolean expression)
credible(boolean expression)
unlikely(boolean expression)
into boolean expressions. The use of 'credible' is where there is a 'most'
likely (i.e. > 75% say) expression sand then other expressions in the same
if/then/else mix which are quite possible but NOT unlikely (>10% chance of
happening say). I think that worrying about percentages of probability is
over the top.
Should these (or a variant) appear in a 'when' expression ?? C++ has them
for switch statements.
PROCEDURES:
Normally a procedure call causes optimizers great pain.
How about qualifying routines which have little or no effect on what an
optimizing is doing.
neutral - does not affect registers or stack
This could be where one is trying to get access to some system variable
(or global variable) and that variable is either being returned to the
caller or set from a parameter. Both quite trivial operations.
Or,
passive - only affects registers used for returns/parameters
A case in point could be where
t = sqrt(v)
is known to always generate a machine instruction for this operation. That
said, I personally think that sqrt should be an operator or a method of the
type, as should abs, but that is a whole new question and one that the team
has already considered.
GCC allows a gazillion more of these procedure attributed. They need to be
studied in detail.
ANYTHING ELSE??
_______________________________________________
Chapel-developers mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/chapel-developers
