One of the problems with the current peer review system is the ease with which a reviewer can recommend rejecting a manuscript based on personal conflicts of interest (for example, viewing the work as competitive with their own). Making reviews open, and possibly de-anonymizing them, could alleviate this (allowing the public to review the review itself). Since the review requires the manuscript itself as context, the manuscript then needs to become publicly visible regardless of the reviewers' decisions.
Another problem is the difficulty that editors have in finding reviewers (to work for free essentially). One solution could be to require authors to act as reviewers before they can submit their own work. For example, if a manuscript requires N favorable reviews to be accepted, then for each manuscript an author submits, they must provide N reviews of other manuscripts.
There is still something missing from the above in terms of "reviewing a review". The closest thing I can think of is comment threads where the post is the manuscript... There needs to be a way for low-quality reviews to be reported as such and invalidated. Right now all this is on the shoulders of the editor, who doesn't have time to do more than add up the recommendations of the reviewers.
Its useful to be able to remove safety checks for speed. I have a C++ code where all data is in array objects. Bounds checking is a compile time option, and it makes the overall code 2X slower. I can do testing with bounds checking on, but once it gets to a supercomputer that needs to be removed. Address sanitizing by compilers is an even more effective tool for this, especially for C. Bounds checking is critical for security, but if you're only concerned with correct execution then a segfault is not much different from an exception.
In my parent comment are listed compile times from scratch, although there probably exist one or two files that would trigger similarly long rebuilds (included indirectly by most other files). If you change a random line of code, chances are the rebuild is quite limited. As others commented above, this actually scares people away from improving the core files.
I did the single file trick for the small library that I control, as a configure option. It definitely does help, 2X speedup in serial compile time typically. however, you lose the ability to compile in parallel, which with my hardware gives a 16X speedup, so for now parallel compiles are the winner.
As others have mentioned, I've resorted to brute force (parallel compile using 16 physical cores, good SSD, 32GB RAM). I have a 20KLOC library that I wrote myself (very few templates), that takes 20 sec to compile in parallel, meaning in serial it would take about 5 min. Then there is a giant 3MLOC system I work with (much templating), that takes 20 min to compile in parallel (consuming 15GB RAM), meaning in serial it would take 6 hours. One can also see in this 3MLOC system that it is the last few small files that take the longest to compile, because they include much of the rest of the system as template code in headers.
I've been doing this without thinking about it for a while and after reading it from a beginner's perspective It seems like quite a few steps. It is the "right" thing to do though, as far as I know.
Seems reasonable. An interesting bit for me was the CITATION file. The lack of citability for software is a recurring annoyance when writing up work that uses that software.
Muratori's compression-oriented programming and Acton's data-oriented design have really helped me in writing HPC code. Carmack's arguments make sense for apps that have a clear main function, although they're less applicable to libraries.
I consider these also "best practices", they are just better for performance than object-oriented practices applied to many small objects.
I'm 80% "software engineer" and 20% "researcher" and have to play both roles to write supercomputer code (I'm the minority, most peers are more researchers). These issues are important right now, as the govt is investing in software engineering due to recent hardware changes that require porting efforts. We recognize the pitfalls of naive software engineering applied to scientific code, and would like to do things more carefully. I don't think we should have to choose one or the other; with proper communication we can achieve a better balance.
Yea, I've seen compilers use lea for some integer math in C/C++, because it is handled by a different part of the CPU and so can happen in parallel with other integer math ops.
Both, and it agrees with your prediction. KNL's cores are each much faster than KNC's cores. A KNC core was over 10X slower than a mainstream CPU core, and a KNL core seems to only be about 4.5X slower (on my particular code). I also get linear OpenMP scaling from 1 to 64 threads on KNL, so the parallelism is all there.
As someone who has programmed both Phis and conventional x86 CPUs, I can confirm that the Phi is more sensitive to data traversal order and NUMA effects on which core accesses which memory. Also, the latest generation (Knights Landing) has much better performing cores than the previous generation.
One of the interesting things to keep in mind is that these new Xeon Phi cards can be used as standalone CPUs, not just as PCIe cards like a GPU. This is the "self-hosted mode" the article talks about. So one can now think about comparing a lone Xeon Phi doing both jobs versus a CPU plus an NVidia GPU.
Its essentially a matter of realistic benchmark acceptance. Right now machines are compared by how well they run this benchmark called LINPACK, which has been criticized for being non-representative of real science codes. As mentioned here [1], China's new system only achieved 0.3% of its peak flops on a slightly more realistic benchmark, HPCG.
It may be that mobile graphics gets by fine with FP32 or less, but I worry that if FP64 gets sidelined then none of the effort going into this hardware today will benefit applications that need real precision like science, weather prediction, GPS, etc.
Agreed. I used to debug large "integration tests". Now with unit testing, I'm only debugging a bit of new code atop a foundation that is regularly unit tested.
I agree, CUDA took a step in the right direction by allowing annotated C++ source to be compiled for the device. As an HPC developer, I'm using the Kokkos C++ library https://github.com/kokkos/kokkos to switch between CUDA, OpenMP, or Serial modes from a single source code.
I also work in HPC and have been doing a better job of this but still struggling in some areas. For example, the sin() and cos() implementations are different on some machines, and their only guarantee is being within some ulp of the right answer. So far haven't come up with a rounding idea that will make those values the same again.
This is worse for our codes because our mesh structure changes topology based on floating point comparisons, so error in values turns into different discrete structures.
Parallelism introduces more headaches, making some codes non-deterministic between runs on the same machine, although I've been able to fix this for the most part.
Its important to break down "determinism" into consistency across changes in something, whether it be hardware or time or partitioning.
Well, Go and Rust can do better threading on this problem than a not-really-optimized C code with OpenMP. Thats a start. Message passing has to be shown next, and then one can decide whether the installation and runtime of Go/Rust/Python/Julia on something like an IBM Blue Gene/Q with its custom compute node OS is easier than a link flag.
Another problem is the difficulty that editors have in finding reviewers (to work for free essentially). One solution could be to require authors to act as reviewers before they can submit their own work. For example, if a manuscript requires N favorable reviews to be accepted, then for each manuscript an author submits, they must provide N reviews of other manuscripts.
There is still something missing from the above in terms of "reviewing a review". The closest thing I can think of is comment threads where the post is the manuscript... There needs to be a way for low-quality reviews to be reported as such and invalidated. Right now all this is on the shoulders of the editor, who doesn't have time to do more than add up the recommendations of the reviewers.