http://permalink.gmane.org/gmane.comp.gcc.fortran hourly 1 1901-01-01T00:00+00:00 http://gmane.org/img/gmane-25t.png http://gmane.org http://permalink.gmane.org/gmane.comp.gcc.fortran/38860 <pre> It's worse than that :-( Many systems have OS calls that execute within the caller's context, but with privilege and other variations, and others that switch context. However, exactly when and how CPU time is accumulated is very variable and often unreliable. Another very common feature is that interrupts are counted in the context of the process/thread that was interrupted, and not the one on behalf of which the interrupt was running. In particular, that makes thread-level CPU measurements very unreliable. Even worse are the (few) systems where OS calls and similar primitives (think MPI-like message passing) can spin off threads that are unknown to the program. How they accumulate CPU time and which context they assign it to is anyone's guess. Add that to the fact that the POSIX timing model is broken by design. I haven't investigated to see how many systems provide the symbols and calls, and then ignore the options entirely or do something completely unlike POSIX's implications. One can't say 'spe</pre> N.M. Maclaren 2012-05-25T09:20:22 http://permalink.gmane.org/gmane.comp.gcc.fortran/38859 <pre>于 2012/5/25 1:48, Ian Lance Taylor 写道: Thanks. I will check it. </pre> xunxun 2012-05-24T22:50:57 http://permalink.gmane.org/gmane.comp.gcc.fortran/38858 <pre> Typically the CPU time is defined such that it accumulates only when the process is in a runnable state. Which excludes being scheduled out due to some other process(es) getting their share of the CPU, but also e.g. being blocked waiting on IO or sleeping. E.g. $ time sleep 2 real 0m2.004s user 0m0.010s sys 0m0.000s $ time ls -lR src &gt; /dev/null ^C real 0m25.361s user 0m3.150s sys 0m8.460s In both the above cases real &gt;= user+sys. This can happen also on an embedded OS with only a single process. Sleeping, in particular, is common for embeded control applications. Consider e.g. an application that controls some device. It does its thing (read inputs, calculate stuff, generate commands for the device), then sleeps for some (short) time, and then again does its thing, sleeps, and so on. </pre> Janne Blomqvist 2012-05-24T21:08:31 http://permalink.gmane.org/gmane.comp.gcc.fortran/38857 <pre> I concur for a multi-processes OS not, but for a some embedded OS which only has a single process. For those, the CPU time since start up matches the execution time of the program (if one neglects the kernel startup time). Tobias </pre> Tobias Burnus 2012-05-24T20:51:22 http://permalink.gmane.org/gmane.comp.gcc.fortran/38856 <pre> While not ideal, I think the upcoming Technical Specification (TS) 29113 will also help a bit; using TYPE(*) and dimension(*)/dimension(..) one can specify explicit interfaces without needing to create an infinite amount of them. (One problem is that one cannot simply create a descriptorless "void *buffer": "type(*), dimension(*)" doesn't allow for scalars, dimension(..) but it requires that the procedure accepts a descriptor; one could use a generic procedure, but then one needs one specific procedure per rank.) It does not solve all type checking issues, but at least some of them. gfortran currently only supports TYPE(*) and not yet dimension(..). Tobias </pre> Tobias Burnus 2012-05-24T20:46:32 http://permalink.gmane.org/gmane.comp.gcc.fortran/38854 <pre> Well, some people did - but a hell of a lot didn't! More seriously, there are perfectly good mechanisms for dealing with KIND in MPI that eliminates any need for #if: MPI_Type_create_f90_real and all that. There are issues that it doesn't resolve (including the one you mention below), but #if doesn't help with them either. Well, yes, but coarrays aren't that. They DO get the type checking right, but at the cost of introducing potential, almost undetectable, race conditions where most MPI code can be proved not to have them. I don't consider that a gain. But that's off-topic for here. Harking back to gfortran. One of the things on my list is whether I could extend it enough (in an interoperability-style mode) enough to resolve this issue, and introduce the ability to have type-checked MPI. I could parse the (trivial) extra syntax with trivial hacks, but got bogged down trying to understand how the code generation works, and didn't have time to reverse engineer it :-( But it could be done. Regards</pre> N.M. Maclaren 2012-05-24T18:37:27 http://permalink.gmane.org/gmane.comp.gcc.fortran/38853 <pre>Been there, done that.... Except that no such replacement has been successful so far. From what little I have seen, I like coarrays, but they have not yet proven themselves in the field. Salvatore </pre> Salvatore Filippone 2012-05-24T18:27:26 http://permalink.gmane.org/gmane.comp.gcc.fortran/38852 <pre> &gt; Also to be blunt, many scientists In my time (the mid-70s) people from the Mathematics Department didn't teach Fortran because Pascal was such a great way to teach programming. I now hear (close to 40 years later) from students working for us that Fortran *still* isn't taught (there probably is another language used as excuse "for teaching programming"). You were assumed to "pick up Fortran" during your graduate days in the mid-70s, and apparently, that still is the case. </pre> Toon Moene 2012-05-24T18:15:05 http://permalink.gmane.org/gmane.comp.gcc.fortran/38851 <pre> Why do you think we wanted coarrays in the 2008 Standard ? I've been working with MPI since the mid-90's - surely by now it should be replaced by something compilers understand beyond "well, I have an external procedure here - hope the programmer got its arguments correct" .... </pre> Toon Moene 2012-05-24T18:10:49 http://permalink.gmane.org/gmane.comp.gcc.fortran/38849 <pre>Dear list, I know we can use gcc -dumpspecs &gt; specs copy specs to default specs location, and also can change the specs value for example, change *cc1: %(cc1_cpu) to *cc1: %(cc1_cpu) -march=native this can change gcc default option. But now I only want to change default gfortran specs option. I try to use *f951: -march=native or *f951_options: -march=native These are all invalid. And I see that : gcc -dumpspecs &gt; specs1 g++ -dumpspecs &gt; specs2 gfortran -dumpspecs &gt; specs3 specs1, specs2 and specs3's content are all the same... Is it normal? But how to set default gfortran specs option? Thanks. </pre> xunxun 2012-05-24T16:39:12 http://permalink.gmane.org/gmane.comp.gcc.fortran/38847 <pre>This patch fixes an ordering problem with deferred string lengths. For str = str2(:nn) where "nn" is a something a tad more complicated than a local variable (e.g. a non-VALUE dummy argument), the result was wrong: the temporary variable with the string length was used before it was set. The attached patch fixes the issue. However, I wonder whether the block should/could always be added. Build and regtested on x86-64-linux. OK for the trunk? * * * Remaining deferred-length issues: - PR 47674: a = a(:n); reallocation messed up; "realloc" should be enough as the length has to be always &lt;= previous length [memory content is then guaranteed to remain untouched]. Alternatively, a temporary is required - PR 49954: String length is wrong for "array(:)(1:1)": It's wrongly the one of "array" instead of 1; there might be some extra issues. - PR 50221: Some odd array assignment issues. - PR 51976: Deferred-string components. Needs a hidden component for the string length. Tricky: expr-&gt;ts.u.cl-&gt;back</pre> Tobias Burnus 2012-05-24T14:33:27 http://permalink.gmane.org/gmane.comp.gcc.fortran/38846 <pre> I'd like to note that it's by no means just a problem with Fortran codes. I have seen horrific C codes that clumsily implement a rudimentary OOP by means of complex ifdefs and lots of duplicated code. Most scientists have never learned even basic software engineering and, according to one survey I saw reported in an article in Nature, only about a third even think they need to. Also to be blunt, many scientists still regard programming as a "lesser" activity that any idiot can do, so they assume they'll just pick it up as they go. Excessive use of autoconf to set basic model parameters (as opposed to finding system libraries) is also bad, and is hard on users since it's easy to forget to set options to configure. Cmake is actually better for this in a lot of ways IMHO, but it's not as widely used or as familiar as configure. Modules by themselves can go quite a way in this regard, and I think are often the best first step in re-engineering. Plus any F95 compiler will support them. </pre> Katherine Holcomb 2012-05-24T12:44:54 http://permalink.gmane.org/gmane.comp.gcc.fortran/38845 <pre>Well, no disagreement here. Object-oriented techniques and design do not always map onto runtime polymorphism. and/or facilities not universally implemented by all compilers.... One annoying case is when you start mixing up parameters for KINDs in various data types with MPI calls.... Cheers Salvatore </pre> Salvatore Filippone 2012-05-24T11:43:47 http://permalink.gmane.org/gmane.comp.gcc.fortran/38844 <pre> I've had no problems with gfortran/g++ 4.6 built from source on RHEL6.2. 4.7 and 4.8 aren't compatible with the current version of Intel C++ compiler icpc but are good otherwise. There are pre-built versions of gfortran on gfortran wiki, but the companion g++ doesn't work on Red Hat. It is difficult to build gfortran for RHEL6.2 using the Red Hat compiler on one of my boxes where the BIOS is incompatible with standard RHEL6.2 kernel (but OK with 6.0). The problem can be overcome by building gcc on an installation which doesn't have that issue, and copying it over. ifort and its predecessors always permitted those calls to internal procedures (but warned about it if you asked). There may be other compilers, besides gfortran 4.2, which supported that extension to f95 which has been included in f2008. </pre> Tim Prince 2012-05-24T10:33:32 http://permalink.gmane.org/gmane.comp.gcc.fortran/38843 <pre> I disagree with the first sentence, though it is unquestionably one of the better ways to resolve this issue - what I disagree is with the implication that it is THE best one (i.e. it may or may not be). I fully agree with the second sentence. Sorry, but to be blunt, the root fault with all such programs is that they are badly engineered. As soon as a program uses a preprocessor or (yuck) autoconfigure for more than one or two small, well-encapsulated modules that deal with intrinsically system-dependent facilities or bypass implementation bugs, it is both both poorly structured and highly non-portable. Modern Fortran (and gfortran, for quite a long time) provide quite enough tools that almost all of the code should be entirely free of such abominations. I agree that the OP would be well advised to look at courses that describe how to do this in modern Fortran, especially modules, object- orientation and just possibly polymorphism. THOSE are the right approaches to resolving this issue properly. Rega</pre> N.M. Maclaren 2012-05-24T10:17:47 http://permalink.gmane.org/gmane.comp.gcc.fortran/38842 <pre> This example really cries out for object-oriented techniques. And, given the likely amount of work performed in VDIFF, the performance penalty at runtime should be neglibible. More on this in the courses on OOP in Fortran that Damian Rouson and myself are giving at various institutions.... Salvatore </pre> Salvatore Filippone 2012-05-24T09:14:50 http://permalink.gmane.org/gmane.comp.gcc.fortran/38841 <pre> I am a bit surprised, because that isn't allowed until Fortran 2008, which was standardised only last year - I wonder which compiler AFNL was developed under. From the release notes, gfortran 4.6 will compile that, so you could try upgrading. Try NAG. Regards, Nick Maclaren. </pre> N.M. Maclaren 2012-05-24T08:52:47 http://permalink.gmane.org/gmane.comp.gcc.fortran/38840 <pre>Hi Tom, this is an interesting problem and I think the solution depends on what resources you have available (as always) and how willing you are to use new compiler features. Without knowing the details I would suggest to explore the following options. On Wed, 2012-05-23 at 19:09 -0400, Tom Roche wrote: building scientific codes tends to be very complicated, many projects use their own build system, include external libraries, etc. I would use standard build tools like the GNU autotools, or cmake to build the project. users are somewhat used to the usual procedure of configure &amp;&amp; make &amp;&amp; make install looking at your examples the first thing that sprang to my mind is using object oriented approaches, where your base model is a base class and the various IMs derived classes. You could then either switch at runtime or compile time which model instance you are going to use. I suspect you could encapsulate all the extra arguments within your objects. I think this is actually a very good example where object </pre> Magnus Hagdorn 2012-05-24T08:22:16 http://permalink.gmane.org/gmane.comp.gcc.fortran/38839 <pre> Here's where FreeBSD really shines with its ports system. You can build any or all of: gcc42 gcc44 gcc45 gcc46 gcc47 gcc48 llvm-gcc4 Or, if you are on i386 or amd64, you can install a pre-build package for all of the above. http://www.freebsd.org/cgi/ports.cgi?query=gcc&amp;stype=name&amp;sektion=lang </pre> Anton Shterenlikht 2012-05-24T08:02:49 http://permalink.gmane.org/gmane.comp.gcc.fortran/38838 <pre>Thank you, that is exactly what I wanted to know. I guess my best answer is probably to grab some fedora fortran packages and see if I can rebuild them on RHEL6.2. I suspect that road will lead me to dependency hell but it's worth a shot. (I had already enabled the testing repos to see if they had anything newer.) Failing that I can start again and give her a full Fedora 18 VM I guess. Thank you for such a detailed answer. You've given me the answer I need. 3 options. 1. Downgrade to 4.2 2. Upgrade to 4.6+ 3. Fix the library. I think at my current level of knowledge I should play to my strengths and go with 1 or 2. Thanks again for such detailed answers. I wasn't expecting it and it shows why GNU has gone so far. On 24/05/2012 2:38 PM, Tobias Burnus wrote: </pre> Franki Hauptle 2012-05-24T07:20:48 http://permalink.gmane.org/gmane.comp.gcc.fortran/38837 <pre>Hi Frank, Tobias Burnus wrote: Just for completeness: There is, of course, another solution: Changing the internal procedure to a noninternal one. I do not know the source code, but might be simple but it can also be difficult. It is relatively simple if the internal procedure doesn't use any local variable or argument from its host procedure. However, I assume that you don't want to change the library code - especially as you do not have Fortran experience. (It is unfortunate that some codes make heavily use of vendor extensions, which reduces the compatibility. It would really help if programmers used flags like -std=f2003 and multiple compilers; that not make code more portable but can also find true bugs.) Tobias </pre> Tobias Burnus 2012-05-24T06:48:48 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.comp.gcc.fortran