milancurcic on master
fix typo in readme Merge pull request #39 from let… (compare)
szaghi on master
Merge tag 'v0.1.0' into develop… Merge branch 'master' into deve… Merge branch 'master' into deve… and 1 more (compare)
szaghi on master
update submodule (compare)
szaghi on master
update submodules update travis config (compare)
szaghi on master
update submodules update travis config (compare)
@cmacmackin @rouson ,
Damian, you know how I think high of you, but I disagree (with respect): the world could be changed, but it currently does not. Intel and GNU have so many bugs about OOP that claiming full support of 2003 or even 2008 standard for that compilers is premature. Maybe the world will change the next year, but in 2017 I am really in trouble doing OOP in Fortran.
I really would like to know your new idea about functional programming, but I am skeptical: if defined operators have so big overhead as I shown above, how functional programming be suitable for HPC? In HASTY I tried to do a really useful, but not so complex, thing with CAF and it is stopped by compilers bugs...
Truth be told, I'm getting really frustrated with Fortran. If I didn't already have so much effort invested in my Fortran code base, I'd probably switch to another language. There are so many bugs related to object oriented programming in gfortran and ifort, and I'm getting sick of having to work around them. Memory management is a massive pain and not something I want to be thinking about as a programmer.
I am not so young as you, but my feeling is really the same: if I did not invested so hard in Fortran, I had likely used some other language two years ago. Probably, I'll try to invest more in Python: I see more and more HPC courses about "optimizing Python for number-crunching". Python performances are the worst I could imagine, but OOP is really a "new world" in Python.
Dear Damian, as always you are too much kind!
trust me that I feel your pain.
I know, but this does not alleviate to much the pain :smile:
I lasted through that process, got reasonably speedy responses from some compiler teams, dropped the compilers from vendors that were insufficiently responsive, and went to great lengths to become crafty about funding compiler development.
I'll try to follow your path, but in my reality searching for gfortran funding is a dream more than a challenge. In these day I'am evangelizing your idea and trying to make conscious my colleagues who are using gfortran for their research that it should be ethically and practically important to contribute to the GNU project with part of the research funding... but in Italy we do research with almost null fund.
Fortran has important features that no other language has and I care most about writing clean code. So much of what I saw in other languages seemed like a crime against humanity. The interpreted languages such as Python are factors of 2-3 slower at best and the compiled languages such as C and C++ lack even basic array manipulation facilities. And no language other than Fortran has a parallel programming model that works in distributed memory. And no other language has support for fault tolerance. To get distributed-memory parallelism and fault tolerance, you could go with MPI, but the MPI being written by almost every scientific programmer I've met will be slower, more complex, and less fault-tolerant than what a Fortran programmer can write with coarray Fortran.
I agree, this is why I selected Fortran, but currently this is all true if I do not use OOP, when OOP come in to play, all the pain highlighted by Chris arises. At the end, for the reasons you summarized and for the efforts I have already invested I'll never stop to use Fortran.
I hope you'll think more about how to contribute to gfortran, whether as a developer (almost all the developers are domain scientists -- few are computer scientists and none have any training in compiler development as far as I know) or through organizational funds...
If finding funds is a dream for me, the possibility that I can contribute to the development to gfortran is even more difficult: I am not up to the task. I know very little about C, but the big issue is that writing a compiler is an art and I am not an artist, just an oompa loompa.
I don't have any great new idea about functional programming in Fortran so you'll be disappointed. I have a set of strategies that were inspired by functional programming and that I frequently employ to make the intention of the code more clear and potentially more optimizable. One is the defined operators and your latest news is discouraging with regard to the performance (recall that I worried that Abstract Calculus might be an anti-pattern for just this reason but you previously reported that Abstract Calculus did not hurt performance based on your experience with FOODIE so I wonder what changed).
Sure, I remember your surprise, but that benchmark was really different from the one of yesterday. In FOODIE I compared Abstract Calculus with polymorphic allocatable functions (in which the ODE solver changes at runtime as well as all the operators results) with an identical test, but without abstract polymorphic operators and without changes of solvers at runtime. However, both version uses defined operators: the ACP has polymorphic allocatable (impure) operators, the other has static (pure) operators returning a type. The performances were identical between ACP and non abstract one, but this is in line with also the test I mad yesterday. What is really different is the comparison between defined operators vs intrinsic operators. For these reasons yesterday I updated our paper (soon a draft will sent to you) and I am planning to add a "performance mode* to FOODIE to allow users to select an operational mode:
%integrate_performanceversion of each solver, but it should be very easy.
For many reasons, you are likely to find more robust compilers for other languages, but you'll trade the compiler bugs for another set of problems in the form of low performance or ease with which you can shoot yourself in the foot or learning curve (it takes years to be a truly competent C++ programmer, for example, whereas the students in my classes become quite competent and even at the leading edge of Fortran programming in the span of one academic quarter. That's a really powerful statement.
I agree, this is why I select Fortran. When I start to play with CAF it takes few days to let me productive, while I am still not able to be really efficient (namely really asynchronous) with MPI after years. Fortran is still the most suitable choice for my math, but there is a lot of pain if we want to exploit OOP.
I think I'll book you soon for a talk, please speak slow :smile: (tomorrow I'll know Alessandro: I am really excited to see his exascale work)
P.S. I am very happy read about Filippone will be your co-author. Your new book promises at lot!
@rouson @cmacmackin ,
I played with operators vs non operators mode in FOODIE... it seems confirmed the overhead of defined operators, see this
stefano@thor(11:50 AM Sun May 07) on feature/add-performance-mode [!] ~/fortran/FOODIE 21 files, 2.5Mb → time ./build/tests/accuracy/oscillation/oscillation -s adams_bashforth_4 -Dt 0.05 --fast adams_bashforth_4 steps: 20000000 Dt: 0.050, f*Dt: 0.000, E(x): 0.464E-09, E(y): 0.469E-09 real 0m5.214s user 0m4.996s sys 0m0.216s stefano@thor(11:51 AM Sun May 07) on feature/add-performance-mode [!] ~/fortran/FOODIE 21 files, 2.5Mb → time ./build/tests/accuracy/oscillation/oscillation -s adams_bashforth_4 -Dt 0.05 adams_bashforth_4 steps: 20000000 Dt: 0.050, f*Dt: 0.000, E(x): 0.464E-09, E(y): 0.469E-09 real 0m10.535s user 0m10.320s sys 0m0.216s
I added the fast mode to only Adams Bashforth solver for now, but I 'll add similar mode for all solver tomorrow, it is really simple and to the end user the change is almost seamless.
See you soon, happy "domenica" :smile:
@nncarlson Dear Neil, thank you for sharing your thoughts, it is appreciated.
If the idea of
Fortran == gfortran was conveyed by me, my bad, it is not my thought neither I want to convey it. In my view a good program must be tested with as much as possible different compilers to obtain cross-verification: compilers are programs as others thus they could (and are) be bugged as others. To me
Fortran == iso-standard-xx.
My current feeling is, however, sad. Due to the sempiterna lack of funds in my research institute I have to strongly rely on free compilers; the access to commercial compilers is possible only when we buy core-hours at HPC facilities or when we obtain a grant at them (1 or 2 times for year, in mean). So, my view is strictly related to Intel and GNU: both have serious bugs about OOP, thus this blocks me.
I tested PGI, but it has too much limited support to F03/08 and no support at all to CAF; it was even very inefficient (in some scenario) if compared with Intel and GNU.
I used IBM XLF when I had a grant on PowerPC cluster, it is a great compiler, but it is not an option for x86 GNU/Linux.
Others said great things about Cray, but I did not never accessed to a CRAY cluster.
Finally there is NAG that seems great, but it is too expensive for me and Cineca (the HPC where I often obtain grants) does not provide it.
All said means, *I agree with you,
Fortran /= gfortran, but, for someone like me
Fortran ~= gfortran + ifort is a good approximation :cry:
program main use iso_c_binding type box class(*), pointer :: p => null() end type type(box), target :: pbox type(box), pointer :: qbox type(c_ptr) :: cp allocate(pbox%p, source=1) cp = c_loc(pbox) call c_f_pointer(cp, qbox) select type (q => qbox%p) type is (integer) print *, 'got integer', q class default print *, 'lost dynamic type' end select end program
c_locof a box wrapper around the polymorphic type pointer as the "context data". The function, whose pointer I passed as the call-back, turned this pointer back to a box around the polymorphic type pointer, and then invoked the type bound procedure that was the actual call-back.
Hi @/all, Just wanted to let you know that you can now try OpenCoarrays in the cloud via Binder. It is implemented as a kernel for Jupyter over at https://github.com/sourceryinstitute/jupyter-CAF-kernel. You can launch the binder (which also has python, Julia, and R kernels installed) using this button: .
Navigate to the index.ipynb file to run a demo. Or create a new notebook using the Coarray Fortran kernel and run your own experimental code, after seeing a few tutorial details in the index.ipynb file. If you just want to skip straight to that file use this link: https://bit.ly/TryCoarrays. To get to the full on binder instance, same as the button, go to https://bit.ly/CAF-Binder
>kernel-nameat the top of the cell. So you could create a notebook with python, fortran, julia, r etc. cells. Perhaps this could be useful for computing some data in one language (Fortran) and then plotting it and/or post processing it in another language (python or R)
I read this comment . It is very interesting for me, I would like to add some Autotools capabilities in FoBiS. I know about your long experience in the field whereas my knowledge of Autotools is near zero. Can you point me to some good references about the right way to identify compilers and their features? For example, I am now trying to implement in FoBiS a simple feature that should check is a compiler support the iso_10646 character kind; my idea is to that FoBiS create on the fly a simple test, invoke
selected_char_kind print the result and capture it in order to understand if the compiler support it. Is this the right way (similar to the autotools one)?
Thank you in advance.
My best regards.
I have just realized that it is possible to use gfortran 7.1.0 on Travis CI by simply selecting
dist: trusty as your container (it will use the container based on ubuntu 14.xy rather than 12.xy).
My best regards.
P.S. the following is extracted from one of my .travis.yml configuration files
language: generic sudo: false dist: trusty cache: apt: true pip: true directories: - $HOME/.cache/pip - $HOME/.local addons: apt: sources: - ubuntu-toolchain-r-test packages: - gfortran-7 - binutils ... install: - | if [[ ! -d "$HOME/.local/bin" ]]; then mkdir "$HOME/.local/bin" fi - export PATH="$HOME/.local/bin:$PATH" - export FC=/usr/bin/gfortran-7 - ln -fs /usr/bin/gfortran-7 "$HOME/.local/bin/gfortran" && gfortran --version - ls -l /usr/bin/gfortran-7 - ln -fs /usr/bin/gcov-7 "$HOME/.local/bin/gcov" && gcov --version ...