Wonderful, that probably means the compile time will be reduced to more reasonable durations. I very much appreciate the efforts of compiler writers and I cannot even begin to appreciate the complexity of compilers. I said it elsewhere: programming seems to be rather chaotic, in the sense that a slight variation to a computational problem may result in very different code (or behaviour). Who would have anticipated that compile-time computing requires so much resources.
Among the arrays in the program, the size of multiples increases the fastest. Asymptotically, it grows as M = N.log(N). (This array is not as compact as it could be; it contains duplicates such as 81, which equals 9 X 9 as well as 3 X 27.)
A compiler could sort this array before scanning, stripping out duplicates, and then scan the sorted array using binary search for each candidate. The complexity of these operations may be estimated as M.log(M), or N [log(N)]^2.
I have no plans whatsoever. And I do not think I am obliged to have. If you allow only potential developers to make comments, this whole forum should better be deleted. I am removing my posts now that you consider them so offending.
Is a compiler required to evaluate constant expressions at compile time? âSilly programsâ aside, if I have, for example,
iAny([SWP_FRAMECHANGED,SWP_NOMOVE,SWP_NOSIZE,SWP_NOZORDER])
(where the SWP_s are parameters) as an argument in a function call, can I expect the compiler to pass a constant evaluated at compile time or is it at liberty to generate code that evaluates a value at run time? I had a quick look at the standard but couldnât see anything that mentioned it.
The compiler is not required to do anything, except somehow produce the correct output. The code in the called subroutine might not be executed if the modified variables do not affect the output.
Surely a pipe dream of mine due to excessive look at bugs reported on online forums when it comes to various derived type options and Fortran processors!
But if GCC/gfortran front-end can miraculously/magically be âbootstrappedâ in modern Fortran, preferably 2018 standard revision as opposed to the current GCC C basis, chances are rather high many will make attempts âto be part of the solutionâ and invitations might not even be necessary. Or if the frontend were to be refactored to modern C++, say >=C++20, there might be takers.
If this growing Community on Fortran Discourse etc. over more than 18 months is not leading to more and more volunteers to the GCC/gfortran FOSS group, it might indicate either a reluctance to work with GCC C in conjunction with GCC workflow and/or the need for more tutorials and help manuals, etc. to lighten the ostensibly daunting nature of the task.
Too bad @msz59 that you removed your comment, it contained very useful timing information and other time complexity comments. Would you mind restoring it? I wanted to implement the missing features in LFortran and try it and compare it.
If you want, just remove the âsnail compilerâ comment. I personally donât think itâs offensive, but @kargl did not like it, so I think itâs fine to remove.
In this forum anyone is allowed to make comments, developers or not.
Speaking from personal experience, when you spend a lot of time contributing to open source, itâs easy to feel unappreciated when a lot of people post the negative things about a project that you spent years contributing to, and almost nobody says positive things, and only a few end up contributing and helping out. And developing a compiler such as GFortran is a monumental task, and even though I didnât contribute to GFortran myself, I suspect you hear less âgood commentsâ, and only hear when something does not work. But I think most people who didnât contribute to open source projects before, or not to compilers, donât realize that.
Long story short: letâs assume the best intentions of others, and letâs be appreciative of each others work.
I wish kargl did not get offended by what I am about to say.
I wanted to say to kargl, you are no doubt a very capable Fortran guy. In fact, many people here, perhaps all of us actually respect you very much. Without you the disclose will not be complete.
I am not qualified to comment on you (your Fortran expertise is way above me).
But perhaps you could try to think of it this way,
people are reporting bugs/issues (even if they did not fix it) simply because they are using gfortran and Fortran. In other words, it means you are doing a great job keeping people using gfortran and Fortran for so many years, right? That only means that, believe me, let me just say this, you did a HUGE job So the bottom line is, you can be very proud of yourself everyday, and you do not have to take anything with regard to bugs/issues personal.
If someday no one discuss bugs anymore, perhaps that will really mean something is wrong.
I have been using gfortran since it first appeared back in 2003 or 2004, earlier using g77 or, even earlier, f2c. I think gfortran is a great software and I appreciate everybody involved in this project. The idea that Iâd want to take a jab at gfortran community because it is reletively slow at compiling some geek code is so absurd that I wanted to cut this discussion, introduced by unfortunate wording of mine (actually borrowed from the opposition of e-mail vs. snail-mail which I always considered harmless and funny).
I do not think it was of any considerable value, the code by @mecej4 is available, so everybody can easily repeat my test on his/her own machine. Still, I can put it here once again (done on an Intel E5-2650 v3, 256G RAM RockyLinux 8.5 machine):
BTW, To my great surprise (and as a warning!) I found that everybody has access to the full history of edits of any post, not only theirs own. That is really weird.
There is a recent thread 79 languages⌠regarding a benchmark of several languages in getting prime numbers less than 1 million. For this who do not follow it, there is a leading group of three (Lisp, C++, D) which outperform the remaining competitors by several orders of magnitude (!).
A comment by @Jweber puts those strange results into context of this topic by noting that the C++ winner uses constant expressions extensively, so there was not much to do at run time. I wonder how @Arjen-@mecej4 code would do in that benchmark but to check that, one would have to use nagfor, which, according to what we already know, is the only compiler possibly able to make it with N=10**6. Maybe @themos?
The bad news is that the C++ constexpr code (for N=10**6) compiles with GNU g++-11 in 7 seconds only.
Yes that would be an intersting tech-demo. I was not even aware that such possibilities exist in the Fortran language (althoung i assume it is not neccessarily a very good idea to use for large data sets in production codeâŚ).
Just two remarks concerning the competition.
a) These results where the compiler does the work are somewhat outside the competiton (I will go a bit more into detail in the 79 languages thread).
b) The results on the web page are not reported values but computed on a small set of systems via a script that in turn obtains its results from Docker images with the compilers/interpreters.
Because of this, free (as in beer and speech) compilers are a requirement and I guess the NAG compiler can not be integrated in the system.
But I do not really think that this is a problem. It is somehow âcheatingâ anyhow
@themos, what do you think the default behavior should be: currently nagfor will effectively âhangâ for very large N, correct? While GFortran refuses to compile N beyond 64K, you have to pass in a special compiler flag.
What would I like as a user? I donât know. It is nice knowing that the compiler will finish compiling any code (one way or the other) in a reasonable time. If the code is millions of lines, then it might take a while, but I think that is understandable. The example in this thread is just a few lines, but it can take arbitrarily long to compile. At the same time, in practice, this pretty much never happens, and when it happens (such as in this thread), we know exactly what we are doing, so it doesnât seem a problem that it will take a while to compile.
)
