Below there are my thoughts related to the discussion at http://www.fortranstatement.com/. Three e-mails that follow are 1) From: Evgenii Rudnyi Subject: Let Fortran die naturally 2) From: Van.Snyder@jpl.nasa.gov Subject: Re: Let Fortran die naturally 3) From: Evgenii Rudnyi Subject: Re: Let Fortran die naturally ******************************************************** From: Evgenii Rudnyi Date: Fr Mär 12, 2004 4:13:06 Uhr Europe/Berlin To: petition@fortranstatement.com, j3_petition@fortranstatement.com Cc: Van.Snyder@jpl.nasa.gov Subject: Let Fortran die naturally Content-Type: text/plain; charset=US-ASCII; format=flowed Let me introduce myself. I am Evgenii Rudnyi, age of 45, working in science and programming since 1980. I have started with FORTRAN-IV, learned Fortran-77 in 1991, and switched to C++ since 1993. During my life I have used other languages as well as assembler, not speaking of numerous scripting languages. I have not signed the anti-Fortran petition and I would like to explain why. I agree with the statements 4 to 7. Yet, I do not like the way the petition is designed for. To ban something is a typical way to solve a scientific question in the former Soviet Union. For me as a Russian, it is a bit strange to see that the USA colleagues have chosen such a way. The programming language is alive if there is a user community. Whether there is a standard or not, I think, does not matter much. Well, the standard is certainly a plus but probably not more. I am afraid that to ban a programming language is about the same as to ban a particular operating system. Also, I disagree with some petition statements. I believe that the statements 2 and 3 should be kept out of discussion. Whether people can earn money with Fortran or not, this is their business. Whether there is a free implementation or not, it is also irrelevant. We should not discuss issues on how to earn and spend money. I do not understand the statement 8 and I think that the statements 1 and 10 are inappropriate. Programming is always difficult and it is for Real Programmers [1] only. If someone would like to have an easy life, she should relay on particular commercial software with GUI to solve a particular problem. If we speak of more general things, one can try Mathematica or Matlab, but I would not say that these languages are easy either. Well, in this case it is easy to start but if someone would like to solve a real problem, things become much more complicated. I use C++ and I should say that C++ is a monstrous language. I am pretty sure that any Fortran cannot beat C++ if to speak complexity. Why I use C++? Probably, because I like it. It allows us to combine quite different programming paradigms: procedural programming, object-oriented programming, generic programming and some rudimentary functional programming. No doubts, this comes for a cost. I have not heard of any other programming language of the same complexity. A Real Programmer nowadays without doubts would have chosen C++ as there is absolutely no limit for the programmer creativity and a possibility to mix everything up by introducing subtle changes. I am sure that a Real Programmer from [1] would love template programming, as no normal person is able to comprehend the error messages generated by the template usage. Whether it is your fault, or it is template programmer's fault, or a compiler creator screwed things up. Finally, the statement 9 is contradictory. The more flexible the language, the more difficult is the optimization. This should be clear. This concerns any language; it is not Fortran's fault. Please, do not misunderstand me. The text above is not pro-Fortran. I just believe that it is better to remove statements 1 to 3 and 8 to 10 out of the petition as they are not Fortran specific. Now I would like to join the real anti-Fortran part, that is, the statements 4 to 7. The only idea to develop a newer Fortran that I have heard of was to have the backward compatibility. Yet, there is no problem to call the old Fortran code from C, C++ as well as other languages. This is what I do quite often in my own practice. Why I should learn new Fortran in order to use the old good Fortran? I have never understood this. Another issue is performance. A Fortran community is probably unique in respect that it says all the time that Fortran produces the fastest code. I find this a bit strange. Could you imagine that when a processor sees that the code has been compiled by a C++ compiler it turns down the processor clock by 10 or more times? Could you imagine that the creators of C++ compilers are damn stupid and they do not care about performance? Let my give you an example. I have never heard about Web-servers written in Fortran. Does this mean that the performance of Web-servers does not matter? Definitely, not. If someone can increase the performance of a Web-server by ten times for the same hardware, she would make a lot of money. So, why people do not use Fortran? Can someone explain it? It happens that when the Fortran community discusses performance, it means only the linear algebra with dense matrices. This is quite an important problem but this is just a special case, even in scientific computing. I think that it is inappropriate to say that the Fortran produces the fastest code without saying that this may be true for rather limited applications. Let me finish by arguing that C++ is not that bad choice for scientific computing. It is complex, yes! But it is learnable for those who would like to learn and who "are not afraid of being impersonal" (see [1]). I have developed two reasonably big codes in C++ to support my research and I will try to justify briefly the use of C++ in both cases. 1) TDLIB, a library to support computational thermodynamics http://www.chem.msu.su/~rudnyi/tdlib/ The solution to a given scientific problem is based on the use of the run-time polymorphism (virtual functions in C++). This feature has an overhead. This is true. It means that a virtual function call is a bit more expensive than a normal function call. Whether this is a bit or a lot, it depends on a personal viewpoint. But what is the alternative? Nothing comes for free. I can just argue that this feature is very important for this application. If someone knows another language that can implement such a feature considerably faster than C++, please let me know. 2) mor4ansys, a tool for model order reduction of ANSYS finite element models http://www.imtek.uni-freiburg.de/simulation/mor4ansys/ In this case, probably, the use of C++ is more a habit than the necessity. Well, one of my goals is to be able to change sparse solvers at the run-time. It is convenient, isn't it? So, I have used the run-time polymorphism again. By the way, if someone thinks that he/she can achieve the better performance, try our benchmark collection for model reduction at http://www.imtek.uni-freiburg.de/simulation/benchmark/ that we have launched recently. By the way, if to speak of sparse matrix linear algebra, I doubt that Fortran has advantages in this area. This is not the case for which Fortran has been designed for. But if the Fortran community develops the fastest sparse solvers by means of the newest Fortran, I will be gladly among the first to learn it. I am very pragmatic. After all, programming is not about a programming language but rather about ideas. Best wishes, Evgenii Rudnyi [1] Real Programmer Does Not Use Pascal, DATAMATION, 1983, v. 29, N 7, p. 263-265. http://internet.ls-la.net/folklore/realprogrammers.html ************************************************************ From: Van.Snyder@jpl.nasa.gov Date: Fr Mär 12, 2004 9:22:16 Uhr Europe/Berlin To: petition@fortranstatement.com, j3_petition@fortranstatement.com Cc: Evgenii Rudnyi Subject: Re: Let Fortran die naturally Reply-To: Van.Snyder@jpl.nasa.gov Content-Type: text/plain X-Spam-Status: No, hits=0.3 required=5.0 tests=NO_REAL_NAME autolearn=no version=2.61 Evgenii Rudnyi wrote: >... Could you imagine that when a >processor sees that the code has been compiled by a C++ compiler it >turns down the processor clock by 10 or more times? Could you imagine >that the creators of C++ compilers are damn stupid and they do not care >about performance? ... Of course not. The performance differences arise from differences in the semantics of C and Fortran, primarily in the semantics of pointers and the need for their ubiquitous use in C. Fortran doesn't allow arithmetic on pointers, and requires that an object have the "target" attribute in order for it to be a pointer's target. Fortran doesn't require one to use pointers for "output" procedure arguments. Fortran doesn't consider arrays and pointers to be the same thing "under the covers." Fortran functions can return composite objects instead of pointers to them. Fortran pointer semantics allow optimizers to do a better job of alias analysis, and therefore a better job of register optimization. Fortran also provides "allocatable" and "automatic" objects, which carry much of the burden carried by pointers in C and C++, but have semantics that are very restricted compared to pointer semantics, which in turn give more aid to optimization. Pointer optimization in C has been shown to be NP hard, so it's unfortunate (for optimizers) that other features of the design of C require the use of pointers so ubiquitously. The amazing thing is that the optimization heuristics that some very clever people have invented to attack this hopeless problem in C and C++ optimizers work as well as they do. I've lost the report "Pointer optimization in C is NP hard," which (if I remember correctly) was a Bell System Technical Report. I thought Barbara Ryder wrote it, but she denied it. There is active work in this area. See http://www.cs.wisc.edu/wpis/papers/toplas97a.ps and the references therein. The 1999 standard for C introduced a "restricted" attribute that offers some help for alias analysis, but the problems for optimizers that are caused by arithmetic on pointers remain. These will never go away; pointer arithmetic is fundamental to the C idiom. >Let me finish by arguing that C++ is not that bad choice for scientific >computing. It is complex, yes! But it is learnable.... For me, C++ is a non-starter for anything important. I studied Leslie Hatton's reports carefully and concluded that I just can't risk the danger of failure, or the expense. Hatton finds that C++ programs on average have a density of statically-detectable defects roughly 2-3 times the density for equivalent programs in C, Fortran or Ada, and a cost-per- defect to repair that is also roughly 2-3 times the cost for equivalent programs in C, Fortran or Ada, giving roughly six times the lifetime cost for C++ programs. I taught C++ for two years. From watching the mistakes the students made in their laboratory exercises, even after being explicitly warned about them, I became convinced that Hatton was right. See http://www.leshatton.org/index_CS.html. Stephen Zeigler found (from measurements, not hand waving) that his C programs are more expensive than his equivalent Ada programs. See http://www.adaic.com/whyada/ada-vs-c/cada_art.html. >Yet, there is no problem to call the >old Fortran code from C, C++ as well as other languages. This is what I >do quite often in my own practice. Actually, there are significant problems if you want your codes to be portable. Look at Burkhard Burow's cfortran macros (see http://www-zeus.desy.de/~burow/cfortran/) if you want a little taste of the complication. The existence of these problems is the reason the 1995 Ada standard, and the 2003 Fortran standard, have sections on interoperability. -- Van Snyder | What fraction of Americans believe Van.Snyder@jpl.nasa.gov | Wrestling is real and NASA is fake? Any alleged opinions are my own and have not been approved or disapproved by JPL, CalTech, NASA, Sean O'Keefe, George Bush, the Pope, or anybody else. ************************************************************ From: Evgenii Rudnyi Date: Do Mär 18, 2004 5:47:28 Uhr Europe/Berlin To: Van.Snyder@jpl.nasa.gov Subject: Re: Let Fortran die naturally Content-Type: text/plain; charset=US-ASCII; format=flowed Dear Dr. van Snyder, Thank you for your interesting email. I am not against Fortran, Ada and any other programming language. I would like just to say that you have not convinced me and explain why. This might help you to convince others in the future. I am a practitioner. My goal is to solve my problems. At the same time, I try to follow the development of programming languages in order to make my bet on a particular language more rational. I am aware about the problem with the pointer optimization. I have followed number of discussion on the Net about this. Well, the main question is what kind of performance I gain: is it 10-20%, 1-2 times or 10 times. My observations that follow tell me that this is not a lot. I do not insist that I am right though. Please correct me if you see that I am wrong. So let us compare performance of C/C++ and Fortran in practice, not in theory. You did not want to discuss the question why people do not use Fortran to write Web-servers and like. This is fine. My personal explanation is that the Fortran community does not want to earn real money. So, let us consider the linear algebra applications. Let us start with dense matrices. Any practitioner knows that in order to achieve good performance one has to use the optimized BLAS. BLAS written in Fortran is just slow. The pointer optimization does not help at all in this respect. However, any practitioner knows that there is ATLAS which generates the optimized BLAS automatically. And ATLAS is written in C. Please explain me this fact. Why people can create the optimized BLAS in C while they can not do in Fortran? What I do not understand? Now let us go to the sparse matrices. This is my current area of research: what is the best sparse library. So far I have tried the two direct solvers, TAUCS and UMFPACK. Both are written in C, however their performance is very good. Well, I am working with ANSYS. Its computational kernel, as far as I understand is written in Fortran. Yet, the libraries mentioned are not slower than the ANSYS sparse direct solver, they are even faster. Again, from the viewpoint of a practitioner, I do not see the difference in performance. I would appreciate any reference or link to a sparse solver that is written in Fortran and considerably faster than others. So, this is what I see. I am ready to learn new ideas on how to program better and produce the fastest code. But ... Best wishes, Evgenii Rudnyi