On Sun, 1 Mar 2020 11:41:09 +1100 (AEDT), you wrote: > >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.
Other than parallelism, which pretty much must come from the programmer, I don't think that is a fair assessment. While I am not an expert on compilers every indication is that a great deal of progress has been made by those writing them, and combined with improvements in hardware a lot more performance has been achieved. > 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? The biggest roadblock to performance is not the language(*) or compilers, but rather the time available to profile the code and find the bottlenecks, and deal with them. As always, the problem is lack of person-hours. This is why a lot of code being run on HPC systems is done in Python. >Borrowing from C++20, but being a bit loose in my interpretation we can >introduce > > likely(boolean expression) > credible(boolean expression) > unlikely(boolean expression) I would be careful about borrowing from C++. While C++ continues on it's march of adding stuff every 3 years two of the bigger issues facing the C++ community at the moment are the question of ABI (not relevant to Chapel at this stage) and a growing consensus that C++ is getting too complicated. There is little point in adding features to a language, and their resulting maintenance overhead, if few people are going to use them. Far better to expend the effort to make Chapel more popular, so people can get the immediate gains from a cleaner route to multi-core use than OpenMP, and multi-machine use than MPI. _______________________________________________ Chapel-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/chapel-developers
