That partially came as a surprise as well. In all honesty, I had never tried it before since most of the solvers I use have been developped a few decades ago and rely almost exclusively on MPI. So, even though I have a good understanding of the gist of multithreading, I’ve never really played seriously with it for HPC.
The almost linear speed-up as I increase from 1 to 8 threads sure is a very nice feature given that I haven’t had to change a single line of code. There is a small catch though. For the problem size considered, everything fits in the cache. If I go to 1024² instead, the speed-up ain’t as good because it no longer fit the cache size. Still pretty good as I get an overall of 5.5-6.1-ish speed-up. I wonder how easy it’d be to combine do concurrent and some cache-blocking tricks, or if it’s even worth it. Haven’t tried with ifx.
I don’t have numbers or evidence on hand, but I recall that in my previous experiments with do concurrent and the ifx compiler, that it really helped it to have the locality specifiers for the do concurrent.
This was probably a more complicated/larger data example than the Jacobi method above though.
Oh dear. Interesting how many completely miss the point of the post and/or are clearly biased by their ill-informed opinion of Fortran. It’s almost as though the post questioned some of their (computing) world views, and they react accordingly. But there are also lots of reasonable and constructive points raised.
Yep. I’m not sure to what extent I should engage with them. Some have valid points but I feel like very few of them have actually had to ever teach a class and are so focused on actual production codes.
Just don’t. The internet has become a resonance chamber for people to tell you that they can do the same taska thousand times better and faster, without actually describing how.
Scan the page for potential useful information or proofreading of your posts, but the rest is just people telling you they once did better with cuneiform alphabet and a clay tablet.
What @kimala said. As a climatologist who does some outreach, I have some experience with would-be experts popping up in comment sections (or even at live events). It’s not worth the time. The time is better spent talking to people who are willing to critically engage.
On a different note, I started building a website with quarto and will likely add a blog section too. It may be a better place to share some experiences/lessons learned there, like you did, than how I’ve been doing it so far – even if it leads to a “meltdown” on the same site, as Philipp put it. So … thanks for the inspiration.
@loiseaujc I looked also at the nocopy version. I would suggest a couple of changes:
It looks weird to do 2 iterations internally when explaining things. I would use a memory swap either with pointers or with move_alloc. This would keep a single call to the kernel per iteration.
Here l2_norm = norm2(u - v) you might be actually creating a temp variable to store u-v. If in this version you want to highlight memory efficiency usage, you might want to use a custom error_norm2( u , v ) and iterate internally.
Yep, we had a private discussion yestzrday night with @ivanpribec about ‘norm2’ among other things. As for the swap with ‘move_alloc’, that is indeed how it should be done in retrospect.
I think they have a partially valid point regarding plotting. Even in Fortran, however, there are good plotting libraries. For students it would be nice that the plotting tools are just contained in a single module that they can use in their programs (so they don’t have to spend time trying to install libraries and they can focus on coding and learning the algorithm).
Two good examples of plotting tools that are just “drop a module in your project” are:
Notes: they both use gnuplot. The module toolbox.f90 by Kindermann and Fehr has lots of other stuff too, but it’s nice in that it is self-contained. I typically call it as use toolbox, only: plot, execplot. (For numerical routines I prefer to use other programs)
Unfortunately, it looks like toolbox.f90 used code from Numerical Recipes. Given the very restrictive license for NR code (don’t know if thats changed recently), I tend to avoid anything with code from NR. I also tend to avoid GPL licensed code if I have a suitable alternative. If people want to release code under any GPL, thats O.K. with me. Some of the places I’ve worked in the past frowned on using any GPL licensed code within their proprietary code. The company lawyers saw it as a cuckoo’s egg that could take over you code. I doubt that would occur but I’m not a lawyer and I’ve learned you can’t argue with them because they think they are always right.
Well, it’s mostly true. If you include some code under GPL in your software, and if your software is distributed (commercially or not), you have to release your software under GPL.
The LGPL is less restrictive, as it is allows you to dynamically link against libraries containing LGPL code, without any requirement on the license of your own software.
Rightfully so; this shouldn’t happen. The parent project has to be GPL licensed too, then. That’s the condition for using GPL licenced code.
I do prefer MIT and comparable licences. However, regardless of what one thinks of GPL, the author’s wishes (in this case expressed through the GPL licence) have to be respected.
True, but the part of toolbox.f90 that does the plotting does not use any NR code and is quite independent from the rest. Would it be a good idea to write a module mod_plot based on toolbox.f90 that contains only the procedures plot and execplot? Which licence would apply?
